Service Oriented Architecture is your Ticket to Hell
August 30th, 2007 by Kavan WolfeAllow 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:
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
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.
August 31st, 2007 at 4:49 am
I fully agree with you on this one, that SOA is a nightmare in waiting in a large-scale environment. The question is, do you think that object-oriented programming is still the solution to this problem or is there another approach that will do what SOA claims to do without the potential downfalls in scaling?
August 31st, 2007 at 11:37 am
I haven’t heard anything about SOA before this post, but I’m not sure how the property that services are able to use other services is any more “strange loop”-prone than OOP–if you have well-documented code. And if your documentation sucks, it doesn’t really matter what framework you’re using, your code will be hard to use regardless.
Surely SOA coding standards would suggest thoroughly documenting any other services your particular service or code segment depends on…but I’m still a student so maybe that’s not how it works in “the real world.”
August 31st, 2007 at 12:24 pm
[…] Reading the Internets August 31st, 2007 huh? I’m moving to China, at least there they censor the internets. I think I’m dumber from […]
August 31st, 2007 at 12:54 pm
Playing devil’s advocate, a lot of really big organizations have had dozens of OOAD development efforts all solve small problems. After a while, the datastore is all over the place, you have multiple places to go for the same information, and chaos reigns. SOA promises to slowly eliminate that hassle by providing one-stop shopping for authoritative sources of data.
Now that’s the theory, anyway. In practice it can become a nightmare, like you said. But the pull is strong. I’ve seen organizations go so far as to buy “standard” database schemas and then struggle to shove everything into that. Standard services aren’t far behind.
My point is that SOA solves a real set of problems as perceived by some organizations. (gee. I feel dirty just saying that) I thought somebody should take a counter stance. There’s probably some SOA guy on his blog right now trashing OOAD. LOL
August 31st, 2007 at 1:15 pm
I do not necessarily agree with all of your points, in the java world, we have things like Spring which help “solve” circular dependencies, In many of my SOAs I *do* have circular dependencies, yet they all seem to work in conjunction flawlessly.
Also, developing a robust, straightforward API is not a “flaw”, it just means that you have to think out your architecture a bit before you start wildly developing useless calls into your system via the service.
I do like SOA because I have often times been able to completely refactor aspects of my code without having to worry if the interfaces will still work, as long as my interface requirements are met, everything is still humming along.
August 31st, 2007 at 1:34 pm
…SOA is your Ticket to Hell…
good read.
August 31st, 2007 at 1:34 pm
[…] Servvice Oriented Architecture (SOA) Published August 31st, 2007 Uncategorized A friend of mine pointed me to an interesting article on SOA called Service Oriented Architecture is your Ticket to Hell. […]
August 31st, 2007 at 1:41 pm
In my opinion you got it wrong. Agility in SOA is more about keeping your business agile than bringing agility to your development team.
Regarding issue #2, you should have some sort of governance to tackle those issues (and on first glance that looks a lot more like point-to-point integration than SOA) because without it no one will ever know what’s going on.
August 31st, 2007 at 2:04 pm
[…] Oriented Architecture is your Ticket to Hell? With reference to Service Oriented Architecture is your Ticket to Hell, it always amuses me how people insist on calling any idea which does not agree with their own […]
August 31st, 2007 at 4:22 pm
Is the circular dependency something that could happen in a non-SOA world? You betcha. I would argue that as with any programming, there are good ways and bad ways to do things. I have seen first hand many people making a mess of a great idea. SOA is a new concept to many people so it might take a while before people fully understand it, and make all the mistakes so they know what NOT to do in future!
August 31st, 2007 at 5:29 pm
You have somewhat missed the point of SOA.
The idea is to connect disparate systems together quickly by defining standards by which the services communicate. Part of SOA is that the services are somewhat self-documenting. The idea does not mean you publish a service somewhere and leave it running without human intervention. Someone will, of course, have to maintain ownership of it. This ownership includes following proper software development lifecycle to keep the service interface backwards compatible as new features are added.
If you think the old way of writing large, complex systems (i.e. a mainframe application with one monolithic code base) doesn’t have some of the same issues you mention, think again. Now more than ever large organizations have systems in place that they are afraid to touch because they are so old and undocumented. They prefer to work around these systems’ capabilities rather than even think about going in and doing a code change. Thus you still see large companies that have web-front ends still creating EDI documents to feed to the mainframe in batches every night.
I’d rather have the madness of SOA than the madness of a million lines of Cobol written by people that have long since retired.
August 31st, 2007 at 6:13 pm
Oh come on now. You set up a pair of bad straw men and tore them down. Congrats.
Point #1: Services help to break the system down into more manageable components. This is good for agility because it enables “chunking” so that the innards can be designed / developed / tested / CHANGED independently with far less coupling that might otherwise result. Moreover, I would claim that designing services is a much simpler task than designing traditional object models that do the same kinds of things (but in a more convoluted and often less composable way). So before you bash design requirements, you should recognize that different kinds of designs have different up-front loads and different long-term maintenance loads. I hope you do at least some design work up-front before you start writing the code, don’t you?
Point #2: Would you blindly integrate a service you did not understand in depth or have reason to trust into your application? Didn’t think so. Besides, you aren’t very likely to get a circular dependency of the form you describe unless J’s service doesn’t provide much added value over B’s or T’s.
August 31st, 2007 at 7:19 pm
Having had contact with the ideas behind SOA from “inside the beast” at least a little, I see it as massive and somewhat welcome shift in the attitudes of those making technology decisions and purchases. It has a lot of smoke around it, but I think the idea comes down to one thing:
Lock-in is bad.
You may be hitting your head saying “well DUH! Who wants to have a proprietary binary protocol I don’t understand, limited frameworks that don’t do what I need to do, or, horror of horrors, no network interface at all so that I’m tied into a given OS or programming environment” (short answer: Microsoft)
Message passing is a relatively uncontroversial and well-understood construct (even in the somewhat more limited for of unix pipes) and networks and IP have been around for some time now. What was missing was the appreciation on behalf of the business people of a system where parts could be swapped out or extended or reused. Does the notion of putting all your data in the hands of one huge product, such as say, SAP, scare the living bejeezus of most programmers? Perhaps, but it didn’t even faze the guy making the purchasing decision (at most places) until very recently. Now everyone has to look at least superficially friendly in letting other systems (that may extend or compete with products being planned by the original vendor) interoperate. OOXML is an example of such a superficial and disingenuous attempt.
Phrased another way:
Lock-in is bad == Competition is good
August 31st, 2007 at 8:21 pm
I think you are jumping down the throat of the latest decoration of an old concept.
We have had, and used SOA for a long time. Take XML and WS / UDDI etc out of the equation and insert any distributed system you care to mention and there is sufficient evidence to suggest SOA has been around for a very long time and had beem used successfully.
You just seem to have had a really bad experience and I admit that in Corporate environments most SOA projects turn into nightmares, and certainly the granularity of the services alway seems to fine, but I have seen several very successful examples.
August 31st, 2007 at 8:32 pm
First thing to know about SOA- it’s nothing more than a buzzword used to sell products or … services. You can’t condemn it outright, because you need more words to explain what any particular purveyor might mean by it. Fowler saw this a couple of years ago. http://www.martinfowler.com/bliki/ServiceOrientedAmbiguity.html
Great point about dependencies. What the SOA backers are missing is that the crucial difference between a dependency on, let’s say, a code library than there is a dependency on a running system that has an API. The dependency on the running system [SOA] is worse.
Data services make sense, SOA is nonsense.
September 1st, 2007 at 4:30 am
“Lock-in is bad == Competition is good”
Speaking from the perspective of someone who has witnessed the death of the mainframe-terminal-in-every-office approach and the rise of SAP, I have to take issue with that statement, in addition to the rest of the comment. SOA, from my view, is a problem, since it requires so much up-front planning for so little advantage over OOAP that can be achieved with much less pre-code planning, which, in the real world, is something that we all want to avoid, as much as possible. Yes, we plan as much as is necessary. But do we really want to have to do more of it before we get into actually solving the problem? There is a beautiful analogy to be made about a firefighter standing on the street corner, building a new strategy for a fire-suppression service while people burn inside the apartment block.
That aside, though, it’s the competition statement that bothers me the most here. Competition, m’friend, is the opposite of efficiency, the opposite of simplicity, and the opposite of productivity. If there was one database model, all database administrators would be an expert in it. If there was one language to write in, all developers would be able to exchange code freely without translation or complex interfacing modules. If there were one hardware platform, there would be no need to maintain multiple code-bases for software. I’m sure you get the picture. We don’t want a new development approach. We don’t even want the old ones that we’ve got. One is enough and two is too many.
So, please, pray-tell, someone, if you all seem to have such a fascination with documentation and planning, where have all your problems with OOAP been coming from, anyway?
September 1st, 2007 at 6:11 am
[…] But also, as Thomas S. Kuhn said, not all changes lead us to a better direction, so many people complain about treating Architectures as Services. […]
September 2nd, 2007 at 1:26 am
I haven’t seen this SOA, but is it just me or is Service Oriented Architecture just a fancy way or saying Object-Oriented? I’m learning Java currently, and I imagine it wouldn’t be that hard to make a package (containing classes) for a specific “service”. The example weather program, could be done with a single overloaded method, easily.
September 2nd, 2007 at 11:17 am
Hi,
A few comments if I may
1. I don’t like Thomas Erl’s definition or views on SOA but the type of agility he talks about and the one you talk about are not the same. Thomas talks about business agility which comes form looser coupling (which SOA fosters) and you are talking about agile development (which SOA is orthogonal to)
2. The way you described SOA (services can take requests…) is indeed useless - but that’s not SOA ( You can see my definition of SOA here: http://www.rgoarchitects.com/files/soadefined.pdf)
3. Regarding problem 1 - SOA requires architecture up-front. Any large scale development needs some architecture up-front. You cannot TDD mars mission starting from a single object (and SOA is targeted at changing an organization’s overall architecture - though it can be used on solution level as well)
4. Regarding problem 2 - The granularity of a service is larger than that of an object, which means different parts of the service can react to different things. i.e. a service can have an interface that services consume and consume messages from other or the same services
Arnon
September 2nd, 2007 at 3:10 pm
[…] Even I wouldn’t condemn SOAstronauts to hell . . . Service Oriented Architecture is your Ticket to Hell. […]
September 4th, 2007 at 1:01 am
Though SOA has issues, I don’t think the ones you raise are them.
1. BUFA: the only things that really need to be nailed early are the interfaces. Their implementations can use agile development, and I agree that fixing the interfaces does narrow the scope for agility somewhat. But SOA is intended to take collaborative SW development outside dev teams and departments, and I cannot see how that can be done productively without clear contracts between the components, namely the interfaces. SOA should run along just fine with a well-considered set of interfaces.
2. Loops: in reality, this is not going to happen. Services depend on other services because they incorporate them or add extra functionality to them. With each added level of service invocation, the chance for a sublevel to call a superlevel becomes less likely since each superlevel adds extra functionality not needed by the sublevels. This is entirely consistent with other procedural designs, eg using C.
September 4th, 2007 at 9:37 am
A strange loop is where you take a second order concept (i.e. an ‘emergent’ phenomena) and apply it in the context of its first order concepts (i.e. its ’substance’). So… what you have here isn’t a strange loop, it’s just an infinite regress.
September 4th, 2007 at 9:42 pm
Thanks for all the comments. Here are a few selective responses:
@Daniel: My point was *not* that the OO paradigm is superior to the SO paradigm, only that the latter has some glaring deficiencies. Sure, some people use it successfully, but some people use Windows successfully - that doesn’t mean Windows or SOA don’t have serious problems.
@Derek: Spring won’t work when you don’t have control (or access to the source of) the services you’re using or the ones using your service.
@CPinto: your business is not agile if you can’t change your code base without breaking an unknown number of dependent subsystems
@eng: I’m not comparing SOA to other approaches.
@Arnon: I like points 1,2 and 3. I don’t know what you mean by point 4
@Kit: WRT point 1, see Erl’s books. WRT point 2, in a marketplace with many service providers, services are not organized into hierarchies. That’s why we can get dependency loops.
@John: thanks for the reminder. It’s been a while since I read Hafstadter. I wasn’t using ‘Strange loops’ in the technical sense. I should have said whacky loops or unexpected loops or something.
September 10th, 2007 at 8:04 am
Cyclic dependency…
September 10th, 2007 at 8:08 am
…it’s the ol’ Chicken and Egg.
October 11th, 2007 at 2:15 am
[…] Is SOA bullshit SOA architecture is not new (raganwald) Code/Data Seperataions vs Encapsulation - (raganwald) […]
October 19th, 2007 at 7:14 am
What you want is an access forms VBA app on top of SQL Server 2005, I run a multi-million dollar corporation on the back of that baby.
Object Orientation is for kids who don’t understand the procedural paradigm. Now COBOL 2 that was a PROPER programming language…
January 28th, 2008 at 8:20 am
Thanks for sharing guys.
July 28th, 2008 at 1:30 pm
[…] Related articles: Service Oriented Architecture is your Ticket to Hell […]