SOA, ESB’s, SOAP and a plethora of other alphabet-soups colluding to increase, not decrease complexity have plagued enterprises and enterprise software for years. Enterprise software vendors, consultancies, and “analysts” such as Forrester, Gartner et al have been at the center of this movement, eagerly cheered on by Enterprise Architects whose careers depend on creating complexity they then get paid top dollar for to manage.
Calling SOA in its enterprise incarnation a spectacular failure would be the understatement of the decade. SOA efforts in most enterprises have not lead to cost savings, they have led to bewildering complexity and massive sunk costs. Complexity disguised as “consolidation”, “standards compliance” or “re-use” can simply never succeed.
The irony of this whole affair is that the promise of “SOA” already had been delivered in other areas – it’s called the Unix-approach, small and simple applications that only do one thing, but do it well, that can be piped together into a bigger whole.
What worked for the Unix-approach was that it was not top-down based as most modern SOA efforts, instead it was a bottom-up approach: little utilities where built to scratch a particular itch. Eventually it emerged that these little itch-scratchers could be combined to scratch even bigger itches, but this was not by design, it was by virtue of being small, specialized and good at one thing only.
This specialization is emerging once again outside of the Unix OS, in what is buzzwordily referred to as “The Cloud”: Google Apps can be used for e-mail and personal productivity, Twitter for messaging, RSS for information distribution/dissemination, Google Maps for location aware services and context, Amazon Web Services for computing and storage.
Small pieces, loosely joined. What they all have in common is that they did not emerge out of some grand, top-down scheme, but as individual services designed to do one thing only, but do that one thing well.
By “accident”, it just so happens to emerge that these services created by disparate organizations for disparate reasons actually provide the infrastructure for most of the computing and communication needs that exist in organizations large and small. Integrate them and you have something very powerful, based on Service Orientation if you will, build more small features and services on top of them, and you can potentially unleash yet another wave of innovation and improvement.
The future is Service Oriented, just not in the leviathan top-down way that Enterprise Architects around the world imagined – the Service Orientation is open, and it emerges from the bottom-up, almost by accident as a multitude of people and organizations scratch their own itches, then find ways of combining their own services with those of others again and again in new ways and permutations.
July 3, 2009 at 2:38 am
This is very much the approach we’ll be taking in an app we’re building.
We have email, we have lead management, we have a quoting tool, we have a website, we have an application process. Now all we need to do is integrate them and allow other special functions to integrate as well
All the above work great on their own and any other function we build will also work great on its own (and be a sellable service/product). However when all are combined then we have a simple process that anyone new joining the organisation is able to get up to speed quickly.
July 7, 2009 at 6:02 pm
The mash-up/pipes approach you’re talking about I guess works for general apps in web/extranet setups, but for corporate intranets where workflows must be secure/reliable and support transactional semantics, a tightly controlled setup would work better. I do agree though with the thrust of your argument (about the general trend).
July 7, 2009 at 6:06 pm
Sekhar:
but for corporate intranets where workflows must be secure/reliable and support transactional semantics
To play a little devils advocate..
Do they really?… And secondly, are they really?..
I would argue that corporate security- and reliability concerns are often paranoia combined with smoke and mirrors to give a false sense of security.
If you really looked at the corporation you work, how much security paranoia is there? I would guess a lot. How many gaping holes in the security setup are there? I would guess a lot, and big ones.
Also from experience – how often are internal servers down, unstable, not available etc? A lot of the time in a lot of organizations.. Maybe outsourcing the running of it to cloud providers who live and die by their uptime and security isn’t such a bad idea after all..
July 7, 2009 at 7:51 pm
[...] The future is “Service Oriented” (just not the way Enterprise Architects imagined) [...]
July 8, 2009 at 9:33 pm
I whole-heartedly agree with the article. I only hope the whole model-driven waterfall approach of software development die the very same death as SOA is doing right now. People should start realizing that the top-down approach just plain doesn’t work the way we tried for so many years..