The enforcement mechanisms you build into governance are crucial. If you’re not enforcing policies, they’re just suggestions. We’re not talking about thugs in jackboots; just make sure that architectural reviews, routine audits, project scorecards, and other measurement activities are tied to natural gating activities such as project planning, project funding releases, and code promotion.
Equally important is to ensure that your process includes an effective feedback loop. As webMethod’s Matsumura says, “A governance mechanism is intrinsically federated. It is neither a ‘you must follow this cookbook’ nor is it something that’s completely fluid. Create a structure that allows for evolution. Policies are manifested in law, and law evolves according to feedback from enforcement. Adjudication procedures built into your governance process will provide feedback on your enforcement process.”
Feedback mechanisms should also include a review board for the process itself, because constant tweaking of the process is a fact of life. A review board leads to continued evolutionary improvement.
In the end, the governance process you create must match the culture of your organization. Some companies do better with more centralized processes, while others have better luck with decentralization.
An SOA enterprise architecture is one of the most important artifacts that the governance process produces. But building one is no small feat. In fact, you might as well reconcile yourself to the idea that it will never be completely finished.
So what’s the order of assembly in the never-ending task of building an SOA enterprise architecture? For many organizations, the most effective route is to build pieces just in time. Start with an interoperability framework, since it’s the easiest part of the enterprise architecture to create. An interoperability framework is a list of supported standards that has been annotated with meta-information, including status indicators that say which standards are required, suggested, supported, or ready for sunset. Building an interoperability framework breaks everyone in and uncovers the weak spots in your governance process.
As a rule of thumb, work on policies that will make the biggest difference first. Almost every significant SOA project, for example, chokes on authentication and authorization issues at one point or another. Without a coherent policy, each project will go its own way and the result will be incompatibility and costly retooling later on.
Registries are another area where policies can make a difference early on. Plan out your registry strategy and then make sure that you have policies in place to support it.
Enterprise and system-level reference architectures show developers, architects, and project managers the preferred way to do everything from building hooks in their code for WSM (Web service management) tools to preferred hardware deployments for high-availability applications.
“If you don’t have a reference architecture in place, the project team will take the path of least resistance,” says MomentumSI’s Biske. “Reference architectures can be too general, giving the application architect too little guidance, or too specific, giving them no leeway.”