Please load the images to see all the content in this ZapFlash!
<http://t.ymlp178.com/uujsapauqjaoausmhazambmuu/click.php>
SOA and TOGAF: A Good Fit?
Document ID: ZAPFLASH-2009421 | Document Type: ZapFlash
/By: Jason Bloomberg & Ronald Schmelzer/
Posted: Apr. 21, 2009
/By guest contributors Clive Hatton and Paul van der Merwe, Real IRM
<http://t.ymlp178.com/uubuaiauqjacausmhaoambmuu/click.php>/.
Service-Oriented Architecture (SOA) is a style of architecture and The
Open Group Architecture Framework (TOGAF) is an architecture framework
<http://t.ymlp178.com/uubeapauqjavausmhagambmuu/click.php>. The
combination sounds promising, but do they play well together? The Open
Group <http://t.ymlp178.com/uubmaiauqjakausmhavambmuu/click.php>
certainly believes they do -- Open Group members have invested heavily
in efforts to bring these two concepts together. Several members have
contributed a great deal of their time and experience to the SOA/TOGAF
Practical Guide project, one of many of the SOA Working Group's projects
in The Open Group.
The SOA/TOGAF Practical Guide project
<http://t.ymlp178.com/uubjaxauqjagausmhavambmuu/click.php> aims to
develop SOA specific extensions to the TOGAF Architecture Development
Method (ADM) that lies at the heart of TOGAF. The idea behind this
project is that if SOA is a style of architecture, then it's possible to
extend the style-independent method of the TOGAF ADM with SOA
style-specific activities and deliverables, to produce a Service
Oriented ADM.
So why should SOA practitioners be interested in TOGAF? If you see SOA
as technology (which ZapThink certainly does not), rather than
architecture, then you may not see any value in an architecture
framework. Even if you correctly see SOA as architecture, you may think
that you have been doing just fine developing and implementing SOA
without any assistance from TOGAF. So what does TOGAF offer you?
*Using the TOGAF Architecture Development Method (ADM) for SOA*
>From its roots in the US Department of Defense, TOGAF has over the
years become the /de facto/ industry standard for architecture
development and includes best practices from hundreds of participating
Open Group members. TOGAF 9, released this year, offers significant
improvements over TOGAF 8, including greater usability, more focus on
holistic enterprise change, and more consistency of output. Additions to
TOGAF in version 9 include a modular structure, a content framework
(which gives structure to architecture models and definitions), and
extended guidance on adopting TOGAF within an enterprise.
In particular, TOGAF 9 also gives explicit consideration to
architectural styles, SOA in particular. Included in TOGAF 9 is a
chapter on using TOGAF to define and govern SOA implementations
<http://t.ymlp178.com/uubbaxauqjatausmhavambmuu/click.php>. This chapter
discusses SOA as an architectural style, factors relating to the
adoption and deployment of SOA within the enterprise, correspondences
between SOA and TOGAF terminology, and the definition and structure of
Service contracts.
The TOGAF ADM, fondly represented as the "crop circle" diagram below,
starts with the Preliminary phase, where an organization establishes and
develops its architecture, and then moves through a requirements-driven
architecture development cycle, ending with the Architecture Change
Management phase, where the organization establishes changes to the new
architecture.
Let's take a quick guided tour through the ADM, and see what SOA can
learn from TOGAF.
* Preliminary Phase
<http://t.ymlp178.com/uubhaiauqjakausmhafambmuu/click.php>. The
preliminary phase prepares an architecture team to do
architecture. It allows for customization of the ADM for the
particular needs of the enterprise and the architecture team.
These needs may include SOA as a style of architecture.
* Phase A -- Architecture Vision
<http://t.ymlp178.com/uubwaoauqjaxausmhacambmuu/click.php>. During
this phase the team defines an architecture project in terms of
scope, stakeholders and Architecture Vision, and obtains approval
to continue with the project. This phase is critical for a SOA
project in order to clearly articulate the business objectives of
the initiative and get the correct buy-in from business stakeholders.
* Phase B -- Business Architecture
<http://t.ymlp178.com/uubqagauqjacausmhakambmuu/click.php>. During
this phase the team develops a baseline and target Business
Architecture, and conducts a gap analysis in support of the agreed
Architecture Vision. A key focus of this phase from a SOA
perspective should be to determine the business requirements and
identify Business Services.
* Phase C -- Information Systems Architecture
<http://t.ymlp178.com/uubyaiauqjagausmhatambmuu/click.php>. This
phase addresses both the Application and Data Architecture. The
team develops a baseline and target Information Systems (IS), and
conducts a gap analysis in support of the agreed Architecture
Vision. Architecting the IS Services and relating them back to
Business Services should be a primary SOA activity in this phase.
* Phase D -- Technology Architecture
<http://t.ymlp178.com/uuhsarauqjaoausmhafambmuu/click.php>. During
this phase the team develops a baseline and target Technology
Architecture, and conducts a gap analysis in support of the agreed
Architecture Vision. Determining the SOA infrastructure
components, such as the SOA intermediary or SOA governance
platform, should be activities during this phase.
* Phase E -- Opportunities and Solutions
<http://t.ymlp178.com/uuhuakauqjagausmhazambmuu/click.php>. The
team completes the architecture definition in this phase by
identifying delivery vehicles (projects, programs, or portfolios)
that effectively deliver the Target Architecture they've
identified in previous phases. Taking an holistic view of the
overall SOA design and identifying candidate building blocks
should complete the architrecture definition in this phase of a
SOA initiative.
* Phase F -- Migration Planning
<http://t.ymlp178.com/uuheaoauqjazausmhaiambmuu/click.php>. The
main focus of Phase F is the creation of a viable implementation
and migration plan in cooperation with portfolio and project
managers. This phase should develop a rollout plan for the SOA
initiative based on the defined architecture. This phase therefore
crosses over from architecture to implementation.
* Phase G -- Implementation Governance
<http://t.ymlp178.com/uuhmazauqjapausmhagambmuu/click.php>. Phase
G establishes the connection between architecture and
implementation, through an architecture contract that addresses
the architectural oversight and review of the implementation.
Ensuring that the team implements the architecture as designed is
as important for a SOA initiative as for any other architecture
initiative. Activities in this phase should align the
implementation to the business objectives.
* Phase H -- Architecture Change Management
<http://t.ymlp178.com/uuhjarauqjagausmhaaambmuu/click.php>. The
goal of architecture change management is to ensure that the
architecture achieves its original target business value. This
goal includes managing changes to the architecture in a cohesive
and architected way. In sustaining the architecture description
for a SOA initiative over time by applying change management would
enable an organization to respond more quickly to business or
technology change that impact the SOA implementation.
* Architecture Requirements Management Phase
<http://t.ymlp178.com/uuhbakauqjazausmhagambmuu/click.php>. The
requirements management process continually drives the ADM.
Architecture often deals with business drivers and constraints,
many of which by their very nature are beyond the control of the
enterprise (changing market conditions, new legislation, etc.),
which can produce changes in requirements in an unforeseen manner.
The key focus of the ADM on business requirements is critical to
the success of any SOA initiative. Aligning the architecture
definition and implementation to the business requirements should
achieve the business objectives and realize the expected value of
the overall initiative.
Don't expect that TOGAF will give you all the answers to your SOA
questions, but do expect the ADM to bring structure your architecture
efforts. Some of the most important benefits of using the TOGAF in a SOA
environment include:
* TOGAF brings an architected approach to SOA.
* The TOGAF ADM covers the full scope of the SOA lifecycle.
* Using a standard method such as the TOGAF ADM reduces project risk.
* TOGAF promotes better alignment with business strategy and
priorities.
*The Role of the TOGAF Content Framework*
In addition to the ADM, the latest version of TOGAF includes a Content
Framework <http://t.ymlp178.com/uuhhaiauqjazausmhazambmuu/click.php>
that provides guidance on how to structure and design architecture
deliverables by way of a content metamodel. This content metamodel
discusses the concepts of function, Business Service, information system
Service, application component and technology component in the context
of SOA.
The Content Framework is a valuable resource to reference when defining
Service models, catalogues and registries. It provides a metamodel that
can guide the team in describing and cataloguing Services, as well as
integrating the Service definitions with the business architecture. The
separation of Business and IS Services as represented in the metamodel
is becoming the norm, but also highlights the importance of deploying IS
Services that support the delivery of business value.
TOGAF also provides a Services extension to the content metamodel to
allow more sophisticated modeling of the Service portfolio by creating a
concept of IS Services in addition to the core concept of Business
Services. Applications directly support IS Services, and creating the IS
Services layer of abstraction relaxes the constraints on Business
Services while simultaneously allowing technical stakeholders to put
more formality into an IS Service catalog. The content metamodel also
provides guidance to the SOA practitioner on how to define the Service
catalogue, and how to integrate the Service definitions into the overall
business and solution architectures.
*The ZapThink Take*
TOGAF is a generic architecture framework that is not specific to any
industry, style of architecture, geography or technology. It further
recognizes that either business or technical communities can lead the
SOA initiative. Each group may have a different focus, but their
activities are complementary and intersect at the concept of a Service.
Implementing TOGAF therefore requires tailoring to adapt it to the
culture and management processes of the organization, as well as the
style of architecture and the technology strategy.
The current strategy of The Open Group is to keep the ADM generic as a
style-independent method, with SOA and other style-specific extensions
confined to separate chapters or even separate documents such as the SOA
Source Book that The Open Group's SOA Working Group has published. There
are, however, several aspects of SOA practice included in the ADM, even
though it hasn't yet been fully aligned with SOA best practices.
How would you decide whether to use TOGAF ADM or not for your SOA
initiative? If you have already adopted a SOA approach, and its working
for you, then the ADM won't necessarily add value for you in the short
term. However it won't do any harm to evaluate your approach against the
ADM. You may find some valuable lessons to be learned from TOGAF.
However, if you haven't yet adopted a SOA approach, or if you are
experiencing problems with your approach, then the ADM is certainly
worth considering. It would require some initial investment in terms of
time and effort in learning and tailoring it, but this should be more
than outweighed by its potential benefits.
<http://t.ymlp178.com/uubsadauqjalausmhaaambmuu/click.php>
<http://t.ymlp178.com/uujbaxauqjadausmhadambmuu/click.php>
<http://t.ymlp178.com/uesyavauqjafausmhatambmuu/click.php>
------------------------------------------------------------------------
<http://ymlp178.com/u.php?YMLPID=guyjqhegsgmbmuuguhm> <http://ymlp178.com>
