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

Transcription

1 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. 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 ongoing EA initiative is a best practice that 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 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 componentbased 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

2 2 O. Noran, P. Bernus business has contributed to SOA being sometimes seen as a separate approach, a competitor and perhaps a successor of Enterprise Architecture (EA). This paper argues that SOA is a style and/or component of EA rather than an alternative 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 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 basis 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 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, a 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 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 such as ISO/IEC 42010:2007 (ISO/IEC 2007)), ISO/IEC 15288:2002 (ISO/IEC 2002), etc.

3 SOA vs. EA: Competition or Synergy? 3 This ensures that GERAM will always include a set of essential concepts shared and agreed upon by the EA community. OASIS Reference Architecture SOA-PG Reference Architecture MSOAM, OASIS SAB BPEL, BPMN... OASIS Reference model GERA Generalised Reference Architecture EEM Enterprise Engineering Methodology utilised in EML Enterprise Modelling Language CBDI Metamodel Open Group SOA Ontologies SOA-PG Reference Model GEMC Generic Enterprise Modelling Concept PEM Partial Enterprise Model used in supports define meaning of implemented in EET Enterprise Engineering Tool used to build EM Enterprise Model SOA Tools SOA Models Linthicum metamodel SOA Trusted Components EMO Enterprise MOdule GERAM Boundary used to implement EOS Enterprise Operational System Executable Services 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.

4 4 O. Noran, P. Bernus 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. Views Generic Partial Particular Instantiation Identification Concept Requirements Arch. design Management and Control Product or Customer Service Software Hardware Design Detailed design Implementation Operation Decommission Life Cycle Phases Resource Organisation Information Function Machine Human 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

5 SOA vs. EA: Competition or Synergy? 5 defining the semantics of the modelling languages used. The Open Group ontology document currently contains definitions for contract, visibility, registry etc. Its structure and contents does abide by the GERAM definition; 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, 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 aspects present in 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 (see GERA MF life cycle phases in Fig. 2). 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 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.

6 6 O. Noran, P. Bernus The RA described in the Practitioner s Guide (PG) authored by Durvasula et al. (2007) specifies the structure and the functionality of model components and thus appears 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. EA 3 Fwk (FIR) Bell s Fwk (FIRO) C R AD DD I SOA Project Partial Level I F OASIS SAB MSOAM R O SOA-PG RA OASIS RA R AD DD I SOA Project Partial Level O F SOA Team (FO) 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.

7 SOA vs. EA: Competition or Synergy? 7 As another example, the EA 3 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). SOA Project Partial Level CS M Id SOA Vision C R AD DD I I F QoS, SLA R O SOA-PG Life Cycle IBM Life Cycle C R AD DD I Op ESB = Policies ESB = Specification ESB = Architecture ESB = Middleware ESB = Web Services M CS M H Governance (Mgmt side) D Possible ESB meanings along its life cycle Fig. 4. Life cycle models, Reference Architectures and Enterprise Service Bus mappings on simplified GERA MF (aspects irrelevant to specific mapping omitted) 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, right). 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.

8 8 O. Noran, P. Bernus 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. 4, 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 and detailed in Fig 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 crossdepartmental 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 as shown in Fig. 5. Representing the location and extent of governance on the GERA framework allows headquarters 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 SOA project s management processes are partly performed by project management personnel, while other parts are performed by the

9 SOA vs. EA: Competition or Synergy? 9 body that provides governance (thus, as shown in Fig. 5, both headquarters and business units participate in the operation of the SOA project s management). 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) 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

10 10 O. Noran, P. Bernus 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 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 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. nonfunctional 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) 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 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:

11 SOA vs. EA: Competition or Synergy? 11 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 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 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 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 (e.g. models) 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).

12 12 O. Noran, P. Bernus 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. Id C R AD DD I Op D CS M BPMES: Bus. Process Mgmt & Exec Serv. DS: Data Service IS: Infrastructure Service AS: Application Service HQ: Headquarters BU BU SP HQ BU: Business Unit SP : SOA Project BPMES DS IS AS M: Management CS: Customer Service Id: Identification C: Concept development R: Requirements AD: Architectural Design DD: Detailed Design I: Implementation Op: Operation D: Decommissioning 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

13 SOA vs. EA: Competition or Synergy? 13 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 serviceoriented 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 a revised and extended version of a paper accepted at ISD 2008.

