1. EI2N2008 © O. Noran, P. Bernus 2008 Service Oriented Architecture vs. Enterprise Architecture: Competition or Synergy? Ovidiu Noran, Peter Bernus EI2N '08 Enterprise Integration, Interoperability and Networking Session 3.2 12/11/2008

2. EI2N2008 © O. Noran, P. Bernus 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. 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. No agreement on SOA definition and on the types and meaning of artefacts involved in its creation / maintenance.

3. EI2N2008 © O. Noran, P. Bernus 2008 EA and SOA had their hype and disillusionment cycles. 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… SOA hype occurred during the EA ‘downturn’ and is now recovering from its own disillusionment trough.

4. EI2N2008 © O. Noran, P. Bernus 2008 What can SOA be in respect to EA? Many ‘solution providers’ argue in favour of 1. The sceptics argue in favour of 2. We argue in favour of 3. Some possible answers: 1. A parallel approach, probably even a successor 2. A fad 3. A type of and/or a component of EA

5. EI2N2008 © O. Noran, P. Bernus 2008 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.

6. EI2N2008 © O. Noran, P. Bernus 2008 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

7. EI2N2008 © O. Noran, P. Bernus 2008 EM GERA Generalised Reference Architecture EEM Enterprise Engineering Methodology EML Enterprise Modelling Language EET Enterprise Engineering Tool Enterprise Model EOS Enterprise Operational System PEM Partial Enterprise Model GEMC Generic Enterprise Modelling Concept EMO Enterprise MOdule supports used in utilised in implemented in used to implement used to build define meaning of The GERAM EAF: ISO15704:2005Amd1 Annex C

8. EI2N2008 © O. Noran, P. Bernus 2008

9. EI2N2008 © O. Noran, P. Bernus 2008 Management and Control Product or Customer Service Human Machine Resource Organisation Information Function Generic Partial Particular Hardware Software Life Cycle Phases Views Instantiation Design Arch. design Detailed design Identification Concept Implementation Operation Decommission Requirements GERA MF

10. EI2N2008 © O. Noran, P. Bernus 2008 SOA-PG Life Cycle IBM Life Cycle C D Op I DD AD R Id M CS C D Op I DD AD R Id M CS OASIS Ref. Arch. SOA-PG Ref. Arch. GERA MF Partial Level

11. EI2N2008 © O. Noran, P. Bernus 2008 F SOA Project Partial Level DD MSOAM AD R I Bell’s Fwk (FIRO) O F SOA Project Partial Level DD AD R I OASIS SAB OASIS RA SOA-PG RA SOA Team (FO) C EA 3 Fwk (FIR) R O I

12. EI2N2008 © O. Noran, P. Bernus 2008

13. EI2N2008 © O. Noran, P. Bernus 2008 (Life cycle) Entity Model: simplified GERA Management and Control Cust Service C Entity D Op I DD PD R Id M P Simplify Formalism used in the Business Model Human Machine Resource Information Function Particular level Hardware Software Design Prelim. design Detailed design Identification Concept Implementation Operation Decommission Requirements Partial level of GERA Modelling Framework Organisation

14. EI2N2008 © O. Noran, P. Bernus 2008 SP AS 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 development R: Requirements AD: Architectural Design DD: Detailed Design I: Implementation Op: Operation D: Decommissioning D Op I DD AD R C Id M CS BUHQ ISBPMES BU Simple Sample SOA Business Model DS

15. EI2N2008 © O. Noran, P. Bernus 2008 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.

16. EI2N2008 © O. Noran, P. Bernus 2008 THANK YOU ( Questions ? )