Shooting the myths of SOA

Over on the Yahoo SOA group list there is some discussion going on including my bug-bear of REST v SOAP. In this, and in some other conversations recently I realised how often certain elements are stated as being the accepted wisdom or an absolute rule. Its not the first list out there, but hell its my own.

1 - SOA = WS, or the broader SOA = Technology

SOA is about architecture this means thinking about the problem and planning. Working out what the services should be and then worrying about the implementation technology. This doesn't mean prancing about doing powerpoint, but it does mean that technology is NOT about the architecture. Technology is about implementation or delivery, Service Oriented Delivery of IT = Technology, so in an SOA world "technology = SOD IT".

2 - Services should be stateless

No they ruddy well shouldn't be. Lets be clear here just because the executable code is stateless doesn't mean the service is. If you store information in a database then the service has state, the consumer of the service doesn't give a monkeys whether you store it in memory, a database, flat files or using the collective unconscious as long as when they call again they know that the service has remembered what they did last time.

3 - Services should be loosely coupled

Again this isn't a sensible blanket goal for an SOA, because sometimes its smarter and more agile to assume that certain services are highly cohesive as they work together to achieve a common goal. Services should be sensibly coupled, but if you are calling a service and using their interface then you are coupled to that interface and will have issues if it changes.

4 - SOA is about reuse

Nope its about use and there is a big difference between the two concepts.

5 - SOA is something I buy

SOA doesn't come in a box, it isn't about technology and you can't just download it or buy it off the internet. SOA is about changing the way you think, its about working differently and thinking of systems in a different way, and most importantly thinking about the business.

6 - SOA is about IT

If SOA is about IT then lets all go home now. We've tried to keep in our little boxes and pretend that the outside world doesn't matter, the whole principle of SOA is that its about the services to be delivered rather than the delivery of those services. SOA is about the business, not about IT.

7 - I've been doing SOA for years

No you haven't, well to be honest there is a possibility that you have been but the reality is that odds are you haven't. SOA isn't just EAI using XML, despite what the old EAI vendors say, and its not just client server either no matter what the analysts might say. Its true that some people have been doing SOA for a while, but the majority haven't. What we are seeing is a collective rewriting of history, which was nicely summed up by Miko in his Defensive SOA anti-pattern. So be honest about it, if you really did think in terms of business services and capabilities then good on you, but if you are saying SOA because you are using technology that came in a box with SOA on it and doing the same thing you did five years ago then it isn't SOA.

8 - Services are atomic

Again no they aren't, first of all they've got capabilities and second of all they might contain other services. So a high level "Sales" Services will contain all of the services related to sales, it might provide a couple of high-level capabilities as well but most of the functionality is going to be delivered by the services that are within it. Services being atomic means that they are at the lowest level of granularity all the time, that just doesn't make sense when you think about how organisations work, Procurement is in Finance, Training is in HR, etc. Services aren't atomic and having this as a goal is dumb.

9 - Services implementation must be hidden from the users

Now generally this is a good idea, but its not a golden rule. Take for instance ordering a product and having it delivered. Hiding everything would mean that you'd see the order go in and then wait. Most decent companies now however enable you to watch the execution of the process through their supply chain so you know exactly what is going on and when things will happen.

So its an okay general rule, but don't think its absolute.

10 - Services are separate from processes

One of the technology created ones, mainly because no products out there enable you to design your service architecture properly, and no process tools enable you to assemble multiple processes behind a single interface. This doesn't mean that service is separate from process, it means the tools are currently rubbish at doing SOA.

Don't start with process, start with service. All process does is provide you with another implementation language for your services.

11 - SOA is heavyweight

There is no denying that some of the sledgehammer to crack a nut technologies out there come under the heavyweight banner and have become associated with SOA. But as SOA is about changing the way we think about systems to make it easier to make the right choices and to separate the different services out so we can deliver them using the right method and the right technology then SOA should in fact be considered as a lightweight approach. It really shouldn't take that long to determine what the services are, and if you can't its a pretty good idea that you don't have a Scooby Doo what you are doing.

12 - Reducing implementation costs reduces TCO

This isn't specific to SOA but its a beguiling myth out there in IT. It says that anything that gets something delivered a little bit quicker means that its cheaper to do. This approach says that if something was scheduled to take 40 days but by doing X you can do it in 30 days that its always good to do X. This misses a fundamental point, and its something that is critical to building a successful SOA, once the service goes live there will be more money spent changing, enchancing, fixing and supporting the service than was ever spent developing it.

If X makes support and modification easier then its a good thing, if it doesn't then you are just storing up problems for the future.

Technorati Tags: SOA, Service Architecture