SOA reuse is a pipe dream for most organizations because they are not willing to change their investment evaluation windows or mindset about the economics of software. Most are just looking to improve their agility -- which is about the way we design interfaces & interactions, not about reused logic.
Now there are quite a few problems with this because what it implies is that an organisation that doesn't change their mindset can get agility through technology but can't do reuse.
This really doesn't make sense. I've argued for a long time that the important element is changing mindset around SOA and that if you don't do that you just get the same problems delivered via newer technology. This means you won't get agility for exactly the same reasons that reuse is difficult when the mindset doesn't change. Agility also means caring about the lifecycle costs and it means making investments in those interfaces and interactions that are broader in scope than simply the development being done today.
There is a lot of other sense in there (except the slightly odd bit where it seems to imply that Google and Amazon could change the definition of Pi, but I think that might be a different Pi to the Pi that Indiana attempted to change).
The point to be made here is that all of these things like flexibility, agility and reuse require a mindset change for most organisations. Primarily this comes down to a simple case of measures and KPIs. Most IT is delivered by projects, the goal of projects is to hit the budget and hit the delivery date, as I've said before this is about CTL v TCO. If you are targeted on hitting a date and budget then any corner that is cut results which means you hit those measures means you are a superstar, any extra investment you make that means you overspend or slip means you are a failure.
The other piece is that Reuse is really an IT concept, the business has a different one, namely use and this is where SOA comes in and where it becomes actually possible to deliver standardised functions that are used by all. Services are about Use not reuse. This behaviour is much easier to create in organisations than reuse as demonstrated by the ERP consolidation programmes, single customer view solutions and other elements that are regularly commissioned by the Business and IT to deliver standardisation.
If IT thinks the same way about delivery then there is no way that either Reuse or agility will be delivered. But its nonsense to say that Reuse is more of a pipedream than Agility when the operational reality of IT is that large parts of the IT estate are standardised in packaged solutions which are being exposed as services into the rest of the enterprise.
I agree with Stu that the problem is the mindset, but I'd extend it to say that the mindset challenge is primarily with IT and its continued religious belief in technology as the primary answer.
Technorati Tags: SOA, Service Architecture
2 comments:
Hi Steve,
My main claim was a veiled attempt at channeling Paul Strassman's point of view: we squander IT investments by focusing on short term return windows & ignoring the residual value in software. Until we do so, reuse will remain a pipe dream for most organizations. There is upside for a shift in mindset -- no more $200m ERP rebuilds every 10-15 years, hopefully -- but after over 3 years watching this battle in the SOA world (after 10 past years in the CORBA/COM world), we're still far away from the dream. I believe the economics of utility outsourcing may speed this trend up, however.
Secondly, I completely agree that services are about "use" and not "reuse". I actually get a lot of quizzical looks when I say this to my colleagues and customers, because most people still say the word "reuse" when they mean "standardized use" -- they just didn't really think it through.
This is what I meant by agility being about interfaces & interactions. This is not a technology thing, IMO. This is about systems architecture in the Old School sense of the term, like economic systems, social systems, etc. The way we deliver our information systems (with projects and budgets) is tied in with this: how do people interact? the users? the service providers? the investors? how is the information organized? how is it consumed? etc.
Broadly applicable answers to these kinds of Zachman-esque existential questions are what we need, because I don't think every organization has the systems design expertise to answer them. By "systems design", I mean general systems thinking btw, not technology systems.
I do believe it is possible to seek out "an architecture for agility", by focusing the way the elements are organized & constrained. IMO there is a lot to be discussed and studied here, and it is interdisciplinary. I think it transcends "just business", but also it transcends technology, as it seems to be intrinsically a liberal art, where an insight is worth a thousand analyses. (I'm in line with Eberhardt Rechtin & Mark Maier's work on systems architecture here).
As an example, the U.S. DoD is really looking at "Net Centric Operations" and "Power to the Edge" as an operational doctrine, something that permeates the organization itself, and isn't just a technology thing. I think they've done a lot of thinking about what it means to be "agile", and it looks different from what I've seen in many people's versions of SOA.
Wonderful thing English :) Nice and imprecise.
I of course agree if you mean that interfaces and interactions are important in the non-technical sense, its the basic premise of the Business SOA method I helped contribute to OASIS.
I agree on the impact of Outsourcing in the space, as its about business value and is fundamentally a contractual framework it creates more focus on just these business centric pieces.
The key, as you say, is the mindset . If that doesn't change then nothing does. And the mind isn't a technology thing.
Post a Comment