James Governor's Monkchips

Hansel and Gretel and the SOA Forest: Why is IT so Grimm?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit


I said the community was smarter than me.

So, after my posting yesterday on why choosing the granularity of your service is like Goldilocks eating the bears’ porridge, comes this little fairy tale of SOA, from a mega value reader. Unfortunately I can’t say who it is, [Who is afraid of the big bad corporate comms department?] but thanks anyway guy! Here it is:

Hansel and Gretel walk through the forest (a metaphor for the FUD distributed by enterprise software vendors).  They come across a clearing (a marketing message that makes sense – something that happens sometimes in IT, albeit mostly by sheer luck). Inside the clearing is a small IT shop with a vendor at the doorway.  The whole house is a model for IT efficiency – all data is moving seamlessly between rooms and the users are happy.  A sign declares “ this efficiency is by the miracle of SOA and web services”. The lure of an efficient IT system is too much.  Being invited by the vendor, Hansel and Gretel walk inside.

Inside lurks the big bad integrator.  Thinking they were being saved by SOA, they now face soaring IT costs.  Starting with simple services, there are now countless consulting bills for service classification, service registry, ontologies of services and more. (Remember, you cannot “consult” without combining “con” and “insult”).  Consultants walk around spewing out buzzword and acronym laden sentences combined with updates on their hourly billing.  Hansel and Gretel become nervous. 

As a desperate last measure, they run up to the vendor and push him into the SOA acronym soup brewing over the fireplace.  They run out the front door and follow a trail of common sense they left behind to get back to where they were before and now live happily ever after, realizing the real intent of SOA marketing is to sell more software.  After all, if it doesn’t change, we can’t sell….


  1. What’s to prevent intended SOAs from becoming JBOWS (just a bunch of web services – from your mainframe blog) the logical evolution of JBORC (just a bunch of reusable code)? Every programmer writes reusable code, but not enough reuse it. I fear it will take an overhaul of the university education system to change it. Today, if a student “reuses” code, they are expelled for plagiarism. How can they be trained to design simple solutions that reuse existing code and services?

  2. I think it takes a deeper overhaul than that, Bruce. Given the extent to which basic concepts of engineering — proper use of source control, componentized design, simplest-possible approaches, et cetera — are NOT taught in computer science departments, the academic concept of plagiarism is actually not a huge worry. After all, it’s relatively easy to teach new grads that it’s OK to copy work, since they like to do that even in school.

    I’m reminded of a quote from Djykstra (might have butchered the name): “Computer science is about computers the way astronomy is about telescopes.” Which is great, and even true — but software engineering *is* about telescopes. And universities are teaching computer science instead.

  3. there is certainly an awful lot of JBORC out there.

    JBORO too – just a bunch of reusable objects… !

    the question on “plagiarism” is an interesting one, because it certainly seems to me that view source really is part of the web design and programming revolution. Seeing how things are done, and adding to that, is how so many important development proceed now, and a lot of kids have learned programming after seeing a few angle brackets and thinking I could do that.

    it certainly seems absurd you could disciplined for using a code sample – i guess the key is what you added to it, or how you used it…

    I fundamentally agree with Fraxas that view source style development learning is not going to teach good architectural practice.

    which takes me back to the mainframe and why its such a great compsci teaching platform. Because of the discipline associated with treating resources as constraints…

  4. Looking at other people’s code before writing your own is a very different thing than re-using objects and services “as-is”. I agree that it will take a deeper overhaul (architecture process, dev process, arch & dev roles, etc) for widespread success… it would be interesting to develop a “critical mass index” – the confluence of things that must occur industry-wide for SOA projects to fulfill their promise, and to assess our current state.

  5. James, Nice post on SOA consultants. Could you do a post on SOA Analysts?

  6. good point jeff. who are we – are we selling magic beans? are or we chicken licken?

Leave a Reply

Your email address will not be published. Required fields are marked *