Abstract
In this series of articles we examine the correspondence, synergies and gaps of Service Orientation and The Open Group Architecture Framework. In this first set of articles we go through the phases, methods, iterations, layers, principles and roles. In part II of this article, we continue with governance issues. The part III of this article, we examines how services are architected and developed providing traceability to the business processes.
Introduction
SOA delivery projects contain stages found in traditional IT projects such as Service Design, Implementation and Testing, but also introduce new processes and stages, such as Service Inventory Analysis and Service Discovery within an Enterprise or Domain Service Inventory. Service Orientation [MSOAM] is a prescriptive vendor independent methodology for (a) delivering services as enterprise assets in a service inventory and (b) developing and governing the service inventory architecture in the enterprise, or in a set of domains of the enterprise. Item (b) corresponds to Enterprise Architecture.
The Open Group Architecture Framework (TOGAF) is a popular, vendor independent, generic Enterprise Architecture Framework, for developing architectures to meet different business needs. It is developed and evolved by members of The Open Group Architecture Forum. TOGAF is descriptive but not prescriptive, and can be tailored to be used together with other architecture and project frameworks and methods. TOGAF 9 extends previous versions of TOGAF dramatically, but for the purposes of this document we concentrate in the support for SOA as an Architecture Style. TOGAF 9 provides a set of Guidelines on how to use a subset set of TOGAF Phases, Inputs and Outputs in SOA Projects and the benefits gained by doing this. This is done both within the TOGAF 9 definition (see [TOGAF] Chapter 22: Using TOGAF to Define & Govern SOAs) and also within the SOA-TOGAF project (see [TOGAF-SOA]).
In these series of articles we will examine how we can use synergies between the two methodologies and what is needed to check when we practice either one but want to use features from the other.
Motivation: SOA is an EA
The starting point for our work is the observation that Service Orientation is a methodology that allows for the definition, development and governance of an Enterprise Architecture. In particular Service Orientation allows for all the features of an EA:
| • |
it defines a complete methodology for service delivery with several strategies (top-down, bottom-up, meet in the middle), concrete criteria for following one strategy over the other (tactical vs. strategic), criteria for choosing and building one service over another, criteria for introducing or hiding platforms, and provides corresponding governance models |
| |
SOA / Service Orientation |
TOGAF |
| SOA |
SOA is considered an architecture with the following characteristics:
| • |
business driven |
| • |
enterprise centric |
| • |
vendor neutra |
| • |
composition centric |
It delivers technical solutions on which the service orientation principles have been consistently applied in several stages.
|
SOA is considered a Business-Led Architecture Style.
There is a recommended Service Contract Template (for Service Governance) and a small set of extensions in the TOGAF content metamodel
|
| Architecture Focus |
Service Inventory (for Enterprise or Domain)
Service & Service Composition
|
Enterprise, including Architecting the Business. Typically used by IT supporting the Business, but can be applied in Organizations independent of IT.
|
| Primary Objectives |
7 Strategic goals related to:
| • |
IT (4) |
| • |
Business-IT relationship (3) |
|
Realization of Business Vision (technology is seen as a way to realize a business vision)
|
| Scope |
Inventory Analysis (Enterprise, Domain)
Project
Methodology, principles and objectives, analysis and implementation-oriented aspects within the service inventory
|
Enterprise (incl. Non-IT)
Segments of the Architecture
Methodology for high-level strategic and governance issues
|
| Layering |
Explicit relationships between architectural and design layers, such as the inventory, processes, services and applications or compositions.
|
The Architecture Development Method (ADM) is confined to a single architectural layer, but there is an implicit hierarchy of architecture layers
|
| Iterations |
Service Inventory Analysis
Service Analysis
Service Design
|
Architecture Definition
Transition Planning
Architecture Governance
|
| Enterprise Assets |
Services
|
Architecture Building Blocks
Solution Building Blocks
|
Table 1 - Several dimensions of comparing Service Orientation and TOGAF
| • |
It provides a well-defined set of principles, patterns, standards, and contexts which can be used for performing the following:
| - |
segmentation of an enterprise into a set of federated domain inventories |
| - |
analysis of a service inventory and business processes |
| - |
modelling of services |
| - |
design of service contracts and service logic |
| - |
implementation of contracts and logic |
| - |
tracing all design & implementation to business processes and services |
| - |
applying security in the inventory |
| - |
deploying the services in a cloud |
| - |
governing the service inventory and the services |
|
| • |
It allows for multiple views of the same business process, service and technology through several service models (entity, composition, process, utility), several dimensions and levels of abstraction (contract, schema, policy, domain, composition, service, contract, logic, etc.) all of which can be combined to demonstrate how the concerns are supported. |
This methodology can be mapped to features of an Enterprise Architecture Framework such as TOGAF.
The dimensions we consider for the mapping of Service Orientation to TOGAF include: phases and iterations (Figure 1), architecture principles, inventory vs. service, domain vs. enterprise, roles, pillars and strategic goals. In Table 1 we provide a preliminary mapping of basic elements of both methodologies. Although there is a fair amount of correspondence between Service Orientation and TOGAF, there are also some mismatches. These are the areas where Service Orientation can complement TOGAF and vice versa.
The purpose of this mapping is to determine:
| • |
synergies and gaps between TOGAF and Service-Orientation |
| • |
how TOGAF emphasizes particular elements of SOA and Service-Orientation |
| • |
how Service-Orientation emphasizes particular aspects of TOGAF |
| • |
how TOGAF can be extended with Service-Orientation elements |
| • |
how the application of Service-Orientation can benefit from TOGAF practices |
TOGAF ADM Phases
|
SOA Phases
|
|
SOA Adoption Planning
Service Inventory Analysis
Service-Oriented Analysis (Service Modeling)
Service-Oriented Design (Service Contract)
Service Logic Design
Service Development
Service Testing
Service Deployment and Maintenance
Service Usage and Monitoring
Service Versioning and Retirement
|
Figure 1 - TOGAF ADM and SOA Phases |
Approach
This article is the first publication on the mapping of SOA to TOGAF. In this article we will not repeat the guidelines, the inputs and the outputs for delivering SOA with TOGAF. These can be found directly in to the TOGAF references provided previously. This approach is richer and provides insight in the relationship between the two methodologies. The guidelines provided by TOGAF 9 can be used as a verification of our mapping.
In this first set of articles we will concentrate on the correspondence of the two methodologies in terms of processes, steps, inputs and outputs; that is, we concentrate on the core of the two methodologies. In follow-up articles we will concentrate on the governance elements of the two methodologies and on recommendations. Finally, in a third article we will check the traceability of services to the business processes and architecture.
These articles are intended for IT professionals with an EA background who want to better understand how EA and TOGAF in particular can apply to SOA projects, as well as those with an SOA background required to work with TOGAF.
In the rest of the article TOGAF refers to TOGAF 9, and SOA refers to MSOAM.
SOA Inventory Analysis and TOGAF Architecture Definition
A fundamental feature of SOA projects is the emphasis on the strategic target state that the delivery of each service is intended to support. This strategic target results in considerations on the time spent on the up-front Service Inventory Analysis and Modeling (including analysis and modeling of services) prior to the services physical design and development.
In the top-down project approach, the Service Inventory Analysis lifecycle consists of four steps that are applied iteratively (Figure 2). These steps define the architecture of the inventory and result in an inventory blueprint of all the planned services for a given inventory. The blueprint corresponds to the target architecture of the domain or enterprise service inventory in terms of business functionality, business entities, technologies and compositions.
In each service inventory the services are organized in service models based on the nature and the reuse potential of the encapsulated logic. Three service models are common to most enterprise environments and SOA projects:
| • |
Task Services have a non-agnostic functional context that generally corresponds to single-purpose, parent business process logic. They encapsulate the composition logic required to compose several other services in order to complete each task. |
| • |
Entity Services are reusable services with an agnostic functional context associated with one or more related business entities. |
| • |
Utility Services are reusable services with an agnostic functional context that encapsulates low-level technology-centric functions, such as notification, logging, and security processing. |
The Service Inventory Analysis defines the Architecture of the Inventory in SOA. Crucial for the Inventory Analysis is the ability to discover existing services or define services that can be discovered. Service Discovery is considered as separate phase in SOA. For the purposes of our mapping we include Service Discovery in the definition of the Service Inventory Architecture (Figure 3).
Figure 2 - The four primary steps that comprise the Service Inventory Analysis phase.
TOGAF ADM Phases
|
SOA Phases
|
|
SOA Adoption Planning
Service Inventory Analysis
Service-Oriented Analysis (Service Modeling)
Service-Oriented Design (Service Contract)
Service Logic Design
Service Development
Service Testing
Service Deployment and Maintenance
Service Usage and Monitoring
Service Discouvery
Service Versioning and Retirement
|
Figure 3 - The correspondence between the SOA Phases and the TOGAF Architecture Definition Phases |
Architecture development in TOGAF involves four architecture domains developed in three phases in TOGAF's Architecture Development Method (ADM) (see Figure 3)
| • |
The Business Architecture, developed in Phase B: Business Architecture, defines the business strategy, governance, organization, and key business processes. |
| • |
The Data Architecture, developed in Phase C: Information Systems Architectures, describes the structure of an organization's logical and physical data assets and data management resources. |
| • |
The Application Architecture, developed also in Phase C: Information Systems Architectures, provides a blueprint for the application systems to be deployed, their interactions, and their relationships to the organization's core business processes. |
| • |
The Technology Architecture, developed in Phase D: Technology Architecture, describes the required logical software and hardware capabilities to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc. |
For each of these architecture domains the objectives are the same:
| • |
describe the baseline business architecture |
| • |
develop a target business architecture |
| • |
analyze the gaps between the Baseline and Target Business Architectures |
| • |
select and develop the relevant architecture viewpoints that will enable the capitalize architect to demonstrate how the stakeholder concerns are addressed in each Architecture |
| • |
select the relevant tools and techniques to be used in association with the selected viewpoints |
The four architecture domains are developed in the three Architecture Definition phases B, C and D in TOGAF's ADM.
In the context of an enterprise or domain inventory, the process of creating an inventory blueprint (the inventory's architecture) corresponds to the development of the baseline and target architectures in the four architecture definition domains in TOGAF: business, data, application and technology (Figure 4). The structure of the Service Inventory Blueprint supports the various architecture viewpoints and it can be used as the tool for creating these views.
Figure 4 - The correspondence between the Service Inventory Analysis Phase and the TOGAF Architecture Definition Phases.
Service Models and TOGAF Architecture Domains
Three of the four TOGAF architecture domains correspond directly to the three service models in Service Orientation as shown in the first three rows of Table 2.
Business Architecture is not represented in any basic Service Model, since it is related to the operation of the business and not to the structure of the Inventory. However, manual and automated Business Processes and Services can be included in an additional Business Process model. It should be noted here that the scope of the Business Architecture in TOGAF is broader than just providing business models for usage in IT.
| Architecture Domain |
SOA Service Model |
TOGAF Term |
| Data Architecture |
Entity (Agnostic) |
Data Services |
| Application Architecture |
Task |
Application Services |
| Technology Architecture |
Utility (Agnostic) |
Infrastructure Services |
| Business Architecture |
Process (Non-Agnostic) |
Business Services |
Table 2 - Correspondence of Architecture Domains and SOA Service Models in an Inventory
Gaps between SOA Inventory Analysis and TOGAF Architecture Definition
The matching of TOGAF's Architecture Definition with SOA's Inventory Analysis requires additional features to both sets of phases, as illustrated in Figures 2 and 3 respectively. The following points are of particular interest:
| • |
TOGAF to support SOA:
| - |
SOA demands a high degree of interoperability across the architecture assets and the solution assets: this corresponds to TOGAF's interoperability degree 3B. Interoperability degrees less than this are unacceptable for achieving SOA (see Table 17 in the Appendix for a description of the degrees of interoperability). |
| - |
SOA defines a set of principles and patterns for Service Inventory Definition, Inventory Analysis, Inventory Layering, Centralization of Logic, Business Processes, Business Rules and Business Objects, Specification of Contracts, etc. These principles and patterns have to be used during architecture definition in TOGAF. |
| - |
Discovery of SOA Assets (Services) is performed via concrete mechanisms in SOA and this is used during the Inventory Analysis. Definition of Information Systems and Technology Architectures will benefit from these mechanisms. |
|
| • |
SOA to learn from TOGAF:
| - |
TOGAF recommends two definitions of architecture: the Baseline architecture and the Target architecture. It also defines criteria when to define the Baseline first (when extensions and reusability of current processes is desired) and when to define the Target first (when existing processes will not be reused or when the future state is agreed in advance). A Gap Analysis is the result of comparing the two architectures. This is used later for planning the service delivery and the intermediate architectures. SOA does not define two kinds of blueprints for this purpose, and the gap analysis is not explicitly performed. We consider the introduction of an explicit gap analysis and a roadmap as defined in TOGAF a positive extension to SOA. Notice that SOA provides patterns for refactoring or transforming inventories. This facilitates the creation of intermediate architectures. |
| - |
TOGAF uses the Business Scenarios as a means to identify business needs and requirements. Business Scenarios must have the SMART properties (Specific, Measurable, Attainable, Realistic, and Time-bound). We consider this kind of analysis of Business Processes beneficial for the Analysis Phase in SOA. |
| - |
An important feature of TOGAF is that interoperability and reusability should be present not only within IT assets (services) but also within Business assets (e.g. business services). SOA does not consider interoperability in its business dimension. What SOA allows though is for the reusability of elements of the business models within process and composition services. An extension of the definition of the current service interoperability principle in SOA to include business processes (and business services) will be of great importance for the success of SOA projects. |
|
Figure 5 - Additional input to TOGAF Architecture Definition Phases for supporting SOA.
Figure 6 - Additional input to SOA Inventory Analysis from TOGAF Architecture Definition Phases
SOA Service Delivery and TOGAF Planning & Architecture Governance
The inventory analysis phase is mandatory in SOA projects that follow a top-down approach or a meet-in-the-middle approach. On the other hand, all SOA projects, including those that follow a bottm-up approach, include phases that involve the analysis, design, implementation, testing and deployment of individual services. Furthermore the operation and maintenance of services involves service usage and monitoring. All these are the traditional service delivery phases in SOA.
TOGAF does not provide detailed phases for delivering the systems that comply with the architecture defined in phases B, C and D. TOGAF provides one transition planning phase and one architectural governance phase for planning and governing the exact projects that deliver the defined architecture (Table 3)
| Transition Planning |
| Phase F: Migration Planning addresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan. |
| Architecture Governance |
| Phase G: Implementation Governance provides an architectural oversight of the implementation. |
Table 3 - ADM Phases for Planning and Governing the Implementation of Systems
TOGAF ADM Phases
|
SOA Phases
|
|
SOA Adoption Planning
Service Inventory Analysis
Service-Oriented Analysis (Service Modeling)
Service-Oriented Design (Service Contract)
Service Logic Design
Service Development
Service Testing
Service Deployment and Maintenance
Service Usage and Monitoring
Service Discovery
Service Versioning and Retirement
|
Figure 7 - The correspondence of Service Delivery Phases to Migration and Implementation Phases. |
Given that each SOA project delivers one or more services to a service inventory, we map all traditional service delivery phases to phases G and F in TOGAF (Figure 7) This approach enriches TOGAF with explicit steps for developing the system(s) that implement the architecture of the service inventory blueprint. That is, TOGAF can adopt all explicit SOA service delivery phases (Figure 8). Additionally to this, both TOGAF and SOA can be enriched with project and product lifecycle models for service development and management. We will examine this in more detail in the follow up article.
Notice that Phase E in TOGAF is part of the Transition Planning, while Phase H is part of Architecture Governance. We will examine these two phases in subsequent sections.
Figure 8 - Additional elements to TOGAF for support of Service Delivery Phases
Conclusion
The next article will continue going through part I of this series.
|
|
