Advice Line | Bob Lewis | InfoWorld | Getting a company to worry about kludges | June 6, 2006 01:53 PM

MORE ENTRIES

Getting a company to worry about kludges

June 06, 2006 | Comments: (0)

Getting a company to worry about kludges

Dear Bob ...

This week's Keep the Joint Running ("Seven warning signs of bad architecture," June 5, 2006) was soooo timely! I did a presentation yesterday to a group of IT execs in our company where I recommended fixing a fundamental flaw in our data model, equivalent to the customer definition issues you described in your article. The question I got from the CIO was as follows: (Imagine him with a perplexed, pole axed look on his face when he asked): "Just how big an effort do you think it would be to implement these ideas? It seems to me it would be quite an undertaking."

The reason is because of all the "kludges" (your word, new to me, and I like it!) in our system today. For exercise and fun, I copied your example of the on-line clothing store, turned on revision tracking in Word and redlined in just one of the many examples of this kind of kludgy design we've got. I could hear my co-worker chuckling from the next office as she read my personalized version (which I doubt I'll share with the CIO)!

So, now for my question--What kind of wake-up call is necessary to change the "build a kludge fragile workaround" mentality to do the sometimes major redesign that will be required to fix all the old "solutions"? How does your advice play in the world of IT budgeting where there's almost always an incentive to "pay it later"? Will "later" ever come?

- De-kludger

Dear Dee ...

Very often, excess kludge accumulation (dare we coin the acronym "EKA"?) is one of the driving forces behind replacing legacy systems with an ERP suite. It's a chance to start clean - or at least as clean as the ERP suite's internal architecture; some are better than others.

It is relatively rare that a company decides to remediate its legacy systems once they suffer from EKA. Usually, by the time anyone is willing to acknowledge the problem, the hole is too deep to climb out of without a full system replacement. So the company either bites the bullet and does it, or it limps along as long as it can.

Or, it builds a data warehouse to provide a clean source of reporting truth. This doesn't fix anything in the transaction systems, of course, but at least managers can get reports without killing themselves.

So far as wake-up calls ... there are CIOs who recognize the importance of architecture and those who don't (usually the latter are the ones who bought the "CIOs need to be business people, not technology people" line). If yours were one of the former, your presentation would have been a wake-up call had one been needed. If yours isn't, several whacks by a 2x4 would be a minimum starting point.

At the risk of sounding like I'm trying to sell business, sometimes an outside consulting review can help get everyone's attention. This can only work, though, if someone with appropriate clout - usually either the CIO or someone the CIO reports to - wants an objective third-party to bring credibility to the issue. Otherwise it's just a waste of everyone's time and the company's money.

- Bob

Posted by Bob Lewis on June 6, 2006 01:53 PM

RATE THIS ARTICLE:

COMMENTS

I laugh at your trivial example: Hah!

Actually, your customer example is only half my former reality. Our customers were financial institutions. Some of them had multiple branches. It was up to the salesperson who brought in a new client to do the initial setup. They had the option of defining the parent corporation as the "customer", with multiples "branches" associated; or to define each branch as the "customer", with a "customer group" that listed each "customer" that belonged to a single parent.

Now think about what happens when you're asked to run a report of activity grouped by "customer". Hmm, do you mean grouped by branch for those which have them? Or grouped by customer group for those which have that? Or both in one report?

Or try to determine which "customers" are handled by which of your field offices. Do you associate at the "customer" level, or "branch" or "customer group"? Same question for sales commission: What level does the salesperson "own"?

Yeah, it was fun.

Posted by: Drew at June 6, 2006 02:57 PM

Even better.....What about the company that builds an entire 'kludge-kitchen' and christens it as their very own 'ERP-like' system ? Programming the beast in the proprietary language of the RDBMS is even more entertaining when that language is seldom taught any more, has been superceded by dozens of upgrades, & the Vendor hardly recognizes the code created by it now. Getting that company to agree to replacing 'what they own, and OWE to nobody in particular' makes for many gray-hair-inducing meetings.

p.s....they're still at it even today, more than two years after I departed. Some lessons simply cost more than others !

Posted by: Gary Robinson at June 7, 2006 11:59 AM

In my experience, this is very tricky waters through which to navigate. Mostly because those at the helm are the ones who are heavily responsible for the difficulty. All it takes are a few short years of the Quick Fix Architecture to produce a Hopelessly Mired Mess, to which the data warehouse is indeed one of the solutions.

In defense of that, after a few years of kludging the financial system into operation, who wants to face the pain and political death of replacing it? I have never seen the helmsman (read CIO) squint into the distance and say "Yep, Mr. Consultant, that is a durn sand bar and we better turn now!" It has only been a leadership change (I didn't want to say "mutiny" -- the analogy was wrong) that has enabled the new person to declare, "I'm the new Capitan, and I want that rats nest of a rope locker made ship-shape!" to get the "Re-Architect Financial System Database" multi-year program kicked off.

Has anyone seen otherwise?

Posted by: Peter at June 7, 2006 06:50 PM

Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account.

Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them.

Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline.

ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings.

Order your copies today!

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert