Data Management Strategies

Meatloaf with Mashup Potatoes

Blogger: Joe Maguire

I like out-of-the-way restaurants in sleepy little hamlets.  The food might not constitute haute cuisine, but the quaint, low-tech atmosphere offers a stark, refreshing contrast to the circles I usually travel in.  How nice it is to peruse a non-drop-down menu.

But I spend so much time thinking about technology, it takes more than a trip to Sap Bucket, Vermont or Tumbleweed, Oklahoma to distract me.  Last time I scanned a dog-eared, laminated menu in a roadside diner, I couldn’t help noticing that I was encountering a mashup. The menu contained four different kinds of data, conforming to four different meta-models:

• Page one showed a reproduction of a pen-and-ink drawing of the diner, as it looked 70 years ago.  (Meta-model: Image data.)

• Page two contained a charming (and apocryphal) history of the diner, founded by great-grandmother as a venue for her cherry pie, a perennial prize winner at the county fair and a favorite of barn raisings and church bake sales for generations.  (Meta-model: Narrative data.)

• Page three contained the menu, with categories for breakfast, lunch, dinner, and dessert.  Certain items were flagged as vegetarian, others as “available in children’s portions.”  (Meta-model: Structured data.)

• Page four contained a map of the area, with “Grandma’s Diner” prominently marked.  (Meta-model:  Geospatial.)

There was no evidence that any computer technology was used to prepare the menu.

The diner menu shows that humans are perfectly comfortable switching between meta-models.  Even the most famished diner knows—instinctively, automatically—that the narrative data should be read sequentially, whereas the structured data can be scanned in any arbitrary order.  Life is short; choose dessert first.

This is yet another case where wetware (i.e., human intellectual capacity) outshines software.  Getting software to cope with multiple meta-models is tricky.  Exhibit A:  the profound difference between query and search.  Exhibit B, in the form of a question: Why, after it took the computer industry so long to develop mashup techniques, did end users accepted mashups almost immediately?

Users almost never discuss meta-models because they don’t need to.  Computer scientists, on the other hand, do quite a bit of lip-flapping about meta-models.  This disparity can lead to an erroneous conclusion: That meta-models are the exclusive province of computer scientists.  This is a serious mistake, with consequences for requirements analysts who interact directly with users.

The lesson here is this:  Computer scientists must know that users employ meta-models, and must learn to distinguish between meta-models that arose organically as a by-product of human culture and meta-models that were concocted by computer scientists to accommodate technological discussions.  Call them organic meta-models and invented meta-models.

Organic meta-models are legitimate vehicles for gathering requirements from users.  Invented meta-models are not.  For data modeling, the most popular invented meta-model in use today is the UML class diagram.  UML class diagrams are based on the object-oriented paradigm, which did not arise organically within human culture as a way to organize a certain kind of data.  Rather, object-orientation was explicitly designed by computer scientists to promote certain desirable traits in software, including reusability of programming artifacts.

Because it is based on an invented, not organic, meta-model, UML class diagramming is not an appropriate vehicle for requirements gathering with users.   That’s why in my decades-long career as a data modeler and requirements analyst, I have never shown an end user a UML class diagram.

Data Warehouses and non-fungible Assets: a bad Combination

Blogger: Lyn Robison

If you do a Google search on "data warehouse failures", you will get a taste of the hazards of data warehousing. One sure path to failure is to try to do something with a data warehouse that data warehouses are not good at. That would be using a data warehouse to track or manage non-fungible assets.

Fungibility might sound like an obscure concept that has little to do with implementing successful information systems, but fungibility is central to relationships, collaboration, ILM, information security, identity management, and business intelligence. And non-fungible assets are something that data warehouses don't manage well.

Understanding the concept of fungibility can enable IT professionals to avoid a common path to failure when implementing a broad range of information systems. A lack of understanding of fungibility is one reason why data warehouses and business intelligence projects often don’t deliver their promised benefits, why enterprises have had such a difficult time implementing CRM systems, and why few if any large enterprises know how many customers they have. If you don’t know how many customers you have and who they are, you can’t know how much each customer is buying from you, or understand what each customer is asking for, or manage how each customer relates to other customers or to your company’s salespeople. And it’s not just customers. If your information systems cannot give you an accurate picture of the non-fungible assets owned by a typical enterprise, you can’t manage them and you can’t manage anything that relates to them.

