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.