Originally published August 7, 2008
In years past, we didn’t have to worry about information agility. There was such a scant amount of information prior to the computer that information agility was simply not an issue. Then came the computer and information spewed out everywhere. Soon, we were awash in information.
At first, people were in awe of the volumes of information and its diversity. But very quickly, people were dissatisfied. It was like a man in the desert dying of thirst. He is rescued, and someone hands him a canteen. He gulps down the contents of the canteen and then demands to know why there isn’t chilled Chardonnay.
As soon as there was a flow of information, people began to discover the possibilities of information. They began to change their priorities and want all sorts of permutations. That’s when people discovered that it is one thing to get information and another to change information. People quickly discovered that information agility was what they really wanted.
Information agility is a multi-faceted subject. There are as many facets to information agility as there are facets on a bride’s new diamond.
One of those facets is the presentation of data. We don’t want to just look at data one way. We want to look at data in many ways. We want to look at lists, exceptions, summaries and detail. We want to look at visualizations. We want to look at information over time. In fact, there are an almost infinite variety of ways in which we want to look at information.
Business intelligence (BI) vendors have discovered this. BI tools today are sophisticated tools that present data in many ways. One user can look at the data one way, and another user can look at the data another way. There is agility in the presentation of data, and that is a first important step to take in the creation of the agile information environment. But presentation of information is only the first step in the creation of information agility.
The agility of presentation is like the many dressings a tree can wear. In the spring, trees are green and full of leaves. In the fall, trees are multicolored. In the winter, trees are decked out with snow. In the spring, trees have their blooms again in the age-old cycle of reproduction. There are many superficial dressings the tree can wear, but at the end of the day, the tree is simply the same tree, rooted in the same place and casting the same shade. No one would call a tree agile. Dressing the tree up with many different variations does not change the basic nature of the tree.
The second aspect of information agility is that of the granularity of the information that is at the root of the presentations of the information. If the basic core of data is summarized and aggregated, then the data is not agile. The data can be used for one or two forms of presentation. But when someone wants to take a very different look at the data, the data must undergo a fundamental transformation.
As a simple example, suppose someone wants to look at data that has been gathered on a weekly basis. The person, however, wants to look at the data daily. Once data has been gathered and summarized on a weekly basis, there is no way to go back and break that data down by day unless the granular data has been saved. Stated differently, if data has been gathered on a weekly basis and the foundation data that goes into the summarization has been discarded, there is no rational way to go back and restate the weekly data on a daily basis.
In order to create an agile foundation of data, data must be stored at the most granular level. When data is stored at the most granular level, then the data can support many different views of the same data. Indeed, the data can be used to support unknown views of data that have yet to be discovered – such is the flexibility of granular data.
Presentation then is the first facet of agility, and granularity of data is the second facet of information agility. But there is a third facet to information agility.
Traditionally, when information systems have been built, the assumption by the designer is that the requirements are cast in concrete. Indeed, popular methodologies spend a great deal of time gathering requirements. Once the requirements are gathered, the system design is created. When you design a database, the assumption is that the requirements are known. The database vendor gives you exactly one way to define how you want the data to be shaped.
Then you start to write programs. The program supports exactly one algorithm, or way in which data is to be processed. Throughout the development life cycle, the assumption is that there is a single way to do things.
But in life, requirements change. It is said that there are two sure things in life – death and taxes. We should add a third certainty, and that certainty is that requirements will change given enough time. Stated differently, all requirements change over time. The only difference between the requirements for one company and the next is the rate of change. Some requirements change slowly. Other requirements change quickly. But, given enough time, all requirements will change.
And what happens when requirements change? The single database design is inadequate. The single algorithm found in the programs is inadequate. Throughout the development process, all the decisions that were made have to be revisited.
This is like taking a tree by the roots and moving it 50 miles. Trees just do not lend themselves to uprooting and transplant. It is expensive and it is cumbersome to go about uprooting a few trees, much less a forest.
Fortunately there are new technologies in the marketplace such as Kalido and BIReady that are designed to accommodate these fundamental uprootings.
Recent articles by Bill Inmon