Let's suppose you're the lead of a team of developers that needs to build a big information system such as an ERP or Human Resources software, or whatever system that is composed by multiple business modules. The system must delivered quickly, be scalable and have good evolution and maintenance capabilities. Your team has experience on SOA technologies and also on development of standard MVC/AJAX applications in ASP.NET, Spring, ExtJS, Smartclient or whatever mix of frameworks. You also have a good project manager in your team. Your stakeholder is baffled with so many technologies and changes in industry that he doesn't care about which thing you use, as long as the functional and non-functional requirements are satisfied.

Would you use SOA practices (such as governance, service repository, service identification/discovery) and SOA infra-structure elements (such as an ESB, a BPEL engine, WSDL-base web services)?

Or would you just use an agile and disciplined development process with your favorite/trustworthy frameworks and provide some RESTful services and other simple integration points with external systems?

Or something else?


Like so many other "silver bullets", you have to look at SOA as a tool set and take what you actually need from it.

First, let me extol the advantages of the abstraction provided by web services in general (forgetting about BPEL and all that pie-in-the-sky stuff):

  • It forces you into loose coupling. You cannot reach into the internals of a web service whenever you feel lazy. It's just not an option. As a result, the API of each service grows out to be very extensive and robust in order to serve everybody's needs.

  • It lets you make any API public, whenever you want. This is a big deal in corporate because you will eventually need your system to interact with other systems. In many ways, system integration work has become a genuinely mundane experience for me because chances are, whatever we need, there's already a web service for it.

  • You can layer in certain horizontal features without ever having to change the API. It's basically Aspect-Oriented Programming at the architectural level; cross-cutting concerns such as logging and security and message queuing are literally just a configuration change away.

  • It massively simplifies deployment of smart-client applications (not so much for web apps). Yeah, it's sometimes a chore to have to go through the rigmarole of redeploying services and updating proxies and all that during the development phase, but that's made up for in triplicate by the number of times I've been able to fix some minor bug in a production system or implement some change to business logic at the service layer, and only have to worry about one deployment, as opposed to 100. Any middleware can do this; SOAP just happens to be the easiest to work with today.

These are real, practical benefits that I've actually experienced, and continue to experience on a regular basis. I won't deny that it's more work up-front to build and maintain web service APIs, but in the long run, it really does pay for itself if you follow proper practices (chunky messages, standards-based policies, etc.)

Now that, in and of itself, is not an endorsement of SOA. Web services are just one tiny piece of SOA, and at times the SOA train really does seem to go off the rails. But there's good and bad. Some choice elements that come to mind:

  • Service Discovery: Semi-useful, if you can get it up to the point where you're able to centrally manage the policies. Otherwise it's really incredibly tedious to have to remember or look up all the configuration and policy elements you need whenever you need to interface a new service or application to the existing ones.

  • Service Broker: Awful, at least in my experience. A broker is a highly effective way to introduce a new single point of failure and extend latencies by several orders of magnitude. I don't bother with these, or with any of the concepts that naturally follow (mainly orchestrations), unless I'm working with legacy systems that cannot be made to support...

  • Service Bus: Very useful specifically for publish/subscribe scenarios. This is the key to boosting (a) performance and (b) "intelligence" in an architecture. (a) because you can do batching, rate limiting, and denormalization to your heart's content, and (b) because the alternative is an inscrutable array of batch processes, ETLs, custom-coded scheduled tasks and other things that will make you go completely insane once you find yourself having to deal with 50 of them running across 10 different machines. ESB pub/sub is the non-crappy version of brokered messaging.

  • BPEL: Is one of those things that sounds really cool in theory, but when you put it into practice, it becomes like trying to drill a hole with a stick of dynamite. Or open a door with a stick of dynamite. Or grate cheese with a stick of... you get the idea. You get this extremely powerful tool that can ostensibly do just about anything, but in practice doesn't actually do any of those things very well, unless the thing you're trying to is blow stuff up, in which case it's an excellent tool for the job.

Now I've got nothing against REST either, but I think it'll be a while before we seriously start to see it being used in the enterprise world. First of all, there's just too much momentum built up around SOAP, and second, REST doesn't have well-established standards around transactions, metadata, security, etc. That's all totally fine and even a good thing when all you're doing is exposing an API to the public, but not so good when you're trying to integrate distributed systems into a larger architecture.

Finally, I say all this with the caveat that the cost/benefit ratio depends on the size of the project and the size of the overall architecture. If your company just started up 2 months ago and just needs a web 2.0 storefront then you are wasting huge amounts of time doing anything that I've mentioned. Just hurry up and get it done. But if you're in a business with hundreds or thousands of employees, multiple offices, a dozen departments, a financial system, a work order system, a CRM, sales force automation, inventory, intranet, customer self-service site and blah blah blah, then "do the simplest thing that could possibly work" ceases to be an intelligent mantra and you need to start thinking bigger.

And while you don't have to call it an "SOA", the ideas and patterns and technologies enshrined by that model are essentially the de facto standard for enterprise development. If you like to swim against the current, make sure you bring a life jacket.


Moving to SOA brings a lot of complexity and overhead. But it lets you scale a complex application across clusters of machines.

If you have reason to believe that your application is going to be too big to actually fit in a single machine, then you have little choice. Go SOA. And be careful to add things like good logging and monitoring for when things go south. (Far, far too many SOA architectures leave that out.)

If you can avoid going down that path, by all means avoid it. Your software will be easier to debug and develop, and is likely to perform much better. Just make sure that state is shared in some central data store, you're using distributed caching, and other standard practices to allow you to have multiple webservers available.


If you're building services for re-use you are basically doing SOA. One thing that can help is the use of a commercial SOA governance tool. We use JaxView. Its very comprehensive. It provides security, routing and throttling, monitoring and auditing for your service infrastructure

  • 1
    +1 for "If you're building services for re-use you are basically doing SOA". SOA is a new name for an old way of working. That's not a complaint - sometimes putting a name on something is powerful. – Tom Anderson Jun 17 '11 at 17:06

I have seen several implementations that used acronym-oriented-architecture to their detriment. There is certainly a place for many of the foundational technologies such as message queues, web services and even service discovery but in particular the benefits people expect to get from something like BPEL never seem to materialize, or do not exceed the costs by the time they are realized.

Still you have to make these decisions on a tool-by-tool or framework-by-framework basis, it is not all or nothing.


It's 2011, I think there's rather little reason NOT to use Agile practices out of the gate. I would think that if you are honest in your retrospectives and - from experience, this is important - actually follow through on the results of your retrospectives you will end up with something that you could call SOA at exactly the time you need it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.