In praise of quick wins

Ronan Bradley of Polar Lake makes a good point: Why should customers experience pain today on the promise of an easier life tomorrow?


I should admit that I have some sympathy with the knee-jerk "no-pain, no-gain" expectation that many proponents of SOA often set - it's certainly true that it's always easier to solve a point problem with a point solution. But this has always been true.

Let's consider why organisations are looking at SOA.

On the one hand, the IT department is being relentlessly pressured to deliver value to the business. The business is feeling constant pain because of IT inadequacies: they want to see all details of a customer on one screen, they want address changes to flow across systems without rekeying, they want to introduce new products in a month rather than a year, they want to know where the mortgage application is, they want to bill for broadband access and phone calls on the same piece of paper... and the "useless" IT systems won't let them do it!

On the other hand, the organisation's IT landscape is a mess. A big, unholy, horrid mess. Systems have been implemented over the years on different platforms, different architectures, to serve different (usually overlapping) areas of the business and all have differing qualities of service and individual peculiarities.

Solving a problem for the business isn't difficult: it's almost impossible.

Now, unless you are incredibly fortunate, you simply don't get the chance to start again. But, as Ronan hints, you don't even get the chance to take a hit and put an SOA in place. Yes... you know it will have untold benefits in the future (and it will). Just imagine having all the key services in your IT landscape available as reusable well-defined components. Bliss!

But... in the meantime, all that the business will see is a massive IT project that has no visible external results. The call centre staff still have to rekey data and customers still complain when their accounts are updated incorrectly. Not many of my clients will get the chance to build this vision in one go.

So what's the answer?

The answer is to remember where we're trying to get to (This guy describes it well). The point is: it is acceptable to build out your SOA as you go.

If you choose to follow this approach, the problem now becomes one of selecting a tool that allows you to expose your applications' services to the enterprise as a side-effect of the main development process. That is: tools that let you - in one step - build your new solution and expose relevant services at the same time. Conflating the two steps has the valuable property that there is nothing to cut out of the project plan when the pressure mounts: the creation of services is core to the current development project. The long-term interests of the IT department and the sponsoring business are now aligned.

I don't want to turn this into a product plug but it would be a dereliction of duty if I were to fail to mention WebSphere Process Server. It is designed from the ground up to be our SOA development platform and supports precisely the vision I have outlined above.

Usual disclaimers apply: this is my personal opinion, these are not necessarily IBM's views, etc, etc