Good review - sorry for our delay in getting around to a ZapFlash on the topic. We're still chewing on TOGAF to decide whether or not it makes sense for us to get involved. Drop me a line - would like to chat with you further on that.
Best, Ron --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > Let me offer my 3-part review of SOA in TOGAF 9 that I posted almost 3 months > ago (ZapThink is getting slower...): > > http://www.ebizq.net/blogs/service_oriented/2009/02/togaf_90_is_short_on_soa.php > > and even got some press on it. > - Michael > > > > > ________________________________ > From: Gervas Douglas <gervas.doug...@...> > To: [email protected] > Sent: Tuesday, April 21, 2009 7:46:40 PM > Subject: [service-orientated-architecture] [ZapFlash] SOA and TOGAF: A Good > Fit? > > > > > > [<SPAN id="misspell-7" class="mark" >ZapFlash</SPAN>] <SPAN id="misspell-8" > class="mark" >SOA</SPAN> and <SPAN id="misspell-9" class="mark" > >TOGAF</SPAN>: A Good Fit? > ZapFlash!" width="759" border="0" height="124"> > > 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. > Service-Oriented Architecture (SOA) is a style of architecture and The Open > Group Architecture Framework (TOGAF) is an architecture framework. The > combination sounds promising, but do they play well together? The Open Group > 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 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 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. > > > > > > > > > > > > > > > > ________________________________ >
