The Beginning (2)

Because we want our intelligence at our fingertips, easily accessible, we collect and store data in computer-based filing systems. In return for the convenience of this and not having to store mountains of virtually useless paper (the bigger the pile, the less useful), we have taken on the responsibility of hiring and working with various kinds of technology-savvy people.

At the foundation is the programmer, also called a developer or a software engineer. These are the people who actually create the scripts for the computer to execute. 20 years ago, programmers were visible to the rest of the organization. Today they are typically segregated and largely invisible except to the CIO.

These are the people who create the screen forms and buttons and functionality that your front line employees actually use to capture and look up information. In larger organizations today, the programmers do not create the filing system for data. Instead, that is designed and built by someone else (the data architect) and the programmer merely connects to it. The power that the programmer holds in terms of our four characteristics of good BI is the power to knowingly or unknowingly subvert the quality of our data.

This is a good time to introduce the concept of the data resource. It is essential that today's business view the data that is captured, modified, stored, retrieved and archived as a resource in the same way that capital is a resource or buildings and property is a resource or employees are a resource. The business must devote the same kind of attention to the data resource as it does to the financial resource of the company. Neglect or failure to do so will render the data resource valueless at best and a liability at worst. In between those two extremes, the business will experience increased costs as your workers struggle to get the quality they need from the data that feeds the processes they work within.

So the programmers who build screens and functionality that allow corruption into the data resource are slowly destroying the business just like termites in the framing of your house. It is vital, in order to end up with the BI we need, that programmers employ processes that are controlled for quality purposes. Employing process standards for programming will not guarantee that our four characteristics will be delivered, but NOT doing so will guarantee that we will never be able to produce the BI that we need.

Before we wrap up this installment, it's good to recognize that there are two kinds of programmers; those who work for you and those who work for someone else from whom you purchase or license the programs (or software or applications or systems or...). No business today is unaffected by programming.

When you are getting control of your processes and instituting quality assurance, you will want to ask the same questions of your software or application vendors. Today, they are often unwilling to talk about this and will use deflectors like "proprietary" to avoid the questions. You need to ask yourself whether you can bet your data resource on "proprietary."

We'll get into this a little deeper next time when we discuss the role of the data architect.