Welcome to hell. Population: everyone.
I figured it was about time now, time to get my feet wet. I figured I needed a place to vent a bit so this is probably what will happen here. Every once in a while at least.
So, what is currently annoying me? Well, a lot of things really. But perhaps most of all the ubiquitous bastard that is SOA. SOA is everywhere. SOA is the best thing since sliced bread. SOA will make your coffee, scratch your back, feed your cat, snuggle up to your wife, steal your car and drive it down to Tijuana to catch one of those pony shows down there while using your money to buy loads of dru… hang on, I got a bit carried away there at the end I think.
Listen. Service Oriented Architecture is a nice enough thing. It’s a good way of thinking when thinking about architecture. But
1: it isn’t new
2: it won’t solve your problems
and of course
3: IT’S THE REQUIREMENTS, STUPID!
I don’t know, I have been around this old planet for a number of years now and I have gone from complete bitter cynic to slightly less bitter cynic and back again to the deepest darkest pits of cynicism, sarcasm, bitterness and utter despair about my fellow men. Come on! Let me tell you a story. Back in 1983 I got my first computer. My parents had absolutly no clue and the fact that I had asked them for a ZX Spectrum and got a Spectravideo 318 should be ample evidence of that. Anyway, I installed the piece of crap on the desk in my bedroom and started playing with it (which back in those days meant spending hours painstakingly entering program listings from computer magazines just to be able to play a really crappy game for ten minutes before you got bored. But you got really good at debugging fairly quickly). A couple of days later one of my friends, actually my only friend back in those days, came over to have a look. I will withhold his name since it would be nasty of me to tell you (well, ok – his name is Lennart, he’s a nice guy and drives an ambulance these days, or so I hear). In any case he looked at the screen where one of said crap games was being played by yours truly and then asked what else you could do with it. By that time I was already properly bitten by the computer bug so I (less than truthfully since this monster had a whopping 32 k of RAM built in) answered “Anything”. We shut down the game and got back to the non-blinking block that passed for a prompt and he asked me to move over. He then swiftly sat down and wrote “Show me a breakdancer”. Needless to say he was royally disappointed and declared computers a crap fad that would never go anywhere.
Anyway, what does that have to do with SOA, I hear you asking yourselves. Well, everything. Unless you understand the limitations that are put on systems in general you can’t really expect to be able to make informed decisions. And the limitations are basically everything that is not in the requirements. If you want a system that is able to perform function X then it has to be in the requirements. To turn up later and say “Hey, why doesn’t this do function X” and follow that up with a “How can it take X amount of hours to get function X when this is SOA” is simply inane, naive and, frankly put, stupid. Too many people within organisations I have seen have touted SOA as the thing that will make anything possible – and from a purely architectural perspective it certainly makes heterogenous systems able to talk to one another. But the fact remains – most of your systems in your enterprise don’t support it. To make them support it is integration work. Integration work takes time, money and effort. Nobody likes to spend these valuable currencies on something that should have been captured in the requirements phase. And which could – actually – have been achieved without resorting to architectural delusions of grandeur. Believe me – I am all for good design. In fact, nothing pissed me off more than bad design. But SOA doesn’t equal good design. It just means that for a specific requirement specification someone has defined service interfaces that a specific consumer (or consumers) are using. Nothing more. Nothing less. It may be right but it sure as hell won’t make your organisation more agile in and by itself. That requires leadership, strategy and above all vision that encompasses more than a governing architectural principle that services should be able to be reused.