Strategic Technology

For all SME executives (and IT Teams) an excellent article by Eric Brown titled; Application Modernization – Replace, Rewrite or Replumb?

I urge you to read that article, Mr. Brown explicitly demonstrates and defines the decisions we need to make when looking at our technology systems. Specifically, (as Mr. Brown’s title suggests) the tough decisions on fixing versus replacing old software or IT systems.

For this post I wanted to pull out one small tidbit;

The AAR systems had both languished in disrepair for years with hacks upon hacks added to each to add new functionality and make the system work.

Defining ‘Hack’

The term ‘hack’, and of course ‘hacker’ has become a pop culture term meaning the typical bad guys stealing your private information, writing viruses, and all of the other nasty stuff that make our computer lives difficult.

In the technology world however, it has a couple of  alternate definitions, and one simply meaning the quick and dirty doing what is necessary to get the job done.

As a physical example, imagine that you want to move a ceiling light 4 feet in your kitchen. Rewiring the complete light to the new location is one thing. Using electrical tape and wire connectors to ‘bandage’ on that extra 4 feet of copper wire is a hack. (A risky one too)

First, as I will demonstrate below – a ‘hack’ is not necessarily a negative thing on its own, but when they get out of control – and worse, when the reason why it was made was never written down, you get ugly bandages of software attempting to keep things running. This is not just a big business problem, it can be worse in smaller businesses. You may use a tool such as Salesforce.com, if you are a slightly larger organization, perhaps some accounting, planning, or manufacturing tools such as Dynamics  (among many other possibilities).

And let me put it bluntly. Many small to medium business technology teams make decisions in ad-hoc formats, and consider actually writing things down to be just as much fun as a root canal.

Your first step should be guidelines on how modifications to IT systems are made, and second? Yes. Write the bloody reasons for that decision down, along with detail of the modifications. (I will state the ‘why’ in a minute)

Consider this example.

Years ago I worked with a business that purchased a type of software tool. (And here is how quickly not following those guidelines can create problems down the road)

We bought that software from a company in the United States. And our business was Canadian.

Simply enough – we don’t have ‘States’ or ‘ZIP Codes’. (As a side note, over the intervening decade, vendors have gotten better at supporting both with State/Province)

So the team modified ‘State’ to ‘Province’ and ‘Zip’ to ‘Postal Code’ within its database and application screens.

Simple!

Until the first invoice was generated from the system. State and Zip not there? software died.

Hack! Modify the invoicing piece of the system to use ‘Province’ and ‘Postal Code’

Simple!

Until the first management report on regional activity. Canadian Postal Codes can contain letters. Software died!

Hack! You get the idea.

Earlier I stated I would answer the ‘why’ question about these type of hacks.

Imagine a year or so later, version 2.0 of that product comes out. How will the upgrade go? My guess is that it will probably not work at all from those ‘hacks’. The worst part is that no one will understand why because they aren’t written down.

The SMB Takeaway

I realize that this example is fairly simplistic, but if you are a CFO, COO or General Manager responsible for IT, I hope it demonstrates that allowing ad-hoc and undocumented modifications will cause problems. Maybe not today, or even next year. But they will eventually.

Understand the risks, ensure you have guidelines, and most definitely, ensure that it is documented.

As another note – we are currently dealing with a system of our own that sounds like the twin brother of the subject used in Mr. Brown’s article. But that is for another time……