Three best chance principles for building successful SOA programs

During this quieter summer period, I thought it would be worthwhile to restate some of principles that seem to improve the chance of success of a SOA program.

The usual health warning must apply:  There can be no one size fits all approach as SOA must adapt to fit each organization’s history and culture.  And with that caveat out of the way…

1. Identify the strategic benefits of the SOA program

SOA can sometimes be associated with the label of middleware and described as ‘plumbing’ with its associations of little added value but potentially high cost (although I have never quite understood this analogy as most people put good plumbing as a high priority in their homes!).  Compounding this problem, SOA programs can fall into the trap of offering only benefits perceived as intangible by non-IT senior management such as infrastructure improvement or enhanced agility.  Such benefits are not only hard to measure, they are harder to sustain through the inevitable ups and downs of an enterprise wide adoption of SOA.

To overcome this problem, it is essential that these longer term benefits are clearly associated with business benefits.  Otherwise, SOA programs will gather dust on the CIO’s desk or be condemned while partially implemented as a waste of time and money.   Some examples of these longer term benefits might be:

  • Reduced cost of rolling out new business processes: Automating business processes is often a costly and time consuming process, particularly across organizational boundaries.  SOA eases this task by providing a single architecture spanning these boundaries and reducing the cost of assembling new business processes.
  • Ability to track and react to regulatory changes:  Many organizations operate in industries which are forced to comply with multiple regulatory requirements which are moving towards real-time and evolving on an almost constant basis.  Regulation typically requires enhanced auditing of activity, control of process, and reporting – all of which can be addressed within the scope of SOA.

2. Leverage the pragmatic potential of SOA to deliver early benefits with reduced risk

SOA as an architectural rather than technology driven concept is capable of delivering individual projects on an as-needed basis within a consistent framework which ensures cohesiveness across projects over the longer term.  Some observers initially recommended an approach which is front loaded in terms of initial investment in expertise and design.  This is both unnecessary and unlikely to yield the full potential of SOA as a key premise underpinning SOA is that the organization is changing and therefore any initial design will be at risk of becoming out of date from the moment it is created.  Given that this is the case, target specific tactical challenges while taking cognizance of the fact that the solutions provided must be combined later into an enterprise-wide system.

3. Make organizational and role changes to ensure long term success

It is possible to execute an individual SOA project within the existing organizational structures and role changes: the designated project team takes ownership for the SOA project and delivers this project as it would any other project.  However, this approach carries two major risks which has proven fatal to some SOA programs:

  • Failure to develop expertise and control: Scaling any strategic program that spans many participating units such as SOA requires the expertise to be propagated across the organization as is the case with any strategic change program.  Furthermore in the case of SOA where services will be reused across project and organizational boundaries, it is essential that good practises and controls (collectively termed governance) are in place and maintained throughout the program.  This is best done through a designated expertise centre as part of an architecture function within IT.
  • Failure to achieve service reuse: SOA success requires the reuse of services and the level of service reuse is a key metric of success.  High reuse rates can only be achieved if an individual is identified who is responsible within the business line or IT function (depending on the service in question) for driving the rate of reuse for that individual service.  In my opinion, this requires individuals to not only to be tasked but also incented to drive up reuse of their portfolio of services.

Ronan

Posted in Imported, SOA.

Leave a Reply

Your email address will not be published. Required fields are marked *