![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Service-oriented architecture (SOA) is an enterprise concept. It can enable evolution from a model based on departmental interfaces to a centrally orchestrated model . SOA enables you to transform organizational silos into functional groups, thereby measurably increasing productivity. It appears that, after a decade or so of discussion and trial, enterprise architecture is starting to take off. First, there is an enterprise notation, the Unified Modeling Language (UML), which other styles tend to gravitate to. Second, there is a broad industry realization that departmental information technology (IT) systems are not islands and must be better aligned to business value. Finally, there is SOA, a framework fully capable of accommodating incremental business technology change without causing much pain.
At present, both TOGAF (The Open Group Architecture Framework) and SOA are still lightly understood. To succeed, an approach to each of them must offer two things at minimum:
- A reference topology (the defining structure)
- A reference implementation flow (the defining sequence)
These artifacts must always be at hand before, during and after a project, because they offer a primary point of reference for planning, design, implementation, maintenance, and optimization methods. This article and Part 2 of this three-part series attempt to present an overview of TOGAF and SOA, respectively.
A great deal of discussion about TOGAF has been focused on the Architecture Development Method (ADM), to the point that the ADM has essentially become synonymous with TOGAF. What separates TOGAF from other frameworks such as the Zachman Framework (ZF) and SOA, is that it offers a method for building enterprise architectures – the Architecture Development Method (ADM). ADM is such a differentiator from other frameworks that most discussion of TOGAF focuses on it.. Less attention has been devoted to ADM's counterpart: the building blocks of an enterprise architecture or the enterprise continuum (EC). For an introduction to enterprise architecture and TOGAF, please read my previous article, "TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP" (listed in Resources).
TOGAF includes two principle parts:
- ADM, which contains procedural instructions for the development of an organization focused enterprise architecture
- An Enterprise Continuum (EC) that supplies a process model and taxonomies of enterprise architecture-related building blocks, including standards, solutions, services, patterns, frameworks, and the technologies that can be used in conjunction with the ADM
A key reason that an organization should consider an enterprise architecture implementation using the TOGAF ADM is that is provides a development roadmap arrived at by industry consensus. The Open Group framework recommends a rendering of both the present and desired future architectures, as well as the transitional states, as a series of modeling artifacts and accompanying specifications documents. These models may be from different architectural domains and differ by granularity and purpose. However, they must be constructed using ubiquitous building blocks.
Putting the spectrum of EC resources in perspective, we speak here about business functions as broad as contract management, implemented by using platform services such as Document Processing, Report Generation, and File Management. Those, in turn, can be implemented using Universal Resource Locator (URL) or Portable Document Format (PDF) technologies that are too reusable resources of the EC, just at a finer level of detail.
To tackle the ambiguity that surrounds the business-to-technology divide, TOGAF has adopted an approach that breaks the enterprise architecture implementation and specification process into two separate but dependent model layers and three potentially different work streams that deal with architecture requirements, business agreements, and architectural solutions, respectively (see Figure 1). These two streams represent a natural divide for most organizations where both enterprise planning and solution implementation groups exist:
The Architecture Continuum (AC) work stream offers a framework to analyze enterprise architecture both in context and scope, defining business agreements and classifying reusable assets according to so-called Application Building Blocks (ABBs).
The Solutions Continuum (SC) work stream contributes a way to describe an implementation of the AC states with Solution Building Blocks (SBB).
It is easier to understand the building blocks (ABB and SBB) by looking at an example, as I do later in this article. Meanwhile, you can think of them as reusable, logical, enterprise IT architecture definition components.
Figure 1. Architecture streams in the TOGAF Enterprise Continuum
AC is composed of four states, as shown in Figure 2. The underlying process is to discover architectural requirements and analyze and understand architectures that are already in place in the organization, from foundation architectures such as TOGAF through common systems architectures, industry standard architectures, (such as SOA and the Payment Card Industry (PCI) standard), to an organization's own, applied architecture. The diagram in Figure 2 is an illustration of an inferred architectural process based on four states:
- Foundation architectures
- Common system architectures
- Industry architectures
- Organization architectures
Figure 2. Architecture Continuum
The left-to-right direction implies a logical progression in organizing an enterprise architecture implementation. However, there is no single correct path in this process, and all states are voluntary. Organizations that skip early states, such as the foundation and common systems architectures, to compress their implementation schedules or save on the cost of implementation might end up spending considerably more on maintenance, systems integration, and, ultimately, replacement. Typically, the progression tends to occur from left to right and in these ways:
- From conceptual to logical to physical
- From technology solutions to business technology systems
- From industry-neutral to vertical business domain-compliant architectures
- From general taxonomies to physical architecture specifications
Consequently, architectural changes made to states at the left will migrate to states at the right. This gating model enables architectural change management in which even a foundational change to the system can be propagated through the system without having an uncontrolled effect on the business.
The various states in the model represent core architectural analysis and specification points. Each state is supported by several Architecture Building Blocks (ABBs), which can reside both inside and outside of the AC taxonomies. The AC approach is applicable across most industries and can accommodate virtually every known information technology standard. For AC to work and be portable across multiple vertical and horizontal business domains or custom organizational business structures, architectures must share a common representation language. Many people, including myself, believe that the Unified Modeling Language (UML) is adequate (see "UML, RUP, and the Zachman Framework: Better together" in Resources).
Besides common modeling rules and a scalable notation, the approach must be based on a central taxonomy and knowledge of modular architecture. TOGAF includes three taxonomies; two supporting Foundation Architectures and one for Common System Architecture. These three in addition to external collections of standards and patterns contain the functional packages known as Architecture Building Blocks (ABBs) mentioned earlier.
TOGAF assigns each of the four states a corresponding set of ABBs. What makes an ABB set belong to one state versus a different ABB set from another state are the unique perspective that the set is based on and a level of abstract representation.
What unites them, though, is a common definition model that comprises main functional applications, interfaces, and dependencies upon other ABBs. A common ABB definition model makes it possible for an enterprise architect to compare, choose, and reuse ABBs throughout a requirement specification, the logical architecture blueprints, and the business agreements, which will translate easily into SC solution architectures. This underscores a special role of AC as a factory of architecture requirements and analysis.
The existence of EC states forms the foundation for fundamental transitions which happen during architecture development.
The Foundation Architecture phase begins when you consider your general computing environment in terms of technology standards and available or accessible products and services, as well as their compliance with the stated business requirements and strategies. This phase of architectural development is supported by the Technical Reference Model (TRM) and Standards Information Base (SIB) taxonomies. TRM forms a catalog for "generic platform services" such as fax or document management, while SIB is a database of industry standards that can be used to define the computing environment.
Common System Architecture is the state wherein you create a set of formal IT requirements. You model domain architecture views, such as Applications, Infrastructure, Networks, and Security, by creating ABBs to describe enterprise-critical system composition and behavioral patterns. The taxonomy within EC that supports this phase is the Integrated Information Infrastructure Reference model (IIIRM). IIIRM comprise conceptual structure of integrated information architecture and coherent description of all its layers and key components.
The Industry Architecture phase guides the adaptation and integration of standards and building blocks for a vertical industry domain (insurance, government services, or banking, for example). This work comprises analysis, selection, and architecture integration of domain-specific ABBs and technology standards. A few examples of industry-specific standards are the ACORD XML model, which represents common data and process structures for information sharing in the insurance industry, and the HL7 standard for exchanging electronic health record information (see Resources for both). At this stage, ABB can stand for either an off-the-shelf implementation of the standard or its logical custom implementation.
The final state, Organization Architecture is the least abstract. It provides a reference for solution architects and systems analysts alike who are involved in the implementation and delivery projects. From the model completeness perspective, this state represents what is typically known as the enterprise architecture of an organization. It encompasses the architecture of concrete organizational deployments, process and system integrations, standard support packages, and domain-level architectures at a logical level, and it is composed of models of internal business data, processes, systems, and rules. As a recommended reference guide, IEEE Std 1003.23, "Guide for Developing User Organization Open System Environment (OSE) Profiles" contains a method for identifying and documenting operational requirements plus IT and IS services to support these requirements, as well as standards, and strategic and interim solutions for required services.
The rationale for having two separate architectural representation tiers and work streams (SC and AC) is to have a layer of indirection between enterprise and solution architectures. Typically, this translates into improved enterprise change efficiency and increased ROI. When business processes need to change, a two-tiered approach can significantly reduce both the effort involved in enterprise architecture and project analysis and the risks by enabling an enterprise architect to choose the best point of enterprise architecture surgery, thereby limiting guesswork by solution architects by enforcing the architectural standards.
From the TOGAF perspective, SC states mimic AC states. SBBs refining ABBs (building blocks) can be either acquired or developed. As with ABBs, granularity of SBBs varies from state to state and, generally, increases from left to right as solution states are achieved. SC states including Products and Services, Systems Solutions, Industry Solutions, and Organization Solutions can be achieved by project architects with the oversight of an enterprise architect and delivered as a series of projects that might use RUP, waterfall, or agile development approaches, combinations of those, or any other solution delivery method. An ADM process can accommodate any variety of project options, see "TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP" (in Resources).
Figure 3 illustrates the relationship between SC and AC for a fictional insurance company.
Figure 3. Solution Continuum and building blocks
Relationship between AC and SC
TOGAF cites the relationship between AC and SC as "one of guidance, direction, and support," which I interpret as the AC Foundation Architecture guides the selection of products and services, System Solutions are implemented as directed by AC Common System Architectures, Industry Solutions are incorporated according to the AC Industry Architecture recommendations, and Organization Solutions are delivered in accordance with the Organization Enterprise Architecture.
TOGAF recommendations are that AC and SC are worked on concurrently, with a one-step delay between their running phases, although this is not a given. AC acts as an architecture layer for SC, which will continuously evolve while tracking and incorporating feedback received from the SC process. The idea is to push the enterprise architecture toward completion by taking it through four states. The architecture cycle is over when the final state is reached; however, as ADM recommends, solution project analysis activities can start before the final enterprise architecture is completed or before it is even fully captured.
A popular and robust implementation of ADM is through achieving "model targets" that represent common milestones for both enterprise architecture and solution delivery projects. I have encountered several implementations of this method; the "gating process" is one of them. In order to pass through a "gate" between two states, the architecture under development has to be validated for compliance and communicated outside of the architecture team. An architecture "review board" might consist of business, enterprise architecture, solution architecture, and project experts to ensure the board's compliance and continuity.
The diagram in Figure 4 illustrates a high-level topology of TOGAF as it was described here previously. Part 2 of this series will follow the same format to reconstruct a topology of the SOA framework. Part 3 will attempt to bridge these two frameworks and will use these charts as lifecycle diagrams to create a unified picture that can serve as a guide during an SOA-anchored enterprise architecture implementation and an SOA implementation that leverages a formidable enterprise architecture framework.
Figure 4. TOGAF reference chart
The author thanks Kieren Tinning and Bernie Lee for their time and attention to detail while reviewing the paper and Jim Densmore from the IBM crew for straightening me out on certain key issues.
Learn
- TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP. This article from the Rational Edge contrasts enterprise architecture with domain architecture disciplines, introduces TOGAF framework, and discusses its Architecture Development Method (ADM) : TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP
- For practical insights into benefits and UML use cases during development of an enterprise architecture project with the Zachman Framework, read the Rational Edge article called UML, RUP, and the Zachman Framework: Better together.
- The Open Group Web site is the most comprehensive source of information about the TOGAF framework.
- The article titled ADM and the Zachman Framework on the Open Group site provides a mapping of the TOGAF Architecture Development Method (ADM) to the Zachman Framework.
- For more information, read Introducing The Open Group Architecture Framework (TOGAF), Part 1: Understand TOGAF and IT architecture in today's world by Nicholas Chase (IBM developerWorks, February 2006)
- Learn more about the examples of industry standards:
- For the ACORDXML model for the insurance industry, see the Organization for Cooperative Operations Research and Development.
- For the HL7 standard for exchanging electronic health record information, see HL7.org.
-
Learn about other applications in the IBM Rational Software Delivery Platform, including collaboration tools for parallel development and geographically dispersed teams, plus specialized software for architecture management, asset management, change and release management, integrated requirements management, process and portfolio management, and quality management. You can find product manuals, installation guides, and other documentation in the IBM Rational Online Documentation Center.
-
Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
-
Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Additionally, some "Getting Started" courses are available free of charge.
-
Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
-
Browse the technology bookstore for books on these and other technical topics.
-
Learn more about IBM Rational Unified Process.
Get products and technologies
-
Download trial versions of IBM Rational software.
-
Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
Discuss
-
Check out developerWorks blogs and get involved in the developerWorks community.
Vitalie Temnenco is a software architect with Sierra Systems Inc., where he provides architecture, methodology, and project delivery services to Sierra’s clients. Previously, he was an architect for the Ontario, Canada government's Workplace Safety and Insurance Board, where he provided architectural mentoring on implementation projects and helped teams embrace IBM Rational Unified Process (RUP) and enterprise architecture concepts. His experience includes designing and building solutions for clients in a variety of business domains, such as banking, finance, insurance, retail, and telecommunications, and he teaches UML and RUP for business and systems analysis, as well as in construction of new systems.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
