Many IT professionals believe innovation in IT pays for itself. But a surprising number of companies I visit aren’t in a position to prove this hypothesis. They typically don’t know what it costs to provide their IT services and can’t quite put a figure on the benefits of IT innovation projects. Without these key data points, they have a hard time quantifying the ROI or payback on any IT project—making it difficult for IT to compete internally with other departments for scarce business funding.
The rest has many considerations for planning our ROI, plus contingencies to muck about with.
For much more detail, see Mindy Cancila’s write-up over at Gartner from earlier this year.
Elisabeth Greenbaum Kasson asked me recently for advice on working with legacy applications. Check out her piece on it. Here’s the full reply I sent to her in email:
– The steps someone could take to get themselves up to speed on their employer’s legacy software.
– How this knowledge can make them indispensable (I know that term is relative)
– Why this type of expertise is so necessary, especially when it comes to integrating said software with new and/or evolving products.
When it comes to “dealing with legacy,” there aren’t that many good options. We often think of “legacy” as software that must be changed but that we’re afraid to change. If you’re not afraid to change it, you often just think of it as “our software.” Legacy has this connotation of it being risky, scary, or maybe just boring.
If someone wants to go down into the mines of legacy management, the first thing I’d recommend is doing some history work to find out why the legacy system in question was created, what it’s currently used for, and, hopefully, who the current stake-holders/owners are. You’d be surprised – or maybe not! – how often some or all three of those are totally unknown: with unknown stake-holders, I sometimes hear tale stories of IT departments just shutting down systems and waiting to see who calls them.
Understanding the why, what, and who of a legacy system will tell you most of what you need to know when it comes to managing it. Further up the management chain, having a good grasp of and on portfolio management is valuable. Given the why, what, and who, you should be able to prioritize any given “legacy application” relative to another with respect to funding and attention. Is fixing the application that’s used to schedule office party birthday cake orders more important than the application used to re-order plungers for the warehouse bathrooms? You won’t know between cakes or plungers if you don’t do portfolio management.
The other aspect is simply learning the technologies you need – operationally, programming, and sometimes physical management – to keep the thing up and running and to modify it. This might mean learning, for example, about operating systems for mainframes, AS/400, UNIX, older versions of Windows, and sometimes even exotic things like OS/2. There’s dozens of programming languages out there, and you’ll need to learn not only the appropriate “old” language, but how the build, version control, and project management tools around those old stacks function.
For more, I wrote about dealing with legacy in my cloud native journey booklet last year.
Instead, it has created a great divide, said Pucciarelli. “This siloed, divided approach brings frustration, disappointment and failure in multiple ways.” For one thing, it doesn’t support healthy team spirit, he said, and the innovation side tends to operate fast to deliver business solutions without the accountability around reliability, quality and security that is expected from the traditional IT side. “It leads to redundancy and inefficiency.”