WIXLIB

Service-Oriented ArchitectureThe Problem of Semantic InteroperabilityAs illustrated in Figure 5, each business process has its own vocabulary. To make things worse, thesevocabularies often contain terms that are specific to a particular enterprise or department; two differentmanufacturing companies, for example, may describe the same manufacturing operations in different ways.And the messages that a particular service generates or accepts are often defined in terms of a particularvocabulary.Figure 5: The Problem of Semantic InteroperabilityAt present, this problem is typically addressed within the services, and by use as far as possible of enterprisestandard and industry-standard vocabularies. In the future, it may be addressed by semantic technology thatis incorporated in the infrastructure, which will be a more scalable way to deliver the ideal of BoundarylessInformation Flow.SOA as an Architecture StyleThe key difference that SOA makes to software architecture is that the software building blocks are looselycoupled services that can be combined dynamically, as opposed to subroutines, scripts, or other forms ofprogram that invoke each other directly.A further difference is the increased emphasis on infrastructure support for service development andevolution. The enterprise architect has always been concerned with principles and guidelines governing theevolution of the architecture components over time. With SOA, this extends to the specification of particulardevelopment tools and methods, and their incorporation in the infrastructure to provide software servicelifecycle support.The ability to develop and modify services rapidly, and the need to ensure that this supports the businessoperations as effectively as possible, impacts on governance: the process by which the translation of thewww.opengroup.orgA White Paper Published by The Open Group10

Service-Oriented Architecturearchitect’s specifications into implemented systems, and the continuing evolution of those systems, iscontrolled.Finally, the ability of SOA to support Boundaryless Information Flow represents a major improvement overearlier architectural styles.SOA is an evolution of traditional enterprise architecture styles, not something different. It has new features,which deliver major benefits. Enterprise architects must be able to take advantage of these new features, andthey must therefore be supported by the architecture frameworks that those architects use.www.opengroup.orgA White Paper Published by The Open Group11

Service-Oriented ArchitectureThe Open Group Architecture Framework (TOGAF)This chapter contains a simplified description of The Open Group Architecture Framework (TOGAF)Version 8.1.1. The reader is encouraged to consult the full description that is freely available from The OpenGroup website [3].TOGAF has three major sections: The Enterprise Continuum, which helps the architect manage different levels of abstraction andprovides context for the use of relevant architecture assets The Resource Base, which is a set of supporting resources, such as guidelines, templates, and checklists The Architecture Development Method (ADM), which many regard as the core of TOGAFThe TOGAF ADMThe TOGAF ADM breaks down the process of developing an enterprise architecture into a number ofphases. First, there is a preliminary phase concerned with establishing principles and configuring theframework itself. This is followed by eight phases that are shown in order of logical dependency, but that aretypically executed iteratively: over the whole process, between phases, and within phases. Central to thesephases is the process of requirements management. This is illustrated in Figure 6.Figure 6: The TOGAF Architecture Development Method (ADM)www.opengroup.orgA White Paper Published by The Open Group12

Service-Oriented ArchitectureThe eight iterative phases are as follows. Architecture Vision: creating a summary of the architecture and what it should achieve, forcommunication throughout the enterprise (and to obtain approval and funding). Business Architecture: describing the product and/or service strategy, and the organizational,functional, process, information, and geographic aspects of the business environment, based onbusiness principles, business goals, and strategic drivers. Information Systems Architectures, comprising:oData Architecture: defining the major types and sources of data necessary to support thebusiness.oApplications Architecture: defining the major kinds of application system necessary to processthe data and support the business. Technology Architecture: delivering a specification of the technical solution at the level necessary tosupport implementation. Opportunities and Solutions: generating an overall implementation and migration strategy byevaluating implementation options, identifying parameters for change, and assessing dependencies,costs, and benefits. Migration Planning: sorting the various implementation projects into priority order and creating adetailed Implementation Plan and Migration Plan. Implementation Governance: developing and operating a process to ensure conformance with thedefined architecture by implementation projects. Architecture Change Management: establishing a process for the evolution of the new enterprisearchitecture in the light of developments in technology and changes in the business environment.www.opengroup.orgA White Paper Published by The Open Group13

