< iCommons is Dead, Long live The African Commons Project (TACP) | Quality Vacation Club Bullies Blogger >
Nov 18

SOA is a Concept, not a Goal

Geek 3 Comments »
Geek

I like the idea of a Service Oriented Architecture; all of your applications reorganised as re-usable and generically consumable services ushering in a new capability to mash-up services across your organisation, aligned to business processes rather than application architectures. I just don't think it will happen.

If you build an architecture from the ground up, then possibly you can get a SOA going. Alternatively, if you have a fairly simple business, or one that relies on very few applications, you may get it going. For how long, I don't know. For the rest of the IT shops, I just don't believe it is something achievable. The systems have evolved, so that you end up with a mish-mash of mainframes, Oracle databases with heavy stored procedure reliance, homebrew applications built in some dead language, VB apps on top of SQL, Solaris scripts etc. Now, you could convert all of those to some form of standard (unlikely), or you could wrap them all in a pretty web service. Great, now what? The one guy who knows the dead language won't recode his app to use the new services. Nor will the vendor selling you the next technomasterpiece have made it flexible enough to consume your new webservices. Possible, someone may come up with a new homebrew app which uses your new SOA, but that's one out of many, and it likely won't consume all the services, so just wrapping necessary services in the first place is a better idea.

The concept is great though, and a strong IT architecture team who keep focussed and pushing for it over several years may be able to make some headway. This is very different from the 'implement SOA now' type consulting engagements (internal and external) promised. Additionally, as the pool of devs collectively forgets how to code in the old dead language, and starting building in web services by default, just because that's what they learned at school, some additional possibilities will be realised. However, this leaves me with the strong suspicion that SOA is a concept, not a goal.

I remember the promise of re-usable objects, and a great big store where we could all instantiate our standardised objects from. I remember Microsoft presenting on how this XML stuff would provide new ways of exchanging business data between companies. In a way, these things, happened, but they were incremental innovations that crept into the way we do things, rather than a rearchitecting. Even then, most of your legacy apps still don't do that sort of fancy stuff.

Alternatively, the above could be rephrased as; I'm tired of hearing about SOA, can we get a new architecture buzzword? (Not Virtualisation though)

Posted by Dominic White

Last modified on 2008-11-20 06:07

0 Trackbacks

Trackback specific URI for this entry
  1. No Trackbacks

3 Comments

Display comments as(Linear | Threaded)
  1. jerith says:
    11/19/2008 10:09:42 PM

    Actually, it is possible to transition a massive business application from a monolithic chunk into a sleek, SOA machine. It's a pretty expensive undertaking, and it requires that all the parts be actively maintained. In fact, it requires that a large and actively developed codebase is the core of your business.

    The major advantage isn't mashability, it's separation of concerns, failure isolation and clearer component ownership. It means that I can operate and maintain my part of the system without affecting your part any more than I have to. I can scale my service independently of yours. That kind of thing.

  2. Dominic White says:
    11/20/2008 01:00:06 AM

    @jerith: Sure, that's what all the ads say, I just don't think it is achievable without large amount of effort for not much gain.

    First off, I think we agree that moving your monolithic app is a big expensive exercise. Rather, most enterprises will wait for the likes of SAP, IBM, Microsoft to just build their apps as 'SOA compliant'. Which they are doing. Alternatively, you can go for a big 'Enterprise Service Bus/Portfolio' deployment with one of those vendors. However, whether you should, and whether it buys you much is a different story.

    You hit a nice requirement: 'It requires that a large and actively developed codebase is the core of your [application]' (I switched business for application as I don't think many businesses would claim that their codebase is the core of their business, unless they were a dev shop). Realistically, most organisations don't do this, and I'm not sure they should.

    As for the main advantages, I don't think SOA will give you those, in fact it will make it worse. Before you could as least say 'this group owns this app/infrastructure', now with your services moving to 'the cloud' (or more likely) 'the bus' that responsibility is much diluted. Is it the WS devs, the SOA bus devs, the original app owner or the portal exposer (i.e. user frontend) group who are responsible for the servic? Likewise, fault isolation is equally complex as you now need to track the calls across systems and apps instead of having your usual group of 'System X' experts who can dig out the problem.

    As for decoupling of maintenance, this too I am sceptical of. I haven't had the pleasure of seeing Netweaver talk to Biztalk talk to Message Queue, and I don't think we will without much effort.

    In short, SOA is going to turn into an incremental innovation with apps increasingly using standards compliant methods for comms (XML, SOAP etc.), but businesses and IT shops in particular, are still going to buy 'a service' from 'an application' and these won't always fit the SOA model, or that orgs structure.

  3. jerith says:
    11/20/2008 06:07:44 AM

    It's definitely a large amount of effort. Whether the benefits outweigh the costs depends entirely on your specific circumstances. I specifically used "business" instead of "application", because unless your business utterly relies on your application, it's unlikely to be important enough to justify the cost.

    Your concerns about ownership are misplaced, I think. In the old world of the monolithic app, you had teams responsible for bits of the app. In the SOA world, each team is responsible for a service in its entirety. There are obviously still dependencies and interactions, but they tend to be a little more clearly defined, since you're not sharing codebase, memory space or even machines with others anymore.

    Fault isolation is a trickier one. While you're not going to break all dependencies, it does mean that the only way an external service can break you is to (a) not be there or (b) behave badly. You can fail or degrade gracefully in (a) and try to mitigate (b). In no case (barring your own bugs) will an external service chew up all your resources or segfault your process. Assuming decent logging and auditing, without which debugging /anything/ is a nightmare, it doesn't become any harder to track down where stuff broke.

    It also makes dealing with scaling a little easier, in that you only need to worry about your own service rather than having to scale out prematurely because someone else's library needs a lot more resources. It also means that you don't need to care if someone else's service needs to grow to deal with load from other sources.

    You do need to standardise your interfaces, or you're in for a world of pain. For your own services, this isn't that hard. If you rely on external services, you'll either have to deal with them or stick thin proxy/translation services in between. If you're using a lot of other peoples' stuff, this can be a killer. You still need decent integration testing and you still need all your teams to talk to each other about design and feature set. Some services will be very specific and only have one consumer. Others will be broad and have to balance the needs of many.

    SOA isn't a silver bullet, of course. It takes more resources to run lots of little applications than one big one. All the packing and unpacking of little chunks of data between services can add up. Specialisation and ensilofication can cause inefficiency. I do think it's the best model currently available for massive, highly available systems.

Add Comment


E-Mail addresses will not be displayed and will only be used for E-Mail notifications

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA