Making the case for modernizing the IT portfolio is a lot like making the case for changing the oil in your car. The case in favor: If you don’t do it, eventually the engine will burn out.
But the ROI for doing it right now? It’s an actuarial problem. Delay modernization today and there’s a statistical certainty that bad karma will follow. But when that risk will become reality is uncertain, too.
So, depending on how long you plan to sit in the CIO chair, you might not need what follows. You can just kick the proverbial can down the metaphorical road, saving the joy for your successor.
Step 1: Document what you have
Modernizing begins with knowing what you have. It’s all supposed to be kept in a carefully groomed and governed CMDB (configuration management database for the non-ITSM-aware). Over the years I’ve asked numerous clients to show me what they have. So far my search for a reliable, up-to-date CMDB has made me feel like a silicon cryptobiologist, hunting in vain for the IT equivalent to the Loch Ness Monster.
What you need first, to avoid joining the ranks of us IT cryptobiologists, is a list of the applications that IT supports, along with the technology stack — the business architecture it supports plus the repositories, integrations, platforms, infrastructure, and facilities each application relies on.
Step 2: Disposition your IT assets
Dispositioning involves deciding on the future state of each item you’ve just documented — its disposition. Start by homing in on a highly deficient application. This drives business benefit on the grounds that if it didn’t, the item wouldn’t be deficient.
You have eight dispositions to choose from:
- Extend: Invest in the item to increase the value it delivers.
- Retain: Keep the item, but only apply the minimum maintenance necessary to keep it functioning.
- Update: For commercial applications, move them to within one version of what the vendor considers current.
- Replace: Implement a commercially available alternative that provides at least the same functionality, or, ideally, the same functionality and more so. As an alternative you might decide to custom-code a replacement, but for most IT shops, most of the time, “buy when you can, build when you have to” is a core architectural principle that’s not to be trifled with.
- Modernize: Refactor the application so it conforms to modern architectural and engineering standards and practices.
- Replatform: Recompile to a lower-cost environment. That’s recompile as in keeping COBOL apps in COBOL, but in a version that runs on a more desirable platform, for example from Z/OS to, say, RHEL 10. But be alert to replatforming’s limitations: Many IT shops “lift-and-shifted” applications to new platforms, only to find that lifting and shifting didn’t in any way modernize.
- Consolidate: For situations where multiple applications provide redundant business functionality, set one as the enterprise standard and migrate the rest to it.
- Retire: For an application that isn’t needed any more, archive its data and decommission it. Just make sure nobody is using it when nobody else is looking.
Step 3: Beware interdependencies and ripple effects
Establishing the disposition for one application is rarely enough. Changing an application’s disposition will likely force disposition changes elsewhere, in other applications, and in its technical stack, especially in the platforms it relies on.
And it’s a near certainty that any change to a business-facing application will affect other applications, and will break one or more integrations besides. Which brings us to …
Step 4: Integrations
Integrations are a special case of the application portfolio. They’re often custom-coded, frequently fragile, relatively unstable, and hard to validate once broken and repaired.
Especially, integrations are vulnerable to conflicting semantics. For example, one CRM package might define “customer” as a person, a second might define it as a household, a third as a corporation, and a fourth as a client corporation’s primary point of contact. Synchronizing their databases is, to say the least, tricky.
And then, the business strategy changes, from concentrating on retail sales to individuals, to a wholesale business model.
Step 5: Execute the plan — even if it requires torching most of the stack
Everything we’ve covered this month and last is just a framework — a way of keeping track of all the hard work that will be necessary to keep the multilayered IT portfolio, if not modern, then at least modern enough.
Actually pulling together enough staff and the right staff to modernize everything that needs modernizing will prove to be a daunting proposition. Which leads to the least joyful aspect of the situation: Once an IT portfolio reaches a certain level of obsolescence, ripping everything out and starting over starts to look more appealing than remediating what’s there.
Maybe a CIO will get lucky and the state of the art will develop so well that the resident AI can reverse-engineer the whole IT production environment.
Failing that, replacing the whole portfolio with a small number of comprehensive enterprise application suites — think ERP, CRM, and packages of similar size and scope, leading to most application dispositions flipping to Consolidate — might prove more practical and economical than trying to fix things piecemeal.
It might not sound like a good plan, but as Tony Mendez said in Argo, it might be the best bad plan you have.
See also:
Read More from This Article: Modernizing the IT portfolio: A primer
Source: News