SAP platform decomposition with CORA: N-tier style
Introduction
In the first blog in this series the SAP SOA Reference Architecture is mapped onto the CORA model. In the second blog 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 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 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.
- CORA and Application Lifecycles
- CORA Methodology, playing with Lego
- The roadmap for Fusion Applications, CORA is there to help
- Technovisions "Sector-as-a-Service" mapped
- Business Logic and the CORA Model, Part II
- CORA and Cloud Computing: Static versus Dynamic View
- Technovisions "Thriving on Data" mapped
- CORA Foundation
- Business Logic and the CORA Model, Part I
- CORA and IBM
- CORA and Microsoft
- CORA and Cloud Computing: Overview
- Technovisions "Process-on-the-Fly" mapped onto CORA
- Risk aware design: using CORA to investigate an IT solution
- A ROA based iPhone App for SAP: Part II
- A ROA based iPhone App for SAP: Part I
- Technovisions "We Collaborate" mapped onto CORA
- SAP platform decomposition with CORA: SOA/ROA style
- 'Why' Driven Solution crafting
- CORA and TOGAF
- SAP platform decomposition with CORA: N-tier style
- Requirements for CORA
- CORA and Oracle
- Technovisions "You Experience" mapped onto CORA
- CORA and SAP
- CORA in action: design guidelines to implement repositories
- The basis of all, your data
- CORA and IAF
- Technovision and CORA - Overview
- The importance of an Integration layer