Q. What is fungibility?
A. You can find a good definition of fungibility here: http://en.wikipedia.org/wiki/Fungibility. You can also find some thoughts on IT fungibility here: http://it.toolbox.com/blogs/minimalit/fungibility-27324. A few quick examples would be: ¾” sheet metal screws are fungible, kiln-dried douglas fir 8’ 2x4s are fungible, barrels of oil of the same type and grade are fungible, dollar bills are fungible, but buildings are not fungible, employees are not fungible, and customers are not fungible. Fungible commodities have attributes and characteristics, with type and quantity being the most important considerations. Non-fungible assets have identity (in addition to attributes, characteristics, and type), with identity being the most important consideration.

Q. What happens if I treat fungible commodities and non-fungible assets the same way?
A. You will not achieve the results you want. (Click on the Dilbert cartoon below to see an example.)

 

Q. What happens if I treat data about fungible assets and non-fungible assets the same way?
A. Your information systems that are intended to track non-fungible assets will not be successful. Examples abound. Enterprises cannot easily determine which data to archive in an ILM setting because they don’t know which data refers to long-lived, non-fungible assets. A large, multi-national non-profit organization does not know how many buildings it owns. The most sophisticated army in the world does not know how many battle tanks it has. Our friend and colleague Joe Bugajski very nearly died when medical professionals could not keep track of his medical condition and treatment (see Joe’s blog post and my related post).

Q. What is the worst way to treat data about non-fungible assets?
A. In two words, “data warehouses”. Data warehouses are best-suited for aggregating, calculating, and analyzing quantities of fungible commodities. For example, they work well for adding up the dollars of revenue and expense for an income statement. This is because data warehouses shine when working on type and quantity. Unfortunately, data warehouses are often misapplied for use with data about non-fungible assets, and millions of dollars of sad experience have shown that data warehouses are a manifestly poor platform for managing identity, as a Google search on "data warehouse failures" will reveal.

Q. What is the best way to treat data about non-fungible assets?
A. In a word, “registries” (another word might be “directories”). Identity is the most important consideration for managing non-fungible assets. For guidance on registries and identity, see "Delivering Integrated Information from Data Silos Using MODS" and the Identity and Privacy home page.

Gartner buys Burton Group

Blogger: Lyn Robison

Burton Group CEO Jamie Lewis called together the BG Research Directors and Service Directors for a series of meetings this week at HQ in Salt Lake City. As the first meeting began on Monday, Jamie stepped to the front of the room to present a set of slides, which was not unusual. But then, one of the first slides he showed had a big Gartner logo right in the middle. Jamie then said, as near as I can recall, “Burton Group has been purchased by Gartner.”

I was so shocked that I almost could not process what I was seeing and hearing. After the initial surprise and after hearing the rationale behind this acquisition, I began to see the potential of this combination. Burton Group’s depth with Gartner’s wide distribution should be a great combination.

At that Monday meeting, the Burton Group Research Directors and Service Directors asked lots of pointed questions of the Gartner leadership, which included Gartner CEO Gene Hall and Gartner SVP of Research Peter Sondegaard. Our questions centered on how this acquisition by Gartner would affect Burton Group analysts’ ability to give our Burton Group clients the fiercely independent and technically thorough guidance to which they have become accustomed. I’ve got to say, I liked what I heard from the Gartner executive leadership at that meeting. Gartner bought Burton Group because they like the guidance that we provide, and they want us to continue to provide that guidance to our clients and to a whole bunch of additional clients in the future.

Stability and Transience In Information Requirements

Blogger: Joe Maguire

Some information requirements are stable—incontrovertible, permanent aspects of reality—whereas others are transient—subject to changes that naturally arise in a dynamic business environment.

The task of distinguishing between stable and transient requirements has been left to requirements analysts working on the front lines—with no guidance from thought leaders, notation designers, or tool vendors, who have really dropped the ball here.  Working requirements analysts are given not-very-useful advice like this:

• Model the entities before the attributes
• Investigate column-level constraints before row-level constraints
• Investigate row-level constraints before cross-table constraints

...instead of useful advice like this:

• Model things with mass before things without mass.
• Model things and places before things-in-places.
• When two users disagree about a requirement, the requirement is more likely to be a policy-motivated requirement than a data-motivated requirement.
• When modeling a taxonomy, expect users to start at the middle levels of the taxonomy, rather than at the top or bottom. 

Side note:  Linguists and anthropologists have observed that regardless of culture, the basic levels of a taxonomy are neither the most general nor the most specific; they are somewhere in the middle.

