Ana səhifə

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

Yüklə 37.2 Kb.
ölçüsü37.2 Kb.

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

Ovidiu Noran, Peter Bernus

Griffith University Australia, School of ICT

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 artefacts 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 unambiguous meanings for SOA artefacts across the business. This suggests that integrating the SOA effort into the ongoing EA initiative is a best practice and will greatly benefit 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 processes 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 component-based software development paradigms. However, the lack of adequate supporting and realisation infrastructure have in the past hindered its adoption (Schönherr 2004). According to the Gartner Group, after the typical wave of vendor hype and unrealistic expectations, SOA is now recovering from the disillusionment phase and heading towards the plateau of productivity (Fenn, Linden and Cearley 2005). Even though standardisation attempts are underway, currently 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. 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 (aided by vendor hype) perhaps a successor of Enterprise Architecture (EA).

This paper argues that SOA is a style and/or component of EA rather than an alternative and or a competitor. This point 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 various artefacts involved in an SOA effort. Secondly, it demonstrates how an SOA endeavour 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 (Bernard 2005; McGovern 2003; Sprott and Wilkes 2005). 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 required ‘SOA framework’ could in fact be a type of enterprise AF, which would support the SOA - EA synergy and integration argument. Thus several typical artefacts described in SOA literature will be mapped against a reference Architecture Framework (AF), obtained by combining a number of mainstream Enterprise AFs and validated against several others. Note that a comprehensive mapping of all SOA artefacts currently identified is beyond 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 (ISO/IEC 2005). ISO15704:2000 sets requirements for reference architectures and methodologies (without prescribing any specific artefacts); GERAM is provided as an example of a generalised enterprise AF that satisfies these requirements. 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, one single AF does not have all the elements required. Several mainstream AFs have been mapped against GERAM (Noran 2003;2005; Saha 2007) and a ‘Structured Repository’ (knowledge base-like) of mainstream AF elements is being built using GERAM as a decomposition and structuring tool (Noran 2007a). 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 standardisation efforts, e.g. ISO/IEC 42010:2007 (ISO/IEC 2007)), ISO/IEC 15288:2002 (ISO/IEC 2002), etc. This ensures that GERAM will constantly include a set of essential concepts shared by the EA community.

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

(dashed outline boxes show possible / generic SOA elements)

The Generalised Enterprise Reference Architecture (GERA) component of GERAM contains the multi-dimensional modelling framework (MF) and other essential concepts 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 genericity 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 of 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.

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 “common understanding of SOA in order to facilitate alignment between the business and information technology communities” (SOA WG - The Open Group 2006). In GERAM, ontological theories are a kind of generic enterprise 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. Due to its structure and contents it does abide by the GERAM definition and 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, such as cardinality (ISO/IEC 2005). Thus, an SOA metamodel should unambiguously define relationships between SOA components, elicit rules for building relevant models and define terminology in a consistent, unambiguous manner.

Linthicum (2007) proposes an artefact called an SOA metamodel. However, according 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 mapping in Fig. 1).

Another meta-model proposition is offered by Everware-CBDI (2007). This artefact appears to fulfil the requirements of a meta-model by GERAM (although as stated by the authors, it lacks some SOA principles such as loose coupling, autonomy, mediation, etc) and thus can mapped on the generic concepts area of GERAM. In addition, the various artefacts depicted in the metamodel can be mapped onto the various 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 life cycle phase.

The OASIS RM (OASIS SOA Reference Model TC 2008) 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 definition since they are RMs for particular SOA systems built expressed at the Architectural Design life cycle phaselevel. The OASIS Concrete Architecture is in EA the Architectural Design level model of the 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, Guttmann, Kumar, Lamb, Mitchell, Oral, Pai, Sedlack, Sharma and Sundaresan (2007) specifies the structure and the functionality of model components and thus appears to be a proper RM at the Architectural level – i.e. an RA according to GERA MF.

The proposed mappings of the two artefacts are shown in Fig. 1 and Fig. 3.

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)

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 (2005) as one of the main components of any EA endeavour. In the SOA domain, McGovern (2003) also emphasizes the importance of having a framework guiding the SOA initiative. It appears that the general meaning given to a DF is in fact that of MF. (Knippel 2005) 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 by this paper.

