Because of my involvement in SOA/TOGAF practical guide project at The Open Group, I am getting many questions related to the use of EA frameworks in general. I just want to share some of my discussions with people on this topic here. Many enterprises have been (and are being) challenged, for example, on use of TOGAF for their real EA initiatives. The challenge is the misconception that EA framework, such as TOGAF, can be used “as is” for supporting Enterprise Architecture work. EA frameworks are “frameworks” and they are not meant to directly apply to all situations and solve all enterprise architecture challenges the same way. This means such EA frameworks must be viewed as a “guide” and needs to be customized to address the individual enterprise needs. EA framework, such as TOGAF, needs to be customized by taking into account at least two factors:

1. Enterprise or Organization needs: What is that the enterprise trying to achieve (business drivers) and what is the maturity level of the EA in that enterprise? Is the enterprise ready to undertake complete or partial business architecture to drive Information, services/applications, data, and technology architectures? Or is the focus on information, applications and technology aspects with limited business architecture effort? What level of governance is needed? How good is the existing EA processes to accommodate the applications/services development (in other words, how integrated is the EA process with the common SDLC processes)? Many more such questions need to be asked to properly customize the EA frameworks in such away that the newly customized EA framework can effectively support moving the enterprise from current state to the target state (or achieving the target business objectives). What this means is that newly customized EA framework should help in addressing current and future enterprise challenges. One important thing to note here is that the customized EA framework is not “final or static” by itself – it needs to be positioned to evolve with the enterprise needs.
2. Architectural style adopted or in use in the enterprise: For example, if the enterprise is adopting SOA style, then the EA framework must accommodate such an architecture style to be of value to the enterprise. Failure to recognize this aspect of customization to the framework leads to disconnected EA work and SOA projects. This is real and you may have experienced such a challenge – i.e. SOA and EA viewed as separate streams of work and a communication gap between the two teams created.

   In addition to the above points, one should also pay attention to the link between EA deliverables and the actual solution implementation projects. Whatever you do in EA, its value is realized only when the artefacts are deployed and show value to business (e.g. customer satisfaction, business agility, etc). The EA metrics (to measure the success of EA effort) are collected based on such values to the business. EA deliverables must guide and support the solution implementation projects. Thus, EA framework customization should include such a linkage to the solution implementation projects.

Bye for now -:)

Awel Dico

As you know the new version of  TOGAF (i.e. version 9) has been released this year with much improvement compared to the earlier version TOGAF 8. I am sharing my reading note below for those who need a quick overview of TOGAF 9 content and want to know the major changes from TOGAF 8. The digram shown below provides a high level summary of how TOGAF 9 contents are related.

Understanding TOGAF 9

Architecture Development Method (ADM)

The main part of TOGAF is the Architecture Development Method (ADM).  If you are new to TOGAF ADM, please see TOGAF document here. TOGAF ADM is an iterative architecture development method divided into phases that guide end to end architecture work. It describes what needs to be done to create an architecture.

Overall the structure and the core concept of ADM process is not changed from what was in TOGAF 8. Some more detail contents have been added to TOGAF 9 ADM and some clean-up is done; i.e. details about input and output chapters of the earlier version is moved to another part newly introduced in TOGAF 9 – Architecture Content Framework (see below).

ADM Guidelines and Techniques

This part of TOGAF 9 provides a collection of guidelines and techniques that can be used in applying TOGAF ADM. If you are about to use TOGAF, I recommend you read this part of TOGAF for some tips and ideas on how to apply ADM. After all the use of TOGAF for your organization requires some sort of customization to your needs – so, understanding some usage scenarios would definitely help you get started in that road.

Architecture Capability Framework

This part of TOGAF 9 provides a set of reference materials and some guidance on how to set up the architecture team – i.e. organization structures, processes, roles, responsibilities, and skills required to perform the architecture work. This includes establishing the governance bodies as well as evaluating the skills of your team to identify training requirements.  Overall, the architecture capability of an enterprise indicates its architectural maturity.  As discussed in TOGAF 9 document, mature architecture capability includes establishment of governance bodies, skilled resource pool, projects/portfolios, architecture repository supported by enterprise continuum – all to deliver solutions that are of value to business. Therefore, looking at Architecture Capability  is necessary to operate an architecture function within your enterprise.

Architecture Content Framework (ACF)