The not-very-useful advice institutionalizes syntax-based priorities.  This is only marginally useful because syntax correlates poorly with human priorities.  The folks who love syntax are the IT folks, because syntax is a fundament of software patterns and abstract thinking.  Unfortunately, syntax is also a linchpin of model-driven development.

The more useful advice honors realities about human cognition and human’s relationships with information.

Modeling techniques and notations that are based on the “not-very-useful” advice above might be called “naïve modeling techniques.”   I hope that someday we will be able to reminisce about the weakness of such techniques, a bit like the way the current automobile designers must shake their heads at pre-ergonomic designs of passenger cabins and operator controls.

I mention naïve modeling techniques for three reasons:

• I’m a modeling guy; it’s in my nature.
  

• When using model driven architecture, bad models will propagate every which way, compromising systems, governance, compliance, security, … almost anything you can name.  Messing up models deserves special attention because models are supposed to be foundational.
  

• Naïve modeling techniques are GUARANTEED to yield bad models.  That is, even if you perform modeling techniques exactly as the designers of those techniques recommend, you will get poor results.  This is true for UML, Object-Role Modeling, and all the various flavors of ER modeling.  That’s because modeling techniques honor the distinctions that IT folks consider important (e.g., the differences between entities and attributes) and completely ignore the distinctions that users consider important, e.g.:

• • the difference between policy requirements and process requirements or …

  • the difference between strict policies (e.g., you cannot get an after-hours badge until your email account is active) and aspirational policies (e.g., we ship 100 percent of orders within 24 hours).
    

Modeling notations do not help IT folks to contemplate or express the distinctions that matter to business folks.  But these distinctions should also matter to IT folks, because they should influence architectural and implementation decisions.  For starters, the stability or transience of a requirement should affect how it is implemented.

• Hard-and-fast data requirements (which are relatively few) deserve aggressive enforcement in a hard-to-circumvent layer of the application stack. 

One example:  Every matrix cell is at the intersection of a matrix row and a matrix column and that row and column must be part of the same matrix.

• Any strict policy deserves aggressive enforcement in a hard-to-circumvent layer of the application stack.  However, because it is merely a matter of policy, it should be implemented in a way that can be relaxed later after the system is deployed (because this is how humans deal with policies; they relax them when motivated by nepotism, changing business climate, whatever).
  

• An aspirational policy is, strictly speaking false.  However, aspirational policies can still deserve to be implemented, perhaps as on-demand reports that indicate how well (or poorly) the company is realizing its aspirations.

In a nutshell, the problem I'm describing is this: Two syntactically identical requirements might not be equally stable or equally transient.  Because modeling notations concentrate on syntax, this important difference in stability is concealed from requirements analysts.  Furthermore, the usefulness of model-driven architecture is compromised, because algorithms of model-driven architecture (such as forward-engineering algorithms that translate logical data models into physical database designs) use syntax-based transformation rules.  Two syntactically equivalent requirements would be translated into identical implementation artifacts, even if those requirements deserve different implementation strategies based on their stability/transience.

Previously published Burton Group research describes how working modelers and requirements analysts can overcome these shortcomings in the current state of the art.  For more information, see "Mind Your Business: Serving Business With Data Models That Focus Exclusively On Data." 

How many more systems do we really need?

Blogger: Lyn Robison

Most large enterprises already have lots of information systems. In fact, a ballooning portfolio of legacy systems has become a significant liability at most enterprises. Even though their enterprise already has too many systems, many IT professionals firmly believe that implementing new systems is their job.

Implementing new information systems is supposed to be the means to an end: delivering higher productivity and better information for decision makers. For many IT organizations, however, system implementation has become an end unto itself without any consideration of whether or not additional systems will actually lead to higher productivity and better information for decision makers.

Examples of the means becoming the end can be seen throughout history. In countless military conflicts, the winning army realizes the conditions for victory first, and then fights. The losing army fights first, and then seeks victory. Likewise, a winning IT organization realizes that they can often deliver higher productivity and better information without implementing any new systems. A losing IT organization looks first to implement new systems, regardless of whether or not those additional systems will actually help their enterprise achieve their goals.

In today’s economy, who wins, an enterprise that has lots of legacy systems that produce bad information, or the enterprise that has a few systems that provide useful information?

Database Consolidation: Approaches and Process

Blogger: Marcus Collins

