Service oriented architecture vs. enterprise architecture: Competition or synergy?

Service Oriented Architecture vs. Enterprise Architecture: Competition or Synergy?

Ovidiu Noran, Peter Bernus

Griffith University Australia, School of ICT {O.Noran, P.Bernus}@griffith.edu.au

Abstract. Currently, Service Oriented Architecture (SOA) is still in its infancy, with no common agreement on its definition or the types and meaning of the ar-tefacts involved in its creation and maintenance. Despite this situation, SOA is sometimes promoted as a parallel initiative, a competitor and perhaps even a successor of Enterprise Architecture (EA). In this paper, several typical SOA artefacts are mapped onto a reference framework commonly used in EA. The results show that the EA framework can express and structure SOA artefacts with minimal or no customisation and can help reason about and establish un-ambiguous meanings for SOA artefacts across the business. Further on, it is shown how an EA-specific approach can help scope the areas of the business that require attention as a result of the changes brought about by an SOA vision and design principles. This suggests that integrating the SOA effort into the on-going EA initiative is a best practice that will greatly benefit all business units of the host organisation.

1 Introduction

Although several definitions for Service Oriented Architecture (SOA) exist, the prevalent view appears to be that SOA is in essence an architectural style promoting the concepts of service (packaged business functions with all necessary information) and service consumer as a basis to structure the functionality of an entire business. The SOA concept is not new, originating in the modular, object-oriented and compo-nent-based software development paradigms. However, the lack of adequate support-ing and realisation infrastructure have in the past hindered its adoption [1]. According to the Gartner Group, after the typical wave of vendor hype and unrealistic expecta-tions, SOA is now recovering from the disillusionment phase and heading towards the plateau of productivity [2]. Even though standardisation attempts are underway, cur-rently there is still no common agreement on a rigorous SOA definition, or the types and meaning of the artefacts that should be involved in the creation and maintenance of an SOA [3]. Furthermore, the realisation that building an SOA involves significant costs and changes to the entire business has contributed to SOA being sometimes seen as a separate approach, a competitor and perhaps a successor of Enterprise Architec-ture (EA) – an increasingly popular approach to describe and manage changes in en-terprises so as to enhance their consistency and agility.

