Mapping SOA Artefacts onto an Enterprise Reference Architecture Framework
Ovidiu Noran
Griffith University Australia, School of ICT,
Abstract.Currently, there is still no common agreement on the Service Oriented Architecture (SOA) definition, or the types and meaning of the artefacts involved in the creation and maintenance of an SOA. Furthermore, the SOA image shift from an infrastructure solution to a business-wide change project may have promoted a perception that SOA is a parallel initiative, a competitor and perhaps a successor of Enterprise Architecture (EA). This paper attempts to map several typical SOA artefacts onto an enterprise reference framework commonly used in EA. This is done in order to show that the EA framework can express and structure most of the SOA artefacts and therefore, a framework for SOA could in fact be derived from an EA framework with the ensuing SOA-EA integration benefits.
1Introduction
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 with all necessary information) and service consumer as a basis to structure the functionality of an entire business. The SOA concept is notnew, originating in the modular, object-oriented and component-based software development paradigms. However, the lack of adequate supporting and realisation infrastructure have in the pasthindered its adoption(Schönherr 2004).According to Gartner Group, after the typical wave of vendor hype and unrealistic expectations, SOA appears to be now recovering from the disillusionment phaseand 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 arigorous SOA definition, or the types and meaning of the artefactsthat should be involved in the creation and maintenance of an SOA. Furthermore, the realisation that building an SOA involvessignificant costs and changes to the entire business has contributed to SOA being sometimes seen as a separateapproach, a competitor and (aided by vendor hype) perhaps a successor of Enterprise Architecture (EA).
This paper attempts to advocate the benefits of using a reference framework in finding common, agreed-upon meanings and actual coverage of the various artefacts involved in an SOA effort. More importantly however, it attempts to show that SOA is potentially a possible style and component of EA rather than an alternative. These aims are pursued by mapping several typical artefacts described in SOA literature 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; rather, the aim is to prove the concept and promote constructive debate.
Fig. 1 Sample mapping of SOA artefacts on GERAM (ISO/TC184 2000)
(dashed outline boxes show possible / generic SOA elements)
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 specialised from an enterprise referenceAF, thus facilitating synergy between and integration of SOA and EA.
The reference framework proposed is described in Annex A of ISO15704:2000, and it is called the Generalised Enterprise Reference Architecture and Methodology, or GERAM (ISO/TC184 2000). ISO15704:2000 sets requirements for reference architectures and methodologies (without prescribing any specific artefacts) and 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 2007). GERAM is not claimed to contain the ultimate list of artefact types; notably, the concept of stakeholder present in ISO/IEC 42010:2007(ISO/IEC/ JTC1/ SC7 2007)) is missing from GERAM. Nevertheless, GERAM is currentlyone of the most complete reference AFs.
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 theproject/product’s life cycle. The GERA MF also features the genericity dimension, which allows representingthe meta-models and ontological theories underlyinglanguages used to build partial (e.g. reference) and particular models.Thus, the GERA MFcontains placeholders for models describing the components shown in the GERAM structure depicted in Fig. 1.Full descriptions of GERAM, GERA and GERA MF are beyond the scope of andspace available for this paper. The keen reader can find all the details in (ISO/TC184 2000).
3 Sample Mappings of Typical SOA Artefacts on GERAM
The following section attempts to map some SOA artefacts currently offered by vendors and / or described in SOA literature and deemed of interest to the scope of this paper. The selection does not aim to recommend or favour any specific artefacts.
Fig. 2 GERA MF(ISO/TC184 2000)
3.1 SOA Ontologies
The SOA Working Group (WG) ofThe 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 (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/TC184 2000). 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 calledan SOA metamodel.However, according to the definitions above, the artefact is rather a high-level reference model since it describes anSOA 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.3SOA Reference Models and Reference Architectures
Many vendors and consultants (IBM, BEA, Oracle, WebMethods, etc) offerwhat 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 RMfrom 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 at the Architectural Design life cycle phase. The OASIS Concrete Architecture is in EA the Architectural Design level model of the 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 inFig. 1 andFig. 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.4SOA Modelling / Documentation Framework
An MF according to ISO15704:2000 is a structure that holds models describing all necessaryaspects of enterprisesand/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 aDF 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.
Fig. 4. Relation project / product / services (based on (Bernus 2008))[anon1]
As another example, the EA3 framework described byBernard (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 Lifecycle
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 (seeFig. 5, 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; thissubdivision exists in the GERA MF and the mapping reflects this situation (seeFig. 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. 4. The figure presents (using a simplified GERA MF modelling formalism) a possible SOA initiative scenario, where the headquarters (HQ) of a business sets up an SOA project but also sets the mission, vision, the design principles and policies, and high-level requirements for the services required.[anon2] 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. Figure 4 shows how an EA-specific representation can be used to describe an SOA-specific scenario.
3.6SOA 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 inanyEAproject.The vision maps onto the Concept development life cycle activity area of GERA, where the stakeholders decideif 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 be present contributing to at 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 includeing 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. 4. 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 personnell, while other parts are performed by the body that provides governance (thus, as shown in Fig. 4, both HQ and Business Units participate in the operation of the SOA project’s management).
Fig. 5. 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 aspect component of the SOA project processes. We subscribe to Knippel’s (2005) view that appointing aseparate 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 beneeded in the TO-BE state.
Many EA methodology models (such as proposed by Spewak(1993)) include guidelines reflecting principlesthat 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’sMainstream SOA Methodology (MSOAM) (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. 4, left) at the Requirements and Architectural and Detailed Design life cycle phases (deending on how detailed the methodology is). Further mapping details are available, however,have not been shown here due to space limitations.
3.11SOA 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 servces to be provided, while the Resource 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,[anon3] security models and policies, test proceduresetc - arealso typically expressed inspecification documents. Depending on the level of detail they could be mapped onto the Functional aspect of the Requirements and Architectural life cycle phasesin the GERA MF (Fig. 5, left).
3.12 Enterprise Service Bus and Policies
The current definition of an Enterprise Service Bus (ESB)according to various sources (vendors,practitioners, academics etc) appears to be inconsistent: a service integration architecture, integration middleware product and a web–services capable infrastructure.As a result, Knippel (2005) concludes that the ESB policy is the most stable and thus important ESB artefact.