Companies taking risk with their own systems

computersystemOne would think that large companies with lots of money and lots of people and lots of systems would actually do something to mitigate the risk factors related to those critical company systems so absolutely necessary to run their businesses. But, don’t be fooled!

The fact is, there are companies out there that are creating risk for themselves! In a day and age when there are so many tech savvy people around, one could be excused for thinking that almost everyone knows of backing up systems, and probably more important than backing up, documenting systems!

You are probably thinking now that I have gone nuts! Documenting systems? You couldn’t imagine how important it is to have proper documentation for the systems that the company relies upon. Let me paint you a real life scenario about an international company with their own risk factors. This is a real life scenario, so I’ll change the name of the company to protect the guilty culprits! Let’s call this company, ACME Supplies Company.

acmelogoACME has a very small electronics and software development department, and this department consists of two software developers and one electronics developer. ACME is an international company, and these three guys basically have to develop and maintain hardware and software for three large divisions within ACME. So, what is the problem? Did I say that the two software developers are brand new at ACME? Both were employed at the same time.

Well, about six months ago the two previous software developers decided to resign and move elsewhere. It always makes one wonder when the two main players in a team jump ship at the same time! These two guys were in charge of developing software for these three divisions within ACME. This entailed the design and coding of the client UIs of three different software applications, with services running on a central server, all connected to several databases, some with many tables and hundreds of thousands of rows of data each! These systems keep track of all the company resources and assets via GPS and other means. That means, they’re crucial. Great!

The problem with ACME is that when the first two developers left, they left absolutely no documentation as to the design of any of these systems. I hope you can start seeing the risk now! There are no requirements specifications, no design specifications, no database design specifications, not even a diagram of sorts. That means, when the inevitable computer crash eventually comes, this company will sit with a big problem. What happens if the backups are no good? Is there anybody that would be able to piece this whole thing together, to make it work properly again?

Before the two new guys could bring anything meaningful to the table, they would have to wade through thousands of lines of code to familiarize themselves with these systems, since there just is no documentation! This could take months!

However, if ACME had done the development life cycle properly, from conception through implementation, maintenance would have been easy. No matter who you are, even if you are a software developing genius, it is still much easier and quicker to read human language than a programming language. Therefore, if these new programmers were given properly written requirements and design specifications, they would have been up and running with the maintenance of those critical systems within a very short period of time, compared to having to go through thousands of lines of code!

I remember back in the last millennium, joined a company that developed military systems. When I arrived there the first day, I was given a pile of documentation with everything about the systems I was going to work on, properly documented. Within only a few weeks, I became an active contributing member of the team, because I was able to pick up the background of the proposed system, the requirements and design. I also knew where I fit in, and what part I had to play.

In the end, companies put themselves at risk by not following tried and tested policies from the beginning. Sure, you may get short-term benefits for your company by skipping those pesky “unnecessary” steps and go straight to implementation, but in the long run, those short-term benefits will inevitably come back to haunt you! Shortcuts bring immediate gratification, but immediate gratification never lasts long, because as quickly as the gratification comes, it also dissipates. Therefore, companies should look at long-term benefits when thinking of creating systems for themselves, and not just on the quick fix.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: