All Posts by Bob Lewis

|In: Architecture|Last Updated:

# # #

I tried to write a column based on Ruth Bader Ginsburg and how her passing affects us all.

I couldn’t do it.

Please accept my apologies.

# # #

Prepare for a double-eye-glazer. The subjects are metrics and application portfolio rationalization and management (APR/APM). We’re carrying on from last week, which covered some APR/APM fundamentals.

If, as you’re undoubtedly tired of reading, you can’t manage if you can’t measure, APM provides an object lesson in no, that can’t be right.

It can’t be right because constructing an objective metric that differentiates between well-managed and poorly managed application portfolios is, if not impossible, an esoteric enough challenge that most managers wouldn’t bother, anticipating the easily anticipated conversation with company decision-makers that would ensue:

Application Portfolio Manager: “As you can see, making these investments in the applications portfolio would result in the APR index rising by eleven percent.”

Company Decision Maker: “Let me guess. I can either trust you that the APR index means something, or I’ll have to suffer through an hour-long explanation, and even then I’d need to remember my high school trigonometry class to make sense of it. Right?”

Application Portfolio Manager: “Well …”

What make this exercise so challenging?

Start with where most CIOs finish: Total Cost of Ownership — the ever-popular TCO, which unwary CIOs expect to be lower for well-managed application portfolios than for poorly managed ones.

They’re right that managing an applications portfolio better sometimes reduces TCO. Sadly, so, sometimes does bad portfolio management, as when the portfolio manager decommissions every application that composes it.

Oh, and by the way, sometimes managing an applications portfolio better can increase TCO, as when IT implements applications that automate previously manual tasks, or that attract business on the Internet currently lost to competitors that already sell and support customers through web and mobile apps.

How about benefits minus costs — value?

Well, sure. If we define benefits properly, well-managed portfolios should always deliver more value than poorly managed ones, shouldn’t they?

Not to nitpick or nuthin’, but no, not because delivering value is a bad thing but because for the most part, information technology doesn’t deliver value. It enables it.

You probably don’t remember, but we covered how to measure the value of an enabler back in 2003. To jog your memory, it went like this:

1. Calculate the total cost of every business process (TCBP) IT supports.

2. Design the best possible alternative processes (BPAP) that use no technology more complicated than a hand calculator.

3. BPAP — TCBP is the value provided by IT. (BPAP — TCBP)/TCBP is the return on IT investment — astronomical in nearly every case, I suspect, although possibly not as astronomical as actually going through the exercise.

It appears outcome metrics like cost and value won’t get us to where we need to go. How about something structural?

Start with the decisions application portfolio managers have to make (or, if they’re wiser, facilitate). Boil it all down and there are just two: (1) what is an application’s disposition — keep as is, extend and enhance, replace, retire, and so on — and (2) what is the priority for implementing these dispositions across the whole portfolio.

Disposition is a non-numeric metric — a metric in the same sense that “orange” is a metric. It depends on such factors as whether the application’s data are properly normalized, whether it’s built on company-standard platforms, and whether it’s a custom application when superior alternatives are now available in the marketplace.

Disposition is about what needs to be done. Priority is about when to do it. As such it depends on how big the risk is of not implementing the disposition, to what extent the application’s deficiencies impair business functioning, and, conversely, how big the opportunities are for implementing the dispositions … minus the disposition’s cost.

Priority, that is, is a reflection of each application’s health.

Which gets us to the point of this week’s exercise: Most of what an application portfolio manager needs to know to decide on dispositions and priorities is subjective. In some cases the needed measures are subjective because making them objective requires too much effort, like having to map business processes in detail to identify where applications cause process bottlenecks.

Sometimes they’re just subjective, as when the question is about the risk that an application vendor will lose its standing in the applications marketplace.

All of which gets us to this: “If you can’t measure you can’t manage” had better not be true, because as often as not managers can’t measure.

But they have to manage anyway.

Comments

|In: Architecture|Last Updated:

