 Good afternoon. Good morning. Good evening. Wherever you are in the world. I'm Mike Lambert. I'm a fellow at the open group and I am chair of the open group architecture forum the forum that was responsible for the production of The new version of the togas standard on April the 16th the open group made some significant announcements We announced first of all a revised version of the togas standard itself version 9.2 We also announced something that we call the togas library This was quietly launched in the middle of last year But we're now making a lot more of it because we think it is the most important thing that was actually delivered this year and finally we've introduced a new credentials program to Compliment the togas certification program and I'm going to talk a little bit more about that towards the end of this presentation So structure of this session first of all I'm going to talk about the standard itself What changes have we put into the togas standard and I'll look at areas like business architecture the content framework and meta model alignment with the ISO standard and security Then I want to move on and talk about the togas library and the significance of that in this with this particular release and Finally, I'll talk about the impact of this version on the togas certification program particularly togas certification for people Let's start off then by looking at the standard itself The last time the togas standard was revised was as long ago as 2011 In 2011 life was very simple. We published a big thick book Called the togas standard version 9.1 We built a certification program based largely on the contents of the big thick book That has given us problems Being a single monolithic Standard hundreds of pages long is really difficult to update It mixes What togas suggests you really must do and guidance on usage and useful tools and techniques All into a single volume and as I said in trying to evolve that we have found that that gave us a problem Almost as soon as we published version 9.1. We had a plan. We had a strategy and Our vision was that we would separate the document up Into a much smaller normative core containing the essence of the togas framework Supplemented by a number of documents providing guidance and one or more documents defining tools and techniques The idea being that each of these could evolve in their own time scale and we didn't need to move them forward in lockstep We had a basic principle and the basic principle was Nothing was going to go away accidentally anything in version 9.1 would either Remain in the normative core Or be extracted to a freestanding guide or white paper or if it was going to be deleted It would be an explicit decision. There would be a proposal and there would be consensus around that Well, we set out on this path and we actually found that this Was something which was really difficult for us to achieve in one step And in fact two or three years ago, we realized that this was going far too slowly And importantly, there were areas of the standard that needed to be refreshed There were one or two errors. There were some areas which were a little bit out of date needed modernization There are areas where we really could do with better information. So we adopted an incremental approach and The important thing about version 9.2 is that it is the first stage of this strategic restructure So there's new material in it and I'm going to talk about that in a couple of slides time But we have Started the process of moving towards that strategic target So some of the guidance material has been extracted into freestanding guides and in doing it We've taken advantage of the opportunity to revise that material Some parts of those guides remain part of the body of knowledge for certification and I will talk a little bit more about that later The chapters describing the architecture development method have been internally Restructured to put the normative material first and the guidance later That will help us as we continue the approach of separating out the content into these three different categories and that process will continue with future versions So I showed you the Togat body of knowledge in 2011 The Togat body of knowledge in 2018 is very much richer We do have the standard sitting in the middle the Togat standard version 9.2 but now that is surrounded by Dozens of other documents providing helpful guidance and advice on how you can make practical use of that Togat standard We call this the Togat library now I'm going to talk a little bit more about that and I'm also going to talk about that term up in the top left Togat series guides in more detail as we move through this presentation If you look at the Togat standard and say what what has changed Actually the changes in the standard itself are relatively modest. That's why it's only version 9.2 Not version 10 or version 2018 or what have you the value the extensive Additional material that's been delivered has gone into this thing called the Togat library Lots of guidance hundreds and hundreds and hundreds and hundreds of pages of more detailed guidance Separated out into in a structured way that will help anybody who is adopting Togat to make the best use of it in their context So let's go back to the standard itself. What has changed? In summary There's been some significant change in the area of business architecture We've done a lot of tidy up of the content metamodel and framework There's new material More up-to-date material on security We've aligned with the latest version of the ISO IEC IEEE standard We've tidied up definitions And as I've already said we've started the process of the strategic restructure In a one-hour webinar. I cannot Describe every single change that has been put into the standard I did a presentation on that last week in London and it lasted three and a half hours I've had to leave something out. However, you can get a white paper W182 which is an introduction to version 9.2 and Include a complete and exhaustive list of every change that has been Put in this is free of charge and you can get it from the open group website in the publications area As I said, we've made some significant changes in the world of business architecture The material on business architecture in version 9.1 was pretty high level We threw in some useful terms But never actually explained how you use them properly nor actually explain what those terms mean for the last Four years we've had a team within the open group dedicated to evolving business architecture top down from the business itself and a little bit more bottom-up Linking to the concepts in the togas standard So in version 9.2 The business architecture is significantly enhanced Don't worry if you can't read the diagram on the right We're going to come on to a bigger version of that in a minute. That was just to make the slide look slightly less dead by power power point ish So the approach to business architecture has been strengthened There are new entities new things that we're going to architect new relationships new artifacts in other words new models New diagrams that that we recommend people should consider Importantly, there is a stream of new guide documents which build on the summary information in the standard and Introduce a lot more detail So far we've got business capabilities and value streams. We've got one on business models very close to deployment now Here is the context for the work we've done on business architecture one important Change that we've made is we've tightened up on terminology We have the work capability What we've done now is we've explicitly identified an Ability that something owns within the business context. So we've introduced business capability So business capability is a particular ability that a business may possess or exchange to achieve a specific purpose So that is clearly linked to the organization of the orchid of the organization because a business function has got Has the ability to deliver business capabilities has the ability to do stuff We've got the concept of a value stream And the value stream is a collection of activities that together create an overall result for a customer a Stakeholder or an end user We've always had over on the left-hand side of this diagram a goal Something that we want to achieve What we've done is we've introduced into business architecture the idea of a course of action but a course of action is a Direction and focus provided by the goals and objectives Which enable us to identify what value streams we need and what business capabilities we need to support Those value streams. So we've got these three new entities in the business architecture So business capabilities I Decomposed abilities that the business has They possess or needs to possess to achieve a specific purpose So this is a particular version of a capability map. It's a heat map Really good communication vehicle because the green boxes say We're okay in these areas. We're fine yellow boxes What we have exists but needs improvement Improvement red boxes. These are capabilities that we need in order to succeed value stream so very bad simple value stream for recruitment activity But it shows the things that have to be done in order that you can achieve the eventual result onboarding the employee So representation of the end-to-end collection of value-adding activities that create the overall result And as you can see on this diagram one of the big values is actually linking those business capabilities To the value streams, which capabilities do we need to support each of these steps? That the idea of an organization map So this is I guess Confusingly similar to an org chart, but it isn't an org chart because the key thing here is to represent the depth of the relationships between the primary entities that make up the enterprise Together with its partners its stakeholders It's business partners. So we're not concerned so much with the people as With the relationships that we need an important change in business architecture in Person 9.1. We start to talk about business architecture Mainly in phase B The business architecture folk have said you cannot Define an architecture vision Without doing some business architecture work Because that has an impact on the plan that you're going to put in place So we start to create the business architecture artifacts in the architecture vision phase phase a Then we refine these we extend them we build on them in the business architecture phase So there is a lot more behind this As I said already there are other detailed guides that support this Total content framework and metamodel. So if you don't know what I mean, it's a diagram that looks a bit like this There are lots of other supporting diagrams that go behind it, but this is the most complex version of it What does it show? It shows the thing in your enterprise that you need to architect and The relationships between them that you need to be interested in The major changes that have gone in in version 9.2 I've already shown you the version of this for business architecture So we put in additions to support the new material in business architecture We've rationalized the IT architecture and We've made some changes to the box at the top. Let's start with the box at the top It did have a very odd name called architecture principles requirements and roadmap we've simply now called it general entities and Highlighted the fact that these are effectively characteristics of everything else in the metamodel We've moved the location entity into this category Because location Shouldn't be something that just sits in the business architecture with one or two random links to a few things It is a characteristic of every part of the enterprise. The location is a significant factor So we've taken the location entity out. We've put location into general entities And for any of those of you who are have got a photographic memory and can remember back from the toga 9.1 metamodel The location entity was colored which meant that we saw it as an optional extension But moving it into the general entities Category we're effectively saying that entity isn't optional. It's no longer an extension It's something that you really do need to take very seriously Going back to business architecture Right business architecture. I've shown you this picture before. What have we done? We put in these three new entities Why have we put these three entities in it is to make our business architecture closer To business architecture in Archi mate and Closer to business architecture in organizations like the object management group In doing this work. We have worked very closely with the business architecture guild so what we're doing is is Aligned with what's called this box. So that is significant. We're continuing to work on that But those three things have been a significant influence on the changes that we've made to the business architecture area in The toga content framework a metamodel So you see we've now put in lots of Changes to relationships for example linking course of action to go all Value stream to go all business capability to function Value stream to business capability actors to value streams so there's been a lot of thought gone into the mapping of The work that we've done in phases a and b on business architecture Finally down in the world of it architecture We've done some rationalization first of all We've changed platform service To technology service not a major change But it reflects the fact that the technology architecture is a lot more than just the provision of API's So it's renamed technology service more significantly We've actually relations Rationalized the relationships. So now there are relationships at the top level conceptual level at the logical level and the physical level And We've actually shown that technology service exists for a purpose in the toga 9.1 metamodel if you look very closely There doesn't appear to be any relationship that means that we needed platform service So that's a bit of an error that's got fixed, but it is altogether tidier neater and more consistent Now let me talk about the ISO IEC I triple e 42 10 2011 standard Togath has always used a model from that standard to explain some of the key concepts that we have such as View viewpoint stakeholder concern Togath 9.1 referred back to a version of this standard published in 2007 That is not only obsolete you can't even get hold of it anymore. So we have to do something about that So what we've done is we have aligned with The 2011 standard now the key thing that the ISO IEC standard Attempts to do is to define a set of standard terms and provide a conceptual foundation for enterprise architecture The relationship between the toga standard and the ISO standard is complex Where it is appropriate? We have used the definitions from the ISO IEC I triple e standard as the basis But the defining similar concept in the toga standard We have not we do not fully conform to that standard Pardon the reason for that is that we have Hundreds of thousands of people who use toga and if we're going to change it What we need to do is to make sure that the changes we put in Don't disrupt their usage of the standard. We have a principle evolution not revolution So we have adapted Many of the concepts that we don't fully conform and we do not defer to that standard Defer means that if we're different, we're wrong. We don't Togoff has been around a long time. It's got a lot of people But it is sensible for us to take advantage of the work that's being done and we've worked very closely With the technical editor of the ISO IEC I triple e standard in this alignment work So this is the picture. It's slightly different to the version that was in version 9.1 Particularly down in the bottom right I'm not going to look at the top right because the definitions of system of interest architecture architecture descriptions stakeholder and concern have not changed dramatically between the two versions of the ISO standard the major areas of change are in this shaded area down on the bottom right and the main thing is the introduction of the box labeled Model kind so we've always had viewpoints and views Viewpoints capture concerns viewpoints define templates Which which allow you to create views? Which are extracts from the architecture description? to address those concerns so a viewpoint is a template a view is a populated template So view is a representation of the system from the perspective of a related set of concerns and Typical view will aggregate one or more models And the model is a representation of a subjective interest Smaller scale simplified and or abstract representation of the subject matter And any of you who've ever listened to me talk about this whether it's in presentations or in training courses will know that I always stress That a model is created to communicate with a specific stakeholder Who operates in a particular context so a viewpoint is a specification for the conventions for a view So it governs the view it's a definition of the concerns It's a definition of what you have to do to address those concerns Now a viewpoint may suggest that you create more one or more models So model kind defines the conventions for a particular type of modeling So a viewpoint contains multiple model kinds a view contains multiple models a model is a populated model time Togas uses the word artifact broadly and continues to use the word artifact We had a lot of discussion about whether we should drop the word artifact and put in model kind and model By and large the feedback we got from the people who use the Togas standard is that that would create more problems that it would solve So in relating these two standards together, we need to recognize that in The Togas standard anything in that box Could be considered to be an architecture or work product that describes an aspect of the architecture architecture viewpoint architecture view model kind or architecture model Let's move on to security So version 9.1 have a chapter on security Open version 9.2 that chapter has gone away We've removed it However, it's been replaced by a freestanding guide This was developed in collaboration with the open group security experts in the security forum The security chapter was part of the body of knowledge for Togat 9 certification The security guide is part of the body of knowledge for Togat 9 certification based on version 9.2 Significantly This document has Aligned the understanding of what risk means with ISO standards about what risk means And it's still contains detailed guidance on adapting the ADM for security But that guidance has been significantly enhanced and brought up to date Let's go back to the definition of risk From ISO 31,000 Risk is the effect of uncertainty on objects Now uncertainty is any deviation from what is expected positive and negative Our traditional view of risk is that it's a bad thing The view of risk from the security people is that risk is potentially a good thing So when we're managing risk not only Should we be trying to mitigate the impact of negative risk? We should be trying to maximize the impact Positive risk. So it's got a significant impact on how we think about risk The guide includes something called the enterprise security architecture Defined as a structure of organizational conceptual logical and physical components interact in a coherent pattern In order to achieve and maintain a state of managed risk and security Or information security So it is a driver of the right kind of behavior There are two components to it. There is Information security management and enterprise risk management Two aspects of the same thing and both of these have an impact on how you deploy the ADM We don't have time today to look into that in detail But the document itself Goes into a lot of detail about how you can make The togaf ADM secure and manage risk So that by and large Has gone into the changes that have gone into the togaf 9.2 standard 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 8 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 the 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 as 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 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 architecture 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 a 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 of telecommunications banking mining And some are related to 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 is 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 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 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 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 establish establishing and evolving an ea capability When 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. It's 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 So 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 Practitioners approach to developing enterprise architecture following the togaf adm I like the 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 And 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 parcel partly because it is now A little out of date. It's a historical record as 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 is 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 certification Let's have a look at what this actually means to the togaf certification program so first of all Togat 9 certification It requires knowledge of the togaf standard And now that some of the material has been taken out of the togaf standard selected materials from the body of knowledge Importantly, this is still togaf 9 certified if you are togaf Togaf 9 certified you need to do nothing You will retain your togaf certification We're also going to develop credentials Much more lightweight approaches to demonstrate more detailed knowledge of specific areas So for togaf 9 certification the content of the body of knowledge is defined in detail In the certification program definition Those of you who are In the service provider world will be very familiar with this document the conformance requirements It defines which of those standards in the boxes at the bottom Are referenced which guides and importantly which parts of them because in many of these only The the high-level Overview of the document is part of the togaf 9 certification body of knowledge By and large Scope of togaf 9 certification is broadly unchanged with the publication of the togaf standard version 9.2 The only thing that has gone away Is the reference to service oriented architectures? Everything else is retained But clearly some of the pointers to materials have had to be changed because they are in different documents So finally, let me introduce to you the togaf credentials program We want to extend togaf people certification to recognize detailed knowledge About some of these elements in the extended togaf ecosystem We're also using it to demonstrate up-to-date knowledge and in fact the very first credential that we have launched Does just that the togaf essentials 2018 credential For those of you who don't know what a credential is It is Something that you earn and once you've earned it you are awarded a badge A credential badge But the important thing behind that badge is you have a link That link takes you to material like the stuff on the right hand side of this screen Which explains exactly what you had to do to earn that badge So it's something you put into your LinkedIn profile It's something you can put into your email footer And you can associate that image with a link to give it credibility Because these are not held by the open group. These are held by an organization called acclaim Which has a degree of Of legitimacy It's going to change its name in the not too distant future, but that doesn't affect the program at all So the togaf essentials 2018 badge This is based on a three and a half hour training session Delivered by an accredited togaf training provider Which covers more or less the ground that I've covered today But in a little bit more detail Of 50 minutes against three and a half hours So in order to achieve to get this credential number one You have to be togaf 935 To demonstrate the fact that you understand The basic togaf standard and then you need to demonstrate that you know what's new in 2018 both in the standard And in the body of knowledge So you have this three and a half hour training course There is no formal exam You don't need to go to pierce and view. You don't need to have some kind of Invigilator It's a lightweight online assessment you'll get 20 questions In 30 minutes It's an open book so You can have the togaf standard whatever Available to you while you do this assessment Once you've completed that assessment Achieve the pass mark of 75% You will be invited to accept your togaf essentials 2018 badge So let me remind you what did we launch last week? The latest version of the togaf standard version 9.2 An extensive library of practical guidance In the usage of the togaf standard in different contexts And a credential badge that you can use to indicate that your knowledge of the togaf standard And the togaf ecosystem is up to date So what you need to do those of you who use togaf certification in any way The what you need to do to demonstrate your value to your customers is have the combination of togaf 9 certification and The togaf essentials credential, which is really easy to get does not require a significant investment of either time or money remember some people like me Passed their togaf 9 certification examination eight years ago That particular certification does not indicate whether or not You've done anything with the togaf standard in the intervening eight years The credential says I have taken the trouble to maintain my knowledge up to date And we are going to require all togaf trainers To have the togaf essentials 2018 badge When they start to deliver courses based on version 9.2 of the standard That brings me to the end of The material that I have thank you for your attention