Copyright. Citation Information: Noran, O., Bernus, P. Service Oriented Architec-ture vs. Enterprise Architecture: Competition or Synergy? in LNCS 5333 (Proceedings of 3rd International Workshop On Enterprise Integration, Interoperability and Networking (EI2N '08)), R. Meersman, Z. Tari, and P. Herrero, Editors. 2008, Springer-Verlag: Hei-delberg, Berlin. p. 304-312

Thus, this paper argues that SOA is a style and/or component of EA rather than an al-ternative or a competitor. This position is supported in two steps. Firstly, the paper shows how a typical EA artefact, namely a reference Architecture Framework (AF), can be used to find common, agreed-upon meanings and actual coverage of the vari-ous artefacts involved in an SOA effort. Secondly, it demonstrates how an SOA en-deavour can be analysed from an EA perspective that facilitates a coherent approach across the business units and provides the premise for organisational culture change enabling the lasting success of an SOA project.

2 The Reference Framework

The need to establish a framework early in an SOA project appears to be generally accepted [4-6]. The assumption made in this paper is that if SOA-specific artefacts can be mapped onto an enterprise reference AF in a meaningful way, then the re-quired ‘SOA framework’ could in fact be a type of enterprise AF, which would sup-port the SOA - EA synergy and integration argument. Thus, several typical artefacts described in SOA literature will be mapped against a reference AF, obtained by com-bining a number of mainstream Enterprise AFs and validated against several others. Note that a comprehensive mapping of all SOA artefacts currently identified is be-yond the proposed scope and space available for this paper; the aim here is to prove the concept and perhaps incite constructive debate.

The reference framework proposed is described in Annex C of ISO15704:2000/ Amd1:2005, and it is called the Generalised Enterprise Reference Architecture and Methodology, or GERAM [7]. ISO15704:2000 sets requirements for reference archi-tectures and methodologies (without prescribing any specific artefacts); GERAM is provided as an example of a generalised enterprise AF that satisfies these require-ments. As such, GERAM can be (and has been) used to assess particular AFs, or to establish a selection of AF components to be used in a specific EA project since often, a single AF does not have all the elements required. Several mainstream AFs have been mapped against GERAM [8-10] and a ‘Structured Repository’ of mainstream AF elements is being built using GERAM as a decomposition and structuring tool [11]. GERAM is one of the most complete reference AFs; in addition, as part of ISO15704:2000, it is regularly reviewed so as to harmonize it with other standardisa-tion efforts such as ISO/IEC 42010:2007 [12]), ISO/IEC 15288:2002 [13], etc. This ensures that GERAM will constantly include a set of essential concepts shared and agreed upon by the EA community.

EM

GERAGeneralisedReference

Architecture

EEMEnterprise

Engineering Methodology

EML

Enterprise Modelling Language

EETEnterprise

Engineering Tool

Enterprise Model

EOSEnterprise

Operational System

PEMPartial 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

OASIS Reference

model

Open Group SOA

Ontologies

MSOAM, OASIS SAB

SOAModels

SOA Trusted Components

SOA-PG Reference

Model

SOA-PG Reference

ArchitectureBPEL, BPMN...

SOATools

CBDI Metamodel

Linthicum metamodel

GERAM Boundary

Executable Services

OASIS Reference

Architecture

Fig. 1. Sample mapping of SOA artefacts on GERAM (ISO/IEC, 2005)

The Generalised Enterprise Reference Architecture (GERA) component of GERAM contains the multi-dimensional modelling framework (MF) and other essential con-cepts such as life history and enterprise entity. The GERA MF (see Fig. 2) contains a multitude of aspects that may be required in modelling an EA project / product, in the context of the project / product’s life cycle. The GERA MF also features the generici-ty dimension, which allows representing the meta-models and ontological theories underlying languages used to build partial (e.g. reference) and particular models. Thus, the GERA MF contains placeholders for models describing the components shown in the GERAM structure depicted in Fig. 1. Full descriptions of GERAM, GERA and GERA MF are contained in ISO15704:2000 and are beyond the scope and space available for this paper.

3 Mapping Typical SOA Artefacts on the Reference Framework

The following section attempts to map several SOA artefacts currently offered by vendors and / or described in SOA literature, that are deemed of interest to the scope of this paper. The selection of particular artefacts does not imply their endorsement.

Management and Control

Product or Customer Service

HumanMachine

ResourceOrganisation

InformationFunction

GenericPartialParticular

HardwareSoftware

Life Cycle Phases

Views

Instantiation

Design

Arch. design

Detailed design

Identification

Concept

Implementation

Operation

Decommission

Requirements

Fig. 2. GERA MF (ISO/IEC, 2005)

3.1 SOA Ontologies

The SOA Working Group (WG) of The Open Group aims to provide ontologies for SOA so as to promote “[…] alignment between the business and information technol-ogy communities” [14]. In GERAM, ontological theories are a kind of generic enter-prise model, describing the most general aspects of enterprise-related concepts and defining the semantics of the modelling languages used. The Open Group Ontology document currently contains definitions for contract, visibility, registry etc; thus, it maps onto the Generic Concepts area of GERAM (see Fig. 1) and the Generic area of GERA MF (detailed mapping not shown due to space limitations).

3.2 SOA Metamodels

In GERAM, a metamodel describes the properties and relationships of concepts used in the modelling endeavour, as well as some basic constraints, as cardinality [7]. Thus, an SOA metamodel should define relationships between SOA components, list rules for building models and define terminology consistently and unambiguously.

Linthicum [15] proposes an artefact called an SOA metamodel. However, accord-ing to the definitions above, the artefact is rather a high-level reference model since it describes an SOA model at the architectural level life cycle phase (see Fig. 1).

Another meta-model proposition is offered by Everware-CBDI [16]. This artefact appears to fulfil the requirements of a meta-model by GERAM (although lacking SOA principles such as loose coupling, autonomy, mediation, etc) and thus can be mapped on the generic concepts area of GERAM. The various artefacts depicted in the metamodel can be mapped onto the aspects of the generic level of the GERA MF.

3.3 SOA Reference Models and Reference Architectures

Many vendors and consultants (IBM, BEA, Oracle, WebMethods, etc) offer what they call ‘reference models’ (RMs) and ‘reference architectures’ (RAs). In GERAM, RMs are seen as blueprints describing features common to specific types of enterprises, while RAs are RMs created at the Architectural Design level.

The OASIS RM [17] in its current version is closer to a meta-model than to an RM from the GERAM perspective since it does not appear to express a blueprint for SOA implementation. OASIS RAs and Patterns do however match the GERAM RA defini-tion since they are RMs for particular SOA systems expressed at the Architectural Design level. The OASIS Concrete Architecture is in EA the Architectural Design level model of a particular SOA system – and thus maps on the Particular level within the GERA MF, at the Architectural Design life cycle phase.

The RA described in the Practitioner’s Guide (PG) authored by Durvasula et al. [18] specifies the structure and the functionality of model components and thus ap-pears to be a proper RM at the Architectural level (RA, according to GERA MF). The proposed mappings of the two artefacts are shown in Fig 1 and Fig. 3.

3.4 SOA Modelling / Documentation Framework

An MF according to ISO15704:2000 is a structure that holds models describing all necessary aspects of enterprises and/or EA projects, along their entire life history. The EA Documentation Framework (DF) is described by Bernard [5] as one of the main components of any EA endeavour. In the SOA domain, McGovern [4] also emphasiz-es the importance of having a framework guiding the SOA initiative.

F

SOA Project Partial Level

DD

MSOAMAD

R

I

Bell’s Fwk(FIRO)

O

F

SOA Project Partial Level

DD

AD

R

I

OASISSAB

OASIS RA

SOA-PG RA

SOA Team

(FO)

CEA3

Fwk(FIR)

RO

I

Fig. 3. Sample mappings of MF and methodologies (left) and human aspect of SOA projects (right) on simplified GERA MF (aspects / levels irrelevant to specific mapping omitted)

It appears that the general meaning given to a DF is in fact that of MF. Knippel [19] describes the SOA DF as a new product, however he suggests investigating whether the SOA and EA frameworks could have common areas and even be merged. This supports the SOA-EA integration proposition made in this paper.

The SOA MF described by Bell [20] provides the conceptual, analysis and logical life cycle phases that may map onto the Requirements, Architectural and Detailed De-sign phases of GERA; however, the MF appears to lack several other aspects. For ex-ample, the human aspect and the management / service distinction are not explicitly represented. Therefore, if such aspects are deemed necessary for the SOA project at hand, elements of other frameworks may need to be employed. As another example, the EA3 framework described by Bernard [5] as expressed in its graphical form (which may not completely reflect the written content) appears to map on the Partial Level, at Concept and Architectural Design life cycle phases, and cover Function, Information and Resource aspects (see Fig. 3, left).

3.5 Further Mappings of Other SOA Artefacts

Further mappings including SOA life cycle, team, vision, governance, methodologies, quality of service and Enterprise Service Bus have been accomplished in order to support the argument that a reference AF can be used to find common meanings and actual coverage of various artefacts involved in an SOA project.

However, they cannot be shown here due to space limitations. The reader is di-rected to [21] for details and interpretations of these additional mappings.

4 Defining and Creating an SOA: an EA Approach

From an EA point of view, it is possible to define the SOA concept for a business by extending its present vision to depict the business as a set of reusable services. It is al-so possible to define SOA design principles as follows: − technology principles – by declaring service orientation as a technology principle

resulting from, and informed by, technology trends analysis; − information management principles – by mandating common data services; − organisational principles – by declaring that the business needs to be organised as

a set of interrelated and reusable services (this is essentially the SOA principle applied to the entire business);

− organisational and cultural principles – by stating that contribution to reusability should be encouraged, measured and rewarded;

− process principles – by requiring that business processes need to be independent from applications and that business management should be able to own and inde-pendently manage / design and roll out changed business processes.

Note that the functional requirements (the ‘tasks’) of the company may not change in terms of what the company does for its customers; however, the management re-quirements do change, in that there are additional, or modified management processes needed to be able to act on the changed principles. The non-functional / resource re-quirements may also change – e.g. performance requirements (for service and man-agement) may have to be stated explicitly (whereupon earlier these were not explicit), because it is known that by adopting the above new principles, QoS can become an essential issue. This is so, because if services become sharable applications they are no longer separately maintained for servicing a dedicated and fixed set of users, and therefore the use of a service by one entity may adversely affect other simultaneous users of the same service in another entity. As a result there are also organisational requirements: there is a need to allocate suitably competent employees to service pro-vision and management in order to ensure the required level of QoS.

A question arises: once the principles and tasks are defined, should a new require-ments specification be created for the entire enterprise? While possible, this would not be a very efficient course of action. Rather, from the vision and the design princi-ples it is possible to locate the entities that need change and draw a business model that does not need upfront detailed requirements specification. Subsequently, the business model can be used to localise the need for change and to identify the neces-sary new artefacts (models).

4.1 Sample Business Model of an SOA Scenario

The following example aims to illustrate the previous description of the role of EA ar-tefacts and business model using a modelling formalism derived from the GERA MF

In the SOA scenario in Fig. 4, the headquarters of a business sets up an SOA pro-ject but also the mission, vision, design principles, policies and high-level require-ments for the services required. Subsequently, the SOA project starts operating and with assistance from all business units creates the rest of the deliverables required for the business, application and infrastructure services. Once the services are operation-al, they perform their primary function, i.e. to support the business units’ operation. In EA, such representations have proven to be effective in achieving a common under-standing of the AS-IS and TO-BE states of the business and scoping the extent of necessary change at each life cycle phase of target entities.

As can be seen from Fig. 4, the business model is in fact an architecture description (a description of the business at the GERA MF architectural design level) that is in-tended to address a specific stakeholder concern, namely what (and who) is needed to implement the (SOA) vision that is based on the changed principles. More details are available in [22]; [11] describes a way to use the business model to derive a step-by-step methodology to create and operate the specific SOA project and its deliverables.

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 developmentR: RequirementsAD: Architectural DesignDD: Detailed DesignI: ImplementationOp: OperationD: Decommissioning

DOp

IDD

ADRCId

MCS

BU HQ

ISBPMES

BU

DS

Fig. 4. Relation project / product / services (based on [22])

5 Conclusions and Further Work

In this paper, we have argued that the use of EA frameworks and approaches is suita-ble and beneficial in SOA projects. The mappings shown are by no means compre-hensive; they rather aim to exemplify how a common reference can help business management and the EA/SOA team work out areas that can be covered by the various artefacts on offer and also point out potential gaps and overlaps. Making sense of the myriad of SOA artefacts created by interest groups, academics, vendors etc is an es-sential step in gathering stakeholder support for the SOA endeavour. Further on, we have shown how an EA-specific approach can help scope the areas of the business that require attention as a result of the changes brought about by a service-oriented business architecture vision and design principles.

The approach advocated by this paper would promote SOA-EA integration rather than rivalry and be highly beneficial - since EA can help an SOA initiative get off the ground by more accurately identifying and predicting required business and support-ing services and sustain it by a cross-departmental approach. EA can also help achieve a cultural change promoting reuse – e.g. by a system of values that rewards business units who share services that become frequently reused.

Clearly, further mappings of SOA artefacts on the reference AF need to be per-formed in order to increase confidence in the use of EA elements and approaches in SOA projects and perhaps build a repository of EA artefacts most suited to SOA. In addition, the suitability of other EA artefacts such as management maturity models [23] or development kits [24] also need to be tested for use in SOA projects.

References

1. Schönherr, M., Connecting EAI-Domains via SOA - Central vs. Distributed Approaches to Establish Flexible Architectures, in Knowledge Sharing in the Integrated Enterprise: In-teroperability Strategies for the Enterprise Architect, P. Bernus, M. Fox, and J.B.M. Goos-senaerts, Editors. Kluwer Academic Publishers: Toronto / Canada. pp. 111-113. (2004)

2. Fenn, J., A. Linden, and D. Cearley. Hype Cycle for Emerging Technologies, 2005. Gartner Group. Retrieved June 5, 2008 from http://www.gartner.com/teleconferences/attributes/attr_129930_115.pdf

3. Erickson, J. and K. Siau, Web Services, Service Oriented Computing and Service Oriented Architecture: Separating Hype from Reality. Journal of Database management 19(3): pp. 42-54 (2008)

4. McGovern, J., Service Oriented Architecture, in A Practical Guide to Enterprise Architec-ture, J. McGovern, et al., Editors. Prentice Hall PTR: Upper Saddle River, pp. 63-89 (2003)

5. Bernard, S.A., An Introduction To Enterprise Architecture. Bloomington, IN: AuthorHouse. (2005)

6. Sprott, D. and L. Wilkes, Enterprise Framework for SOA. Component based Development and Integration Journal (2005)

7. ISO/IEC, Annex C: GERAM, in ISO/IS 15704:2000/Amd1:2005: Industrial automation systems - Requirements for enterprise-reference architectures and methodologies (2005)

8. Noran, O., An Analysis of the Zachman Framework for Enterprise Architecture from the GERAM perspective. IFAC Annual Reviews in Control, Special Edition on Enterprise Inte-gration and Networking (27): pp. 163-183.(2003)

9. Noran, O., An Analytical Mapping of the C4ISR Architecture Framework onto ISO15704 Annex A (GERAM). Computers in Industry 56(5): pp. 407-427. (2005)

10. Saha, P., A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO15704:2000 Annex A), in Enterprise Systems Architecture in Practice, P. Saha, Editor. IDEA Group: Hershey, USA. pp. 1-17.(2007)

