Solution Maturity

In Anger Management and the Enterprise Design Debt I took Ward Cunningham’s excellent Technical Debt Metaphor and applied it to the enterprise. I proposed that all those little bits of debt from each project get wrapped up and become a kind of currency to aid communications with the business. The notion of Enterprise Debt is important for two reasons:

1. It is very real. Just because most businesses ignore it doesn’t make it go away. Like real debt, it gathers interest and hampers business agility.

2. Like it or not, this is always seen as IT’s fault. Over time this causes the IT Department to lose self-respect, stop being creative, and see good people leave, reducing its ability to deal with debt.

The essence of my proposal was this:

• IT has got to see its job as delivering only perfectly formed, thoroughly tested, strategic, software products into production. We are not here to cut corners in quality (if all you want to do is cut corners then you can get much cheaper people to do that).

• However, we do recognise that there are occasions when the benefits of seizing an opportunity outweigh the risks of not delivering perfect software. This means finding the best solution available given constraints of time, budget, people etc. Ideally these occasions will be rare, but they may be more frequent at certain times in a company’s life-cycle.

• When these occasions arise IT has another role to play, which is to make sure that the business is fully appraised of the risk and impact of any compromises made, ahead of time, so that everybody can make good decisions.

• These risks must be tracked and managed long after the projects have delivered in a way that is dispassionate and unemotional, adopting the same kind of techniques used to treat stress and anger management, because this removes blame from IT and allows it to continue pursuing the goal of perfectly-formed software.

Perfect Software?

If the business runs ten projects a year, three of them might warrant a debate on whether the underperforming COBOL system needs a rewrite. All systems will need a rewrite one day, whether because they can’t be enhanced fast enough to keep up with business demand, because they become too unstable, or because they can no longer be supported or upgraded. Once any one of these is true, the perfectly formed answer is a rewrite - so that the next ten projects can focus on moving the business forward.

In practical terms “perfection” doesn’t exist. It’s what bad architects seek when they forget the immediate business situation and instead seek a kind of erotic stimulation in overly elaborate diagrams. But pursuing perfection isn’t a bad thing. Paul Graham’s essay “How can Art be Good?” makes the point that seemingly subjective concepts (goodness in art, perfection in software) are often more objective than is obvious. Summarising what he said: if you wrote a program in a new language with no training you’d make a pretty bad job of it (I have some excruciatingly bad college Pascal to prove this) and yet, as you learn techniques, understand language idioms, read other’s code, fix your mistakes, you do get better. What you are moving towards is perfection, even though you can’t actually get there.

The goal of the IT Department is therefore perfection - through techniques, sharing good code, etc - because this is what makes it a professional discipline and what justifies a Development Manager earning twice what a Product Manager gets.

Cut Corners?

There may be good reasons to leave the COBOL system rewrite for another year (priority, budget, resource, skills) and plan to make the best of it with remedial fixes and tactical business improvements. But this is not an IT decision. Putting off the rewrite and allowing one third of the IT budget to be spent on tactical fixes, will make next year’s planning much much harder: the COBOL system will cost more to rewrite and more projects will have to be scrapped to do it.

If the competition rewrites their COBOL system this year they may have an edge in the market. Project planning and roadmap scheduling is a game of poker and it’s a game the business plays, not IT (though IT has a crucial advisory role in how to play the cards).

How bad could it get?

But why worry? You can only do what you can do, right? Well here’s the thing. Eventually the limitations of that COBOL system will directly impact the ability of the business to compete. You won’t see it from inside IT, you won’t even see it from inside most parts of the business, but the finance department will - revenue will drop while support costs will rise. Rewriting the system ceases to become an option, because by now it will take three years to do, during which there will be no new functionality, two sets of bills to pay (maintaining the old system and paying for the new one), and falling revenue. There are few CEOs brave (or crazy) enough to address that head on.

Even Gartner, usually so upbeat about IT, have noticed this happening across the industry. In the recent “Signs indicate a train wreck is coming, unless you modernise IT” (reference G00158648, if you are a subscriber) they say:

Gartner is concerned that many IT organizations are overly focused on what tactical step to take next and are missing the ever-worsening bigger picture with respect to IT modernization

They stop short of saying a company could go out of business because of its IT burden, but I won’t - I think Enterprise Technical Debt is so insidious, so pernicious, that over time it could absolutely prevent a company from continuing to trade independently. Not with a bang or a crash, but with a downsizing whimper and a takeover sigh.

Three things need be in place for this to happen:

• The business has to utilise IT in what Harvard Business School Professor Warren McFarlan called “offensive mode” (i.e. depend on it for market advantage, rather than simply to automate or stay in business)
• The debt has to be high enough to affect planning beyond one year
• One or more competitors need to have not made the same mistakes.

Only one of the three is controllable - the technical debt.

Controlling Debt

My original proposal was to communicate using a Debt Register spreadsheet, that looks something like this:

Variation	Fix Cost		Risk Exposure	Maintain Cost	Biggest Risk	Owner	Fix Plan
---------	--------		-------------	-------------	------------	-----	--------
Extend		$1,000,000		$1,500,000		$300,000/year	Failure holds	Bob		In next year's
COBOL App													up sales for			Roadmap
															a month

The point being that each business decision to go tactical can be illustrated in business terms with clear business owners. Each annual planning session can then use this to assess debt and make wise investment choices.

Issues

There are two issues with this approach. The first is that technical debt isn’t tangibly real until the business has to wait a long time for something they really need immediately. Waving ten line-items of debt totalling $10m will rarely result in a $10m get-well project. Businesses appreciate being given lots of information when they make tactical decisions, but they’d really rather forget about the debt accrued afterwards. Which leads us to the second issue: debt is a negative concept and, as political strategists will confirm, communicating via a negative is not always wise. We need a way to make debt positive, or at least not so negative.

Debt and Maturity

So here’s where I got to: each year the business puts together a plan, and that plan is a way of saying “here’s where we want to be a year from now”. In a perfect world, that’s exactly what would happen. But, more often than not, the plan contains too much change for one year, so ways are sought to cut corners and deliver more with less (i.e. add new functionality to the COBOL system, rather than take the hit of rebuilding it and adding new functionality). IT calls these cut corners Technical Debt and aggregates it up into Enterprise Debt.

The way I see it, what the business is asking for in the plan is maturity in the CMMI sense. That is to say they specify new delivery models, ways of working, processes etc that they believe will make them more competitive in the marketplace, and they want these institutionalised via their software platforms. Institutionalising something is the same as saying it’s strategic - i.e. not dependent on the ad hoc best-efforts of named individuals, but part of the fabric of doing business and, more importantly, subject to continuous improvement.

CMMI is a very big (and frankly very dull) process-improvement practice that promotes a structure for being good at things (essentially by making them institutionalised, repeatable and continuously improved) and defines five levels of maturity.

1. Initial - something is done, but the quality of it pretty much depends on who does it
2. Managed - someone makes sure that it’s done consistently
3. Defined - it’s documented so others can see how it’s done and also do it consistently
4. Measured - data is collected about how it’s done so everyone can talk about it objectively
5. Optimised - all of the above can be put to work making it better

The CMMI intro presentation quotes an errant software manager as saying “I’d rather have it wrong than have it late. We can always fix it later” so clearly there’s already a link between it and cutting-corners and debt. You see this 5-stage model appearing everywhere (TOGAF uses it to define Architecture Maturity Models) so I thought why not adapt it to measure Enterprise Debt in a more constructive way?

The logic goes something like this: The business wants maturity. IT uses Enterprise/Technical Debt to illustrate how far short of this maturity target we fall every time we cut corners, but we could turn this around and show how mature the business is becoming by measuring the Solution Maturity of its software. Maturity and Debt are two sides of the same coin, you can flip between them depending on the message you want to get across.

Solution Maturity Model

The Solution Maturity Model is merely a way of applying some objective measures to a design intent, or existing software architecture, so that its ability to meet strategic goals can be debated. This would vary by organisation, but here’s a basic model, which goes from best-efforts, to design-patterns, to components, to reuse, to composability. The idea being that each is a logical precursor to the next.

1. Developing

   Emergent, random or accidental architecture. Quality is mixed and mostly depends on the skill of the individuals involved. This slows progress because different changes compete for the same individual. Limited options for extension often lead to a just get it done it attitude any strategic planning is a luxury. Documentation is non-existent, sparse or conflicting. Architecture is consigned to an inappropriate overhead. To-do lists grow ever longer. The business isn’t happy with the service and yet everyone is working flat out to deliver it.

2. Repeatable

   Adopts known good-practice patterns to solve problems. Various standard implementation patterns are debated, agreed and published. Anyone unfamiliar with the work could understand the code easily, which is based on what works, not what’s already there. May be harder to do at first, but gets easier over time. Documentation and use of patterns reduces dependence on key individuals. There is a clear partitioning of logic, some into separate layers. Problems are solved consistently but these aren’t reusable later without effort.

3. Changeable

   Visible signs of components that are loosely coupled, isolating change. Internal structures are separated from the external representation. Interface payloads are based on business models, not implementation models. Small changes in one system have no impact on others. Clear use of layers to separate concerns and support fault-tolerance. Larger (less frequent) changes may still have a ripple effect. Small business changes can sometimes cause major technology change. Regression testing is still painful.

4. Reusable

   Component interactions are based on patterns, supporting reuse in different contexts. Repeatable patterns are developed into solutions that reduce effort on later projects. Interfaces are generic enough to change less and less. Layers expose services that can be safely reused by higher layers. The amount of relational database coupling is nil. Rippling change only occurs when there’s a rippling business shift. Architecture value is measurable. Architecture and business alignment is close to 100%. Applications support the business model, but does not help drive it in new directions.

5. Capable

   Changeable services align directly to business strategy. The architecture is based on well known patterns and structures. The exposure of these structures is designed to be reusable. The internals of these structures is designed to contain change. Application services are delivered in a way that allows them to be further exploited by the business, so conversations are as much about the capability driving the business as they are about functionality supporting it.

Using it

A Solution Maturity Model can be used anywhere that a negative assessment might be counterproductive. For example, you need to review the design on a new project. You could list all the things wrong with it and have that age-old confrontation with the project managers and developers over what the value of strategy is over just meeting immediate requirements - 90% of the time you will lose. Or you could show how the annual business plan requires a maturity level of four, say, and illustrate why this design rates a two. Will you win more than 10% of the time? Maybe not, but you are at least able to link one project’s contribution, or lack of it, to an overarching business goal that isn’t specifically technical (i.e. you must use an ESB because we say so otherwise we call that design debt).

You start the year at one maturity level (easily measured and brought into the conversation) and the business plan will require an improvement on this, or at least the ability to maintain it. Each project is therefore implicitly expected to contribute to the new maturity. They all contribute something and that’s what the conversation becomes about. Are they contributing enough? Rather than what is the debt being amassed? It’s a subtle but important shift in the tone of the conversation. Business sponsors will often say that they have no choice but to go tactical to hit dates, but they’re not so quick to accept this when it’s put in the context of not moving the company forward.

Summary

Technical Debt is a bit.. well.. technical and makes the debate one between the sponsor and IT, whereas Maturity is less so and makes the debate one between the sponsor and the CEO. It’s not that the tactical approach is wrong, you could go tactical all year and still come out on top, it’s about making the business understand that they have a responsibility to extract the maximum value from their own information systems. IT’s role is to show how this can be done, and highlight when it might not be happening.

I think the Debt Register remains an important part of communication with the business. It’s critical that they understand in base financial terms what their decisions mean, but over time I have come to the view that it has a kind of effectiveness half-life of about three months. It’s around that time that those tactical changes become seen as just “how things work” and you’ve really got to deal with that, not harp on about the debt the naughty business has amassed. The notion of Enterprise and Solution Maturity just helps us not forget the wider objective we are both here to achieve.