Data Management Strategies

Does IT manage systems, or manage data?

Blogger: Lyn Robison

The traditional view is that enterprise IT manages systems. The data is the business’s concern. The only thing that IT people do with data is define the structure of data in databases, which means that the only work IT people do with data is to design the shape of the buckets that the businesspeople pour business data into.

Smart enterprises are realizing that someone needs to manage the data within these systems: not merely the schema, but the data itself (the rows, not just the columns). But who does that? My Burton Group colleague Noreen Kendle asks a great question in her previous blog post: Is Data Management an IT Function?

Every large enterprise needs a data management organization (DMO) that is populated with people who are techie enough to manage data, yet not so nerdy that they refuse to sully their hands by touching data. The DMO must include a healthy mix of tech-savvy businesspeople along with techie-but-open-minded IT people. Noreen’s question is whether that DMO should report to the business leadership or to IT leadership.

Technology is becoming a commodity. IT is being consumerized and commoditized, and enterprise IT departments are finding themselves competing against providers of IT externalization (outsourcing, SaaS, cloud computing, etc.). Those IT departments whose bread and butter is managing and implementing technology will sooner or later find that they are peddling artisan wares in a highly competitive commodity market. The enterprise IT department’s custom, handcrafted IT systems will be expensive and of poor quality in comparison to the mass-produced information technology that businesspeople well be able to buy for a few shekels from electronics retailers and cloud computing providers.

So, IMHO, the answer to the question of whether the DMO should report to the business leadership or to IT leadership depends on whether or not the IT leadership has a clue. If they have no clue, IOW if the IT leadership believes that IT's primary job is to manage technology and systems, then the DMO should report to the business leadership. If the DMO is part of the business, when IT commoditization and IT externalization eventually banish the IT department’s technophiles from the enterprise, the DMO won’t be banished along with them. The DMO will continue to function within the business, no matter what happens to the nerds in IT.

If the IT leadership does have a clue, if the enterprise has a CIO who realizes that they are a CIO instead of a CTO, then the DMO could report to IT leadership and be effective in its mission of managing the enterprise’s data. The DMO will include people who manage structured data, documents, content, information security, identity data, and the delivery of useful business information to businesspeople, and that DMO will become the enterprise IT department. From what I can see, the techies in the IT department will by and large have go to work for cloud providers, or will be obliged to find new careers.

The bottom line is that enterprises will no longer be able to afford enterprise IT’s artisan technology and systems when the off-the-shelf, mass-produced technology and systems begin to offer cheaper and more effective alternatives. If the enterprise IT department survives at all, its primary task will be data management, because the technology will be an outsourced commodity. So, as a technophile myself, I can say that it’s been fun to tinker with technology, but now the time is right for enterprise IT people to learn to manage data.

Is Data Management an Information Technology (IT) Function?

A few years ago I would not have questioned data managements fit as an IT function.  As data continues to gain recognition through initiatives such as master data management, service oriented architecture and business intelligence, IT departments have been challenged with understanding, managing, and governing the data. Many of my fellow data professionals who have been involved with data ownership/governance initiatives have expressed the difficulty of getting the business to take ownership of the data.  This is one of several reasons I have begun to question ITs role in data management. Why is it ITs job to “get” the business to own what they already own? There is something backwards about that.

Data is a representation of the organization.  The organization uses this representation, the data to operate record, manage, report and plan.  Organizations have been creating and using data long before computers were ever thought of. Data is clearly a business asset, not an IT asset as is hardware or software.  Prior to computerization, the business owned, managed, understood and governed their data assets.

Information technology is about effectively applying technology to the organizations data/information assets in order to help the organization reach its goals. Just as machine technology can be applied to a manufacturing process, information technology can be applied to a business process. The products that flow through the machine technology are never considered part of that technology or the responsibility of the machine technologist.  Products are considered a business owned asset.  So why has data and its responsibilities an IT function?    Data is clearly a business asset and most likely one of their most important assets.   It’s becoming clear to me that the responsibilities for data belong in a business department, not IT. The functions involving applying technology to the data asset, such as a DBMS, should remain the responsibility of an IT department.

The Right Shape for your IT Department

Blogger: Lyn Robison

IT departments are not one-shape-fits-all. The IT needs of a broadcast media company, for example, are not the same as those of a consumer product manufacturer. A government agency needs a different set of IT services than a retail bank. And the IT department of an insurance company will perform fundamentally different work than the IT department of a large law firm. The IT departments in these enterprises all have different “shapes”.

The shape of an IT department ultimately determines how well it fits within its enterprise. An IT department is shaped by the CIO’s decisions regarding priorities, leadership structure, initiatives, staff composition, physical locations, and metrics. Mistakes on these decisions will give the IT department a shape that does not match the type of organization it serves.

There are common characteristics, even among diverse enterprises, that can inform a CIO’s decisions about the ideal shape of the IT department. This blog post (which is kinda long) explores those common characteristics.

You’re not my Type

An understanding of the similarities between your company’s IT needs and the IT needs of other organizations can give you valuable insights into the decisions that you must make about the shape of your IT department. Dissimilar companies often have IT needs that are surprisingly similar – even if those companies use divergent business models or operate in unrelated industries. The IT experience of companies that are seemingly far removed from yours can often yield greater insights to you than the companies that are directly related to yours.

So the question becomes, how do you measure the similarity of your enterprise’s IT needs with those of other companies, particularly those that are outside of your industry and that appear unrelated?

One approach is to identify the dimensions along which IT requirements tend to vary between companies. I have identified 16 dimensions for measuring the shape of IT services in disparate types of organizations. Any two companies that score similarly along these 16 dimensions will have IT needs that are similar, even if the organizations differ from one another in other respects.

When performing your own analysis, you are free to adopt the dimensions that I have identified, or you can merely use mine as a point of departure to create your own dimensions. The dimensions that I have identified are:

1. World-wide scope – What is the scope of the organization’s work? Are they undertaking a truly a world-wide effort?
2. Broadcast the news – Do they broadcast messages or information?
3. Create content – Do they create their own content that they publish or broadcast?
4. Publish books and magazines – Do they do printing and publishing?
5. Develop products for sale – Do they create products and bring those products to market?
6. Research and development – Do they engage in R&D efforts to create new products?
7. Supply chain and ERP – Do they have a supply chain where they purchase raw materials, manage inventory, and distribute goods?
8. Manufacturing – Do they manufacture physical goods and products?
9. Professional services – Do they engage in professional services (such as a law firm might)?
10. Finance – Do their financial needs require them to function as a financial institution?
11. Field organization – Do they have a field organization that must be trained and managed from headquarters?
12. Big data – Do they have to manage large quantities of data?
13. Analysis of big data – Do they analyze large quantities of data?
14. Track membership – Do they have a concept of membership and do they track the levels of membership of their constituents?
15. Find individuals – How much are they interested in individuals, and not just in the mass market?
16. Win hearts and minds – To what degree do they try to convert people’s hearts or change people’s minds, as opposed to merely informing people of facts?

To assess how the IT needs of various organizations might compare, you will need to establish for each dimension a maximum, a minimum, and some points in between. For example, an organization whose very existence depends on the products it brings to market will be placed at the maximum of the Develop products for sale dimension. An organization that brings products to market merely to enhance its other activities will fall somewhere in the middle of the scale. And an organization that develops no products for sale will of course be at the bottom of that dimension.

Let’s look at some examples to see how the IT needs of different types of organizations compare. Following are some Kiviat diagrams (also known as Radar Charts), which show how different organizations might score along these 16 dimensions.

    
Figure 1: Broadcast Media Company

As you can see in Figure 1, a broadcast media company has heavy IT needs for content management and for broadcasting. By contrast, Figure 2 below illustrates the IT needs of an independent software vendor.

 
Figure 2: Independent Software Vendor

