The Rabbit Hole

Considerations and reflection on technology and IT strategy

linked-In Follow on TwitterRSS Feed
Laurent Chades


Posted on January 3rd, 2010 by Laurent Chades

Ok ok, I know that IT and SOA governance have been quite fashionable words. But let’s stay away from hype in this short note.

Sometimes, integrators don’t see the need for governance. Recently I even heard someone saying ‘SOA governance are boyscouts’ practices ! We don’t need this‘. In his defense,  I must admit that we have heard and red so many things (too many?),  that governance has been completely discredited. Furthermore, integrators are often present for a limited period. They deliver the system their customer ordered and their action is over. They not always see what a system without governance can become.

From a recent experience, I would say that SOA governance must be implemented directly by  customers (or with some help from third party consultants).  First, this is a way to ensure that the implementation and management of the system fits in the initial vision. The second point is that SOA governance is often a question of  arbitration between actors of the enterprise. Considering this, an integrator, as an external actor, may not have sufficient political weight to be efficient in this role due to the following points (not exhaustive ; feel free to add yours in the comments):

  • An integrator may not fully have access to the sponsor whereas others actors from the enterprise may have.
  • As I’ve seen sometimes, an integrator may have direct or indirect stakes in another project involved in a decision making that could prevent him to follow the governance principles

Another common pitfall I’ve met is the illusion of SOA governance. In this case, the project had a good design method, that ensured traceability of the functional requirements from logical architecture to the code delivery. This is a good practice, and the technical leader argued that since it was possible to track the impact of a change in the code, it was enough to avoid the definition of services governance. But SOA and services governance are different things, good design and development practices don’t substitute to governance (and vice versa). SOA governance is not about managing the implementation and the internal design of services. It focuses on the services availability to consumers, evolution decisions and the impact analysis on actual consumers, decision to expose or withdraw a service, management of the service levels and capacity planning …

No matter in which case you are, if your governance process is not efficient or doesn’t exist, one day or another, someone is going to say ‘Oh my god!! We had a really clear vision of what we wanted and how it was supposed to work, how did we get here?‘.  But ‘efficient’ doesn’t mean necessarily heavy. A good governance process must be appropriate. By appropriate, I mean 2 things:

  • Setting up governance must be an iterative process. With you first integration project introducing the need for SOA governance, you should only concentrate on what’s relevant at this first level. The principles you define must focus on your immediate problems: service life cycle definition, service versioning policy, … Keep complex things  for a later iteration, for instance, you won’t meet governance issues concerning 2 different service consumers asking for 2 different evolutions of the same service if this service does not exist yet. Concentrate on the first delivery of the services to their consumers. This is more appropriate and will enable you to reach a good maturity level of your first principles ; they will be the foundations for the next iterations.
  • Don’t get lost in over-sized tooling ; Governance is not ‘tools’. Deploying and customizing complex tools if you’re in the early stage of your SOA transformation could lead to extra costs. Indeed, your governance process will probably change a lot at the beginning and you maybe won’t have a lot of services to manage at this stage. Wait to have a stabilized version of your governance, this will prevent you to implement something you are going to remove. Furthermore, if you are not familiar with SOA principles, you’ll have a better idea of the help a tool should provide once you have made your first iteration and your process is running smoothly.

As a conclusion I would just say don’t neglect your governance process. It’s not required to be huge and overwhelming, keep it simple and rational.

Be Sociable, Share!

Comments are closed.

Laurent Chades' Blog

  • Tags

  • RSS News

Copyright © 2010 Laurent Chades. Theme by THAT Agency powered by WordPress.