In my recent post I detailed key points organizations should consider when embarking on a database consolidation initiative. In this post we’ll look at the different approaches and describe a structured approach which will It will lead to more predictable and repeatable results, be more efficient to execute, and provide the transparency required by IT governance processes.
There are two different approaches to database consolidation namely:

• Hardware consolidation
• Software consolidation

With Hardware Consolidation multiple databases servers are consolidated onto a single physical server using server virtualization.

A benefit of the hardware consolidation approach:

• Risk reduction: Hardware consolidation is inherently a simpler process than software consolidation because no changes are being made to the physical database. All database objects and associated access privileges remain intact, so the testing required after the consolidation activity is minimal.

A drawback of the hardware consolidation approach:

• All or nothing: Hardware consolidation involves moving the server and all its constituent databases as a unit. As business processes evolve, a possibility exists that the databases on a server contend for system resources. Of course, this may be resolved by moving to a more powerful server.

With Software Consolidation multiple schemas, derived from one or more distinct databases, are consolidated into a single database.

The benefits of the software consolidation approach are:

• Finer granularity: The software consolidation approach offers a finer degree of granularity than does hardware consolidation. Because the “unit of movement” is a database schema (i.e., one or more applications), this approach can be deployed when the databases on a server are contending for resources, have version incompatibility, and so on.

• Database redesign: The software consolidation approach allows the database to be physically redesigned. The redesign can involve index rebuilds, data file placement to eliminate disk performance hot spots, data sorting, and archiving to improve performance.

• Database version upgrade: The software consolidation approach can be combined with a database version upgrade. The rigorous testing required by such an upgrade can be used to validate the consolidation activity.

The drawbacks of the software consolidation approach are:

• High risk: Software consolidation is inherently more complex and therefore involves higher risk than hardware consolidation. The source databases will have their structure, privileges, and so on, and all instance data extracted. The extracted data will then be inserted into the target database. The testing of the application after this extract/insert will be extensive.

• Change control: Once deployed, databases are often accessed by users for reporting, data mining, and so on, that are unknown to the IT department. Major schema changes may impact these user applications and/or processes.

Organizations operate in a high competitive and regulated environment and so efficient and repeatable business processes are integral to an organization’s wellbeing. This applies equally to the database consolidation process. The recommended process is shown schematically below:

 
The Burton Group Structured Approach to Database Consolidation (SADC) takes a series of inputs and, through a complex tradeoff analysis, outputs a plan for a detailed analysis phase followed by the execution of a series of phased consolidations. The tradeoff analyses take the set of possible consolidation scenarios (i.e., schema-to-database and database-to-server combinations) and use the business objectives and constraints (i.e., prioritized tradeoff criteria) to determine the optimal consolidation scenario.

 
Organizations should treat database consolidation as a continuous process. At any given time, organizations will be either preparing for or executing a set of consolidation activities or phases. The reason for this is that the one of the key drivers for the SADC process is the hardware refresh schedule. In a large organizations, hardware will be refreshed on a cyclic schedule (e.g., three to five years), so in any given year, approximately 20% of the hardware will be refreshed.

The inputs to the process are:

• Application portfolio
• Hardware refresh cycle
• Consolidation approaches
• Consolidation considerations

The tradeoff is made using:

• Prioritized tradeoff criteria

In a recently published document - Structured Approach to Database Consolidation, Burton Group Senior Analyst Marcus Collins explores the topics described in this post in more detail. Each approach has its benefits and drawbacks and the document details theses. Adopting the approaches outlined in the document will allow organizations to develop a roadmap for the successful reduction in operational complexity.

Database Consolidation: Understanding the process

Blogger: Marcus Collins

The ever-changing business environment is forcing organizations to continually reevaluate their existing IT landscape. Consolidation is one approach that many organizations are adopting to improve efficiency. Databases are a major component of the operational IT budget both in terms of manpower (e.g., database administrators or system administrators) and hardware (e.g., database servers). Therefore, the consolidation of databases and database servers is a priority for CIOs. But databases are also core to the business processes and informational needs of the enterprise, so consolidation should be approached in a methodical way. Therefore, organizations should adopt a more structured approach when undertaking database consolidation to assist with the analysis phase of the initiative.
Database consolidation should not be thought of as a purely technical activity concerned with database migrations or virtualizing database servers. There are a number of other factors that should be considered as the consolidation activity is planned:

