 Now let me talk about the ISO, IEC, IEEE, 4210, 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 had 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 Togath standard and the ISO standard is complex. Where it is appropriate, we have used the definitions from the ISO, IEC, IEEE standard as the basis for defining similar concepts in the Togath standard. We do not fully conform to that standard. Part of the reason for that is that we have hundreds of thousands of people who use Togath, 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. Differ means that if we're different, we're wrong. We don't. Togath 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 been done, and we've worked very closely with the technical editor of the ISO, IEC, IEEE 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, description, 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 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 a view is a representation of the system from the perspective of a related set of concerns, and a typical view will aggregate one or more models. And a model is a representation of a subject of interest. A 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 one or more models. So a 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 kind. Togeth 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 Togeth 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 Togeth standard, anything in that box could be considered to be an architecture or a work product that describes an aspect of the architecture. Architecture viewpoint, architecture view, model kind, or architecture model.