 Right at the beginning I stress the fact that the important element of the launch of version 9.2 is not just the standard, but it's the availability of the information that helps people use the standard. So the TOGAF standard is successful. 75,000 individual certifications, eight certified software tools, 70, greater than 70 accredited TOGAF training courses as of the beginning of April. I think we're up to 77,500 certifications now, so it continues to grow. That's why we need a date on the bottom. But why is it successful? It is not successful because you can open the TOGAF standard and using that alone solve all of the problems of every enterprise. It's successful, firstly because it's mature and stable, but because there are additional resources and documents that support its practical application, it's now at the heart of a really high-value ecosystem. Don't worry about that term. I'll tell you what I mean by ecosystem in one slide's time. The success of the TOGAF standard is critically dependent now on the visibility of that ecosystem and the continued integrity of that ecosystem. What do we mean by the TOGAF ecosystem? Top left, you'll see a picture of the TOGAF 9.2 standard. There are a lot of other boxes on this slide. Over on the right are some of the stakeholders, people who have concerns about TOGAF, people who have requirements for TOGAF, people who would not be able to use the TOGAF standard if we didn't understand their concerns. Top right, we've got the certification program. We've got variants of the standard. We've got the pocket guide. We've got the study guide. At some stage, we'll need to have interpretations. When you've got a new standard, you don't need any interpretations because nobody's read it yet. But when people start to read it, they'll be asking us questions, what did you mean by this particular thing? Since 2011, we've published lots of the TOGAF materials in lots of other languages, Japanese, Chinese, French, Portuguese, African, Polish. All of these are part of the ecosystem, a collection of interconnected and interacting components that enable the practical application of TOGAF standard. This is an architecture. There are relationships. A lot of the other documents relate back to the standard. If we break that relationship, we break the ecosystem and we make it really difficult for people to continue to use the TOGAF standard. So we take that ecosystem very seriously. Down on the bottom right, the big red box is entitled the TOGAF library. This is the collection of resources that have been produced, some by the open group, some by other people, explaining how the TOGAF standard can be practically used in a more specific context. Remember, it's very generic. It's designed to be generic. If you know more about the context in which you're going to deploy the standard, you can be much more prescriptive. There are lots of categories of document in the library. There are standards, the traditional output from the open group process, consensus standards. There are guides or white papers. Importantly, we now have a new category of guide. So guides are supporting documents, but something which we call a TOGAF series guide is something that represents the same level of openness, interoperability and consensus as standards from the open group. Guides and white papers are typically produced by a single forum and approved by a single forum. A TOGAF series guide is reviewed and approved by the total membership of the open group. Every member gets to comment, every member gets to vote. So they have a status which is much stronger than guides the open group has produced for a long time. So the TOGAF library, what it effectively is doing is documenting architecture styles. Styles are usage of the TOGAF standard in a more specific context. What we found is that good old enterprise continuum is a really good categorization mechanism for architecture styles. Some documents are foundational. They're broadly applicable. Some documents are more generic than relate to a specific style of architecture such as service orientation. Some are related to particular industry segments such as telecommunications, banking, mining, and some are related to the deployment of the TOGAF standard in a specific organization. We get a lot of things into that category in the form of case studies presented at quarterly open group conferences. So this is how the TOGAF library is structured. There is a hierarchical structure, top level, these four categories, and then below that they're categorized by subject area. How do you find it? Dead easy. One click from the open group home page. In the publications menu, click on the TOGAF library. The contents of the TOGAF library, the majority of the content is available free of charge to everybody. Some of it there is a charge for but typically relatively modest and members of the open group typically do not have to pay. Our intent is that this is a public library of resources. By the time I get to the end of this presentation, I'm going to talk to you about keeping your knowledge of TOGAF up to date. To do that, you will need to be familiar with a number of documents from the TOGAF library. So I want to draw your attention to some of these. Business scenarios. This is one of those TOGAF series guides. It's been through a detailed review. The business scenario method has been around for a long time. Two years ago, we had a workshop to discuss how it could be improved. The results of that are a pre-standing document, G176, which is a revised and updated version of the business scenario technique. Value streams. This is something that's come from the business architecture people. It addresses how to identify, define, model, and map a value stream and how you link it to other components of the business architecture. Business capabilities. It describes what a business capability is and how you can actually use business capabilities to enhance your business analysis and your planning. How to define business capabilities. How to decompose business capabilities. How to analyze them. Integrating risks and security within a TOGAF enterprise architecture. I've mentioned this earlier. This is the material that was taken out of the TOGAF standard, updated, enhanced. Using the TOGAF framework to define and govern service-oriented architecture. There was a chapter on this in version 9.1. This has been taken out of the standard and it's been replaced by a much more substantial body of material as part of the strategic restructuring, which covers pretty much the same ground but in a lot more detail. The TOGAF leaders guide to establishing and evolving an EA capability. In the TOGAF standard, there's some general information about standing up an EA capability in the preliminary phase and some stuff about EA capabilities later in the standard. This document is practical guidance for people who have the job of establishing an enterprise architecture capability. Practical guidance as to how they should do it is written for that person. The diagram over on the right, some of you may recognize because we have a series of documents called World Class EA for a long time. The thing in the middle there identifies the fact that one of the things you need to do when you're creating your EA capability is to work out what is your class of engagement. At the one end, you're doing it top down to support the definition of strategy. You may be supporting a portfolio project, a single project, or you may only be applying architecture at the solution level. You need to know what it is because that has a significant impact on the architecture capability. A practitioner's approach to developing enterprise architecture following the TOGAF ADM. I like the bottom bullet here. This is a claim from the authors and I think I agree with their claim. This is intended to bring the concepts and generic constructs in the TOGAF framework to life. Guidance on using the TOGAF framework. If you're very observant, you'll notice we've got the same four classes of engagement. But it also shows how these can actually be linked together in a practical way. The TOGAF Integrated Information Infrastructure Reference Model. So this describes the triple IRM. We removed this from version 9.2 partly because it is guidance and past that partly because it is now a little out of date. It's a historical record of some work that was done 15 years ago. It is valuable. The overall structure is still sound. But the deeper you go into this document, the more dated the content is. Certainly the technical services that it describes are not representative of today's IT landscape. So we retain this because it's got value but it is placed in a historical context as is the technical reference model. This is even older. First version of this was developed in 1988. When it was put together, it was absolutely critical because the audience for this was people architecting below the application platform interface. Most of the people using the TOGAF standard now are architecting above the application platform interface. So this model itself is not relevant to many, many companies. There are lots of other technical reference models available. The overall concepts are sound. But again, the detailed taxonomy is not representative of today's IT landscape. So this has been put into a historical context.