• An application-decommissioning initiative should be conducted alongside the database consolidation initiative. Applications are sticky—they are far easier to create than to decommission; this drives up operational complexity, business risk, and cost. The cheapest and most straightforward consolidation approach is decommissioning!
• A comprehensive application portfolio should be developed and should include:
• • Business context: The relationship between database, application, and business process, and the service level required by the business process
  • Technical context: The relationship between database and the supporting hardware; internal database structures, version, and feature usage
  • Operational context: Both current and historical workload and usage statistics and forward-looking capacity planning data.
• Database consolidation is a continuous process because it is driven by the hardware refresh cycle and the evolving nature of businesses (e.g., entering new markets, mergers, and acquisitions). The supporting processes (e.g., application portfolio management and technology refresh) should be an integral part of the IT processes.
• The key to any consolidation initiative is standardization at all levels of the technology stack and within the associated IT processes. Standardization reduces operational costs, reduces business risk, and enables business agility. The standardization should be defined in concert with a strategy of tiered service levels.
• Consolidation is a series of tradeoffs and compromises with no correct answer. The degree to which a consolidation initiative will be successful is directly related to the understanding of the organization’s priorities for cost reduction, service levels, and risk acceptance. A tiered set of service levels, with each specifying detailed availability and performance constraints and scalability requirements, will simplify the tradeoff analysis and improve the chances of success of the standardization initiative.

In a recently published document - Structured Approach to Database Consolidation, Burton Group Senior Analyst Marcus Collins explores the various approaches to database consolidation. Each approach has its benefits and drawbacks and the document details theses. Adopting the approaches outlined in the document will allow organizations to develop a roadmap for the successful reduction in operational complexity.

Controversy about the Data vs. Process Debate

Blogger: Lyn Robison

I was not trying to be controversial with my previous post, but apparently I struck a nerve. Perhaps it will be helpful for me to explain the background logic that went into the ideas I presented.

First, let me acknowledge that there are areas outside of data and process that are vital to the success of enterprise IT. By mentioning the data vs. process debate, I am not advocating the removal of project management, security, collaboration, identity management, or data center management from the list of vital concerns for enterprise IT. We in IT must do all of those things, and more. (If anyone has something to add regarding one of these other vital concerns that is related to anything that I say about data, I am all ears.)

Data management needs to appear on the list of vital concerns for enterprise IT as well. In my work in Burton Group’s Data Management Strategies area, I talk to lots of IT professionals about data management practices such as MDM, ILM, MODS, IQ, and BI. When it comes to the more basic data management practices that we advocate, sometimes IT professionals ask me, “Why would we need to do those things? What’s the ROI on that?” Clearly, from these folks’ perspective, data management isn’t really on the list of vital concerns for IT.

The way that people think about data largely determines their innate desire to perform basic data management practices. If someone thinks about data only in a limited way, they will not perceive the need to carry out the basic practices of data management. Let me give three broad characterizations of how I’ve seen IT professionals think about data.

1. Input/Output: IT professionals view data in the context of the application or the system or the business process that created it. Data is viewed merely as the input/output for business processes. In this way of thinking, if a process needs some data as input, it is perfectly okay to blithely replicate some data so that the process can get the data input it needs. The processes are the priority, and the data is simply the juice to get the processes started and merely the byproduct after the processes are completed. This is the way that SOAP seems to have been designed: for feeding input to and for obtaining output from processes. This way of thinking is a hold-over from the batch data processing mainframe days, when the computer systems made no real attempt to preserve data, and instead merely processed it. Data produced through this way of thinking is at best a distorted, inconsistent, incomplete picture of reality, because the computer systems are not designed to preserve accurate data, and instead are designed simply to execute processes.

2. Fungible Commodity: IT professionals view data in the context of the type or topic of the data. Computer systems are designed to preserve data, but the data is viewed merely as a fungible commodity that can be easily aggregated. A large corporation’s financial statements are a prime example of this. Numbers of dollars for revenue, expenses, assets, and liabilities are totaled up for each division. There is no need to keep track of individual dollars, because dollars are fungible assets: one dollar is just as good as another and all that is needed are the totals. In this way of thinking, databases are viewed as containers that hold data the way that steel barrels hold crude oil or railroad cars hold lumber. IT professionals create databases and then the business processes fill ’em up with data. Data warehouses and BI tools are used to aggregate this data. Data produced through this perspective makes it possible for corporations to manage fungible assets such as money, but they cannot manage non-fungible assets such as customers, because the computer systems are not designed to preserve unique instance data or to indentify individual assets across silos. (Hence the huge amounts of money that was spent on ineffective CRM systems over the past couple of decades.)

