DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > SOA is the Software Equivalent of a Fast Breeder Nuclear Reactor

SOA is the Software Equivalent of a Fast Breeder Nuclear Reactor

Allan Kelly user avatar by
Allan Kelly
CORE ·
Feb. 17, 13 · Java Zone · Interview
Like (0)
Save
Tweet
9.02K Views

Join the DZone community and get the full member experience.

Join For Free

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.

SOA Software

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • You Are Blind to the Risks in Your Cloud — Why Companies Need Cloud Security Monitoring
  • Testing Strategies for Microservices
  • Verizon’s Data Breach Report: Cloud Security Insights
  • Monitoring at the Edge of the Third Act of the Internet

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo