Introduction
This blog is the third 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 COmmon Reference Architecture (CORA), Part II blog post the the SAP SOA Reference Architecture has been mapped onto the CORA model. In this blog post CORA is used to asses the 'SAP Business Suite', regarding separation of responsibilities, decoupling, re-usability, portability and substitutability of elements, by plotting the different SAP-components onto the CORA layers and elements. This is called the 'SAP platform decomposition'.
Platform decomposition of SAP CRM and SAP ERP
In this example an organization wants to use SAP CRM en SAP ERP to standardize their processes and data. Both platforms will be implemented using the N-tier architecture style. First the Logical architecture is shown presenting the logical elements neededNext, the physical architecture is described, showing the SAP components viewed on top of the logical TI architecture. The integration between the software components elements is also shown (with the red lines) which represent the contracts between these components.
Assessing the results
This example shows that the CORA is a ‘relaxed layered’ model. The logical elements within the composition layer are not needed in this situation, so this layer is omitted. The CORA also shows that pre-delivered SAP software components can overlap different layers. For instance the SAP WinGUI component and Portal component are both Channel Access and Presentation layer software components. Also the SAP Webdynpro ABAP component is both a Presentation and Application layer software component.
A disturbing fact is the possibility that components should logically reside in a certain layer, but are actually delivered in another layer. Examples are the SAP Workflow and SAP Business Object Layer components which are logically Composition Layer components but are actually delivered as Application Layer components.
This overlap and ‘wrong’ positioning of components can not only lead to connectivity problems with other technologies but will also make re-use laborious and runs the possibility of causing serious governance issues with regard to determining when to use what component and which resources to use when implementing these components.
By using the CORA to position pre-delivered components logically, expected possibilities and usage regarding these components can be assessed carefully.
In the next blog post a SAP platform decomposition is described using a combination of N-tier and SOA architecture style.