A commercial software company’s IT needs will look like those shown in Figure 2. Figure 3 below shows what a government intelligence agency’s IT needs are.

 
Figure 3: Government Intelligence Agency

In these three figures, you can see that a broadcast media company will have greater need for content management systems than a commercial software company. On the other hand, a commercial software company will have a greater need for a customer relationship management system than a broadcast media company will.

More than merely showing what types of systems a company will need, however, these 16 dimensions determine the shape of a company’s overall IT needs. That shape indicates what the IT department’s priorities should be, how the IT leadership team should be structured, what types of talent the IT department should hire, which IT groups need to be physically co-located, which IT functions must be located close to stakeholders and users, what IT initiatives the IT leadership and staff should pursue, and what metrics are truly indicative of success in IT.

By assessing your company’s IT needs alongside a wide variety of other organizations, you can find those enterprises that have IT requirements that are like yours and that are unlike yours. This analysis can tell you which organizations you should ignore from an IT standpoint, and which ones you should watch and learn from. This can help you avoid best practices from companies that would actually lead you in the wrong direction, and can also give you valuable insights from unexpected companies and industries.

To illustrate this point, Figure 4 below compares and contrasts the IT needs of a group of hospitals with the IT needs of an Intelligence Agency.

 
Figure 4: Government Intelligence Agency and Hospital Group

As you can see in Figure 4, there is a surprising amount of overlap between the hospital group and the government intelligence agency.  It is apparent that the hospital group could potentially learn valuable IT lessons from the government intelligence agency regarding data handling and information management. By contrast, the IT needs of the hospital group would have only a small overlap with the IT needs of a broadcast media company or a commercial software company.

Clearly, if you were to fail to accurately assess the IT needs of your enterprise, your decisions regarding the shape of your IT department will be flawed. You might emphasize the wrong concepts, you could create the wrong organizational structures, you may well watch the wrong metrics, and you likely will take your IT department in a direction that will not fulfill the IT needs of the enterprise.

Shapes that never Fit

One shape that never fits any IT department is that of a commercial software company. The assumption by some CIOs and IT leaders is that because IT departments and commercial software companies both produce software, they should be structured similarly. However, as you can see in Figure 2, the IT needs of a software company are quite unlike those of the other types of companies illustrated in Figures 1, 3, and 4.

An even greater sin is to attempt to structure an enterprise IT department like a product development group within a commercial software company. Product development groups have so little in common with enterprise IT that this shape will never fit the needs of an enterprise. While it is true that product development groups and IT departments both produce software, enterprise IT departments often buy more software than they build. Enterprise IT departments must also integrate, deploy, secure, operate, monitor, backup, and upgrade software within an operational environment – something that software product groups never do. In addition, enterprise IT departments must ensure that software is managed properly for data retention, prepared for disasters, regularly evaluated, and retired at the appropriate time. An enterprise IT department that is structured like a product development group will be at a disadvantage when its staff is called upon to perform these vital IT functions.

Another common misstep is to structure the IT department so that it merely manages technology, and not the information that the technology systems produce. To be effective, enterprise IT departments must concern themselves more with managing information than with managing technology. CIOs find that they can spend millions to upgrade their systems, only to end up with no net gain in information availability for their users. Instead, they just get bad information faster. Or, they end up with more unstructured content with no way to apply that information to reach better business decisions. To be effective, CIOs must function as CIOs, not as CTOs.

Shapes that always Fit

Information systems exist to do just two jobs: they automate processes and they provide information. Unless an IT system does at least one of those two jobs effectively, it is as useless as an automobile factory that manufactures un-drivable cars or a slushy machine that produces unpalatable slushies. Therefore, two initiatives that always improve the fit of an IT department are business process improvement and information quality.

