Revenue Journal®

Having spent much of my career in the tech industry, I have a deep understanding of hardware, software, and networking. It comes in handy as I help company leaders improve their systems.

Over the last few years, I have become dismayed at how often I encounter top executives who do not understand the technology they depend on every day to run their businesses. Business has shifted from paper to digital, and yet many top execs don't understand what goes on in the "back end" of those systems. For example, I often encounter financial people - controllers and CFOs - who are put in charge of IT. But they don't understand how IT really works. This puts them, and their companies, at a distinct disadvantage:

1. They can't supervise and manage processes they don't understand.

2. IT people can - and often do - use executive ignorance as a way of inflating their own importance, and they often pretend that something is more difficult than it really is, to avoid having another project piled onto their already-overflowing plates.

Here's a typical scenario: I'm in a meeting with the IT people, the CFO, and the CEO. We have already identified a serious inefficiency, which needs to be fixed, and are now discussing how to improve the systems and processes so the problem will be solved. As we explore possible solutions, the usual reaction of the IT people is, "Nope, we can't do that." Or, "Sure, we could do that, but it will take six months." The top execs in the room accept these pronouncements. I don't. I start to diagram and drill down. "Here's how the data flows through the system now, right?" I will ask, and the IT people will nod. "And if we just add this one drop-down menu to this screen, and store the data here and export the data to here, won't that solve the problem? Couldn't a routine be written to accomplish this in less than an hour?" The IT people grudgingly agree.

I'm not bringing this up to brag. I'm bringing this up because any top exec should be able to do the same thing. But unless those execs take it upon themselves to understand the "back end" of their systems, they will remain at the mercy of the "that's too hard, it will cost too much, we can't possibly fix it in our lifetime" knee-jerk responses that they will always get from IT people.

The reason that IT people object is they are already working their tails off for bosses who make unreasonable demands because they don't understand what they are managing. IT people are constantly having to explain why something takes a long time or is complicated. A few sentences into their explanation, they can see the executives glazing over. They know that they are not communicating. The execs, who become lost in a sea of acronyms, can't help IT people make decisions.

Good managers help in two major ways: they prioritize work and they help staffers come up with better solutions to specific problems. Managers who are responsible for making IT decisions can't do either of these things if they don't understand IT.

Getting smart about IT

There are a number of books on the subject of IT management, including Making IT Work and The Executive's Guide to Information Technology. However, I find that it is not the details that get executives in trouble, but their basic ignorance of the component parts of IT systems, how they relate to each other, and what you can do - or can't do - with them. In other words, there is a big picture, a contextual framework, that is missing from their knowledge bank.

Given an understanding of the contextual framework, it is possible to diagram and discuss the specifics within that framework, and then make intelligent decisions. Everyone can agree on what the problems are, what is at stake, what is possible, and what should be done.

I'm going to sketch out that contextual framework in this article. We'll focus on the four basic building blocks of all IT systems: input, storage, manipulation, and output. Once you understand these building blocks, you can have intelligent conversations with your IT people, using these building blocks as a basis for your discussions.

INPUT

All interactive systems depend on input. Data must be entered or imported into forms. Application programs have evolved from mainframe-based systems, to PC-based systems, to server- and browser-based systems. Many companies are now building web-based "front ends" for their existing "back end" systems. Their applications reside on a server and are accessed via a web browser.

Input in the web-based world is driven by navigation conventions. People expect web-based apps to behave in the usual way. They expect to be able to click on live items, select from drop-down menus, make selections using radio buttons, fill out forms, and send the form to the server using a submit button. Thanks to new programming languages such as AJAX, which helps to speed the interaction between the application and the web server, web apps are becoming as fast as PC-based applications. Google's Docs & Spreadsheets is a great example of a web-based application that looks and behaves as a PC application would.

Data can be entered by a live person or imported from another application or system. If you need to bring in data from another system, you have to understand where the data are presently stored and write instructions that identify the source of each piece of data and the intended destination for that data. Writing the code to move data around can only take place after you have "mapped" all of the data, determining where the data reside, what the data are called, what the data consist of, and where the data should go. This can be a time-consuming and error-prone process because you have to untangle the difficult dialects used to identify certain types of data. "Invoices" might be called "invoices" in one system and be contained in "receivables" in another.

