Skip to Content


This blog is the second 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 this second blog post, the  SAP SOA Reference Architecture is mapped onto the CORA model.

Architectural views of SAP and CORA scope

The SOA  Reference Architecture of SAP describes  a SOA-based layered architecture.


  This Reference Architecture describes a SOA-based layered technology. Service-enabled applications contain required functionality. The provisioning layer provides abstraction from the actual backend systems by providing a consistent set of services. SOA middleware supports service-enabling legacy systems handling the system-centric and cross-organizational processes. In the consumption layer services are utilized to create user interfaces and processes. The user interfaces layer offers several possibilities to implement user interaction based on available services.

Mapping the SAP SOA reference architecture onto the CORA layers results in the  following matrix./wp-content/uploads/2010/06/sap_mapping_276768.jpg

Assessing the results

SAP is mixing Channels and Presentation technologies compared to the  CORA. It mentions Portal but also Adobe Form which in itself can be  accessed throughout a Portal as an electronic form. Back-end  connectivity and Service Bus are two layers. In the CORA this is one  layer but separated in different elements. The  Enterprise SOA  consumption layer contains the same elements as the  Composition layer in  the CORA. The difference in the naming of the  layer is interesting  because composite services are not only consuming  but actively providing  themselves too! A Data layer is not recognized  as a separate layer but  positioned  within  applications.

SOA management is a horizontal layer while in the CORA  it is  positioned as a vertical layer to manage SOA on more horizontal  layers.  Important is the absence of a Security  and IT Governance. Impact for  implementing SAP is that firstly security needs to be included over all  layers. Secondly the governance of SAP components and integration in  the whole  governance cycle including run-time governance needs to  assessed.

What is the added value of CORA in the SAP field

As shown the CORA model is used as a quality instrument to assess the  the  SOA Reference Architecture of SAP. The following questions could  be  raised:

  • Why are the vertical CORA layers absent?
  • What are the  cluster and separation criteria based upon?
  • If other architecture styles than Service Oriented Architecture  (i.e. N-Tier or Resource Oriented Architecture ) is used, does this  reference architecture still apply?
  • Etc.

For both an Enterprise Architecture and Software Architecture on  Enterprise Level it is not possible to use solely the SOA Reference  Architecture of SAP as a quality instrument because:

  • within a  common IT Landscape multiple architecture styles (N-tier,  Service  Oriented Architecture, Resouce Orientented Architecture)  co-exist  instead of just one,
  • the clustering is based on SAP  components, which can differ from  other vendors.

As shown in  this assesment at the (SAP) project  implementation level  the SOA Reference Architecture can be  used to create a Solution  Architecture, because of its direct relation  with the SAP components.  However this should only be  done when it  is connected to the  CORA, to guarantee architectural governance between  the Enterprise and  the project Solution Architecture.

CORA can also be 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 will be described  in the next blog.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply