The Triumph of Hope over Reason (SOA & The Tarpit of Irrelevancy)

This is the fifth in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. For those who are behind, you can read the previous installments here:

• Tactics vs. Strategy
• Standards-based vs. Standardized
  
• Tools & Anti-behavior
  
• Rubick's Cubicle
  

A very funny site shows that this Internet thing might not be a fad. The Chuck Norris Facts web site has lots of great hyperbolic claims about Chuck Norris, American actor and legendary bad-ass. Some of the "facts":

• If you have five dollars and Chuck Norris has five dollars, Chuck Norris has more money than you.
• There is no 'ctrl' button on Chuck Norris's computer. Chuck Norris is always in control.
• Apple pays Chuck Norris 99 cents every time he listens to a song.
• Chuck Norris can kill two stones with one bird.
• When the Boogeyman goes to sleep every night, he checks his closet for Chuck Norris.

Some of this may be just a tad exaggerated. I'm pretty sure that when Chuck Norris does pushups, he is not in fact pushing the earth down instead of pushing himself up. The site is here, if you want to go read more of them. I'll wait.

OK, now that you understand more about Chuck Norris, here's another site of over-the-top exaggeration about an over-hyped subject: SOA Facts, modeled after Chuck Norris Facts:

• SOA is the only thing Chuck Norris can't kill.
• SOA invented the internet, and the internet was invented for SOA.
• SOA is not complex. You are just dumb.
• SOA can always win at TicTacToe. Even if you go first.
• One person successfully described SOA completely, and immediately died.
• In a battle between a ninja and a jedi, SOA would win.
• SOA knows what you did last summer, and is disappointed that it wasn't SOA.

I used a bunch of these in one of my SOA talks as bumper slides between the various topics, which provided a nice fun icebreaker. But I reserved two of them for the last part of the talk because I think they aren't exaggerations at all, merely deep truths:

• Implementing SOA for the first time is the triumph of imagination over intelligence.


• Implementing SOA for the second time is the triumph of hope over experience.

SOA has gotten so complex, with so many moving parts, that getting it right is extraordinarily difficult. Once you've lived through one of these projects (especially if you've fallen into the other tarpits I discuss in the previous installments), you understand the first quote at a deep level. That you would try it again truly is the triumph of hope over reason.

Rubick's Cubicle (SOA & the Tarpit of Irrelevancy)

This is the fourth in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. For those who are behind, you can read the previous installments here:

• Strategy vs. Tactics
• Standards-based vs. Standardized
• Tools & Anti-behavior

Developers love to solve puzzles. One project manager with which I used to work kept a jar full of little nail puzzle (like this) on his desk:

Any time he was having a conversation that he didn't want developers to listen in on, he'd grab one of the puzzles and toss it to them. Inevitably, the developer would grab the toy and immediately become totally absorbed in solving the puzzle. After about 10 minutes, the puzzle would yield up it's secret, and the developer would look up and ask "Did anything important just happen?"

Developers tend to be problem solvers -- it's one of the appealing things about fiddling with computers. But what happens when you take a natural problem solver and present them with dull work, with no interesting challenges? What happens frequently is what I've deemed the Rubick's Cubicle anti-pattern.

If the presented problem isn't complex enough, developers will figure out ways to make it complicated and therefore challenging.

Writing the same dull CRUD application over and over is boring. But what if you could figure out a way to get all the simple CRUD applications to talk to one another? That's a nice and juicy puzzle. This perhaps explains the complexity fetish I see in so many "Enterprise" architectures and applications. Some of it is accidental complexity, accrued from years of piecing together parts that were never meant to work with one another. But I don't think accidental complexity covers the entirety of why things are so convoluted.

I remember back in the mid-90s, I was the CTO of a small training and consulting company. We were absolutely delighted when we first saw EJB: here was a technology no one could understand without extensive training. The same thing happened with all the variations of COM, DCOM, and CORBA. Those were flush times for training companies because we knew that developers would be drawn like moths to a flame, frequently with the same result.

Building the simplest thing that can work is sometimes duller than crafting some devilishly complex Rube Goldberg machine, but keeping it simple is a worthy challenge in it's own right. If you find yourself in Rubick's Cubicle, stop and ask yourself: "is there a simpler way to do this? Perhaps dismantling something that no longer serves it's purpose? What is the simplest thing that could possibly work?"