Enterprise Design Debt

I think the question I get asked most often is how to manage the constant struggle between IT trying to deliver something to quality and budget, and the business wanting everything yesterday. When a project is late, I have yet to see a business representative say that they want the good version next week, over the not-so-good version today. In fact the conversation tends to go along the lines of we’ll take the tactical version and launch that today, and install the strategic version later. Except that no sooner have the attendees left the room when the strategic version loses focus, other project issues take priority, and new business demands emerge. Before you can say what’s the point of doing strategy and architecture, when all you guys want is crap quickly? you find your architecture and strategy ignored while you deliver crap. Quickly.

And it gets worse.

Having saddled your operational colleagues with said crap, things inexorably start to go pear-shaped. All those point-to-point connections and the lack of transaction management lead to data integrity issues. Operations do their best to prop it up with monitoring and scripts and late nights, but eventually it starts to impact the business. And who’s fault is it? IT’s of course. They only ever deliver crap, so they must be to blame. All the fancy words and ideas about better architecture and capabilities mean nothing if they remain in documents clogging up corporate shared drives. A perfect architecture only ever exists in your head, but a useful architecture only ever exists in operations.

It’s a serious issue. I’ve seen businesses outsource almost their entire IT function in the hope that someone else can do a better job. They simply cannot see that they are mostly to blame for the situation: impatient for delivery, uncertain about their own requirements, unable to fund projects properly, they force IT to deliver poor quality software. The end result is that nobody is happy. The business is frustrated and IT loses pride in itself. Without a sense of identity, pride and mission, IT cares less and less over time about everything it does and a vicious circle begins.

The features of this downward spiral are a lot like the features of behavioural issues that individuals experience. Focussing on the negative aspects of existence, and an inability to see positive possibilities, can lead to anger, depression and all manner of emotional disorders. The more angry or depressed you become, the more the outside world changes its reaction to you, mostly in negative ways, and thus a self-fulfilling prophesy is born - your low opinion of yourself is reinforced by a seemingly low opinion of you in others. Phsycologists will tell you that one good way to help break the cycle is not to act out your feelings, but to express them. I will call this the verbalise don’t externalise maxim.

Externalising is when you act angry, say, because you feel frustrated (swearing and cursing, aggressive posture, clipped speech, etc). Far from being a way to ‘let off steam’ it reinforces your feelings and tends to exaggerate them. In software delivery this would translate to feeling depressed about the last release and turning up at the post implementation review full of predictions of doom and gloom about new strategies that may make the next one better. There’s nothing wrong with feeling depressed when things don’t according to plan, you’d have to have pretty low ambitions for everything you ever do to go right. What you need to be able to do is verbalise what it means to deliver software below your desired standard. That verbalisation needs to be blameless, impersonal, and above all, useful as a currency in future do-it-quick or do-it-good conversations. In technology that currency is the Design Debt.

All projects should start out with high architectural ideals. Not overburdening - they should maintain all the qualities of agility and elegance - but certainly strategic enough that more than just the immediate functional requirements are being met. As these enterprise aspirations are translated into a solution architecture, the trade-offs will begin. Where architectural facets are clearly wish-list items, the business impact will be minimal (you might think it’s the best thing slice bread, but it’s only business impact that should be considered in trade-off meetings). But some compromises may be set the business up for potentially serious consequences. Making a clear case for a good feature to be kept in, despite extras cost or time, is the first step. That’s common sense, so I won’t labour the point, but do make your presentation story-like it’s so much more convincing than saying things like ‘security is good because it keeps data safe’.

So let’s say you did your presentation, and even though the sponsors got it, they still want to go with a sticking plaster security approach. The system will still work, but there’s a risk. Now you need to calculate the design debt incurred.

Design debt is just like real debt. When you want to cut corners in life (e.g. buy a new car before you can really afford it) you can get into debt. You acheive your aim, but there’s a debt to pay at some point. There are many ways to pay a debt off, but you can never just ignore it. If you do it gets bigger. Sometimes you are lucky and you receive a windfall to pay debt off more quickly. If you can guarantee a debt with some equity or similar promise, then you can service only the interest rather than the balance. Debt is also a currency that independently represents the need to have cut a corner in the relationship between the debtor and the lender.

It’s not for IT to force the business into any one choice over another. Sometimes getting to market quicker really is better than putting a great solution out there late. For all my speeches about IT being an equal in the business partnership, it clearly has neither the visibility nor a mandate in this area. But it is IT’s duty to make the consequences of these decisions transparent to the business and not to let it ‘forget’ these consequences, or to internalise them in a kind of techo-emotional behavioural disorder. So I favour keeping a debt register (just a spreadsheet, available online, no need to get overly bureaucratic) with the following in it:

• Nature of variation - Brief description of what the issue is.
• Cost to put right - Man-days (money gets too emotive) to apply corrective action
• Cost to spot fix - Man-days to address risks should they materialise. This might be the same as above, but as the figurative horse will already have bolted there might be clean-up, PR, etc work to do.
• Cost to maintain - Man-days per Month to manage this variation
• Risk created by variation - List of untoward events that might occur by having this in production
• Owner of variation - The name of an appropriately accountable person giving the OK for the variation even after seeing the design debt
• Plan for rectification - Ideally, a date and some steps to remedy the situation at a later date. This may never come, but you need a plan to cost some of the items above

You need to be clear that this is not an artefact to beat the business with if things do go wrong. It’s just a mechanism to verbalise what you may inadvertantly forget later. It’s also not an excuse for not trying to get good solutions in. In my experience the more frank and forthright you are with the business the more they will listen. I lied a bit at the beginning because I have got business people to agree to deliver late rather than poorly on many occasions. They may not have liked it, but they could see that managing the design debt is a shared responsibility that can’t be ignored, and woven into the fabric of delivery it helps both sides stay out of counselling.