Wednesday, December 5, 2007

Forget the Horse....just use the Cart

I was intrigued by this post from Tom Cozzolino from Liquid Hub asking the question "Will the absence of a governance strategy doom your SOA project?". SOA Governance means many things to many people, but I think that everyone can agree that a well formed and well executed SOA Governance strategy is critical to the success of any SOA initiative. In fact, a governance strategy is critical to the success of most any IT project that you may be working on. I say this with the understanding that "governance" is really a catchall phrase for implementing the necessary controls to insure that the business objectives that you establish for your IT initiatives are actually being realized by the projects as they are being delivered.

My experience tells me that most organizations today are investing in SOA projects. Some do not categorize their investment as "SOA" specifically, but let's face it we are all using XML, Web Services, and the evolving standards to build new applications, integrate existing systems, and create new products and services for our customers. We are doing this for two primary reasons:

1. We have to be able to react more quickly to changing market dynamics so that we can remain competitive, and "SOA" provides an opportunity to do that by providing standard building blocks that will allow me to continue to use the new assets and services that I am creating in new and different ways, giving me the ability to rapidly create new applications from composite services, and

2. We have to break the cycle of spending the majority of our budget (in most cases up to 80% of our IT budget) on "keeping the lights on". We have to shift the balance so that more of our money is spent on innovation and new development.

In both cases SOA provides the means to the end that we are trying to achieve. The questions really begin after we have made the decision that we need to do this. How do we get started? That is the question that I get most often. The answers that are generally provided are similar to what Tom is recommending. Go buy a registry/repository and make sure that everyone is putting their assets into the reg/rep so that they can be discovered and used by other projects. In theory it sounds great, in practice it is "Forget about the Horse....just use the Cart".

The analogy is simple. If you standup a registry/repository and have everyone put their work into it you are simply allowing poor design practices, poor development practices, and likely poor services to be made available for consumption. You are doing more than "Putting the cart before the horse", you are eliminating the horse altogether.

The single largest killer of SOA initiatives within enterprises today is the first time a poorly conceived and developed service is used by a project team and it fails. Confidence falls, momentum stalls, and the doubters get a clear indication that this "SOA thing" will not work. A simple and long standing fact of "garbage in, garbage out". Something we all learned decades ago. This is what you will get if your first step in any SOA initiative is to provide a registry/repository to your project teams without the necessary governance policies in place to certify your services.

I contend that you should take a different view of governance for your SOA initiatives. I contend that you should apply the same principles that you are already using, with one exception. SOA is an architecture – you can’t buy this. To achieve SOA, you first need to define the standards, guidelines and best practices you need the organization to adhere to as services are built. These should be codified as policies and form the basis for your governance initiative, from DAY ONE.

You probably have already established some type of governance process (ok, call it an SDLC applied to SOA), and that process includes a formal set of "gates" that you take your projects through where you can review the work that is being done. When you review the work, you are applying a set of policies to determine if the artifacts you are reviewing (design documents, component code, WSDL's, XML Schema, etc.) comply with the policies that you have established to ensure that the business objectives that you are trying to achieve are being met. The exception is that you should remove the mundane task and tedious work of applying these policies to the artifacts, and automate the enforcement of those policies.

You should do this as early in the project life-cycle as possible (I say Day One), and you should provide continuous and consistent enforcement across the entire life-cycle. This cannot be accomplished if you wait until the artifacts are published to the reg/rep. What about the design documents that are typically stored in a document repository or file system? What about the component code (Java, C#, Cobol, etc.) that is typically worked on in some IDE and stored in a source code repository? Yes, what about the WSDL's and XML Schema that makeup the interfaces for your services?

In order to have a comprehensive Governance approach, you need to establish and enforce policies from inception through operations for your IT projects including your SOA projects. You do this today, generally with a manual approach. Why not automate that with a comprehensive Policy Management solution and free your resources to focus on exceptions and higher order problems?