Each discipline in business has its own technical jargon. If you ask IT people to map these data, you will end up with a very big mess. Accounting people should help IT people map accounting systems; marketing experts should help IT people map marketing systems, and so forth.

STORAGE

Data brought into the system must be stored. We all know about physical storage - hard drives, chips, and the like. Decisions about these hardware devices are pretty easy to make; you know what kind of storage you're using now, you can usually predict how your storage needs will change over time, and you make sure you always have enough. A good rule of thumb is to buy 4x the amount you think you need. You'll still grow out of it.

On the software side of data storage, we have databases. This is where I find the most ignorance. All databases operate basically the same way. It helps to think of the database as you would a paper-based system. The blank input form is referred to as a template; the individual blank lines on the form are fields; and a single filled-in form is a record. A record can contain any number of fields, restricted only by the limits of the database program you're using. It's relatively easy to add a new field to a blank template, but it is dangerous to remove fields from the template without first investigating what that field contains and how that data are used throughout the system.

When you combine the data in one database with the data in another, you need to know the names of the fields and what the fields contain. You also need to know the characteristics assigned to the fields. These characteristics go beyond the name of the field (e.g. "last name"). The last name field might only accept 24 characters, for example. This is a characteristic of the field. Or, a field containing a number could be characterized as a "US dollars" field.

Characteristics of data are called "metadata" which means information about the data. An example of metadata can be found in the marketing and sales sections of IBM's business partner portal, which I recently redesigned. These sections contain selling and marketing pieces, including brochures, data sheets, presentations, etc. These pieces are stored as documents. Each document has its own metadata, such as "document type," "product," "language," "audience," "length," etc.

Using these descriptors, IBM's business partners can search for certain types of documents selling a specific product, written in a particular language and aimed at a specific audience. The search function does not look within the document for key words, but instead uses the metatags - the document's characteristics - to provide quick, accurate search results.

It's helpful to enter all the fields and their characteristics into a spreadsheet, and include the sources and destinations of the data. Everyone understands spreadsheets, and it's a great way to make sense out of what appears to be chaos.

MANIPULATION

Once the data have been entered into a system, you will want to do things with it. You'll want to go get it, analyze it, check it, combine it in different ways, perform calculations, and create reports (which, it should be noted, are "output"). Data manipulation is the most complex aspect of what IT people do. They use a variety of languages and tools to write the code that manipulates data in the desired way.

IT people will cringe at what I am going to say next - because it is a gross simplification of a very complex process - but all data manipulation does the same thing: it identifies the data required to perform an action, and then describes how that action should take place. Your job as a manager is not to understand the arcane details of how the programming occurs, but to thoroughly understand which data will be required and what actions should be taken with that data.

OUTPUT

When we think of output, we often think of reports. There are other types of output: results of a search, data that are used in the manipulation of other data, and transactional paperwork (such as invoices, checks, packing slips, bills of lading, etc.). Proper output is usable by the recipient, whether it is a human being or another system. This is obvious, but seldom done well. Creating good output begins with an analysis of the people or systems that will be using the output, and an analysis of how the data will be manipulated to generate the output.

That's an overview of the four main components of IT.

Next time you're in a room with your IT people trying to solve a problem, remember these four building blocks: Input, storage, manipulation, and output. When you start to diagram a process with your IT folks, the conversation will be much more constructive if you write these four words on a whiteboard, treating them as section headers for the process you're diagramming. IT people will find this a bit tedious, but the section framework diagram will be very useful as you untangle the realities of the problem and possible solutions. And it will keep you from getting too bogged down in acronym soup.

------------------

Note 1: I did not include "networks" in this article because it's an enormous subject all by itself. I once wrote a "LAN to WAN Guide" for a client. Even though I was only focusing on basic concepts and systems, it was still 60 pages long.

Note 2: Yes, the word "data" is plural. Always seems awkward, but it's technically correct. If you really want to impress your IT people, that's how you'll use the word. On the other hand, the Oxford Dictionary says: "Strictly speaking, data is the plural of datum, and should be used with a plural verb (like facts). However, there has been a growing tendency to use it as an equivalent to the uncountable noun information, followed by a singular verb. This is now regarded as generally acceptable in American use, and in the context of information technology. The traditional usage is still preferable, at least in Britain, but it may soon become a lost cause."