Every enterprise has a set of software applications that are core to the business, that automate important process, and that have large numbers of users. The processes embodied in these enterprise applications and the information they provide are prime targets for business process improvement and information quality initiatives. These business processes are static enough that they can be documented, measured, and improved over time. The information that goes into and comes out of these processes often is not as reliable, accessible or clear as users need, and an information quality initiative can fix that.

Every enterprise also has a large number of ill-defined or dynamic processes that tend to be done a little differently every time, depending on the immediate situation.  These dynamic processes are the type that Accenture unearthed in a survey they conducted last year.  They found that middle managers spend more than a quarter of their time searching for information necessary to their jobs, and when they do find it, it is often wrong. (See “Managers Say the Majority of Information Obtained for Their Work Is Useless”, 4 January 2007) These dynamic processes require a large number of software applications and data sources, and involve a relatively small number of users. As a result, business process improvement is not practical here, but information quality can be highly valuable.

Shaping Up

Comparing your enterprise’s IT needs with those of other enterprises can help you identify the ideal shape of your IT department. Your enterprise architecture group should be able to perform this type of analysis for you. When completed, this analysis can show you where your department is out of shape and perhaps does not fit as well as it should within your enterprise. It can also provide you with some valuable examples in unexpected places.

Data Management and Cloud Computing

Blogger: Lyn Robison

The graphic below is from my esteemed Burton Group colleague Dan Blum’s upcoming Catalyst presentation on Cloud computing.

As he explains in a recent blog post,: “As we move from left to right in the diagram and put more and more control in the hands of the service providers, the outlook shifts from fair weather green to ominous red.” 

 

The far-left column shows in green that a traditional enterprise IT department controls the entire technology stack with only the network shared with a service provider (because of the Internet). The next column shows that with server hosting providers, the organization shares control of the server, storage, and network functions.

Dan explains in his blog, “As we move from Infrastructure-as-a-Service (IaaS) with its line of demarcation in the server where the silicon stops, to Platform-as-a-Service (PaaS) where you cross the line after your code and applications are integrated with outside components, to Software-as-a-Service (SaaS) where you abandon all control when you hand over your data I paint the functions these services control an alarming red.”

This graphic illustrates that as cloud computing alters the IT landscape, data is the only thing that organizations maintain any control over. Ironically, most enterprises lack any formal data management function. IT people tend to think that their job is to manage technology and systems, yet data (not technology) is something that enterprises must manage as cloud computing becomes prevelant.

As cloud computing gets adopted, those enterprise IT people who think that their job is merely to manage technology and systems will find themselves no longer working in enterprise IT –- they will be forced to go to work for or to compete against cloud providers.

The Information Management track in the upcoming Catalyst conference will provide guidance for managing enterprise data, which is important because, as this graphic illustrates, data management might become the primary task of enterprise IT in the future.

A Data Management Freebie

Blogger: Lyn Robison

It’s not often that you get something for nothing, especially something valuable like innovation in silo bridging for large enterprises.

Guidance on overcoming the problem of data silos is particularly valuable because:

• Data silos are a permanent fixture in modern enterprises -- silos exist because of organizational boundaries and because of the boundaries of information systems, applications, and databases.

• Data silos prevent businesspeople from getting the information they need to make informed decisions and do their jobs. You can see examples here and here.

• Efforts at silo busting, where silos are eliminated using SOA or enterprise-wide applications, are risky and expensive and usually don’t succeed.

• Silo bridging instead of silo busting is the only sensible strategy.

The best way that I know of to bridge silos is to use MODS, the Methodology for Overcoming Data Silos. I am doing a free webcast on MODS. It is not magic, but it is inexpensive, low-risk, and delivers compelling results. You can find out about it here:

You can get the overview of MODS here. You'll need to register to download it, but it's a simple process. I hope that you find this information valuable. Lemme know what you think!

Data Integration that can actually Work

Blogger: Lyn Robison

Recently, I watched an interesting documentary about Worldport, the worldwide hub for UPS in Louisville, Kentucky. It is obvious that shipping companies such as UPS have conquered the data integration problem, and offer a vital key for the rest of us.

