1. Architecture Capability Framework and Architecture Governance
Now, architecture governance is a few things. It’s three things. It’s a system of controls over architecture. And so you’re going to put governance in place and it basically going to be a systemize process for how you make changes to your architecture. You do not just get that idea at 09:00 A. m. To make a modification to your architecture. Load up the document and Ms word, make a change, hit save, increase the version number, and within ten minutes you’re done right. Governance controls how architecture changes. It’s also ensuring compliance with the architecture.
So you’ve got your architecture set in stone, pretty much. The implementation team has signed what’s called the Architecture contract in order to ensure that they’re delivering what was defined in the architecture. And then as an ongoing basis, months and years in and down the road, you’re still making sure that the architecture complies with the definitions that you’ve created and that there’s not been any changes to the architecture that haven’t been gone through the architecture governance process. Architecture governance has to do with the management of these systems and finally accountability to the business for this.
So as a governance team governance team is going to basically have to go back to both the corporate governance, which might be executive board, it’s going to go to it governance or technology governance and basically say, we said we would deliver this, the team delivered this, and we can ensure that so many months down the road we’re still complying with that. Now, most organizations just they don’t have an architecture governance board and no other form of governance. There are many different kinds of governance within organizations. You’ve got that top level corporate governance. And this is sort of outside the scope of TOGAF and outside the scope of enterprise architecture.
But there’s got to be a group of people that meet every once in a while to talk about the company as a whole, the long term vision, making sure that each department has goals and what they’re measuring to achieve those goals. Technology also. And it are both types of governance as well that are outside the scope of enterprise architecture. But of course, you’re working with those teams. And finally we have the architecture governance that we’re just talking about. So what is a principle of good governance? The Togov 9. 2 standard does have some concepts of what good governance means. There’s six of them, one of them is discipline.
So essentially, everyone who’s involved in governance needs to be committed to adhering to that process, really. And you have to understand that this is the authority. You cannot make a change to the architecture without the approval of the Architecture Governance Board. And everyone that’s involved in that has agreed to that and follows it. Transparency means that all actions are available for inspection. So essentially, if somebody wants to come back and say, hey, what was the deal with this decision and how did that get made? That everything’s available for inspection.
Independence means that you don’t have a particular department or a team or a person who has undue influence over the decision making. So you’re making decisions on the Architecture Board for the good of the entire organization. And it’s not like one particular department is sort of pulling stuff into their direction. And there’s conflicts of interest, for instance, accountability. We talked about the layers of governance. The Architecture Governance Board is responsible to the corporate governance and it governance, et cetera, above it in terms of they made decisions and they can stand by their decisions, they’re accountable for them.
Responsibility means that everyone who’s involved in architecture governance has to act responsibly. Finally, fairness is pretty self explanatory, but you want to make sure that all your decisions that are made on the architecture governance process don’t give an unfair advantage to any particular party. So you’re again operating in the interests of the entire organization and not favoring a particular member, a particular group who’s always getting their way at the expense of other parties. And so that’s the characteristics of good governance.
Now, the Architecture Board, we’ve talked about that a few times, but the Architecture Board is essentially a cross organization board that makes sure that your architecture governance is executed. It is supposed to be representative of all the key stakeholders. And so it’s not just your enterprise architect who has self appointed himself to lead the board. It’s supposed to be some senior members across different departments who meet, say you meet once a month or whatever. That process that you establish is to make these architecture decisions and it basically represents your entire organization. And that way you can follow those key principles.
Now, we’re talking about architecture capability and the Architecture Capability framework. Another element of that is what’s called architecture contracts. The toga F 9. 2 specification defines architecture contracts as joint agreements between development partners and sponsors on the deliverables, quality and fitness for purpose of an architecture. Now, there are various points within the adm where you can establish a contract. When you are kicking off an adm phase, in the Phase a Architecture Vision phase, you are agreeing to a statement of work.
That statement of work is technically a contract between the sponsors and the people who are paying for the architecture work and yourself to say that you’re going to create an architecture that meets their purposes. Then when you go into the implementation, into Phase G and Phase H, you are creating contracts with the implementers to say that they’re going to follow the architecture and they’re going to agree that you give them exactly what to implement and they go and implement it. And particularly in Phase H, as we are going into more of a maintenance mode and operations, that they’re not going to start changing what they’ve just implemented without following the proper architecture governance.
So that’s an architecture contract. Another concept of architecture capability is called Architecture compliance. I think this is important for the exam in that you should know there are different definitions for compliance. So what does it mean when you say that an architecture is compliant? Now, the on screen are six definitions that are given by the togga 9. 2 standard and each of them means something slightly different when it comes to how an architecture matches the definition, how the implementation matches the definition. So an irrelevant architecture means that the definition and the implementation have nothing in common, right? There’s just no overlap between the features that you’re talking about in your architecture and what is the implementation.
So it’s not even you can’t even say that it follows or doesn’t because they’re not even touching. A consistent architecture means that your architecture specification, there’s parts of it that have been fully implemented and properly implemented, but the implementation doesn’t cover every single part of your, your specification and there’s parts of the implementation that are not in your specification. But it’s so it’s not wrong, it’s just not perfect. In the compliance section, your implementation is 100% true to your architecture definition, except there’s whole parts of your definition that are not implemented.
So the implementation essentially is a subset of your overall architecture. conformit is the other way around. It’s, that the implementation is a superset. So you’ve implemented the entire architecture as written, plus more that’s conformant architecture. A fully conformant architecture is perfection, essentially, that the architecture that is implemented and the architecture that is written is 100% mapped, right? There’s nothing that’s implemented that wasn’t in the architecture and there’s nothing in the architecture that wasn’t implemented.
So that’s sort of fully conformant is sort of the top level of architecture compliance. And finally, nonconformance and nonconformance means that there are features in the architecture specification which are implemented but are not in accordance with the specification. So they’ve done something that you didn’t, not only didn’t you tell them to do, but you tell them to do something different and they did it different. So these are sort of the key features, the architecture board, compliance contracts, governance. These are things that you need to know when it comes to architecture capability.
Finally, we can talk about compliance reviews. We said as you go into the implementation, the Phase G implementation governance section, you’re going to want to make sure as you go along that the architecture being developed is in compliance with what you have defined. And so those are compliance reviews. It’s also part of Phase H. When you are in that waiting mode, when you are looking at changes to the horizon, when you’re handling change requests, that you want to make sure that the implementation doesn’t change, that there’s no unapproved change.
