Thursday, October 14, 2010

Simplicity is hard

One of the things I get to do a lot of is look at IT estates that are a complete and utter mess. Systems overlap in functionality, are difficult to maintain and the links between them are more complicated than Glenn Beck's issues with reality. When doing a Business Service Architecture it becomes clear that the big issue here is that IT doesn't learn the lesson of Unix Do one thing and do it well. In SOA, particularly business driven SOA this is the whole point of services, they do one thing and they are designed to be integrated.

Having the "services" as clean though is pointless if what you have under the covers is just the same old crud with some REST or WS-* lipstick on top, you actually have to have an implementation that is clean all the way down or you are still screwed.

The BSB Specification was based around that principle of doing one thing well, and the whole point of the DSB/BSB split is to keep it simple.

This then becomes the real issue, its actually really hard to architect and deliver simply. In the MDM space for instance you see MDM solutions that morph into MDM + ODS + Reference Data Management solutions. "clean" ERP installations are destroyed by customisation and the Java solution gets some crufty bolt ons because "it was easier to do it there". The delivery builds the blob with lipstick on it and suddenly we are no better off.

Why does this happen? Well more and more I believe its because the SIMPLE pictures that describe a business architecture are either not drawn at all or are abandoned because of their simplicity. People, architects especially, don't like putting in place the rigour and control that is required to deliver a simple solution, its much easier to deliver a blob and let people cope with it in support. Simplicity isn't a valued commodity because it doesn't allow people to show off their understanding of complexity.

"Je N'ai fait celle-ci plus longue que parceque je n'ai pas eu le loisir de la faire plus courte.
--I have only made this letter rather long because I have not had time to make it shorter."
Pascal. Lettres provinciales, 16, Dec.14,1656. Cassell's Book of Quotations, London,1912. P.718.

Simplicity takes time and effort and the end result is much more satisfying, easier to explain, easier to maintain and easier to use. Most people however take the easy route to complexity.

Technorati Tags: ,


stu said...

My sense is that you need to be in a relatively unassailable political position to promote and enforce simplicity within a large IT shop. It runs counter to what every vendor, system integrator, or wannabe architect is incentivized for - more shiny tools, more billable hours, more bubbles & lines, more job security. The only folks that might appreciate simplicity are in service operations, but they're usually outsourced and thus don't have a lot of sway.

And if you do manage to try something simple, when you run into the typical project bumps and bruises, the blowback can be much harsher than normal because you can't deflect attention and blame the usual suspects ... "oh it's that IBM again, you know how complicated they are", "this architecture was designed for the next generation of hardware (snicker)", "let's bring a consultant in to review the design"....

This is one reason why most WS-* contracts are still rather point-to-point and poor. The only area you might get some agreement is on the highly common bits of XML used across services, most everything else will be one-off without a lot of willpower and ability to respond to change.

I also think the intolerance for simplicity is why standard blueprints for REST contract & interface description in IT are rare. It requires a lot of will to stick one's neck out and make decisions that aren't backed up by lots of nodding faces, even if they'll lead to a more maintainable result. Yet someone has to give it a shot if it ever is going to become an understood industry practice & something the masses can wrap their heads around.

Unknown said...


Couldn't agree more, its very sad but the basic mindset of IT is indeed to focus on the shiny bits and ignore the simplicity....

God its depressing :(

stu said...

I stay optimistic and motivated by the "honeymoon effect" of joining an organization, it's sort of like American presidential politics, you have 18 months to actually change things, the rest of the time is staying alive and trying not to get impeached

That doesn't bode well for enterprise-wide change in the larger places, but does mean you can get (some) things done.

Anonymous said...

Ha ha, that's funny! "Glenn Beck and reality", that's a really good joke on your part! I'm impressed! I mean, what does Glenn Beck know about reality? I mean, he only predicted that the value of the dollar would be so screwed that the other countries wouldn't touch it anymore, right?

Oh, wait...

Hmmm, looks like Glenn Beck does have a sense of reality.

You know, I'm curious: why would you make some sort of statement on a blog that has absolutely NOTHING to do with politics, and invites all kinds of IT associates regardless of their political beliefs? You probably have no reason, but it seems like nowadays you can't go anywhere, any sort of TV show, blog, or web site, without somebody injecting some sort of political statement made out of pure emotion, designed to "sucker punch" somebody with opposing viewpoints that least expects it.

Oh, sure, you have every right to do that. That is your freedom of speech, don't mind that. But keep in mind when I had my RSS feed select a bunch of Oracle blogs, it selected a BUNCH of Oracle blogs, a lot that say the same things that you do. If you want to alienate a segment of your readers, that's your business. I would rather go somewhere else.

Happy Thanksgiving!

Unknown said...

Anon... three paragraphs of ranting about a single comment.

Happy Thanksgiving and chill

Anonymous said...

Steve, your observations are astute and on target. I've recently experienced this after going through an architecture review where I was specifically told that my solution couldn't, obviously, be that simple. Talk about exasperation; despite meeting all requirements and having the ability to easily scale, my architecture is now being re-factored to be highly coupled to its clients, scalable only by the introduction of new components that manage the solution and lots of hardware. I don't even want to be associated with this impending pit of problems.