SOA Governance Is Not a Documentation Exercise

by Mervin Chiang

SOA governance doesn't have to be a massive undertaking

Published May 2010

Download
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:

1. Your SOA project team goes away on a group holiday and their bus rolls off a cliff. How much information have you lost? How fast can you start the project again with a new team?
2. You have to revisit this same SOA project area again in two years. How much can you reuse? Can you truly achieve agility here?

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.

Practical Governance

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.

Step 1: Strategy

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?

• A strategy focused on speed may result in reduced reusability and agility, because it may not allow time to discover or build highly reusable services.
• A strategy focused on reusability can have the opposite effect, slowing down your project methodology in order to allow time to better understand your service portfolio in order to build reusable services.
• A strategy focused on agility is probably the most difficult to implement because it requires a sound architecture to ensure a speedy response to business processes changes.

Step 2: Architecture

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:

1. The classifications have to be clear and distinguishable from each other. Think: how is a business service different from a proxy service? What is the difference between an orchestration service and a business service? If there are gray areas, rethink.
2. Specify examples and design templates or patterns for each classification.
3. Complete a draft portfolio of the service architecture based on your classifications. Remember, the theme here is practicality. Don't dwell on the architecture too long, If you reach an impasse, pick a best fit, and test it by moving on.

Step 3: Method

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.

Step 4: Competency

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.

Step 5: Technology

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:

• A common governance repository that hosts your SOA reference architecture and all its defined artifacts. And I;m not just talking about a UDDI v3- compliant service registry. Do you have a relational repository that can index services and relevant artifacts and tell you which are owned by whom? Which business processes those services address? Which corporate strategy those services fulfill?
• To increase agility you may want to consider automation. This means to execute or workflow some parts of your processes in the methodology in order to accelerate the lifecycle once it becomes stable
• To maximize reusability, you may want to consider scripts, reports, or enablers to enhance the discoverability of the services. And I don't mean a search engine that gives you the service name and its Web Services Description Language (WSDL) location. You'll probably want to know a whole lot more about that service: its owner, its typical consumers, incoming and outgoing dependencies (what it consumes; what consumes it), and its classification and place in the SOA.
• To increase speed, you may want to acquire best-fit reference models or prebuilt adapter sets. You can do this once you have a stable version of your architecture and your methology is comfortabley defined. You'll know what to look for.

Taming the SOA Governance Beast

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.

---

Mervin Chiang ( LinkedIn | Twitter | Blog) is a consulting principal with the SOA specialist services group Leonardo Consulting.