Useful metrics have to satisfy the seven C’s.

Until two weeks ago it was the six C’s (Keep the Joint Running: A Manifesto for 21st Century Information Technology, Bob Lewis, IS Survivor Publishing, 2006). That’s when I found myself constructing a metric to assess the health of the integration layer as part of rationalizing clients’ application portfolios.

In case you haven’t yet read the Manifesto (and if you haven’t, what are you waiting for?), metrics must be connected, consistent, calibrated, complete, communicated, and current. That is, they’re:

> Connected to important goals or outcomes.

> Consistent — they always go in one direction when the situation improves and in the opposite direction when it deteriorates.

> Calibrated — no matter who takes the measurement they report the same number.

> Complete, to avoid the third metrics fallacy — anything you don’t measure you don’t get.

> Communicated, because the biggest benefit of establishing metrics is that they shape behavior. Don’t communicate them and you get no benefit.

> Current — when goals change, your metrics had better change to or they’ll make sure you get your old goals, not your current ones.

The six C’s seemed to do the job quite well, right up until I got serious about establishing application integration health metrics. That’s when I discovered that (1) just satisfying these six turned out to be pretty tough; and (2) six didn’t quite do the job.

To give you a sense of the challenge, consider what makes an application’s integration healthy or unhealthy. There are two factors at work.

The first is the integration technique. At one extreme we have swivel-chairing, also known as integration by manual re-keying. Less bad but still bad are custom, batch point-to-point interfaces.

At the other extreme are integration platforms like enterprise application integration (EAI), enterprise service busses (ESB) and Integration Platform as a Service (IPaaS) that provide for synchronization and access by way of single, well-engineered connectors.

Less good but still pretty good are unified data stores (UDS).

The second factor is the integration count — the more interfaces needed to keep an application’s data synchronized to every other application’s data, the worse the integration score.

Here’s where it gets tricky.

The biggest challenge turned out to be crafting a Consistent metric. Without taking you through all the ins and outs of how I eventually solved the problem (sorry — there is some consulting IP I do need to charge for) I did arrive at a metric that reliably got smaller with better integration engineering and bigger with an integration tangle.

The metric did well at establishing better and worse. But it failed to establish good vs bad. I needed a seventh C.

Well, to be entirely honest about it, I needed an “R” (range), but since “Seven C’s” sounds much cooler than “Six C’s and an R,” Continuum won the naming challenge.

What it means: Good metrics have to be placed on a well-defined continuum whose poles are the worst possible reading on one end and the best possible reading on the other.

When it comes to integration, the best possible situation is a single connector to an ESB or equivalent integration platform.

The worst possible situation is a bit more interesting to define, but with some ingenuity I was able to do this, too. Rather than detail it out here I’ll leave it as an exercise for my fellow KJR metrics nerds. The Comments await you.

The point

The point of this week’s exercise isn’t how to measure the health of your enterprise architecture’s integration layer.

It also isn’t to introduce the 7th C, although I’m delighted to do so.

The point is how much thought and effort went into constructing this one metric, which is just one of twenty or so characteristics of application health that need measurement.

Application and integration health are, in turn, two of five contributors to the health of a company’s overall enterprise technical architecture, the enterprise technical architecture is one of four factors that determine IT’s overall organizational health, and IT health is one of ten dimensions that comprise the overall enterprise.

Which, at last, gets to the key issue.

If you agree with the proposition that you can’t manage if you can’t measure, everything that must be managed must be measured.

Count up everything in the enterprise that has to be managed, and considering just how hard it is to construct metrics that can sail the 7 C’s …

… is it more likely your company is managed well through well-constructed metrics, or managed wrong by being afflicted with poorly designed ones?

It’s Lewis’s metrics corollary: You get what you measure. That’s the risk you take.

If you can’t resolve a thorny conundrum, try asking the question backward.

In the United States we have an ongoing, unresolved question: What are society’s obligations to the poor? 90 years after FDR’s New Deal we’re still arguing about this, with plenty of programs but little in the way of a national consensus.

What if we asked the question backward — instead of asking what obligations, if any, we have to the poor, let’s ask what privileges should accompany wealth?

We might imagine a continuum. On one end are certainties: Wealth should entitle those who have it to more and cooler toys. Tastier meals. Freedom from having to pick up after themselves, vacuum their floors, and scrub their plumbing fixtures.

Terry Pratchett once pointed out that “privilege” means “private law.” On the other end of the continuum from better toys, food, and household hygiene I think most of us would agree that wealth shouldn’t entitle its owners to private laws, whether in the form of legislation passed to benefit the favored few, or better judicial outcomes because that’s what you get when you can afford the best lawyers.

For that matter, instead of asking if the poor should be entitled to free healthcare, question inversion leads us to instead ask if wealth should confer better health and longer lifespans for those who, through luck or skill, have more of it.

Keep the Joint Running isn’t the place for this conversation, although I’d be delighted if you decide to have it, whether in the Comments, at your dinner table, or in a local tavern accompanied by conversational lubricants.

What does fit KJR’s charter is a very different business question that looks much the same when you invert it.

The question: How can business leaders keep their organizations from turning into stifling, choking bureaucracies.

The inversion: Must all rules apply, all the time, to everyone, regardless of their performance, contribution to the bottom line, or where they rank on the organizational chart?

For example:

> In your sales force is a rainmaker — someone who’s exceptional at designing and closing big, profitable deals. He also has a volatile disposition and huge temper, which he aims at whoever is convenient whenever he feels frustrated. The question: Should his direct financial contributions result in, shall we say, a more flexible and nuanced response from HR than another employee, with a similar temperament who contributes far less to the company’s success should get?

> Your company has a well-structured governance practice for defining, evaluating, and deciding which capital projects to undertake.

Your CFO is championing a major capital project. While it seems to make sense she hasn’t run it through the process. Instead she’s schmoozed it through the committee, whose members trust her judgment … or might want her to return the favor come budget season.

The question: Should the CFO and her executive peers be allowed to skip procedural steps that lower-level managers are required to follow?

> Your company’s recruiting function has established specific procedures for filling all open positions. The CEO recently brought in a new CIO to straighten out the company’s IT organization, and the CIO wants to bring in “his team” — three managers he’s worked with in the past. He knows they share his approach to running IT and are the right people to lead the company’s IT turnaround.

Should he be allowed to bypass Recruiting’s procedures?

For most of us the instinctive answer is yes — the rules apply to everyone.

Except for most entrepreneurs, who tend to see the uniquenesses of situations as well as their similarities.

Take the case of the CFO and her capital project. Companies institute governance frameworks and procedures for reviewing capital proposals to reduce the risk of making poor investments. The CFO applies these frameworks in her sleep. Dragging her proposal through the procedure wastes a lot of her valuable time with little additional risk reduction.

On the other hand, insisting everyone follows these rules, from the top of the organization to the bottom, helps establish an egalitarian perspective that says nobody gets special privileges. It also ensures the company’s executives don’t get sloppy, mistaking arrogance for good judgment.

But on yet another hand, if everyone in the organization had the CFO’s level of financial sophistication, there might never have been a need for the rules in the first place.

“There are reasons we have rules,” is a phrase you’ve probably heard from time to time.

And I agree. There are reasons we have rules. And if we took the time to remember those reasons we’d all be better off.