Thursday, February 14, 2013

SOA is software equivalent of a fast breeder reactor

A fast breeder nuclear reactor is a wonderful idea. Basically, you put in used nuclear fuel from a conventional reactor, burn it, produce useful electricity and at the end of the process the used fuel has changed into a form you can put back into a conventional reactor.



Alternatively, another use for the final product is put in nuclear bombs but we don’t like to mention that.



Fast breeders have been shown to work but have failed to take over the world. They are very expensive to build and operate, pose security dangers and are hideously complex to operate - as you might imagine of a device cooled by liquid sodium, lead or mercury.



In other words: they are not commercially viable.


They aren’t even sensible to Governments.



I have come to the conclusion that in the software world Service Oriented Architecture, SOA for short, is the equivalent of a fast breeder.



SOA works in the laboratory. The technology can be shown to work by big service companies - IBM, Accenture and co. It seems like a great idea.



But… SOA doesn’t make commercial sense.



Let me explain why I believe this.



SOA is all about Reuse. Reusable code and systems.



Reuse does not come for free, you have to write code for reuse. Figures on cost of reuse v. cost of single use are not common. As a general rule I refer to Fred Brooks 1974 observation that it costs about 3 times more. Admittedly not a solid reference but the best I know.



The first problem is: do you know it is going to be reused?


If you write an SOA system and then find it is used once then it is very expensive.



In order to know it will be used more than once you need to accept requirements from multiple sources.


Which means your requirements costs go up, response times go up, responsiveness goes down. Which means you loose time and money.



Worse still, the loss of focus leads to distracted teams, complicated stakeholder management and competing interests. You risk producing a camel rather than a horse.



There is also an assumption here that there is enough commonality that can be factored out for reuse to make the whole thing viable.



Now SOA, and reuse, are sexy. Its something all developers want to do. And they want to do it properly. And such projects tend to be technically driven.



So they loose their business focus and get absorbed in details.



Then there is the matter of testing. Testing costs also go up.



Add in maintenance: fixing a bug in one system is going to hit other systems, all of them need testing. (“Write once, test many” as we used to say in the early days of Java.)



And who pays for this?


If it comes out of the IT budget we again loose business drivers and increase technical focus. But if one group pays for it they are paying far more than they would need to for single use. And if you apportion costs you are going to spend a lot of time arguing.



In other words: SOA works in the lab but not in commercial environments.



My advice, as is with any type of reuse: write it for the problem in hand, get something that works, have plenty of automated tests. And wait. When someone comes along with a problem that looks similar, a real candidate for “reuse” modify the thing you have just enough to cope with this, with tests. Then wait and repeat.



This way you only pay the cost of reuse when someone actually wants it.



SOA and Fast Breeder reactors both belong to the class of technologies which while possible, even fascinating, don’t stake up commercially. Actually, come to think of it that covers most forms of software reuse and nuclear power.

6 comments:

  1. Isn't the real benefit of SOA its modularity so that responding to change is easier?

    You said to me yourself that when devs push for reuse they're actually after modularity, a side effect of designing for reuse.

    ReplyDelete
  2. Yes and Yes.
    SOA does promote modulaity and I did that that.
    But SOA is a terribly expensive way to get modulality.

    SOA is, as far as I can see, a big expensive sell to big managers who expect big things. Expectations are set and moduality is not, or rather should not, be one of them. If moduality is the main sale then I suspect the work is already dominated by techies who have lost site of the business goal.

    If you want moduality then set out to create modulality. I think a good way to do this is to promote automated testing, specifically: automated test-first unit testing.
    - This flows from my "Reuse Myth" piece a while ago
    http://allankelly.blogspot.co.uk/2010/10/reuse-myth-can-you-afford-reusable-code.html

    ReplyDelete
  3. Allan - This is a great post, because it applies to many areas of software development and testing, not just SOA. Particularly, if you replace "SOA" with "automation" you get the same type of tradeoffs and an analysis of why automation tools don't work for most organizations.

    If applied and designed right, automation tools provide benefit in software testing but only in instances where thought is put into the reuse of well-designed scripts to improve overall quality and not for simple blind cost reduction.

    I love posts that spur me to think outside my personal box.

    ReplyDelete
  4. Thanks Jeff,
    Funny you should mention automated testing, I had something to say on that too..
    http://allankelly.blogspot.co.uk/2013/02/soa-is-software-equivalent-of-fast.html

    allan

    ReplyDelete
  5. This blog post was reproduced on DZone where there has been several more comments
    http://java.dzone.com/articles/soa-software-equivalent-fast

    ReplyDelete
  6. You're describing something more like a Web Services Architecture rather than SOA - not to say that that isn't the common interpretation.

    Real SOA (or SOA 2.0, if you prefer) isn't about reuse at all. It's all about modeling the stable business abstractions, and then using EDA and things like UI composition techniques to create systems.

    I've got some more info on my site here: http://www.udidahan.com/first-time-here/#soa

    ReplyDelete

Note: only a member of this blog may post a comment.