A brave new SOA world?

Yes, it has been a while, but I have been busy and preoccupied. Following my last post on SOA I decided that I needed a good hard look at the whole SOA story - there seems to be so much noise and marketing about it that I feel my small and addled brain has missed out on the important points that make it oh-so-exciting.

To that end I have attended a couple of seminar presentations on the topic from a case study and a major vendor point of view - my life is not as exciting as it sounds! But hey, the free breakfasts were good.

OK, I think I get it a bit more now - however I think many of the major SOA "pushers" are heavily focusing on the techie feature-function issues and haven't got such a strong grasp around the tangible business benefits yet - or if they have they are failing to articulate them. Sitting in a presentation where a vendor product executive was extolling the virtues of their forthcoming (over some years) SOA it was hard not to notice the air of disinterest across the roomful of financial and business attendees.

Here is a great business benefit courtesy of PepsiCo - it costs between US$20k and US$120k per annum to support an application interface. So if you, like they, have upwards of 1200 (!) of the suckers across the enterprise then your IT application support and maintenance budget is a serious cost to the business. A sensible goal would be to collapse and consolidate the application landscape into a core set of common tools and a select set of specialised components. If you can then build a process centric layer over an SOA (or Enterprise Bus) that allows you to standardise a range of those user interfaces and remove them from the constraints of dealing with the original application suite then you are on the P&L bus to saving tangible costs.

So in an environment like this where is an SOA layer going to come from? Is it sensible to expect that capability and commitment to openness to exist end-to-end across the business application portfolio you use? Probably not. I think there will be components of ready made exposure from core application suites and these will need to be extended and enhanced through additional bespoke development in line with the business processes.

This is where I think the reality clashes with the dream - as you build ever increasing layers of specific complexity on top of a generic core application SOA how much threat do you bring to the solution when fundamentals changes are made to the foundation SOA? Further to what extent have you got the capability to actually achieve the full objective if so much of the underlying process logic is buried in a framework you are completely reliant on and yet have absolutely no control over?

Even today we are all exposed to the vagaries of the existing APIs over commercial applications. Only last week our team had to devise a workaround to overcome a potential weakness in an API to achieve an appropriate level of audit control for a client's SOX compliance requirement. It probably wasn't a weakness in the API when the purposes for the process were originally foreseen however times have changed and compliance demands have increased. In fairness to the application author the latest version of the API resolves the issue however upgrading wasn't a viable option for the client.

So in our brave new Utopian SOA world how will we handle demands for change? I am guessing in exactly the same way we do today - with bespoke developed workarounds and customisations that add support and maintenance cost to the delivery of IT systems into the business. Sound familiar?

I think the SOA story as pushed by application vendors is a defensive move on their part to protect themselves from client attrition through application malaise, attrition or retirement. If you are serious about an SOA in your business then you may have to bite the bullet to develop the whole end-to-end capability for your self. Interestingly that is pretty much what Pepsico seems to have done in conjunction with a BPMS.

The "Lego dream" of SOA

Sticking with Cynthia Rettig she has some great comment on the realities of the current tech buzz around SOA - "The Lego dream has been a persistent favorite among a generation or more of programmers who grew up with those construction toys. Unfortunately, however, software does not work as Legos do".

Boiling SOA (service orientated architecture) down to some very simple points, I see it as 1) the removal of business logic from the application interface layer and 2) the exposing of said business logic in a way that it can be consumed on demand from any application (ie an API or web service). As Cynthia says - this is a massive job for legacy applications and riddled with complexities and pitfalls - not least of which is what happens when these things get nested on top of each other and you hit a problem buried deep down in the underbelly of the beast?

I get the business benefit of this for software application behemoths - who appear to me to be the ones most pushing this barrow - "hey, don't throw out our old stuff - just drive it in a different way". What I struggle with is the genuine business benefit for the business user. The argument consistently put is that you can flexibly consume an end to end business process with a modular approach to the application layer.

It's seems like a great idea but when I put it in terms of some crude analogies does it really stack up?
The boomer couple retiring from their inner city lives are moving out to the hobby farm in the mountains - rather than sell the 2 door soft-top sports car they have taken the SOA approach and dropped in a sturdy 4x4 chassis and transmission. While they were at it the SOA'd the cat by peeling off the skin and fur and replacing it with a border collie shaggy dog model.

Hmmm - didn't quite get the expected outcome there. I think this SOA thing has a long time to run before the true business benefits are fully realised.

Entering the SOA and BPM debate

Plenty of blogs and mainstream press these days are focussing on SOA (service orientated architecture) and in the business process management world there is lots of debate about are SOA and BPM the same thing? Is one a subset of the other? How do they interplay?

I'm a simple old soul really and perhaps not sufficiently learned about the various, and assuredly complex, layers in all of this however as I see it:

SOA serves the IT community and BPM serves the business community.

My thoughts are guided more along the lines of where the budget holder and project sponsor is than affinity to any church on this.

If the dollars and sense are in the IT division then there is a reasonable likelyhood that SOA will get the nod - it comes with lots of techno-speak that sufficiently disguises it as a complex and IT-driven dark art.

If the champions are from the business then BPM may be more involved in the outcome as the push comes from the outside in and the business will most likely be focussed on costly customer-driven interactions and processes and looking for tangible ways to salve those pains.

If there are drivers at both ends then I think there is a comfortable place in the middle where they intersect with a common goal of driving efficiencies and improvements in service delivery for all parties.