All Posts in Technology

|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: Architecture|Last Updated:

There are, according to the KJR Manifesto, no best practices, only practices that fit best.

More often than not, though, “best practice” refers to neither. Most so-called best practices are really no more than minimum standards of basic professionalism.

Take a situation I’ve run into several times over the past few years: Whether due to mergers, acquisitions, and divestitures, years of IT being stretched too tight, or just plain sloppy management, IT can’t produce an accurate business applications inventory.

Clearly these IT organizations aren’t in sync with “best practices,” which call for instituting:

  • PMO (Program Management Office): The body responsible for reviewing, approving, and tracking all IT-related projects. The PMO matters because it’s the projects it oversees that change the applications inventory.
  • CMDB (Configuration Management Database): A repository that keeps track of What’s Installed Where. Business applications are among the “configuration items” the CMDB keeps track of, along with every piece of real and virtual hardware, server OS instances, DBMS instances, development environments … every item IT has to keep up and running.
  • CAB (Change Advisory Board): The organization responsible for reviewing all “change requests” (read “installation requests”) to make sure development teams, IT infrastructure teams, and anyone else trying to change the IT production environment has dotted all requisite i’s and crossed all corresponding t’s. Also, for making sure someone updates the CMDB to reflect every change.
  • EAMS (Enterprise Architecture Management System): An information system that keeps track of … well, of all layers of the enterprise architecture, from hardware at the bottom to platforms layered on it, to information repositories, applications, and the business capabilities, functions, and processes that depend on them.
  • ARB (Architecture Review Board): Enterprise Architecture’s enforcement arm — the organization that reviews all IT-related plans to ensure they conform to the company’s technical standards. And, for making sure every change results in an update to the EAMS.
  • Forms: Lots of forms, to make sure each change consistently updates the CMDB, EAMS, and enterprise project portfolio to keep them consistent with one another. Or, as an alternative, application integration that makes sure an update to any of these systems synchronizes the others.
  • MA (Mandatory Arbitration): With three different committees, each responsible for finding flaws in the creative work of other people, do you think all parties will agree? Envision the oarsmen on a trireme with multiple captains directing them to row in different directions.

Forget (or at least delay) best practice. Achieving the minimum standard of basic professionalism in all this is more than ambitious enough. And that’s having a single, trustworthy application inventory. What it will take:

Count each application once. Is the application installed on multiple servers in multiple locations? Doesn’t matter. Count it once. Do you have separate Dev, Test, Prod, and possibly other intermediate instances? Doesn’t matter. Count it once.

Do you have multiple versions or releases installed? That does matter — count each of these as separate inventory entries.

Determine application granularity. If you, like most businesses, rely on large-scale suites to support major business domains (e.g. Workday for HR, Salesforce for CRM, SAP for ERP), the suites aren’t granular enough. Make each module an entry.

If your business is at the other granularity extreme, microservices are too granular to track in the inventory. Go up a level and track the applications microservices assemble into.

Manage app/platform dualities. To take an example, SharePoint is both an application and a platform for building applications. Track these uses separately.

Track the bare minimum. For each application track its name, version, product owner (or non-Agile equivalent), IT support lead, a brief description, and vendor. If you can’t easily implement the inventory on a spreadsheet you’re being too ambitious.

Related: If you find yourself tossing around terms like “metadata,” stop unless you’re planning on using an EAMS for the job. Don’t even daydream about metadata until you have an accurate inventory.

Survey the business. Ask each top-level executive this question: “What are the five applications your organization relies on the most? Please reply; also please forward this survey to your direct reports, asking them to respond and also to forward it to their direct reports.”

Use the results to validate your inventory, but be careful. Your business respondents might not use the same application names you used in your list.

Enlist the PMO and ARB. Ask them to let you know of any new applications being installed, updates to existing ones, and retirements.

And finally, instill in everyone the first rule of inventory management: What the inventory shows today will be wrong by this time tomorrow.

Comments