This is newly introduced to TOGAF. The main function of Architecture Content Framework is to ensure consistency within the ADM and provide guidance on overall architecture deliverables. Architecture Content Framework specifies what the architecture should look like once it is completed. In that sense it provides guidance on what to produce while working through ADM phases. It also guides the Architecture Repository to be structured as per content metamodel. The use of content metamodel also simplifies the work of generating viewpoints and views for stakeholders communication on demand.

Enterprise Continuum and Tools

Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of related architecture deliverables. Architecture Repository is where the various architecture deliverables are stored and managed. As you work through the ADM phases, you interact with the Architecture Repository in two ways – reuse and populate (store).  You need to look at the repository if there are any previous architectural building blocks that you can reuse. You also need to populate the Architecture Repository once you complete the architecture through the ADM.

As to what changed from the earlier version TOGAF 8, the Enterprise Continuum part is revised – existing content is rearranged and new contents are added. In TOGAF 8, the reference models are discussed in the continuum part. In TOGAF 9 this is moved to another part of the document making the Architecture Continuum part cleaner and clearer than before. New contents are added on architecture partitioning and the repository.

Stakeholders Viewpoints and Views

The use of TOGAF requires identification and addressing stakeholders concerns. That means as you work through the ADM, stakeholders concerns need to be considered. Moreover, it is important that you communicate to the stakeholders by addressing their specific viewpoints and creating compatible views from the repository as needed. After all, stakeholders are your customers and customers want to see what is important to them – not to you -:). Therefore, in putting together the Architecture Content Framework, you must consider stakeholders concerns. Architecture Content Framework  should identify the deliverables that are reviewed, agreed, and signed off by the stakeholders.

Awel Dico, PhD

I have been chatting with colleagues from other organizations working on SOA or planning to do so. During those discussions I observed that many of the organizations approach SOA work from pure technology perspective. Did you lately get a chance to talk to Enterprise Service Bus (ESB) product vendors? For example, many vendors and consultants advise you to buy ESB if you need SOA. But is that really SOA? The answer is No. ESB and other technologies are useful and of value if and only if you know what to do with them. Yes, such technologies make your SOA implementation easier and support many of the SOA principles. However, I think any SOA initiative must address business needs. Business needs must drive business services identification; which in turn drives the need for technology services. I think SOA will fail, if SOA is viewed purely from technology perspective without much attention to business needs. Why would one invest in technology products (such as ESB) if the need for it is not justified from business services perspective?

Fortunately, this is no more a point of argument as it used to be (remember those discussions on top-down versus bottom-up approaches?). Today, many enterprises have already realized that the right approach to SOA is from business perspective. Such a realization is a good step; but not enough to guarantee SOA success. Actually many organizations seem to be struggling with how to approach the SOA work from business perspective. I observed two camps of enterprises. The first camp is one that has some activity with Enterprise Architecture framework and at the same time adopting SOA. The second camp is one that has no EA activity but still want to adopt SOA. The enterprise in the first camp has difficulty bringing together their EA work and SOA work. The worst case is for some of those enterprises EA and SOA are treated differently and the teams are separate. The goal of EA is to close/minimize the gap between business and technology by providing enterprise wide support for both business and technology groups through standards, guidelines, governance, etc. If such an EA activity doesn’t include SOA as one of the best practice architecture style, how would one expect success in SOA initiative?

To prevent SOA failure, the two camps should rethink their approach. I think enterprises in the first camp must integrate their EA and SOA work – these two should really be viewed as one. Those in the second camp may have to adopt two things – EA framework and SOA. I don’t think SOA will succeed without proper EA work in place.

There are few EA frameworks out there that can be enhanced to support SOA and has a potential to lead to a success. One of these is TOGAF. TOGAF helps the enterprise to do work on business architecture from which business services can be identified. It provides an architectural process by linking key architectures one after the other, i.e. Business architecture, information architecture and technology architecture. Even though TOGAF provides a mechanism for approaching architecture from business architecture and then to technology architecture, some enhancements are required to use TOGAF for SOA. A guide to help with such enhancement is under development by the Open Group SOA working group. In conclusion, if proper enhancement is done to TOGAF for SOA support, TOGAF can be at the rescue for the enterprise struggling to lift their head out of the architectural mess and do the right SOA. I will try to give some ideas on how TOGAF can be used for SOA work in my future postings. I will be presenting on this topic at the Open Group Architecture Practitioners conference in San Francisco on January 28, 2008.

Awel Dico, PhD