Appreciating The Hidden Value in Amateur IT Systems

There is an odd little trope in the world of business IT systems in the shape of home-grown systems that are built by people who are rank-amateurs. These systems offer a curious value to the business – often *enormous*, untapped value to the business – but also carry some weird risk points.

A business that is now well established having been founded 20 years ago can be a pretty large business. An oddity about IT functions within businesses is that very small businesses almost never have an IT function, but very large businesses almost always do. There is a common development point (a bit like an “IT adolescence”) where the business crosses from one mode to the other – a common way to do this these days is to bring in some sort of outsourced IT.

We live now in an era where IT is more accessible, but I would say also less creative. Modern businesses are much more amenable to buying systems (there are more of them, they are much cheaper and easier to buy than before), but they don’t integrate them. Older businesses, when thinking about their IT needs 10-20 years ago were more inclined to build something from scratch.

These in-house bespoke systems are now quite weird, because they were built by people with no IT experience, but they are to all intents and purposes actual, proper software. The reason why this is relevant today is that these systems developed one or two decades ago are still operationally important within the business.

One of the huge advantages of bespoke software is that, like a bespoke suit, it is custom made and fit to the business. When bought from a specialist provider, that provider will come into the business, learn about what the business does and what needs it has, and design a specific solution to fit. These days we tend to do this by having a core off-the-shelf system, with bespoke parts that are then customised as a type of hybrid compromise.

When this was done by an amateur inside the business, the person who started it was likely very *au fait* with the operational imperatives of the business. These efforts were usually self-started *and* homegrown, meaning that usually the individual would find innovate their own solution to a perceived business need. They also would have “lived in” the business for a long time. As a result, we’d find a solution where the “business analyst” part was superb, but the construction quality was relatively poor. Compare that to having an external company come in and do it – you end up with average-to-good analysis and average-to-good construction.

You can factor in survivorship bias here – we’re only talking about systems that are still in use. Anything worse that superb analysis on the homegrown system, it would not be used. Anything worse that average-to-good analysis or construction on the external provider’s system, that also would not be used.

Now that we have a 20-year-old legacy system, built by a rank amateur, we have a number of problems.

Firstly, the construction of these systems tends to be horrible. That tends to make them unmaintainable, especially if they are built on a platform that has become as unfashionable as Global Hypercolor t-shirts. (They still make PowerBuilder, for example.) There are also usually manifest issues in things like not having separated live and development environments, issues around planned change management, etc.

Secondly, the integration methods tend to be equally horrible. Usually, the only way that you can integrate with them is to talk directly to the database – effectively resulting in two parallel systems, with no way of controlling change in the original.

Thirdly, and this is the big one, and perhaps unexpected – the business tends not to see the value in them. (This is not helped by the fact these systems tend to look bad from an interface perspective.) What the business often does not see is how in these systems that have grown up with the business, they end up being exactly “mated” to that business. They become an almost pure expression of the business needs, expressed as software code.

It's notionally similar to the idea that the couple that met in school at 15 who remain happily married 40 years later did so partly because their personalities developed as a matched pair, fitting into each other. As the business grew, the software system changed – and vice versa, what the software system could or could not do (or could or could not be made to do),

Now when the business is looking at it’s IT and wants a new system, the risk is that this homegrown system is not properly “mined” for value. That software likely expresses the business’ needs better than a phalanx of external business analysis could come up in a century of day rates.

However, those systems likely do need to be replaced. They are unstable foundations in that their ropey construction does create a risk base that needs to be managed out. (Even if there are no terribly apparent risks, it’s not safe to have the business depend on a system that cannot be maintained.) The trick then is to do so in a way where you don’t throw the baby out with the bathwater. You have 10-20 years of business analysis “learns” in that system, after all.