 Toba, 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 have already shown you the version of this for business architecture. So we've 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. So 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 have got a photographic memory and can remember back from the TOGAP 9.1 metamodel, the location entity was colored, which meant that we saw it as an optional extension. By 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've 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 ArchiMate 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 aligned with what's called BizBock. 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 TOGAP content framework and metamodel. So you see, we've now put in lots of changes to relationships, for example, linking course of action to goal, value stream to goal, business capability to function, value stream to business capability, actors to value streams. So there's been a lot of thought going 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 APIs. So it's renamed technology service. More significantly, we've actually 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 TOGAP 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.