I’ve been heavily involved in application portfolio rationalization and management (APR and APM) over the past few years. They’re complex disciplines. As a consultant, I don’t mind a bit.

In case you aren’t familiar with APR and APM:

What’s the point? Rationalizing the applications portfolio accomplishes several useful results, among them identifying and making plans for dealing with: (1) unused applications that should be decommissioned; (2) weak applications that should be improved or replaced; (3) redundant applications that should be consolidated.

That’s APR. APM? The point of establishing an ongoing application portfolio management practice is to make sure the company doesn’t recreate the applications mess once the APR process has cleaned it up.

Why “portfolio”? APR and APM are built around the idea that your applications portfolio is analogous to an investment portfolio. The corporation invests in it and expects a return.

Also, like the funds and equities that make up a portfolio of financial investments, some applications are stronger than others. The mix continually shifts as time passes, and so, just as a fund manager sells weakening equities and buys newly promising ones, the application portfolio manager should constantly re-evaluate the applications that make up the company’s application investment portfolio.

It’s a persuasive argument, to the extent that arguing by analogy is ever persuasive. But it fails on three fronts (at least).

First, in a portfolio of financial investments, each individual holding has a market value that’s its only value. But in an application portfolio, holdings have value to the extent they support business capabilities, functions, processes, and practices.

Which means determining the financial value of an individual application is a challenging exercise in creative metrics. Unless some other topic distracts me, we’ll talk about this in more depth in future columns.

Second: The holdings that make up an investment portfolio are not dependent on each other. You can sell one without that sale having even a slight impact on the value of any of the others … unless, of course, you’re Warren Buffett and lots of other people pay attention to your investment decisions. (If you are Warren Buffett … call me.)

Where was I? That’s right: Independence. In an application portfolio, few “holdings” are entirely independent of other applications in the portfolio. You can’t just sell one that’s underperforming and expect everything else to seamlessly continue, nor can you add one without having to integrate it into others.

The Department of Redundancy and Duplication Department

Imagine you undertake a thorough APR assessment. Among the findings, you find seven different raw materials inventory management systems. Clearly, you need to establish a standard — either one of the seven, or an entirely new one — and consolidate.

Clearly, that is, until you take a closer look and realize each came along with one of seven business acquisitions that occurred over the past few years.

Consolidating inventory management systems means one of two alternatives — either standardizing the inventory management process across the seven independent business units that use them, or implementing an inventory management system that’s flexible enough to accommodate seven different ways of managing inventories.

Except that by the time you’ve achieved that level of flexibility the result might be just as difficult to support as, and far more disruptive than leaving the seven systems you have alone.

There’s no such thing as rationalizing the applications portfolio. My major premise is that there’s no such thing as an IT project. My minor premise is that rationalizing the applications portfolio would amount to chartering a bunch of IT projects. My conclusion: There’s no such thing as rationalizing the applications portfolio. Q.E.D.

Every single application in the portfolio is embedded in business functioning somewhere in the enterprise. Change any holding in the portfolio and you change how the business runs.

Oh, and, by the way, if you’re IT and want to rationalize the application portfolio, the portfolio changes had better result in more efficient and effective business functioning, because … aw, c’mon, you don’t need me to spell this out for you, do you?

Why not start with APM?

Here’s another binary choice in your APR/APM decision tree: You can rationalize the portfolio (APR) and then institute the means for preventing a recurrence of the problems you undertook the APR to solve (APM). Or, you can institute an APM practice and put it in charge of rationalizing the portfolio. It’s iterative and incremental APR.

APR first means documenting the current state, designing the desired future state, and planning a program to close the gap. APM first means constantly achieving better but never getting to best. But as the definition of “best” constantly changes, achieving it couldn’t be done anyway.

The KJR Conclusion: Better is better than best.

# # #

Do I have to say this? If you need help rationalizing your company’s applications portfolio, let’s talk. Because if you call anyone else you’ll hurt my feelings!

Comments