The SOA MF described by Bell (2008) provides the conceptual, analysis and logical life cycle phases that may map onto the Requirements, Architectural and Detailed Design phases of GERA; however, the MF appears to lack several other aspects. For example, 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 (2005) 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 SOA Life Cycle and Service Life Cycle

The SOA PG (Durvasula et al. 2007) describes a set of life cycle phases for SOA projects. On mapping onto GERA, a possible interpretation is that the Requirements life cycle phase has been omitted from the model, and so have the phases beyond Detailed Design (see Fig. 4, left). This may be due to the intended scope of the SOA PG; however, when performing an SOA project, the practitioner should be aware of the issue and if necessary seek to complement or replace this life cycle model with one that provides all necessary phases.

Another life cycle model is proposed by IBM (IBM 2007a;2007b). Again, it appears that some life cycle phases are not covered – notably concept and requirements. It is interesting to note that this model distinguishes between the management and service / production aspects of the SOA project; this subdivision exists in the GERA MF (see Fig. 2) and the mapping reflects this situation (see Fig. 3, right).

It should be noted that the IBM model also distinguishes between the SOA project lifecycle and the service lifecycle. The distinction between a project and the product(s) of the project figures prominently in EA best practice and is also reflected in GERAM – which allows for the representation of the business, project, product and any other relevant EA artefacts’ life cycles as illustrated in Fig. 5.

3.6 SOA Vision

Articulating a coherent and easy to communicate vision is identified by Knippel (2005) as paramount to any successful SOA initiative and it is no different in any EA project. The vision maps onto the Concept development life cycle activity of GERA, where the stakeholders decide if and how to satisfy the need(s) present in the Identification life cycle phase.

3.7 SOA Governance

In the mainstream literature it is often argued that an SOA initiative would not succeed (or be severely limited e.g. to the infrastructure level) without a proper cross-departmental governance approach. Governance should contribute to all SOA project life cycle phases and a governance model should also make clear which business units influences which area of the SOA project, the authority of the SOA /EA team, how services will affect the business units, etc. Thus, SOA Governance maps onto the management part of the GERA MF and should cover all relevant aspects and life cycle phases of the SOA project, similar to the area occupied by the SOA team, however it must include the non-human area of the management side as well (i.e. the supporting management information systems / decision support system). Depending on the specific details of the SOA project, various extents of the project’s life cycle phases may be managed by the business HQ – as shown in Fig. 5. Representing the location and extent of governance on the GERA framework allows HQ and the SOA team to unambiguously represent their position / authority and to specify what governance deliverables are needed in what areas, for each life cycle phase of the SOA project. In other words, the (SP) Project’s management processes are partly performed by project management personnel, while other parts are performed by the body that provides governance (thus, as shown in Fig. 5, both HQ and Business Units participate in the operation of the SOA project’s management).

Fig. 4. Life cycle models, Reference Architectures and Enterprise Service Bus mappings on simplified GERA MF (aspects irrelevant to specific mapping omitted)

3.8 The SOA Team

The SOA team is in GERA terms the human component of the SOA project processes. We subscribe to Knippel’s (2005) view that appointing a separate, dedicated and independent SOA team can be detrimental if an EA team exists and has (or can gather) the necessary SOA skills. The SOA/ EA team must have sufficient authority and management support. Such aspects can be detailed within the Functional and Organisational aspect (see Fig. 3, right).

3.10 SOA Methodologies

In GERAM terms, EA methodologies (called Enterprise Engineering Methodologies - EEMs) aim to assist in the (re)engineering and in the management of on-going change within a business. Typically, models of an AS-IS (present) state and one or several TO-BE (desired future) state(s) are created, with the methodology providing a set of process descriptions required to reach the chosen TO-BE from the AS-IS. An important issue in EA is achieving a common stakeholder understanding of the AS-IS and potential TO-BE states. Similarly, in an SOA adoption/on-going project, understanding the AS-IS is paramount e.g. in order to determine what might constitute a service and what services may be needed in the TO-BE state.

