SOA, Governance and Upgrades

I have had the opportunity to work with some excellent people over the last little bit on an upgrade of the underlying technology of a Service Oriented Architecture (SOA) application.  The team I worked with were amazing.  One of the big lessons I had through the process was that in the world of SOA, governance is not a word to be taken lightly.

Say your SOA application is written on Websphere and when you go to upgrade your application framework the above services built are effected by this change in underlying technology.  How do we ensure that our end consumers of our service are not effected without some massive regression test?  SOA was supposed to be that magic bullet that made us less dependent on each other.

But what if our guidelines to our services consumers have enough wiggle room, that how they write their interfaces could have an issue down the road.

This is a real issue that the new platform may need them to more rigidly follow governance due to a higher level functionality.  I guess this all about how tightly coupled we are. 

So whose fault is it?  My observation is no-one.  The rules of SOA are in change, the evolution of our Enterprise applications are in flow.  So now we do have a place, a need and an ability to effect our success by putting in governance.  This will save us from having to:

  • rewrite code
  • do regression testing of our enterprise when someone makes a change
  • help belay the fears that one group may have over another groups efforts.

So now we move forward we work on how we communicate an interface/xml spec and work together to create a higher level of indepence.

  1. Jim Reply

    Governance must be shorthand for something. Could you explain what you mean?

Leave a Reply to Jim Cancel reply

captcha *