3. Picture of Reality: IT professionals view data in the context of its real-world counterparts – as representations of individual things in the real world. In this way of thinking, data is a picture that must accurately represent reality, otherwise the data is useless. The computer systems are designed to manage non-fungible assets, in that there is a 1-to-1 mapping between a data entity and its corresponding real-life object. If a corporation has 3,592 customers, its computer systems will contain exactly 3,592 customer identifiers. Data about customers will of course be spread across any number of silo-ed systems, but those systems will all use the appropriate customer identifiers for the data that relates to each one of those 3,592 customers. This is the way that REST and resource-oriented architectures seem to be designed: every entity is given a unique identifier. REST has built-in methods to manipulate the data that represents individual assets, even across multiple silos. MODS is a data management methodology for reconciling and then maintaining those unique identifiers for each asset. The XQuery Dev Stack is the set of technologies that is best-suited to implementing MODS. Data produced through this perspective makes it possible for enterprises to act on accurate intelligence and to take actions that are based on the truth. Data such as this makes it possible to accurately evaluate systemic risk on a macro level, as well as to manage individual assets on the micro level. In short, data created through this way of thinking is an accurate picture of the realities that are important to the business.

Enterprise data is a mess because too many IT implementers and IT leaders view data only as “Input/Output” or as a “Fungible Commodity”. Those IT implementers and IT leaders who view data as a “Picture of Reality” are naturally eager to perform the basics of data management that we advocate in Burton Group’s Data Management Strategies area.

My previous blog post on the Data vs. Process Debate, along with my other blog posts, are intended to pursuade IT professionals to think of data as a picture of reality. This concept is at the heart of what we do in Burton Group’s Data Management Strategies area.

The Data vs. Process Debate

Blogger: Lyn Robison

When I speak about the importance of data, a few IT professionals will usually feel compelled to bring up the importance of business process automation. They make the point that information systems automate business processes, and they don’t want me to neglect that important IT topic in my zeal for data. In fact, they kind of imply that data is not really what enterprise IT does -- business process automation is the real work of IT.

While I can appreciate the value of business process automation, from what I can see, data is more fundamental than process. I am not saying that data is more important than process -– they are both vital in the work of IT –- but data is more fundamental. The reason is simple. Processes require data as input. If you do not have good data, you cannot have good processes. Good data is the prerequisite for good business processes.

Of course, the process folks might counter by saying that good business processes are what produce good data, so process is the prerequisite to data –- kind of a chicken and egg argument. I don’t agree with that. Data does not necessarily spring from business processes. Data can and will exist independent of any business processes. Good data is a picture of reality. Good data is a record of those aspects of reality that the business deems important. If you don’t have good data, you have no picture of reality, and you are in La La Land. Any business processes that businesspeople perform that are not based on reality will be unproductive.

So, if you want good business processes, make sure you have good data. You can improve your data by becoming proficient at measuring and tracking data quality in your enterprise. If the data gets better, everything else that the business does will get better along with it. A rising tide (of data quality) will raise all ships.

What do you think?

Quality doesn’t matter, until it suddenly does

Blogger: Lyn Robison

My colleague Jack Santos wrote in a blog post today, “Lyn Robison (from our Data Management group) loves to rant about how business people put up with bad information from their IT departments.  No doubt. The sad thing is businesses want more.” I think Jack’s observation is true that businesspeople always seem to ask for more information even though its quality is shoddy, but I also think that this situation won’t last forever.

During the 60’s and 70’s, the American auto industry assumed that American consumers would always ask for more cars, even though the quality was shoddy. That observation was true, but it did not last forever. Quality didn’t matter, until suddenly it did.

As soon as someone (the Japanese automakers in this case) demonstrated to American consumers that they no longer had to settle for shoddy vehicle quality, vehicle quality became paramount. Likewise, as soon as a few IT shops demonstrate to businesspeople that they no longer have to settle for shoddy information quality, information quality will become paramount. IOW, if word gets out that the information coming from IT systems need not be garbage, look out. Businesspeople will demand high quality information from IT systems all of the time. And those IT people who cannot deliver it will find themselves in the same situation as the American automakers.

Those IT shops that do not want to end up looking like Detroit (see my "A Crystal Ball shows the Future of IT, and it is … Detroit?!" blog post for background on this) will adopt the approach of the Japanese automakers and start focusing on information quality today. These visionary IT shops will put themselves ahead of the curve and will find their prospects for the future bright and secure.