Service-Oriented ArchitectureSOA and TOGAFThis chapter describes the application of TOGAF to SOA, focusing on the eight iterative phases of theTOGAF ADM.TOGAF as a whole provides a valid framework for SOA. 2 Some parts of it – the Enterprise Continuum andthe Preliminary, Opportunities and Solutions, and Migration Planning phases of the ADM – are unaffected.The ways in which the other phases of the ADM are carried out are changed, in some cases quite radically.New, SOA-specific resources are needed for the Resource Base.The rest of this section considers the iterative phases of the ADM, and evaluates the impact on them of SOA.Phase A: Architecture VisionThe general approach to the Architecture Vision phase is not changed. The vision, naturally, will be aservice-oriented one, achieving benefits such as improved enterprise agility and information flow. But a fullblown SOA may not be appropriate for the enterprise in question and, if the enterprise does not yet haveextensive experience of SOA, it may wish to apply it in one particular area, perhaps as a pilot project, ratherthan enterprise-wide. The Architecture Vision phase will set out the scope of the SOA project within theenterprise, and the level of SOA to be achieved.Phase B: Business ArchitectureThe Business Architecture phase is concerned not only with the operations performed by humans, but alsowith the software services and business information that support them, as shown in Figure 7.Figure 7: Scope of the Business Architecture Phase2This is an interim conclusion of the SOA/TOGAF Practical Guide project of the SOA Working Group.www.opengroup.orgA White Paper Published by The Open Group14

Service-Oriented ArchitectureIn this phase, what should be done by people and what should be done by technology may not be clear – andshould not have to be clear. The business operations should be described without regard to how they will beimplemented.One major difference for an SOA project is that it will be natural and desirable to describe the businessoperations as services.The second major difference is that, while the existing business operations can be described precisely, thetarget operations that the architecture will support in the future may not all be known; business agility is akey benefit of SOA. Because of this, the Business Architecture phase of an SOA project may, as well asdescribing specific business operations, describe methods for developing new ones.Phase C: Information Systems ArchitecturesThe Information Systems Architectures phase consists of two parts: Data Architecture and ApplicationsArchitecture.An important consideration for both parts of this phase is that they must consider how the new services willinterwork with existing applications that will not be converted to services. “Legacy”, as ever, must not beforgotten.Data ArchitectureThe Data Architecture part of the Information Systems Architectures phase is concerned with the BusinessInformation component of Figure 4, as shown in Figure 8.Figure 8: Scope of the Data Architecture Sub-PhaseThis is crucial to an SOA project. There is as yet no best practice for it that is specific to SOA, although thereis much interesting work in progress; for example, on the Semantic Web.www.opengroup.orgA White Paper Published by The Open Group15

Service-Oriented ArchitectureApplications ArchitectureThe Applications Architecture part of the Information Systems Architectures phase is concerned with theSoftware Services component of Figure 4, as shown in Figure 9.Figure 9: Scope of the Applications Architecture Sub-PhaseWhen TOGAF is used to develop a solution architecture, this phase may identify specific applicationcomponents; but when it is used to develop a high-level enterprise architecture it will often just describegeneral application areas.The key distinguishing feature of an SOA is that the software applications are defined as loosely-coupledservices. Again, for an agile enterprise, it will in general not be possible to describe all the target servicesprecisely, and this phase may describe methods for defining and evolving services as well as identifyingapplication service areas or describing particular services.Phase D: Technology ArchitectureJust as the Business Architecture phase is not only concerned with operations performed by humans, theTechnology Architecture phase is not only concerned with the infrastructure. As shown in Figure 10, it isconcerned with the technical specification of the infrastructure and also of the software services and businessinformation.www.opengroup.orgA White Paper Published by The Open Group16

Service-Oriented ArchitectureFigure 10: Scope of the Technology Architecture PhaseHaving said which, a particular kind of infrastructure is needed to support the service paradigm, and thespecification of this kind of infrastructure (service bus, registry, etc.) is an important feature of theTechnology Architecture phase for SOA.The second difference for this phase is the focus on tools. Methods are important for the BusinessArchitecture and Information Systems Architectures phases of SOA development. The TechnologyArchitecture phase must specify the tools to support these methods.A third difference is that, although the infrastructure does not have to be service-oriented to support SOA,many SOA projects will wish to apply the principle of service-orientation at all levels, and specify a serviceoriented infrastructure. The SOA Working Group is investigating this topic; see “Service-OrientedInfrastructure” in Appendix A, Current SOA Working Group Projects on page 20.Like the Information Systems Architectures phase, the Technology Architecture phase must also considerhow the new services will interwork with existing applications that will not be converted to services.Phase E: Opportunities and SolutionsSOA has little impact on the Opportunities and Solutions phase of TOGAF.Phase F: Migration PlanningSOA has little impact on the Migration Planning phase of TOGAF.www.opengroup.orgA White Paper Published by The Open Group17

