Take No Prisoners

Service Oriented Architecture is your Ticket to Hell

Allow me briefly to depart from the usual subject matter of this blog, BS in society, to address Service Oriented Architecture (SOA), BS in Information Technology. I recently discovered that proponents of SOA, such as Thomas Erl, claim it increases agility. This is unadulterated bullshit.

SOA for Dummies

Suppose you are a programmer and you have to build a large, complicated application. You have to break up the code into pieces so you can keep everything straight and not get lost. For years, programmers have divided code into interconnected hierarchies of objects, a practice called object-oriented programming. Service Oriented Architecture is an alternative code organization, based on services. For example, you might have a weather service that returns weather conditions, given a city. A service is a chunk of code that has several properties:

  • A service can take requests
  • Given a well-formed request, a service will send a response
  • A service can use other services
  • Service Oriented Architecture has become a major buzzword in the software design community, and everyone and his code monkey is claiming to use it. So if it doesn’t do what’s promised, a lot of people are going to lose a lot of money.

    The Claim: SOA Increases Agility

    Thomas Erl is the guy who wrote the book, literally, on SOA (see Service-Oriented Architecture (SOA): Concepts, Technology, and Design, Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services, SOA Principles of Service Design). He claims that SOA facilitates agility. This is bogus for two reasons: SOA requires upfront architecture, and SOA, left unchecked can create strange loops.

    Problem One: SOA Requires Architecture Upfront

    One of the key tenants of Agile Development is to delay defining the system architecture (the organization of the code) as long as possible, because having a defined architecture limits your flexibility in changing code. According to Erl, SOA requires even more upfront architecture definition than an upfront-design-heavy object-oriented software development process. In other words, SOA requires you to do a whole load of up-front design and specification that’s very difficult to change after. Not being able to changes things is the antithesis of agility!

    Problem Two: Strange Loops

    Here’s something really interesting about SOA: your services can use other people’s services and vice versa. Furthermore, you have no idea how anyone else’s services work, or what services they are using. Now suppose Bob makes a service, B, and Tim makes a service, T, using B, and Jane makes a service, J, using T. The dependency looks like: B<–T<–J . Now suppose that Bob sees J, and thinks, hey, if I use this I can make my service way simpler. When Bob changes B to use J, we have a dependency loop, and all the services will just go around and around until something crashes. The problem is that Bob has no way of knowing which services depend on his. Now scale this up to thousands and thousands of interconnected services, made by many, many different programmers. Nobody can see the dependencies. It gets to the point that if anybody changes anything, the whole system can come crashing down. Debugging becomes a nightmare! More specifically, the lack of dependency knowledge drastically limits your ability to change services, once again retarding agility.

    SOA is the Opposite of Agile

    I’m not saying that SOA doesn’t have any advantages. It certainly promotes low coupling and code reuse. If you already have a large library of helpful services, you may be able to code some things faster. What I am saying is that SOA, scaled up in the distributed way SOA proponents talk about, does not foster agility. Loads of upfront design and unknown dependencies seriously hamper a code provider’s ability to change things quickly. I’m also not saying that these problems are insurmountable. What I am saying is that, if SOA is scaled up without precaution, it can create systems so precarious that anyone asked to maintain them will feel like s/he’s won a ticket to programmer hell.