Page Links

	What the IT Industry Has Never Understood

 

Providing business what it really needs comes not from IT experience but from overcoming IT experience.

 

Information concepts have evolved intuitively across centuries.  Despite computers, they still assume and are based on pencil and paper technology ... as though, strategically, the computer does not exist.  Despite some benefits, automating these concepts also automates pencil and paper incapabilities, clouds our understanding of information, and leads us to presume knowledge we have neither developed nor applied to information management.  

 

 

To develop effective information management we must first

recognize that conventional information technology isn't it.

 

 

Page Contents A False Discipline What we don't understand because we don't understand information. The I.T. Penalty. The costs and consequences of not understanding information. Accounting Systems Legacy practices that are based on and, in concept, still assume we're using quill pen and ruled ledgers. CRM, ERP, SAP Partial solutions that obstruct whole solutions. Databases and Spreadsheets Automating pencil and paper instead of information. Word Processing Making it pretty but not informative. Operating Systems Making how technology works more important than how information works. Enterprise Modeling Expediting the problem. Information Architecture Re-designing what already exists naturally. Normalization Force-fitting function to follow (third normal) form to justify foregone conclusions. Object Orientation Assuming an implementation tactic makes up for the lack of an effective Information strategy. System Development Planning the least benefits at the highest cost. Data Mining Gold or fools gold?

 

 

 

A False Discipline.

Understanding technology does nothing to help us understand information.  The assumption that it does obstructs real comprehension. Knowing information is not the same as knowing about information (anymore than "knowing" air by breathing qualifies someone as an aeronautics engineer). Skill with information has NEVER been a requirement for planning information systems. Well over half of information management costs are due, not to how we use computers, but to how we fail to use information. Information technology is what we do, not to manage information, but because we DON'T manage information.

IT products and practices have never been tested as to whether they constitute good information management (they do not). IT perspectives are quaintly naive, having more in common with alchemy or flat-earth thinking than with managing information effectively. IT practitioners are unwittingly trained to expedite information problems, not to solve them The IT industry relies on poor information management to justify its products and practices.

 

Accounting Systems

 

 

Accounting concepts were developed in the 16th century to compensate for pencil and paper limitations.  Automating these practices automates the limitations, not information.

 

Accounting keeps track, not of business, but of the financial consequences of doing business.  It deals in secondary, not primary information ... in effect, not cause ... in shadow, not substance.  The point of accounting rules is to provide a prescribed set of secondary (financial) consequences for every business without having to know the primary details ... the substance ... of any business. Information about substance, even when known to an accounting system user, is routinely, almost aggressively, excluded from proper information management. 

 

When primary information is properly managed
accounting is a side-effect, not a system.

Automating pencil and paper accounting practices is like replacing a horse with a car and then hitching the car to a covered wagon: efficiency improves but we are still constrained by covered wagon limitations. Properly managed primary information provides better and more comprehensive "accounting" results than the most rigorous pencil-and-paper automating accounting system can ever hope to achieve.

 

 

The information content of an organization is a cohesive whole.  Information is intrinsically and naturally integrated. This cohesive whole is the common denominator of all would-be information management systems. Conventional systems, however, don't fit together as part of a cohesive whole.

 

The conventional IT perspective is very like the six blind men who, upon encountering an elephant, cannot agree on what they have found.  One, touching the elephant's side, perceives a wall.  Another sees the trunk as a snake.  For others the ear is a fan, the leg a tree, the tusk a spear, and the last thinks the tail is a rope.  Their perceptions are irrational ... contrary to reality.  None sees the cohesive whole.

 

The first decision made about a system is what part of the whole the system will be about. By narrowing the focus there is no intent or interest in assuring that information managed will be usefully available for all the purposes to which it could apply.   By their very nature, conventional systems dis-integrate information.  Though useful in specific and limited ways, they are inherently irrational.

 

If systems based on the same cohesive whole were rational it would be impossible for them not to integrate with each other.   The fact that we suffer multiple systems that don't intrinsically integrate (CRM, ERP, SAP, Accounting, Inventory, payroll, personnel, order processing, etc., etc.) actually proves the point of irrational systems ... of blind men with elephants. 

Due to lack of knowledge about information, the IT industry has never created rational systems, dis-integrating rather than integrating information.

This problem self-perpetuates because far more effort is spent making business conform to systems than in making systems conform to business ... a problem that predates the invention of computers.  This increases the unreality of systems and makes it extraordinarily difficult to know when systems are truly about business or if, at heart, they are just another struggle with information dis-integration.     

 

 

 

Information functions in four dimensions, not just the two, row/column dimensions imposed by pencil and paper and mimicked by databases and spreadsheets. The terms "row" and "column" describe how we organize data on paper; not how information applies to and what it means in the real world.  Row/column describe media form (e.g. paper, discs, etc.), not information function. 

 

The two missing dimensions are information chronologies, telling about and distinguishing between when something happened and when we found out about it.  Replacing databases (and spreadsheets) with "information" bases requires making sure "rows" and "columns" are appropriately meaningful and chronologged as things change over time. 

Conventional systems are only necessary to compensate for the failure of databases to manage information in all four dimensions. 

 

 

 

Word processing provides for the cosmetic organization and presentation of data ... of symbols ... letters, numbers, punctuation, words, pixels, etc.  There is nothing intrinsic to word processing that does anything to help us organize information ... to organize meaning.  Word processing is purely symbol manipulation, not meaning management.  It is intrinsically non-informational and as such is not information technology in any "meaningful" sense of the term.

 

 

 

 

