The CORA Model

A practical guide on using a COmmon Reference Architecture to design
and deliver integrated IT solutions successfully
  • Home
  • CORA Model
    • CORA Requirements
    • CORA Foundation
    • CORA and Business Logic
    • CORA Layers...
      • Overview
      • Channel Access
      • Presentation
      • Composition
      • Integration
      • Application
      • Data
      • Security & Compliance
      • IT Governance
    • Target Groups
    • Sitemap
  • Connections
    • Enterprise Architecture...
      • CORA and Technovision...
        • CORA and Application Lifecycles
        • Technology Trends...
          • Overview
          • You Experience
          • We Collaborate
          • Process on the Fly
          • Thriving on Data
          • Sector-as-a-Service
      • CORA and TOGAF
      • CORA and Archimate
      • CORA and IAF
    • Sol./Softw. Architecture
    • Vendor Connection...
      • CORA and SAP
      • CORA and Oracle
      • CORA and Microsoft
      • CORA and IBM
    • Cloud Computing...
      • Overview
      • Static and Dynamic view
      • ERP and PaaS
  • Methodology
  • Experiences
  • The Authors
  • The Book
    • Paper Version
    • eBook

SAP platform decomposition with CORA: SOA/ROA style

PostAuthorIconWritten by Theo Elzinga | Print | E-mail

Introduction

In the second blog in this series a 'SAP platform decomposition' was described with regard to SAP CRM en SAP ERP implemented using th N-tier style. 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.ssappf_erp

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.

ssap_soa_mapping0001

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.

 
Follow Us on Twitter

theo_elzinga1_klein     leon_klein

Latest Articles
  • Assessing IT solutions with CORA
  • CORA and Archimate
  • Architecture Styles and CORA
  • ERP and PaaS
  • CORA and Application Lifecycles
  • CORA Methodology (Project level)
  • 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

Joomla template created with Artisteer.