Enterprise Architecture has a role to play in both developing a vision of the future, and in providing governance and oversight to make sure that the organization can measure its progress towards that future.
The governance part is tricky. Architectural Governance is part of a larger fabric of governance that needs to exist throughout the organization, not just in IT but also in the business groups themselves. This means that governance has two masters. Governance has to align to business value, on one hand, and “measures of compliance” on the other.
For enterprise architecture, the business value lies on the proposition that systems designed with better architecture will be more flexible, maintainable, and reliable than systems that are not. Measures of compliance, on the other hand, can include things like “numbers of projects reviewed” or “evaluated quality of architecture is trending upward.”
In my opinion, governance is about motivating people to do the right thing. All compliance programs are really all about helping a person or team to do the right thing. There are may ways to that goal.
Of course, it’s a challenge, in any society or organization, to define what it means to “do the right thing.” I’ve noticed, as I conduct the architecture review program here in Microsoft IT, that there is a spectrum of governance. Different people in the organization tend to fall somewhere along this spectrum. Some folks want to “educate and encourage” good behavior, while others want to “monitor and inform” management about bad behavior.
The reason that I point out this obvious fact is that your Enterprise Architecture governance program will have many components. One component may surround innovation, and another may surround process improvement. In my organization, we have a governance process around architectural standards and review.
Each component will have an owner. The owner is the person who is accountable for insuring that a particular behavior (do the right thing) is happening. For architectural review in Microsoft IT, that is the Microsoft IT CTO Barry Briggs. He also happens to own the measurements for our architectural repository.
For each component of governance, it is important that you expose the governance owner to this spectrum and get agreement to the question: “Where on the spectrum do we want to be?” Even better: add the element of time to the conversation. “Where should we start?” and “Where should we end up?”
By getting your compliance owner to declare, specifically, where your compliance program needs to be on this spectrum, you are able to do many things:
In one case, one of our partners was working with Microsoft on their SOA program. Their IT Leadership wanted to improve the use of shared services. They developed a shared service reuse program and a governance model to make sure that everyone used the services. The governance program was poorly rolled out and executed, and the program lost credibility.
As a result, whenever anyone asked about using those shared services, that person was derided and their idea discarded. In order to get past compliance, managers created a crafty way to “game the system” in reporting the results. While the compliance numbers looked good on paper, the actual use of shared services declined overall. The program that sought to increase the use of shared services caused it to decline instead.
Compliance is part of the game when you are trying to encourage good behavior in an organization. Making it work is not easy. The person responsible for insuring that compliance occurs has to have the right level of ownership and accountability. But just as importantly, they need to carefully consider where, on the spectrum of governance their program should be, now and in the future, in order to deliver on business value without encouraging different kinds of bad behavior.
Looking at your 'Spectrum of Governance', I'm reminded of a workshop I took way back when on Situational Leadership. It's a very basic idea, that as a leader you need to adapt your style to the motivation and skill level of your, well, follower.
Seems to me that the appropriate place on your spectrum would also be very influenced by the architectural maturity of the organization as well. An organization that's very clued in about architecture, but for whatever reason is resistant, might require a more punitive model. An organization where people are more or less bought into the concept but don't know as much about it would be better suited to a coaching / encouraging style of governance, and so on. Fairly obvious, I suppose, but I think a decent way to link up maturity models and governance models.
Interesting point, Derek. I agree that the model of governance that you select is going to depend on the readiness of the organization to accept it. It will also depend on the goals you are trying to achieve. Unlike situational leadership, where you are leading people, the composition of an organization, and the momentum towards, or away from, change can be altered very quickly with changes in staffing, leadership positions, and org structure.