by Mervin Chiang
Published May 2010
Oracle SOA Governance
Responses to the question "What are we doing about SOA governance?" vary. Some try to dodge the question. Others offer a fuzzy explanation that something is being done, and mumble something about managing services in an Excel spreadsheet.
So what is SOA governance? Do organizations really need it at all? If the answer is yes, where should you start? SOA governance doesn't have to be a massive undertaking. This article will walk you through this mysterious topic of SOA governance, its importance, and how to get started.
Architecture is the "A" in SOA. The term architecture carries ominous implications. But a significant part of governing Service-Oriented Architecture boils down to a matter of service management.
Why manage services?
At the start of this paper, we alluded to the fuzziness of people's understanding of SOA governance. When the issue of SOA governance is raised, one common response is, "We're just starting out and have only two dozen services. Do we need this?" Another response is, "This is only our first SOA project. Let's first see how it goes."
These responses imply that the organizations in question equate SOA governance with the thick manual that comes with a digital camera. How often do we refer to these manuals after we open the box? There may be some complex functionality on the camera that you want to explore, but you avoid the manual.
Let's consider two scenarios:
Speed, reusability, and agility are the top three promised outcomes of SOA. Speed can be realized quite easily in this technology. But how can you ensure reusability and agility?
I'd like to propose the notion that simply considering and applying basic SOA governance, or service management, can go a long way.
SOA governance does not have to be complex and difficult task. By adhering to a few sound steps, governance can begin on day one of any SOA journey. This assumes, however, that you want to keep using SOA in your organization. If you have invested a lot into this technology to only use it once in a single project, this article will be of little interest. However, if you really want to maximise your investments and reduce rework, some simple planning and governance at the start can go a long way.
Figure 1 shows a simple breakdown of the basic construction of service management, illustrating five steps to start practical SOA governance. Remember, the goal is to ensure the longevity of your SOA journey and to lower long-term costs by starting now, in your short-term project.
Your SOA governance strategy doesn't have to be a long and highly debated exercise, and it doesn't have to be 30 pages long. The idea is to prioritize the various benefits your organization perceives as important reasons to use SOA. Those priorities then drive the foundational principles for service design in building out your SOA. For example, which is more important to your organization: speed, reusability, or agility?
In this context, architecture does not refer to physical or infrastructure architecture. This is not about how the BPEL engine talks to the enterprise service bus (ESB) or where the service registry would sit. This is more about your service meta-architecture or SOA reference architecture, which will define the taxonomies in the services you build and the services themselves. Again, this need not be a laborious task involving multiple architects debating in a room. A simple first step can be to agree on a clearly defined set of classifications that will distinguish your services. Here are a few guiding principles:
Many organizations I come across ask; What methodology should we use? What's the standard SOA methodology? What is a methodology?
A methodology is a clear set of defined steps to take to achieve a goal. In other words, a process. In this case, it's the process for SOA. I don't know if we will ever have the standard SOA methodology. But you should consider the following three views when evaluating a service. You will need processes to handle each of these views, and they will be highly dependent on the strategy you have defined in Step 1.
Services from a project view. How are services conceived and designed? If you focus on reusability or agility, is there more time allocated to service discovery and better service design?
Services from a lifecycle view. Once services are deployed into production, are there methods for their continuous optimization? Do you consider rebuilding for better reuse? Do you consider service bundling for greater agility?
Services from an enterprise view. This may be the most important of the three views. Refining the five steps in this article is just as important as the SOA project or the services themselves. This makes practical SOA governance possible. As you undertake more and more SOA projects, you will need to refine your architecture and improve your SOA methodology. But you will have a better service portfolio and therefore greater visibility for planning ahead.
This step combats complacency. Once you have the processes around SOA-your methodology-you can identify the skills and roles required to ensure longevity in your SOA roadmap. This step is critical to protect against your SOA ace walking out on you to join a competitor. There are many roles involved in a SOA ecosystem. Proactively indentifying them and planning for training ensures that if your team really goes on a holiday and never returns, you have a competency framework for systematically filling the roles that are key to ensuring a successful SOA journey.
Finally, you are ready to look at the tools you will need to improve your SOA journey. Obviously in SOA, you will need some sort of process engine-an ESB and various other components that make up what one would consider a SOA environment. However, with the previous four steps in mind, what is what is missing from your SOA setup? The following are important considerations:
The five steps outlined in this article should help to demonstrate that SOA governance need not be difficult exercise. The biggest pitfall is the failure to consider it initially. That failure typically results in a lot of re-architecting of your SOA down the road. The important thing to remember is that this is an incremental and iterative journey. Service management is a lifecycle in itself, and if your SOA plans extend beyond a single project, you must consider SOA Governance on Day One.