UPS has multiple computer systems at Worldport, multiple computer systems at each of their regional hubs, and handheld computer systems for each of their drivers. These computer systems are silo-ed at UPS, just like computer systems are silo-ed in any other large enterprise, and as a result, each package enters and leaves many data silos on its journey from its origin to its destination. Yet UPS is able to provide an integrated, 360-degree view of each parcel as it moves through UPS’s shipping lifecycle. How does UPS do it?

One thing they do -- and this is a key for any enterprise that is looking to integrate operational data from silos -- is this: they identify each parcel.

That’s it. That is the big secret. They identify each parcel beyond the bounds of any data silo. They don’t waste hundreds of thousands of dollars trying to eliminate silos by doing SOA. They don’t replace all of their little silos with one big silo by implementing a risk-laden and hugely expensive ERP or CRM system. They simply identify each parcel. They give each parcel a tracking number by which it is known within all of the IT applications, information systems, and databases throughout UPS. Because each parcel is known in all information systems by its tracking number, UPS can pull together information about each parcel from all of their data silos, on demand.

Assigning each parcel a unique identifier is no doubt cheaper and a lot more effective than implementing SOA or a CRM system. We ought to do that in enterprise IT. We could give a unique identifier to each thing that we want to keep track of: each customer, each product, each supplier, each policy, each asset, each employee, each project, each decision, each work activity, etc.

If you knew and if everyone in the enterprise knew that every system that had any information about any of these individual things would reveal that information based on that thing’s identifier, data integration could almost be easy. Okay, maybe not easy, but certainly easier.

It turns out that in data integration, which one is almost more important than what kind? Any enterprise that identifies its non-fungible assets with unique identifiers can do silo-bridging instead of silo-busting, and will be better prepared to transition to cloud data management when the time comes.

Identifying important instances of data is one of the pillars of Burton Group’s MODS. Stay tuned for more guidance on MODS at Burton Group’s upcoming Catalyst conference.

BTW, we have a secret discount to Catalyst available to readers of this blog. To get the discount, here's what you do:

