Is your enterprise carrying a whopping pile of debt thanks to your previous IT decisions?
Most executives I meet can’t answer that question. They might look to see how much depreciation they’re carrying at the moment, or how many years into the future they’ve contracted away. Few look at the real debt.
Butcher a piece of packaged software with code modifications, and you’ve taken on a whopping pile of debt.
We don’t think of it that way, of course. We think of it as (let’s say) a $10 million project to produce a new system. But if $3 million went into the licence and infrastructure, $1 million into the implementation costs, and $6 million into the modifications (to adapt the package to “suit the business”), you just took on a minimum of $6 million of debt.
Or did you think that, when the vendor withdraws support for that version and you’re forced to upgrade it, you were going to get away with anything less to retrofit all those mods into the new version of the product you chose?
In fact, the problem will be worse, and not just because the passage of years drives wages and contractors’ fees up.
Much like a piece of software you wrote in house, modifications introduce convolutions that increase testing, debugging, and make the process of delivering new function take longer. Few of us are so rigorous that we have iron-clad documentation and crisp, clean, clear paths through the code in anything in our portfolio.
About six years ago a Canadian financial services company undertook to extract itself from the debt problem built up on just one of its packages (its ERP system). Three years and multiple millions later, all the mods were either gone — the business changed, not the software — or the functions were in separate modules written in-house that worked with a pristine package core.
Since then, it’s been able to deliver many new systems against that base, while taking advantage of every new release issued by the package vendor and its new features. Having come from a release frozen in time for a decade, that’s quite an improvement.
There was no free lunch in the change-over — but when your delivery cycle for new systems falls from years to weeks, you get a solution that can easily be shifted to a hybrid cloud to provide for continuous operations and a flexible cost of infrastructure, and you’re getting value for money on the maintenance front (since you can capture all new vendor enhancements), a lot of problems melt away.
Much of that stems from the Y2K rush to completion. The hard deadline of “implementation must be complete before the end of 1999” meant that not many shops stood their ground on package modification. The bad habit of “the answer is a package no matter what the problem” coupled with “the package will be changed, not the business” adopted then has persisted even though the 21st century ought to have been the time where we cleaned up all the debt we took on in the 1990s.
Fourteen years later, most of us haven’t started. Still, this isn’t going to get better on its own. Like it or not, this wrenching cultural shift — both in IT and in the user community — and finding the money and resources to restructure your base is why you have the big corner office, the title, and the pay packet as an IT executive.
It’s easy to talk about the virtue of managed cloud services, the flexibility of “just in time” infrastructure, the ability to adjust to demand of message-passing instantiations of processing nodes, the addition of the data flows to and from an Internet of Things, and a hundred others exploitations of technology. Trying to slam all that onto a debt-ridden, chaotic base simply means you’ll deliver far more slowly, at far higher cost, than the enterprise can sustain to retain its profitability and market position.
In other words, overcoming the debt issue in your portfolio is this generation’s equivalent of the Y2K problem. The deadline isn’t a calendar date, though: it’s the point at which your employer becomes terminally non-competitive thanks to being let down by its IT solutions.
Given that in three more cold wintry weeks baseball players will be reporting to spring training camps, it’s fair to use a sporting analogy. Between your backlog of requests, your need to make sure you meet customer needs, and the debts you’re carrying, your bases are now loaded.
It’s time to bat cleanup — and clear the bases. Go for the home run of cleaning up your portfolio.
Seven steps to software security
After a decade of news detailing countless successful cyber-attacks, it's hard to imagine a corporation not understanding they need a software security solution. Unlike implementing software quality assurance, the processes that go into making applications more secure are still relatively immature. As well, ownership for the security of software in an organization is not always consistent or clear.