I’ve always maintained its difficult judge your Enterprise Architect at annual reviews because the success of what we do can only really be judged over longer periods. I’d like to share a SOA success story that goes back to 2005 and has stood the test of time:

The initial business problem was to outsource part of the organisation but reading between the lines it could be seen that this was an area that was likely to undergo more changes. It also involved multiple ‘consumer’ systems wanting to use similar ‘services’ that would be provided from more than one system.

The scenario met the two things I have come to recognise as requirements where a SOA will deliver the maximum impact to the organisation:

1)      There is demand from three, or more, systems for a given service. This satisfies Robert L Glass’s “rule of three” (Fact 18) from his book Facts and Fallacies of Software Engineering which states it is “three times as difficult to build reusable components as single use components” and “a reusable component should be tried in three different applications before it will be sufficiently general….”. I’ve seen SOA approaches used where there is only a single client and yes, these work, but was the extra build cost worth it?

2)      The organisation using the proposed SOA is undergoing a prolonged period of change. How you can judge this is more gut instinct than a known fact but you can look at how the wider industry is changing.

I’d say these two facts alone make SOA a likely candidate but there was a third reason: the service was likely to be provided by more than one implementation (because some of the requests would be answered by another organisation) thus a need to bring in some middleware features like content-based-routing.

Buying a service from another organisation is also a good indicator that SOA principles and designs can be applied because there must be a contract, both in the legal sense and technical sense.  I would expect the purchasing organisation to drive the integration and the supplying organisation to provide the service, technically.

So what happened? Well the SOA went in fairly smoothly and then:

• The outsourcing was abandoned
• A significant portion of the original systems were replaced with updated implementations
• The organisation was sold and merged with another organisation, requiring additional ‘consumers’ and’ providers’ to be added and requests to be routed
• The newly merged organisation sold a large part of itself, introducing even more complexity during a two-year transition
• Once the transition was complete the remaining systems could be simplified

Throughout all these changes the SOA proved to be adaptable and flexible. Some changes were necessary but the fundamental design endured.

Follow