160 likes | 373 Views
EI2N '08 Enterprise Integration, Interoperability and Networking Session 3.2. Service Oriented Architecture vs. Enterprise Architecture: Competition or Synergy?. Ovidiu Noran, Peter Bernus. 12/ 11 /2008.
E N D
EI2N '08 Enterprise Integration, Interoperability and Networking Session 3.2 Service Oriented Architecture vs. Enterprise Architecture: Competition or Synergy? Ovidiu Noran, Peter Bernus 12/11/2008
Service Oriented Architecture (SOA) (the verb): aims to structure the functionality of a business using the service (packaged business functions with all necessary information) and service consumer as base concepts. No agreement on SOA definition and on the types and meaning of artefacts involved in its creation / maintenance. Enterprise Architecture (EA) (the verb): aims to describe enterprises and manage change so as to enhance consistency and agility. No consensus on EA definition or artefacts either.
EA and SOA had their hype and disillusionment cycles. SOA hype occurred during the EA ‘downturn’ and is now recovering from its own disillusionment trough. SOA enthusiasts realised that just like EA, SOA must encompass the entire organisation in order to achieve anything positive. From a glorified Web Service paradigm, SOA gradually started to ‘look and walk’ more like EA. So, the question arose…
What can SOA be in respect to EA? Some possible answers: 1. A parallel approach, probably even a successor 2. A fad 3. A type of and/or a component of EA Many ‘solution providers’argue in favour of 1. The sceptics argue in favour of 2. We argue in favour of 3.
Components of the argument (not complete but it’s a start): 1. Show that EA frameworks can contain, express and suitably classify typical SOA artefacts 2. Show that an SOA endeavour can be analysed and guided from an EA perspective and that this approach: a) facilitates a coherent approach across business units b) provides the premise for organisational culture change The real benefit (as we see it): … integrating the SOA initiative in the ongoing EA effort enables the lasting success of the project.
The need for a framework permeates the SOA literature. Could an (Enterprise) Architecture Framework (EAF) play the role of an SOA framework? Perhaps - if it can “…help create, organise, interpret and analyse [service-oriented] architectural descriptions” (ISO42010) containing all the relevant (SOA-specfic) artefacts. In the following we have tried to map such ‘SOA-specific’ artefacts on an EAF and observed the results. The framework chosen is the GERAM EAF
GERA EEM EML GeneralisedReference Architecture Enterprise Engineering Methodology Enterprise Modelling Language utilised in implemented in used in define meaning of GEMC EET Generic Enterprise Modelling Concept Enterprise Engineering Tool supports The GERAM EAF: ISO15704:2005Amd1 Annex C used to build PEM Partial Enterprise Model EM Enterprise Model used to implement EMO EOS Enterprise MOdule Enterprise Operational System
Generic Views Partial GERA MF Particular Instantiation Management and Control Identification Product or Customer Service Concept Requirements Software Hardware Arch. design Design Resource Detailed design Organisation Information Implementation Function Operation Decommission Machine Human Life Cycle Phases
GERA MFPartial Level GERA MFPartial Level CS CS M M Id Id OASIS Ref. Arch. C C R R SOA-PG Life Cycle AD AD IBM Life Cycle DD DD SOA-PG Ref. Arch. I I Op Op D D
SOA Project Partial Level SOA Project Partial Level EA3Fwk (FIR) C SOA-PG RA OASIS SAB R R SOA Team (FO) Bell’s Fwk (FIRO) AD AD MSOAM DD R DD OASIS RA O O I I I F F
SOA Project Partial Level CS M Id ‘ESB = Policies’ C SOA Vision QoS, SLA… C ‘ESB = Specification’ R R ‘ESB = Architecture’ SOA-PG Life Cycle AD AD ‘ESB = Middleware’ DD IBM Life Cycle R DD ‘ESB = Web Services’ O I I I F Op Possible ESB meanings along its life cycle Governance (Mgmt side) D M H CS M
Partial level of GERA Modelling Framework Formalism used in the Business Model M P Management and Control Identification Id Cust Service Concept C Requirements R Software Hardware Prelim. design PD Simplify Design DD Resource Detailed design Organisation I Implementation Information Function Op Operation D Decommission Machine Human Particular level Entity (Life cycle) Entity Model: simplified GERA
M CS BPMES: Bus. Process Mgmt & Exec Serv. DS: Data Service IS: Infrastructure Service AS: Application Service HQ: Headquarters BU: Business Unit SP : SOA Project ------------------------------- M: Management CS: Customer Service Id: Identification C: Concept developmentR: RequirementsAD: Architectural DesignDD: Detailed DesignI: ImplementationOp: OperationD: Decommissioning Id C R AD DD I Op D BU BU SP HQ BPMES IS AS DS Simple Sample SOA Business Model
Conclusions: • We were able to map the SOA artefacts investigated with no (major) issues. The mapping has also provided insight into the nature of some artefacts from an EA perspective. • Employing a business model using EAF constructs has helped identify the true environment of the SOA project • Further Work: • Perform further mappings to validate the concept and • Continue to promote the integration of the SOA efforts in the ongoing EA initiative.
THANK YOU ( Questions ? )