Operating systems/software (including in the broadest sense databases and programming languages) are designed to help us use technology. That they promote or benefit the effective use of information is assumed, not verified.  

 

Using computers better does not mean we are using information better. 

 

Each operating platform is just a different way to try to cope with information functions that have existed since long before computers were invented without really knowing what those functions are, how they work, and whether operating software really supports them. Changing platforms neither changes nor enlightens information functions. 

 

As long as we are forced to rely on Technology Oriented Operating

Software instead of benefiting from Information Oriented Operating

Software we will not have effective information management.

 

 

 

 

One of the most important but not always obvious functions of "Enterprise" is to compensate for the inability to manage information effectively.  This is the essence of information management concepts as they evolved before the invention of computers and have continued since.  Compensatory techniques are not really solutions.  They are crutches made necessary by information management incapability.  Enterprise modeling, in effect, models information crutches, perpetuating rather than solving information problems.  Unknowingly faced with a choice between automating information crutches or automating information capability, enterprise modeling by its very nature makes the wrong choice without ever understanding a choice was made.

 

 

It is impossible to design an information system.

 

The term architecture implies design ... an act of creativity.  While information is structured, it occurs naturally as a reflection of real world structure. It is there to be discovered, not designed.  The concept information architecture is like saying Earth architecture, forest architecture, or solar system architecture.  A subtle distinction, but one that if not made has us struggling against reality ... attempting to create constructs that are not subject to creation. 

 

The point is to design vehicles, not information ... transportation not terrain.  Confusing the two causes information misuse and distortion. 

 

 

 

 

Normalization is a technique for organizing data to fit into a computer.  Unfortunately organizing data is not the same thing as organizing information .  Without clear understanding of the differences between the two, normalization relies on organizing data types ... what data looks like ... with little consideration of information types ... how we derive meaning.

 

The result is that normalization demands restricted perspectives and criteria, looking at some factors to the exclusion of others.   A normalized view of "flight" for example, would make it difficult to tell the difference between a vulture and a jumbo-jet because they both have wings.  Perhaps a ludicrous example in the real world, but not so in the virtual world where differentiations are not so obvious. 

 

Prejudice is equal parts cause and consequence of normalized thinking.

 

Ironically, many if not most system development efforts reach a point that, in order to satisfy requirements, the rules of normalization are set aside.  This should be a red flag to developers that the very idea of normalization is seriously flawed but the concept is so entrenched in the IT psyche it is never appropriately questioned.  Providing a false illusion of objectivity, normalization is a way to justify foregone conclusions ... to justify "technical" prejudice.

 

As with normalization, object orientation has far more to do with how we create systems than with the systems we create.   In simplest terms an object is a distinct component part for which "information" and procedures about that information are discreetly packaged within a system to support how we want to use specific information in a specific situation.  How that same information can be used regardless of specific situations is sacrificed. Object orientation is a sound technical tactic for packaging systems, but a very restrictive strategy for packaging information capability. 

 

 

 

 

Systems begin with a a requirements' definition ... a statement of the results expected from a would-be system.  Unfortunately, this is like expecting a car buyer to state every place a car will ever be driven before it can be built.  Only then can the car be designed and manufactured.  If later, new routes and destinations are needed the car has to go back through re-engineering and re-manufacturing

. 

Conventional system development operates on the assumption that the reasons for a system (as identified by a requirements' definition) are also its legitimate limits (that, if we buy a car to commute to work, that is all it ever need do).  In fact the real reason for requirements' definitions is to set limits on the use of information ... to limit the size of the problem system developers have to tackle.  Requirements' definition are solely for their benefit, not business's. 

 

Requirements definitions are a negotiation between system

developers and system users to impose artificial limits

on information and to lower expectations for systems.

 

By restricting the development of information, requirements' definitions actually work against a business's own best interests.  Based on the artificial constraints imposed, limited results is exactly what system developers set out to provide.

 

This is done through a very "heavy rail" way of thinking.  We survey routes to destinations (analysis), plan how routes will be developed (design), then lay track (program).  We build trips, not transportation, providing the least informational benefits at the highest cost. 

 

What gets lost in the complexities of conventional system development is any reasonable semblance of true information management.  Systems manage procedures (routes) and results (destinations) on the assumption that this constitutes managing information without recognizing that true information management does not impose limits on the use of information.

 

 

It is virtually impossible to determine whether information

captured months and years earlier is valid ... is truly meaningful ... for

the long-after-the-fact usage for which it is mined.

 

 

When customers place orders a lumber company encourages its sales people to substitute a better grade of lumber or longer boards with no cost increase if the specific item a customer wants is not available.  This substitution can occur several times during order-processing. Using the computer system customers' orders are changed to reflect what happened ... what was shipped ... losing sight of what was intended ... what was ordered. On certain items, product substitution was more the rule than the exception.  When used to plan production to fit what customers presumably wanted, the contaminated "order" data encouraged the manufacture of higher priced items that the customers didn't necessarily want to be substituted at a loss for the lower priced items they actually did want.

 

 

Conventional systems are typically torn between completing an activity (filling orders ... for which the example system succeeds) and truly managing information (keeping track of what customers really want ... for which the example system fails).  These conflicts are subtle and pervasive throughout legacy systems and almost always favor completing an activity to the detriment of actually managing information.  How a system was used for (and often "tricked" into) completing activities is little understood by data-miners.  Rarely do they know or consider the validity (or lack) of their own data.