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.