Many EA methodology models (such as proposed by Spewak (1993)) include guidelines reflecting principles that cut across business units, e.g. cultural change and politics. Such principles applied to SOA – such as promoting a culture of sharing and reuse and obtaining enterprise-wide support are at the very heart of a successful outcome.

Noran (2006) describes a set of steps that can be used to produce a methodology for a specific EA project (a ‘meta-methodology’) involving several businesses. This concept can be readily applied to an SOA project if the participating businesses are replaced with units of the same business, business HQ, etc and the end products are deemed to be the SOA project and its deliverables / artefacts.

Sample dedicated SOA methodologies are the OASIS SOA Adoption Blueprints (SAB) (OASIS SOA Adoption TC 2006) and Erl’s Mainstream SOA Methodology (MSOAM) (Erl 2007). These methodologies are in GERA terms reference models of processes and as such they map onto the functional aspect at the Partial Level of GERA (see Fig. 3, left) at the Requirements and Architectural and Detailed Design life cycle phases (depending on how detailed the methodology is). Further mapping details are available however have not been shown here due to space limitations.

3.11 SOA Quality of Service and Quality Control

Quality of Service (QoS) is an essential aspect in SOA acceptance. QoS monitoring can be partially automated; however, underlying requirements must be specified e.g. in the Service Level Agreements (SLAs) that would map onto the Functional and Resource aspects at the Requirements life cycle phase in the GERA MF (the functional aspect determining the services to be provided, while the Resource aspect detailing the required capabilities of the resources used to implement the services – i.e. non-functional requirements). Quality control aspects such as version control, reuse policies, service document rules, security models and policies, test procedures etc - are also typically expressed in specification documents. Depending on the level of detail they could be mapped onto the Functional aspect of the Requirements and Architectural life cycle phases in the GERA MF (see Fig. 4, left).

3.12 Enterprise Service Bus

The current definitions of an Enterprise Service Bus (ESB) according to various sources (vendors, practitioners, academics etc) appear to be inconsistent: service integration architecture, integration middleware product, web–services capable infrastructure, etc.

It may be that in fact all these views are correct and that they are simply expressing the same concept materialised at different life cycle phases of the ESB. Thus, using a life cycle–enabled perspective (such as provided by a ‘type 2’ architecture described in the GERAM specification), the ESB as policy would reside in the Concept area; the ESB as architecture can be an RM in the Architectural Design life cycle phase; and ESB as middleware and possibly part of the infrastructure could then reside in the Architectural and Detailed Design life cycle phases. Therefore, various stakeholders can describe the ESB differently depending on the life cycle phase they wish to illustrate (see Fig. 4, right).

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 also 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 declaring / 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 independently 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 requirements 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 requirements may also change – e.g. performance requirements (for service and management) 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 also, because when if services are become sharable applications they are no longer separately maintained for servicing aa 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 for the allocation of suitably competent employees to service provision and management in order to ensure the required level of QoS.

A question arises: once the principles and tasks are defined, should a new requirements 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 principles 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 necessary new artefacts (models).s

Sample Business Model of an SOA Scenario

The following example aims to illustrate the previous description of the role of EA artefacts and business model using a modelling formalism derived from the GERA MF (the life cycle - instantiation plane - see Fig. 2).

In the SOA scenario in Fig. 5, the headquarters of a business sets up an SOA project but also the mission, vision, design principles, policies and high-level requirements 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 operational, 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 understanding 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.

Fig. 5. Relation project / product / services (based on (Bernus 2008))

As can be seen from Fig. 5, the business model is in fact an architecture description (a description of the business at the GERA MF architectural design level) that is intended 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 (Bernus 2008), while (Noran 2007b) describes a way to use the business model to derive a directly applicable step-by-step methodology to create and operate the specific SOA project and its deliverables.

5 Conclusions and Further Work

In this paper, we have argued that the use of EA frameworks and approaches is suitable and beneficial in SOA projects. The mappings shown are by no means comprehensive; 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 essential 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 supporting 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 performed 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 (GAO 2003) or development kits (NASCIO 2004) also need to be tested for use in SOA projects.

Acknowledgements: this is an extended and revised version of a paper submitted to ISD2008.


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2016
rəhbərliyinə müraciət