Co-authors Thomas Erl and Anne Thomas Manes discuss their recently published book, SOA Governance: Governing Shared...
Services On-Premise and in the Cloud (Prentice Hall, April 2011). They delve into the trending adoption curve of SOA governance, agile governance and the looming governance tasks of cloud computing.
How you define SOA governance?
Anne Thomas Manes: The quick definition is 'governance makes the rules.' A lot of people think it will impose more work, but the best governance system is one that people appreciate, that helps people get work done, with the highest quality, and that is beneficial to business. The essence [of any governance system] is the same; the distinction with SOA governance is what things do I need to govern when I apply service-orientation to my application portfolio. What are the extra things I have to cover? These are important decisions related to an SOA initiative that you didn’t deal with before, so it’s how you define the rules associated with this.
This is an important point: An SOA governance model and system has to be in alignment with all the rest of the governance in the organization. You can’t go off and create a bunch of processes and a new level of authority that contradicts stuff you’ve got in place.
Where are organizations in the adoption curve of SOA governance?
Manes: A lot of companies have barely touched the surface; others have just enough governance to keep it under control. A lot of companies think governance is something you buy—you get a registry, repository, management utilities, and you have governance. That’s not governance. Those are tools that help you manage information and operations; you can enforce security and runtime policies, but that doesn’t help you to define policies and who makes decisions, or to establish processes to coordinate your investments into SOA and execution of the SOA initiative.
Thomas Erl: We’ve not often seen true SOA governance in place, something that genuinely addresses the distinct aspects of adopting and applying service-orientation to your project delivery lifecycle and methodology. As a result, you still have organizations under the belief they’re doing SOA governance, but they’re not getting the results they expected. They apply other forms of IT governance or other approaches to SOA projects and it’s not always the right match. You end up with conflicting priorities or requirements, and get disappointing results.
You also hear lot about standardization in terms of it being the central part of doing SOA the right way and there continues to be confusion around adopting industry standards. You need to define standards custom to your requirements/environment/business goals and the scope to which you’re adopting SOA. Those types of standards are critical to success, where you truly get the opportunity to establish consistent characteristics of the services you deliver. If you apply SOA governance, you’re forced to make that distinction early on in the planning and modeling so those standards are part of the system.
You describe several styles of SOA governance—centralized, federated, independent. Is there one style that offers more benefits?
Manes: Most agree the federated model is most effective, but it won’t work in every organization. The governance style must be compatible with the organizational style that’s in place.
Erl: It depends on the scope of adoption. When you adopt SOA, especially in a larger IT enterprise, what’s often not feasible is a big bang approach to transform the entire enterprise. Those environments are better off with a domain-based approach that can be independently owned and governed. Ideally this needs to be planned ahead of time. You can have one parent SOA governance office oversee different domains with their own governance systems, and the parent office assures certain baseline standards are applied.
You say the first step in an SOA governance effort is to establish a SOA governance program office. What would that consist of?
Manes: Having a recognized office with the authority to establish rules is a prerequisite for any program. It’s a good idea to have input from multiple perspectives—those who are familiar with the processes that people go through for determining how to approve investments in any software project. Likewise, you’ve got people well versed in the current program for deploying and developing applications. The same people who established the software development governance program are likely to be involved in the creation of a SOA governance program.
Erl: The SOA governance program office is primarily led by those who understand SOA and service-orientation and those who specialize in IT governance. The SOA governance program encompasses the governance system, but also all the other logistical aspects of that system, so project plans, roadmaps, tools, and the steps to make it part of the overall means by which projects are regulated.
Is there such a thing as agile governance?
Manes: When defining your precepts you need to constantly be willing to reassess if you’re achieving your goals, by reevaluating and understanding if they’re helping you deliver better solutions more quickly and then going back [and addressing them if they’re not]. That’s the definition of agile.
Erl: The governance system for an SOA initiative needs to be inherently responsive to business changes. To me, a governance system improves the responsiveness of those that function within it because so many decisions have already been made. A good analogy is made by [co-author] Leo Shuster: A governance system is like the guardrails along the highway. Putting the system in place requires effort and investment, but once you have it there you follow it again and again as you deliver more services. Like guardrails, governance is something that improves agility and lowers the risk of delivering services and augmenting existing solutions in response to change. If a governance system is flexible while maintaining the required level of regulation and consistency that maximizes the chances of it being effective.
What are the governance considerations specific to cloud-based services?
Erl: When your resources are hosted by a third-party cloud provider, there is a limitation to the extent of control as to how they can be governed. That’s something to factor into the governance system. If your governance says it has to comply with industry standards and the supplier doesn’t support that, you have to say ‘How can we [govern] within the cloud given these constraints and still be in support of our business requirements?’ The other extreme is when you deploy an entire set of services in the cloud and the governance system itself is customized for that particular environment. That’s rare right now.
Manes: You have more inherent risk in deploying in the cloud and need to take appropriate risk mitigation by deploying [governance] precepts specifically for the cloud.
Related SOA Governance information
Understanding SOA Governance sample chapter from “SOA Governance: Governing Shared Services On-Premise and in the Cloud,” by Erl et al. – PearsonCMG.com