Skip to Content

The Common Reference Architecture (CORA), Part III


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.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.