1. Go to the Catalyst home page (http://catalyst.burtongroup.com/). Either: click and then drag your mouse off the logo and release the button. OR: roll over the San Diego button but do not click, wait about 20 sec.

2. A message will pop-up stating "Congratulations! You’ve found an exclusive discount code for Catalyst 2009. Use promo code: Easter Egg and get General Sessions for only $999! Register today – this discount is limited to 50 users and could disappear at any time!"

3. Register.

That's it. Hope to see you at Catalyst!

“Happy Talk” from an IT Industry Analyst

Blogger: Lyn Robison

I’ve never been accused of too much happy talk about the current state of enterprise IT, or about its future. My A Crystal Ball shows the Future of IT, and it is … Detroit?! blog post is a prime example of my lack of happy talk.

Upon closer examination, however, you will realize that I am not all gloom and doom about enterprise IT. My blog post Enterprise IT need not end up like Detroit stikes a positive chord and my post The Economy, Innovation, and the Future of IT is downright rosy in its outlook. I am actually quite bullish on the future of enterprise IT – I am just not bullish about the future of enterprise IT in its current form. Enterprise IT is headed for some big changes in the next five to ten years.

If you wish to keep doing what you’re doing within your role in enterprise IT, mine is probably not the blog you should follow. IT people who hope to ignore the future and continue merrily working inside their cubical will be blindsided by the waves of change that are coming to enterprise IT. On the other hand, if you would like to be forewarned about the changes that the future will bring to the careers of enterprise IT people, I will do my best to tell you about what I see coming.

The Economy, Innovation, and the Future of IT

Blogger: Lyn Robison

For years, the political leaders of the United States (in both parties) have pandered to the wants of the electorate with reckless abandon, and as a result, the federal government now faces perilous budget deficits. The good news is that, as incredible as it sounds, enterprise IT has actually contributed in the past to solving this problem by significantly increasing the productivity of the U.S. economy. I will explain how in a moment, but first let’s review the bad news. 

A recent article in the New York Times entitled, “America’s Sea of Red Ink Was Years in the Making” quotes Alan Auerbach, an economist at U. C. Berkeley, who says, “Bush behaved incredibly irresponsibly for eight years. On the one hand, it might seem unfair for people to blame Obama for not fixing it. On the other hand, he’s not fixing it. And,” he added, “not fixing it is, in a sense, making it worse.” The article continues, “What, then, will happen? ‘Things will get worse gradually,’ Mr. Auerbach predicts, ‘unless they get worse quickly.’ Either a solution will be put off, or foreign lenders, spooked by the rising debt, will send interest rates higher and create a crisis.” The article also states, “That is the legacy of our trillion-dollar deficits. Erasing them will be one of the great political issues of the coming decade.”

Fortune magazine recently published an article entitled, “The next great crisis: America's debt”. The article states, “Within a decade the average household that pays income tax will owe the equivalent of $155,000 in federal debt, about $90,000 more than last year.” It goes on to say, “It can't go on forever, and it won't. What will shock America into action is the prospect of fiscal collapse, which will grow more vivid each year.” The article paints a bleak future in which big entitlements frustrate any real prospect of reducing the deficits. Our future looks bleak, and there appears to be no way to avoid it.

One hopeful note in this bleak picture of our collective futures is the positive impact that enterprise IT had on the U.S. economy during the 1990s. On April 5, 2000, in an address entitled "Technological innovation and the economy", Alan Greenspan basically gave enterprise IT the credit for the largest economic expansion on record. He asserted that “something profoundly different from the typical postwar business cycle has emerged in recent years. Not only has the expansion reached record length, but it has done so with far stronger-than-expected economic growth ... While there are various competing explanations for an economy that is in many respects without precedent in our annals, the most compelling appears to be the extraordinary surge in technological innovation that developed through the latter decades of the last century.” Mr. Greenspan explains that IT (specifically, ERP systems) succeeded in the 90s in materially reducing “large swaths of inventory safety stocks and worker redundancies”. He observed, “In short, information technology raises output per hour in the total economy principally by reducing hours worked on activities needed to guard productive processes against the unknown and the unanticipated.” During the 1990s, we used enterprise IT to innovate our way to economic prosperity.

That innovation really worked. Federal tax revenue increased during most of the 90s, and the federal government actually ran a surplus in 1999 and 2000. The CBO estimated then that the government would run surpluses of more than $800 billion per year from 2009 to 2012. (Unfortunately, the government will actually run a $1.2 trillion annual deficit instead: a $2 trillion swing in the wrong direction. A little more than a third of that negative $2 trillion came from an economic downturn, a third came from legislation signed by President Bush, and a little less than a third will come from President Obama’s extension of several Bush policies, the stimulus bill, and Mr. Obama’s agenda on health care, education, energy and other areas.)

My point in all of this is that enterprise IT accounted for vast increases in the output and efficiency of the U.S. economy during the 90s. We innovated our way to economic prosperity once -- perhaps we can do it again. Doing so will require another “extraordinary surge in technological innovation”.

Mr. Greenspan referred to a “revolution in information availability” that occurred during the 1990s, which makes me believe that the technological innovation we seek will not come through technology technology, but rather through information technology. IOW, our technological innovation needs to bring about another revolution in information availability.

In my blog post A Crystal Ball shows the Future of IT, and it is … Detroit?!, I predicted that enterprise IT will face the same fate as the American automotive industry if enterprise IT continues to focus on the production of technology instead of the production of information. I stand by that prediction, and Mr. Greenspan’s comments about the 90’s “revolution in information availability” seem to harmonize with my assertion about the importance of information. Now, I hereby predict that enterprise IT can indeed revive the entire U.S. economy and avert a federal budget disaster if enterprise IT will focus on the production and delivery of useful information to the businesspeople who need it to make decisions and do their jobs.

This revolution in information availability needs to be the opposite of the failure in information availability that I delineated in my Smoking Gun blog post, which materially contributed to the subprime mortgage crises, whose ripple effects precipitated the current recession.

The 1990’s revolution in information availability came as a result of the conquest of data silos in the supply chain. The next revolution in information availability will come as a result of the conquest of data silos throughout the enterprise.

The conquest of data silos should be paramount in the minds of enterprise IT leadership and staff. At Burton Group’s Data Management Strategies service, overcoming data silos is paramount in our minds, and we are providing guidance to that effect. We recently published an overview entitled “The Methodology for Overcoming Data Silos (MODS): Using the New XQuery Development Stack” and we will soon publish another overview entitled “Delivering Integrated Information from Data Silos Using MODS”. These overviews point the direction of the innovation that enterprise IT must pursue for its own sake and for the sake of the economy at large.

The Seven Top Data Delusions

The world of data is full of delusions - false beliefs or ideas about data. These are fueled by the mountains of data related white papers, articles, blogs, and marketing material. If I "google" any data topic, like master data or BI, millions of hits are returned. As I skim through these, nearly all are regurgitations of the last – thus the data delusions continue to grow. It is interesting how much is assumed to be true if we read it in print.

Below are the seven most popular I continue to see:

Data Delusion One

: If the data is there then it must have been deemed good data. There are not secret data police monitoring the data in most organizations. A large percentage of incorrect data lives within the data stores.

Data Delusion Two

: If it looks right then it must be. Typically, data is considered "poor quality" when it obviously looks incorrect or is known to be incorrect. Often data can "look" right, when it is not. How do you know if the answer returned when you ask a question, using a computer system, is correct - you would not need to ask if you knew the correct answer?

Data Delusion Three

: A new tool/technology will fix the data problems. There continues to be a belief that the tools/technology will auto-magically figure out if the data is correct or belongs together. Unfortunately success is always dependant on the quality of what goes in– garbage in, garbage out is still true.

Data Delusion Four

: Data is a computer phenomenon like software or hardware. Many of the definitions support this, but data has existed for longer than before computers were ever imagined. Data is a representation of the real-world organization, its things, people, locations and events. Computers help to automate the processing of data.

Data Delusion Five

: "Cleaning" the data fixes it. There is always a reason data becomes corrupted. It just does not magically happen. Data errors or poor quality data are a symptom of a problem, rarely the problem itself. Fixing a symptom does not fix the problem - it’s like taking an aspirin for a brain tumor.

Data Delusion Six

: The data meaning can be deduced from its name/definition. Even in the rare case when a data store has been diligently modeled from a business standpoint and implemented accordingly, the data system deteriorates over time. Many of the data stores in our organizations have never been designed / modeled in the first place. The data field names and sparse definitions were often the best guess by the programmer at the time. `

Data Delusion Seven

: Data can be managed/integrate/cleaned at an individual attributes/columns level. The data attributes/ columns are intended for description purposes. They are relative to what they are describing, as well as to the relationships/ dependencies of the things they are describing. When data attributes/columns are taken out of this context and treated indiviually, they can lose much of their meaning, and thus integrity.

Increasing the Mileage of Enterprise IT

Blogger: Lyn Robison

The best way for an enterprise to improve their IT mileage is to get more from their existing systems, and the best way to get more from their existing systems is to do a better job of managing data.

IOW, to get more out of IT, enterprises don’t need to implement new IT systems; all they need to do is manage data more effectively in their existing systems. Competent data management will breathe new life into old systems and will add polish and shine and power to mainstream systems.

Economic conditions are making it difficult for enterprise IT groups to undertake expensive and risky software development projects. Smart IT groups are looking instead at low-cost projects that offer a large bang for the buck. Data management projects, particularly MODS projects, give the high IT mileage that these lean times demand.