Introduction
This blog is the fourth in a series around the usage of the CORA model in a SAP-centric environment. In the The COmmon Reference Architecture (CORA), Part I blog post, the CORA model has been introduced. In the The COmmon Reference Architecture (CORA), Part II blog post the SAP SOA Reference Architecture has been mapped onto the CORA model. In the The Common Reference Architecture (CORA), Part III blog post the 'SAP Business Suite' has been assessed by plotting the different SAP-components onto the CORA layers and elements ('SAP platform decomposition').In this blog a SAP platform decomposition is performed using a combination of the N-tier and SOA architecture style.
Platform decomposition of SAP ERP using a combination of N-tier and SOA architecture style
In this example an organization wants to re-use of business functionalities on top of the existing ERP solution. This solution, implemented using the N-tier architecture style is therefore extended by the SOA architecture style. First the Logical architecture is shown presenting the logical elements needed.
Next, the physical architecture is described, showing the SAP components viewed on top of the logical TI architecture. The integration between the software components is also shown (the red lines) which represent the contracts between these components.
Assessing the results
Looking at the Physical architecture it is striking to see that a lot of the logical elements within the Integration layer are implemented in one physical component, the SAP Netweaver Process Integration. It is unclear how the separation of synchronous, a-synchronous, integration core and integration meta data is implemented. This leads to some questions which need to be answered:
- Can the Enterprise Services (SAP ES), stored in the Enterprise Services Repository (ESR) and Composite services be called from a services layer (mediation) or are they called upon directly?
- Does the SAP service repository (ESR) also store agreements between services? How is the usage of the services monitored?
- Do the SAP ES services directly call the SAP ERP basic services? Or do they use service mediation capabilities?
- Are there any rules or principles regarding the storage of data within the Composite services?
- Etc.
This example shows clearly within Packaged Based Solutions like SAP the SOA style is always built upon the N-tier style, thus combining both styles. The SAP WINgui component connects directly to ERP-backbone (N-tier) while composed services are calling the ERP-backbone services and using the PI-integration layer for service mediation (SOA). Besides that, some software components within the composition layer are N-tier style in nature (Universal Work list, Collaboration). SOA style components such as those within the Composite Application Framework are delivered in logically ‘right’ layers. However overlapping physical components still exist (Universal Work list, Collaboration, Visual Composer). Next to assessing SAP-components carefully by using the CORA model, the delivery of N-tier style components, SOA style components and the combination of both adds additional complexity regarding implementation and governance.
In the next blog post the ROA architecture style is introduced and mapped onto the CORA model by designing an interface between an iPhone and SAP CRM.
2 Comments
