“o you have a governance plan?” It’s not a question you want to hear while putting together a world changing Service Oriented Architecture (SOA). Governance is one of those words that can strike fear into the heart of a software architect. Visions of endless meetings and committee reviews immediately give you that queasy feeling in the pit of your stomach. Process and overhead guarantee a slow down in an already tight project plan and cause developers to spend more time drawing diagrams and writing documents than actually writing code.
As I delved into the world of SOA governance, I quickly realized that it was nothing new. Rather, it is simply a reorientation and formalization of many of the things good software architects have been doing all along. When you create software architecture, requirements exist that go beyond the immediate requests of the business users. Consistency, repeatability, testability, scalability, and manageability are built into good software architecture. SOA governance ensures that your SOA has them. Governance doesn’t have to be a bad word. In fact, you may already have some of the pieces in place for your SOA governance plan and not even know it. If you’ve spent any time designing software, you might have already solved some of the issues.
Governance allows you to proceed in a proper, consistent, and repeatable manner. Consistency is essential when designing, building, deploying, and managing services across an organization. You’ve used these same principles in enterprise architectures, but now, you’re using them for SOA. It’s about making sure that your SOA scales beyond an initial set of services. In any software architecture, it is important to look at your process and ask yourself if it will work when the application is twice as big. How about five times as big? How about ten? How about when ten other applications are using that component you designed? The point is that adding SOA to the equation does not somehow change the fundamental best practices that you and your organization have followed all along. Let’s explore some of those issues and discuss how they apply to SOA. You’ll see that governance is nothing more than a fancy word for the same things good architects already perform. If you’re building an SOA without considering governance, then you’re only solving half the problem.
Often, governance concepts are divided into two broad categories: design-time and run-time. It helps to bring this back to the familiar realm of traditional software architecture. You can apply a set of best practices and management principles at various phases of the software development lifecycle. Analysis, design, construction, deployment, and maintenance still happen for an SOA and there are still best practices and management principles that you can apply at each phase.
Roughly speaking, design-time governance covers the analysis, design, construction, and deployment phases while run-time governance applies to operations and maintenance. Together, these two phases make up the service lifecycle. Now, you have a taxonomy when designing an SOA. A taxonomy like this is useful because it helps drive the right decisions at the right times.
|Table 1. Taxonomy: Taxonomies are useful in driving decisions.
|Establish key benefits of SOA
|Analysis and Design
|Determine which services to build
|Publish Test Results
|Deploying New Versions
|Retiring Old Versions
Let’s dive into the issues that you need to consider within these two broad categories.Design-Time Governance
The lifecycle of any piece of software really begins with a vision in the initiation phase of the lifecycle?and services?are no different. At this point, it’s important to come to an understanding of why an SOA makes sense for your organization. What properties of SOA provide the most benefit? Is your organization most interested in SOA for interoperability, potential for re-use, external customer availability, or some other factor? As with any software project, it is these factors that will ultimately drive the decision making process going forward. Analyzing these factors/properties may result in a decision that SOA is not a good fit. The key is understanding the problem you are trying to solve and how SOA fits into the solution.
In the analysis and design phase, it’s time to make some tough decisions. For example, what services are you going to build? The importance of this decision cannot be understated. A discussion of Business Process Management (BPM) is beyond the scope of this article but, it is important that consistent criteria and a thorough understanding of the business be applied to the SOA analysis process. It is not simply a matter of turning software components into services. SOA service design should be driven by the business requirements. A system needs to be in place to drive this process. The goal is to enable a repeatable process for determining which services are needed, avoid the creation of duplicate services, and ensure that services provide the proper level of functionality to satisfy consumers.
During analysis and design you’ll have to start making technology decisions. At this point, you should choose a platform along with any third party tools. The choice of tools depend on the given platform and the requirement decisions you have already made. Connected to the platform and tools decision are the policies and Service Level Agreements (SLAs). The policies involve deciding who can call your services, under what circumstances, and how often. The SLA makes promises to the service consumers regarding the availability and responsiveness of your services. When combined, these decisions will help you select the most appropriate tools and platform.
It is finally time for the construction phase:
- Stay consistent for good governance.
- Follow proven practices for your toolset.
- Adhere to coding standards.
- Use established design patterns to isolate the things that change from the things that stay the same.
There is nothing new or mysterious going on here. Adding SOA does not change the basic principles of writing good software.
Testing goes beyond simply trying out the services and making sure they work. There needs to be a strategy in place for proving that the services meet the requirements put together in the analysis phase. That means not only that the services work as expected, but that they are fault tolerant, can scale to the expected workload, perform under stress, and can enforce the policies set forth. There needs to be a solid strategy in place to prove that any given services meet these requirements.
After your services are completed, you’ll need to answer these questions before beginning the deployment phase:
- How will consumers find out about your service?
- Will you use a UDDI registry?
- How will you make SLAs, policies, and test results available to potential consumers of your service?
Just because your services are deployed and available to consumers doesn’t mean that the governance job is done. Remember, governance covers the entire lifecycle of your service from the moment it is conceived until the day it is retired. That means the governance plan needs to cover the monitoring and maintenance phases of the lifecycle. Monitoring your SOA goes beyond simply logging exceptions (although exception management is important). During the design-time phase of governance, you had to make decisions about the policies you would enforce on your services. Now, you must decide how to enforce those policies from a technology perspective. How do you plan to report policy violations and what actions will you take? You’ll need to consider what applications are using your service and how often. Are you going to provide auditing details? If so, how will you track them?
The final stage for your service is maintenance. In the maintenance phase, consider how to roll out new versions of your service to consumers. What will you do in the case of a breaking contract change? Will older versions of your service be kept around to allow consumers time to transition to a newer version? Do you even know who all your consumers are? If so, how will you notify them of a service change? Finally, how do you plan to retire deprecated versions of your services?
Unfortunately, there is no single product that can meet all your SOA governance needs. Technology platforms such as Microsoft .NET and Java provide the underlying technology and can offer some solutions through instrumentation and custom policy capabilities, but they don’t complete the picture. Products from vendors such as Oracle, IBM, AmberPoint, SOA Software, and others can help with lifecycle management and runtime monitoring but again, they don’t solve every problem. When brought in after the fact none of these products are a substitute for a solid governance strategy as an integral part of your SOA. These products and platforms should be evaluated in conjunction with the creation of your governance plan.
There is more to building an SOA than simply building web services. All the experience and all the proven practices you learned pre-SOA still apply in the SOA world. Understanding that helps you understand that governance is your friend and no SOA is complete until a governance plan is part of the design. In this article, I’ve presented some of the questions that are answered by an SOA governance plan but remember, this is not a comprehensive list. A spoonful of governance helps the SOA go down in a most delightful way.