CIO Magazine Admits SOA Hype
It would appear that SOA is coming down off the hype cycle after a few years as the preminent buzzword. CIO magazine has a cover story on The Truth About SOA.
CIOs need to pursue an SOA strategy carefully because the service development and architecture planning pieces of SOA are distinct but not independent—they need to be considered and executed in parallel. Services built in isolation, without taking into account the architectural and business goals of the company, may have little potential for reuse (one of SOA’s most important benefits) or may fail outright. Grand architectural planning exercises may drag on endlessly, without providing any real business benefit.
It’s nice to see a fairly conservative IT magazine like CIO mention that the big up front SOA design isn’t likely to work. We’re still grappling with SOA ourselves as an organization. There’s been a lot of hype, a good bit of grand design, and as of yet only one web service in production. At the end of the day with product owners really involved in Scrum projects, they’re not willing to compromise all the effort involved to use an SOA style architecture on their application.
Ed Gibbs @ June 16, 2006
This is a very interesting aspect of IT these days. SOA was attempted at a number of large enterprised circa 2002, and it failed to live up to its promises. Today there is renewed interest in the idea because some of the key technologies have caught up with the vision. As far as hype is concerned, we in the agile community are as guilty as the proponents of SOA. Given the poor results of traditional approaches to IT work, maybe we would all be wiser to consider objectively the merits of any idea that has the potential to improve matters.
A recent book, Software Factories, provides a very good summary of major trends in IT and where the gaps are between concepts and real products. Food for thought. IMO the authors make a classic logical error, though: They seem to be looking for a one-size-fits-all approach, and they seem to have latched onto SOA and reusable components as that approach.
In my view, we need to be taking a bipartite approach to IT. SOA has an important role to play in that, because that’s the interface layer between the unmanageable legacy code and the new code. In that scenario, agile methods complement the SOA environment by providing the customer-facing solution delivery service, providing short time-to-market, close alignment with business needs, high quality solutions, and lower cost of development and deployment. Meanwhile, the SOA side of the house offers cost savings and a path to legacy remediation and replacement.
Agile fits well on the delivery side and lean development fits well on the SOA side for a number of reasons, but especially two: (a) The tactical solutions are justified on the basis of ROI (IRR), while the SOA environment is justified onn the basis of reducing overhead cost for operations (there is no IRR calculation unless cash flow goes positive at some point in the lifecycle and stays there ; untrue for the SOA environment; when people talk about ROI for SOA it’s an imprecise use of the term; they only mean “return on investment” as the “cost savings” through compoent re-use), and; (b) there is a high degree of “end uncertainty” in customer-facing business solutions, while SOA design is more predictable, based on technical considerations that aren’t subject to changing business requirements.
So I’m not convinced there is a one-size-fits-all approach for us, whether it’s agile or SOA or anything else.