Service-Oriented ArchitecturePhase G: GovernanceSOA Governance is the application of Enterprise Architecture, IT, and Corporate Governance to ServiceOriented Architecture. 3 The SOA Governance processes focus on governing the service lifecycle, supportingservice infrastructure, and compliance with the service oriented architecture of the organization.Corporate Governance affects the implementation of the Business Architecture; and IT Governance affectsthe implementation of the Information Systems Architectures and the Technology Architecture. ArchitectureGovernance ensures that the integrity of the architecture as a whole is maintained.With SOA, it is generally the case that each part of the enterprise depends on services provided by otherparts. This helps to improve the overall efficiency of the enterprise, and allows for greater service re-use, andshould therefore be encouraged. But it means that good governance is essential, so that the service users areassured that service provision will be maintained in the manner that they expect.Also, the increased emphasis that SOA has on methods and supporting tools, and the nature of the servicelifecycle, impact on Corporate and IT Governance, and this impact must be addressed in the ImplementationGovernance phase.Phase H: Architecture Change ManagementModification of the architecture itself is addressed in the Architecture Change Management phase. SOAdelivers agility. Changes to services and development of new services should no longer be regarded aschanges to an architecture, when they are carried out using methods that are part of that architecture. Projectsthat in a traditional architectural approach would be subject to Architecture Change Management maytherefore be covered by Implementation Governance in SOA. The dividing line between projects thatimplement the architecture and projects that change it remains; but SOA can move projects across that lineby including methods for change within the architecture.3This is an interim conclusion of the SOA Governance project of the SOA Working Group.www.opengroup.orgA White Paper Published by The Open Group18

Service-Oriented ArchitectureAppendix A: Work on SOA within The Open GroupThe Open Group formed its SOA Working Group [4] in October 2005 in response to the rapidly growinginterest in SOA and the importance of SOA to its vision of Boundaryless Information Flow.The SOA Working Group was constituted as a working group of The Open Group joint Customer Counciland Supplier Council, to facilitate participation by all members.The mission of the SOA Working Group is to develop and foster common understanding of SOA in order tofacilitate alignment between the business and information technology communities.It does this by conducting a work program to produce definitions, analyses, recommendations, referencemodels, and standards to assist business and information technology professionals within and outside of TheOpen Group to understand and adopt SOA.In addition to setting up the SOA Working Group, The Open Group also established, in October 2006, aspecial working group of its Governing Board to develop a maturity model for SOA, based on input fromIBM.This appendix describes the SOA-related activities of The Open Group, including the work program of theSOA Working Group and the Governing Board SOA Maturity Model working group.Initial ActivitiesFollowing its formation, the SOA Working Group set up three projects to establish its role and eventualscope of work: Definition of SOA SOA Case Studies Evaluation of the Value that The Open Group can add to the Evolution of SOAThese projects are now all completed. Their results form the basis for the current program of work.Definition of SOAIn order to promote better understanding and to give the IT industry an opportunity to make progress, it isimportant to come to a single, generally agreed definition of SOA. This project was responsible fordeveloping that definition and promoting it through the SOA Working Group to the rest of The Open Groupand the industry in general, to help both business and technical people to gain a better understanding of SOAconcepts.Under the leadership of Dave Hornford of Hornford Associates, the project team reviewed a number ofexisting definitions for SOA and services and the emerging OASIS SOA Reference Model, and delivered abasic definition of SOA. This definition is reproduced in Definition of SOA on page 6.SOA Case StudiesMuch has been made of the business benefits offered by adopting a Service-Oriented Architecture.Companies must be able to understand how to obtain those benefits in order to realize th

Service-Oriented Architecture www.opengroup.org A White Paper Published by The Open Group 4 Boundaryless Information Flow achieved through global interoperability in a secure, reliable, and timely manner Executive Summary Service-Oriented Architecture (SOA) is an architectural style that has recently come to prominence.