Service-Oriented Architecture (SOA) governance is getting a lot of attention. However, within most enterprises, the definition and implementation really depend on the SOA governance vendor that just left the building. Indeed, confusion is a huge issue when considering SOA governance, and the core issues are more about the fundamentals of people and processes, and not the technology.
SOA governance is a concept used for activities related to exercising control over services in an SOA, including tracking, monitoring, and controlling changes made to the services. The trouble arises when SOA governance vendors attempt to define SOA governance around their technology, as all take different approaches to SOA governance. Therefore, it’s important for those who build SOAs within the enterprise to take a step back and understand what’s really needed to support the concept of SOA governance.
The value of SOA governance is pretty simple. Since services make up the foundation of an SOA and are, at their essence, the behavior and information from existing systems externalized, it’s critical to ensure those who access, create, and change services do so using a well-controlled and orderly mechanism. Those of you who already have governance in place, typically around enterprise architectural efforts, will be happy to know that SOA governance doesn’t replace those processes, but becomes a mechanism within the larger enterprise governance concept.
People and processes are the first things to get under control before you begin to toss technology at this problem. This means establishing an understanding of SOA governance with the team members, including why it’s important, who’s involved, and what core processes need to be followed to make SOA governance work. Indeed, the core SOA governance strategy should be independent of the technology. The technology will change over the years, but the core processes and discipline should be relatively durable over time.
Thus, the first step is to define a core SOA governance process that includes, but is not limited to, defining the business objectives, defining policies, designing policies, testing policies, implementing polices, and monitoring policies and services. The idea is to create a lifecycle management approach for both the services and the policies that are bound to them, and like more traditional software development lifecycles, are well-understood by the players at a detail level, and at a high level by the stakeholders.
It’s important to document this process at a very detailed, but functional level. Consider this a “living document” as the processes change, as we continue to refine the processes as we learn more, and as the requirements of the business change.
Once you have a clear understanding of the SOA governance process and the players understand how to implement the process, then and only then do you select the technology set. Within the world of SOA governance there are two types of technology to consider: design-time SOA governance and run-time SOA governance.
Design-time SOA governance, as the name implies, typically provides an integrated registry/repository that attempts to manage a service from its design to its deployment, but typically not during run-time execution of the services, albeit some do. Run-time SOA governance works and plays well in the world of SOA management, and should be linked with design-time SOA governance, but often isn’t. Thus, we have design-time, which is all about defining the policies that need to be enforced by the services and implemented by the consumer of the services. Run-time governance is the process of enforcing and implementing those policies at service run-time, but may do other things as well.
The idea is that once you understood how you’re going to implement SOA governance within your problem domain, selecting the technology to support those processes will be easy. Keep in mind the technology is subordinate to the processes you’ve just established, so don’t get caught up in the hype around the technology. Once again, the processes should be durable over time, whereas the technology will always change.
SOA governance is an important concept, but those who focus too much on the technology and hype are doomed to fail. Get your people and processes under control first, and the rest is easy.
