Road to ESA The EPI Model Part 1
We are promoting SAP ESA for almost a year now and therefore we use our 5-layer EPI (Enterprise Process Integration) model. Our model is very successfully and big SAP customers in the Netherlands adopt it. They like it because it is useable for IT managers to create a picture about the technical impact of ESA. But it is also useable for business process owners (BPO) to give their processes the right place within the ESA concept. It can also help us to collect information about the different layers, the stage of implementation and the different products on each layer. We also use the model to explain SAP approach of NetWeaver, BPP, CAF and all other initiatives. From our model is it easy to make a step towards an Enterprise Service Bus to give the whole of ESA the right place within an organization. The advantage of the model is that is generic and can be used to explain the possibilities. In part one of this web log we will explain the model. In the second part we will give some examples how you can use it. In part three we will explain the EPI Model Approach.
The EPI Model
The evolution of IT, bases of the model
In our opinion, for the first stage we use only a generic integrated persistence/presentation layer. We wrote information on paper.
In the second stage, we store information in a database using a separated presentation layer and we create simple reports which we print on paper.
In the third stage, we add business logic. First only business logic was focused on one business process or one organizational department. Later on in this stage we make use of centralized integrated business logic (ERP). We were able to make a registration of all our data into a back office application. Registration is done when the process is completed. Because of functionality gaps in ERP systems, the need of decentralized access to centralized business processes (SRM, CRM, SCM), the ROI of legacy systems and innovation (internet) most companies use a best of breed approach and get different applications for their back office layer. At this point the applications are the owners of the business process.
We needed a new layer to consolidate the data between the different applications. In this fourth stage, we introduce a new Exchange layer on top of the different Back office applications. We consolidated the access from the presentation layer. We introduce a portal. For the consolidation reports/analytics we added new back office applications like Business Warehouse. SAP has implemented this stage with SAP NetWeaver.
Now we have consolidated the data we need to add more flexibility to our business processes. Most of our business processes are locked into the back office layer. This is no problem for registration business process of that application. Just like a database can store data of a particular business process, an application can store a part of the total business process but not all of the business process. In the past, we implemented additional needs of a business process into the application at the back office layer or we used the exchange layer to do this. Also we didnt implement the whole business process because this could not be done or was too expensive. For this we needed a new layer, where the overall business process is leading and not one of the back office applications. This new layer we called the composite process layer. In this layer, we focus on the total business process. We can add new and change existing process steps. Not only the registration business process, but also facilitate collecting process steps (using SAP Interactive Forms) and manual steps can be designed within this layer. Every business process designed within the composite process layer will be rid of the gaps that will lead to unnecessary loss of process time, because we are in control over the complete business process and are able to check deadlines in a pro-active way.
Theo Bolta is a Netweaver Solution Architect for NL for Business