11. Noran, O., Discovering and modelling Enterprise Engineering Project Processes, in Enter-prise Systems Architecture in Practice, P. Saha, Editor. IDEA Group: Hershey, USA. pp. 39-61 (2007)

12. ISO/IEC, ISO/IEC 42010:2007: Recommended Practice for Architecture Description of Software-Intensive Systems. (2007)

13. ISO/IEC, ISO/IEC15288: Information Technology - Life Cycle Management -System Life Cycle Processes. (2002)

14. SOA WG. Open SOA Ontology. The Open Group,. Retrieved June 23, 2008 from http://www.opengroup.org/projects/soa-ontology/uploads/40/12153/soa-ont-06.pdf

15. Linthicum, D.S. SOA Meta-model. (PDF). Linthicum Group. Retrieved June 12, 2008 from http://www.linthicumgroup.com/paperspresentations.html

16. CBDI. CBDI-SAE™ Meta Model for SOA Version 2. Retrieved June, 2008 from http://www.cbdiforum.com/public/meta_model_v2.php

17. OASIS SOA Reference Model TC. OASIS Reference Model for Service Oriented Architec-ture V 1.0. OASIS Group. Retrieved June 20, 2008 from http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

18. Durvasula, S., et al. SOA Practitioner's Guide. BEA Systems, Inc. Retrieved April, 2008 from http://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html

19. Knippel, R., Service Oriented Enterprise Architecture (Doctoral Thesis). IT-University of Copenhagen: Copenhagen. pp. 125. (2005)

20. Bell, M., Introduction to Service-Oriented Modeling, in Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture, Wiley & Sons. (2008)

21. Noran, O., Mapping SOA Artefacts onto an Enterprise Reference Architecture Framework (in print), in 17th International Conference on Information Systems Development - ISD 2008. Cyprus, Paphos. (2008)

22. Bernus, P. How To Implement SOA For The Whole Of Business. in Service Oriented Archi-tecture 2008 - Implementing And Measuring Soa Projects To Drive Business Value Sydney, IQPC. (2008)

23. GAO. IT - A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1). US General Accounting Office. Retrieved 07 Jun, 2008 from http://www.gao.gov/new.items/d03584g.pdf

24. NASCIO. Enterprise Architecture Development Tool-Kit v3.0. National Association of State Chief Information Officers. Retrieved Jul, 2008 from http://www.nascio.org/aboutNASCIO/index.cfm