14 14 O. Noran, P. Bernus References Bell, M. (2008). Introduction to Service-Oriented Modeling. In Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture, Wiley & Sons. Bernard, S. A. (2005). An Introduction To Enterprise Architecture. AuthorHouse, Bloomington, IN, Bernus, P. How To Implement SOA For The Whole Of Business. Paper presented at the Service Oriented Architecture Implementing And Measuring Soa Projects To Drive Business Value, Syndey,2008 CBDI. (2007). CBDI-SAE Meta Model for SOA Version 2. Available: Durvasula, S., Guttmann, M., Kumar, A., Lamb, J., Mitchell, T., Oral, B., Pai, Y., Sedlack, T., Sharma, H.and Sundaresan, S. R. (2007). SOA Practitioner's Guide. BEA Systems, Inc. Available: Erl, T. (2007). Appendix B: Process Descriptions. In SOA: Principles of Service Design, Prentice Hall PTR. Fenn, J., Linden, A.and Cearley, D. (2005). Hype Cycle for Emerging Technologies, Gartner Group. Available: GAO. (2003). IT - A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1). US General Accounting Office. Available: IBM. (2007a). The Role of SOA Quality Management in SOA Service Lifecycle Management. (PDF Document). Available: IBM. (2007b). SOA Governance and LifeCycle Management. (PDF Document). Available: y/soahighway/pdf/soa_gov_slm_brochure.pdf, ISO/IEC. (2002). ISO/IEC15288: Information Technology - Life Cycle Management -System Life Cycle Processes., ISO/IEC. (2005). Annex C: GERAM. In ISO/IS 15704:2000/Amd1:2005: Industrial automation systems - Requirements for enterprise-reference architectures and methodologies. ISO/IEC. (2007). ISO/IEC 42010:2007: Recommended Practice for Architecture Description of Software-Intensive Systems. Knippel, R. (2005). Service Oriented Enterprise Architecture (Doctoral Thesis). IT-University of Copenhagen, Copenhagen Linthicum, D. S. (2007). SOA Meta-model. (PDF). Linthicum Group. Available: McGovern, J. (2003). Service Oriented Architecture. In J. McGovern, et al. (Eds.), A Practical Guide to Enterprise Architecture, Prentice Hall PTR, Upper Saddle River, NJ, pp

15 SOA vs. EA: Competition or Synergy? 15 NASCIO. (2004). Enterprise Architecture Development Tool-Kit v3.0. National Association of State Chief Information Officers. Available: Noran, O. (2003), An Analysis of the Zachman Framework for Enterprise Architecture from the GERAM perspective. IFAC Annual Reviews in Control, Special Edition on Enterprise Integration and Networking(27), pp Noran, O. (2005), An Analytical Mapping of the C4ISR Architecture Framework onto ISO15704 Annex A (GERAM). Computers in Industry, 56(5), pp Noran, O. (2006), Refining a meta-methodology for collaborative networked organisations: a case study. Int. J. Networking and Virtual Organisations, 3(4), pp Noran, O. (2007a). Discovering and modelling Enterprise Engineering Project Processes. In P. Saha (Ed.), Enterprise Systems Architecture in Practice, IDEA Group, Hershey, USA. Noran, O. (2007b). Discovering and Modelling Enterprise Engineering Project Processes. In P. Saha (Ed.), Enterprise Systems Architecture in Practice, IDEA Group, Hershey, USA, pp OASIS SOA Adoption TC. (2006). SOA Adoption Blueprint - 'Generico'. OASIS Group. Available: doc, OASIS SOA Reference Model TC. (2008). OASIS Reference Model for Service Oriented Architecture V 1.0. OASIS Group. Available: Saha, P. (2007). A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO15704:2000 Annex A). In P. Saha (Ed.), Enterprise Systems Architecture in Practice, IDEA Group, Hershey, USA, pp Schönherr, M. (2004). Connecting EAI-Domains via SOA - Central vs. Distributed Approaches to Establish Flexible Architectures. In P. Bernus, et al. (Eds.), Knowledge Sharing in the Integrated Enterprise: Interoperability Strategies for the Enterprise Architect, Kluwer Academic Publishers, Toronto / Canada, pp SOA WG - The Open Group. (2006). Open SOA Ontology. The Open Group,. Available: Spewak, S. H. (1993). Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. Wiley, Sprott, D.and Wilkes, L. (2005), Enterprise Framework for SOA. Component based Development and Integration Journal, pp.