Why You Need Enterprise Architecture with Your ERP

by Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice

I've been working with many companies lately whose IT systems are dominated by enterprise resource planning (ERP). This is not surprising, since an ERP system is an essential part of most IT portfolios today. In many organizations, the ERP system contributes as much as 70% of the total IT capability. So one question that many companies are struggling with is: why is it still important to have enterprise architecture (EA)? Didn't you buy an architecture with the ERP?

First, let's consider the typical implementation of an ERP. The war stories of complex, lengthy, and expensive implementation are numerous. The major challenges are in the customization of the ERP system to fit your particular requirements. This usually involves integration with existing systems, which is usually done at the data level with ETL technologies. Often, these efforts result in a system that is difficult to enhance or modify and expensive to maintain. In addition, the architecture (which is rarely designed for your company) is totally ERP-focused and, among other things, is designed to lock you into the product and implementation. Is this really how you want your overall IT capabilities to be designed and implemented?

Second, consider that the ERP provides the commodity IT capabilities that your company needs for typical operations but does not provide competitive advantage. What about the other 30%-50% of your applications that are needed to supplement and integrate with the ERP system? Are they just an afterthought in your IT budget, or are they important to your operations and competitive advantage? How should your IT be designed to combine the benefits of commodity ERP with the other critical aspects that provide market differentiation?

Enterprise architecture considers your entire set of IT requirements, now and in the future, and designs a strategy that meets those needs as well as a roadmap for accomplishing them. Of course, it includes ERP, but it isn't limited to or dominated by the ERP. Instead, EA designs a flexible approach that meets all of your requirements, integrates all of your IT systems together, and includes and leverages the ERP.

Best practices today for ERP implementations include a modular, service-oriented approach to extending and customizing processes. Rather than extensive modifications to the ERP modules, the basic capabilities are extended with external services, and everything is tied together with business processes that compose the basic ERP functions and extensions together to meet the specific requirements of your enterprise.

Integration takes a similar approach and extends beyond the traditional data focus. Existing system functions and data are exposed as well-designed integration services, which are then composed with ERP capabilities at the process level. In addition, these approaches are consistent with the direction being pursued by the major ERP vendors, which are spending billions of dollars to remodularize and service-enable their product suites.

So the enterprise architecture has to describe what all of the important systems in your enterprise are, including ERP. At the enterprise level, it needs to describe how all of these systems fit together, both at a business level to meet overall enterprise goals and objectives and at a technology level. It needs to incorporate all your different channels, partners, providers, and so on. In addition, it needs to build in agility and flexibility to meet your particular environment and market. The difference between having an architecture and not is simple: do you want to be limited by your ERP or enabled by it? It's up to you.

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at mrosen@cutter.com.

-- Mike Rosen, Director, Enterprise Architecture Practice