All Posts in Strategy and Tactics

|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

|In: Strategy and Tactics|Last Updated:

Businesses that adopt Agile often miss out.

Don’t misunderstand. I’m all in favor of Agile development, although I’m less than sanguine about its ongoing evolution from simplicity and charm to complexity and excessive proceduralization.

But the missing out comes from a failure to recognize what Agile isn’t, namely, it isn’t limited to application development. Agile is a way of thinking, not a series of steps. And its way of thinking applies to any situation where an organization needs to address some set of problems and opportunities with a design and a plan, but the problems and opportunities are deeply fluid.

And oh, by the way, those whose opinions about the problems and solutions govern decisions are in flux as well.

Start by imagining, just hypothetically you understand, your boss calls on you to charter and launch a new department. It will be called the Math Department and its purpose is to solve math problems for the rest of the enterprise.

Any and all math problems.

Tell her when you’ve finished the assignment.

Hoo Hah! Say what?

Further imagine your professional career began in IT, where you were schooled in Waterfall methodologies.

And … you’re doomed.

To design the Math Department you need to understand Math. Which you start out to do, reading everything you can get your hands on about Math.

But the more you learn about Math, the more branches of mathematics you learn about. The subject is, as Einstein … using math, by the way … pointed out about the universe, finite but unbounded. So you go back to your manager, explain the impossibility of carrying out your assignment, polish your resume, and don’t look back.

Or, you could apply Agile methods.

You’d start with a few Epics … say, basic arithmetic, algebra, and trigonometry. These would comprise your initial Backlog.

You’d then take the simplest and, happily, most needed of the Epics from the Backlog … arithmetic … write user stories (yes, you could turn story problems into user stories), and write a position description to hire someone who can solve all the user stories. Which is how you come to hire Michael Vincent Peterson. You nickname him MVP (did I really need to spell this out?) and the Math Department is off and running.

Well, walking anyway.

Once Arithmetic Services is stable (are stable? No, it’s a thing — “is stable”) you follow the same pattern for algebra, and follow that pattern for trig.

It’s right about here you discover that just having experts isn’t enough. The Math Department has become popular enough that it needs some level of management — enough to decide how to process requests and set priorities. How should you handle this?

The same way: You add an Epic to the Backlog, this one for designing and implementing Mathmanagement (catchy, eh?), just as you’d do if one of your executives came along to tell you he needs the Math Department to handle differential calculus.

If you boil Agile down to its essentials, you’ll find principles you can apply to a whole lot more than application development, for example, the principle that there’s little point spending time designing solutions you won’t be in a position to implement before they become irrelevant.

So the moral of this story is that more often than not, businesses can achieve important large-scale change one small change increment at a time. And they can do so with far less disruption and risk than trying to design a comprehensive solution.

Which gets us to two consequential and immutable universal laws. The first, articulated by my college roommate Jack Buckmiller states, “If a meal takes longer to cook than it takes to eat, you’ve done something terribly wrong.”

Add Lewis’s corollary: “Buckmiller’s Law only counts the time I spend cooking a meal, not the time someone else spends making one for me.”

I’m pretty sure these are relevant to the subject at hand. You’re welcome to disagree.

In any event, a second, contemporaneous but somewhat better known rule is Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” (John Gall, Systemantics: How Systems Really Work and How They Fail (1975))

To which I suppose we should add one more non-business-derived business principle. It’s something I learned in Driver’s Ed: Don’t over-drive your lights.

Comments