A lot of different users helped lay out the ground work that lead to the recent release of TOGAF 9. Through field work, they helped create new templates and added more depth and functionality. These new-enhancements could help raise TOGAF's role in multi-vendor IT projects and large procurements.
Paul van der Merwe, managing consultant with Real IRM, an enterprise architectural consulting firm in South Africa, described the adoption of TOGAF by SASOL, a South African chemical company. SASOL recently began to integrate TOGAF in with their business capabilities development methods. He said, "Part of the benefit is that as they roll out a new capability globally, they have a mature business architecture. They have saved millions of dollars by not having to reanalyze the whole process every time they want to re-implement a service. SASOL was one of the companies that donated pilot templates to the Open Group for TOGAF 9.
Mike Turner, enterprise architect at Capgemini in the UK, said that Capgemini has been using its internally developed Integrated Architecture Framework (IAF) for years. It provides is a content centric framework that deals with the meta-model of how you create architecture work products. They found TOGAF 8 to be a good match with IAF, because TOGAF added a process, while IAF added a content framework. Capgemini helped bake some of the improvements seen by this combination into TOGAF 9 so they could be used by other organizations.
Turner explained, "TOGAF 8 provides a step by step process to create an architecture, and then govern the realization of that architecture, but it does not give you a specific set of concepts you can formally model your architecture in. It says you need to look at business processes and produce models of those, but it does not talk about what constitutes a business process model and that that relates to other concepts like you application portfolio. TOGAF 8 only provides high-level non-specific guidance on how to visualize that stack."
TOGAF 9 has taken this guidance down two levels of abstraction. It has enough specificity where an architecture diagram vendor like IDS Scheer or Telelogic could take a customers framework and configure it to support TOGAF with little ambiguity. TOGAF 9 is sufficiently detailed where an organization can move from one tool to another with consistent output.
For example, Capgemini has been engaged with a large global manufacturing organization that entirely outsourced their IT operations to four major vendors. Each week, it expects a weekly review of its status. Turner said that in the past, each systems integrator would be using its own methods for doing architecture, so organizations had to develop internal methods and translations in order to provide consistency. But this created challenges for the outsourcing vendors who would have to translate their own process into the contracting organization's process.
Turner said, "The different systems integrators would pay lip service to the target architecture, and then use their own methods and translate their outputs into the company's methods. The company ends up spending a lot of time and effort developing its own frameworks and methods and gets suboptimal results because no one is committed. This organization is extremely enthusiastic about TOGAF 9 because those problems disappear. This is powerful because you are maintaining the flexibility of being able to multisource your services, but getting a consistency that is going to be a huge positive for the organization."
TOGAF 9 is expected to play a much bigger role in the procurement and contracting process in large scale projects. For example, the UK Government is working on several large-scale IT transformation initiatives that on the order of a billion dollars. Turner noted it is too big a risk and a conflict of interest to have one vendor define the problem and provide the solution. He said, "You need an enterprise architecture to be able to frame problems that are this large and complex. Because TOGAF is an open standard, organizations can define their needs using TOGAF, and feel safe and confident that someone that bids to implement the solution will be able to pick it up, understand what it is about, and understand the risks and costs while getting closer to the original business intent. Having that architecture makes it much clearer what the constraints are, and you get a better understanding on both sides and a more productive working relationship."
Another place where TOGAF 9 is expected to shine is in helping to roll out service-oriented architectures, by enabling organizations to better separate and communicate about businesses and technical services said van der Merwe. In the traditional technical Web services paradigm, the focus is on bringing a certain degree of rigor around how application functionality is encapsulated and documented. But if you just look at a technical SOA solution in isolation, there is a real risk that you can over-invest in SOA capability or invest in SOA capability in the wrong part of the business, so your business is not flexible where it needs to be. To get the best return on investment for SOA, it is important to understand from a business perspective what capabilities your business has and why.
Turner said, "I did a QA review for a client that built a fantastic enterprise service bus architecture. They evaluated the market, picked a great product, and implemented a system that was scalable, reliable, and ran flawlessly. But no one needed to use it. The company had never been able to articulate the business problem they were trying to solve. The business was quite satisfied with the file transfer paradigm. Unless you understand the business problem, there is a real danger that you build a flawless platform with no uptake."