Data Management Strategies

The Business Intelligence Investment: The Analysis Process

Blogger: Marcus Collins

In my recent post I detailed the critical success factors for a successful analysis initiative namely:

• Having the right analysis process
• Having access to the right information
• Having the right context
• Having the ability to make decisions at the right time
• Having the right leadership
• Having the right team dynamics
• Having the right people

And finally:

• Choosing the right problem

In this post I’m going to explore the “right analysis process” in more detail.

Organizations operate in a high competitive and regulated environment and so efficient and repeatable business processes are integral to an organization’s well being. This applies equally to the analysis process. The analysis process should be tailored to meet the requirements of both the organizational culture and the context of the analysis. For example, a move into or out of a market segment would require a more thorough analysis that a series of experimental what-if scenarios.

The process is shown below:

Frame the problem – requires the analyst to have a clear understanding of the problem with the problem boundaries defined and it decomposed into its constituent parts.

Design the analysis – is the selection of the appropriate technique or framework. For example, to identify the most balanced decision amongst candidates the trade study would be used.

Gather the data – identifying data that is relevant to the problem and determining the source of this information and, importantly, determining what information is not available. Data quality metrics are important as they allow the analyst to evaluating the impact of the quality metrics on the analysis output.

Execute and interpret – two different skills are used here. Execute requires an analytic discipline with a focus on quantitative fact and rule-based logic. Interpretation emphasizes human judgment. Both techniques should be used in this step of the process. The output of this step will either be actionable and the process will move onto the implementation stage or not actionable and the process will move back to the start and refine and/or reframe the original problem statement.

Implement – in context of business intelligence this is the implementation of business change. A key recommendation here is that the analysis is not the act of making decisions; rather it is a single factor in the justification for a decision. The actual decision will be a combination of quantitative information, qualitative information and human judgment.

Measure – the traditional IT view of measurement focuses on efficiency and cost. Within the context of the business intelligence initiative the focus should shift to measuring business value.

Continuous learning – the analysis process is iterative and key to the success of this is culture of continuous learning. Organizations should encourage a culture of learning through both successes and failures.

In a document to be published in early June and a series of TeleBriefings on June 2 and 3, Burton Group Senior Analyst Marcus Collins will explore the analysis process and each of the other critical success factors in more detail and provide guidance on how organizations can develop a roadmap for the successful deployment of a fact-based decision making culture.

Enterprise IT need not end up like Detroit

Blogger: Lyn Robison

Follow-up to my previous entry: Enterprise IT can avoid the fate of the American auto makers by making an innovative course correction. (Even though this course correction is inexpensive, reasonable, and immediately profitable, some IT people will reject it out of hand.)

The course correction is simple: focus on information quality at the expense of IT production.

• Never call an IT project “done” until the data from and for the business is right, even if the project deadline is looming
• Never count an IT system as “up” unless it is currently delivering useful information to businesspeople, which means that IT groups must constantly measure the quality and usefulness of the business information that is coming from IT systems and count systems as “down” if the information is useless to businesspeople
• Allow (and encourage) everyone (both in business and in IT) to call out data quality problems on IT projects and in the ongoing operations of IT systems, which may very well result in project delays or system “down” time
• Execute MODS projects (MODS is the Methodology for Overcoming Data Silos), which are data management projects, not software or IT infrastructure projects, and which present huge bang for the buck in today’s IT environment. Today’s enterprises already have lots of software and IT infrastructure, but they lack useful business information, which makes the value of software or IT infrastructure projects low and the value of MODS projects high.
• Establish enterprise-class data governance, undertake master data management, and perform data modeling
• Create a data management organization and take a systems approach to enterprise data
• Adopt information quality metrics as the primary metrics for the IT organization
• (BTW, Burton Group's Data Management Strategies service provides guidance on all of these topics)

Many production-focused, technology-centric, dyed-in-the-wool IT veterans will be skeptical about focusing on information quality at the expense of their bread and butter. Most IT people have built their careers with bits and bytes, using heroic efforts to meet project deadlines, and doing whatever it takes to keep IT systems up and running, and they will be reluctant to let something as fluffy as “information quality” become an impediment to their production.

American auto makers have faced this question of quality vs. production for the past 30 years, and they have chosen poorly enough to have their customers gradually abandon them. Enterprise IT now faces that same choice.

Those enterprise IT groups that correctly choose quality over production will find themselves ideally positioned to leverage the technology commoditization that cloud computing will bring. They will deliver the high-quality business information that their customers demand, and they will deliver that information using commodity technology from the cloud.

The Business Intelligence Investment: Realizing the Benefits

Blogger: Marcus Collins

IBM recently published a report that states that while 75% of organizations recognize the opportunity for analytics only about 15% have a well developed analytic capability. This mirrors the finding of a 2008 report published by Accenture.

The current economic climate and highly competitive nature of today’s business environment requires that the traditional approach of making decision, based solely on intuition and gut instinct, be replaced by one where a rigorous information and fact based analysis process guides the decision making.

Given this landscape, what can organizations do to ensure an effective business intelligence initiative? As we analyzed both the successes and failures of business intelligence projects, a number of critical success factors emerged:

• Having the right analysis process
• Having access to the right information
• Having the right context
• Having the ability to make decisions at the right time
• Having the right leadership
• Having the right team dynamics
• Having the right people

And finally:

• Choosing the right problem

None of these factors involve tool deployment – many organizations have already made the investment in the analysis tools – rather they focus on the softer process and organizational aspects.

The key recommendations are that analysis should follow a clearly defined process with a focus on the reliable delivery of business value; that the analysis initiative should be led by the business, with strong involvement from IT and that organizations should embark on a proof of concept to both refine the internal processes and as a poster child for a wider deployment.

In document to be published in early June and a series of telebriefings on June 2 and 3, Burton Group Senior Analyst Marcus Collins will explore in detail each of these critical success factors and provide guidance on how organizations can develop a roadmap for the successful deployment of a fact-based decision making culture.

A Crystal Ball shows the Future of IT, and it is … Detroit?!

Blogger: Lyn Robison

The American automotive industry carries with it some eerie parallels for enterprise IT. Given the state of the American auto makers, we probably should not strive to mimic Detroit.

Historically, quality was not the primary concern for American auto makers, production was. As a popular book explains, “Bad parts, when they happened to be noticed, were simply labeled and set aside to be repaired at another time and by another department. The mantra is ‘produce large quantities at all costs and fix problems later.’ As Gary Convis, President of the Toyota, Gerogetown factory, explained: ‘When I was at [an American auto manufacturer], if you didn’t run production 100% of the shift, you had to explain it to Division. You never shut the line off.’” (Jeffrey Liker. The Toyota Way. McGraw-Hill, 2003. page 130.)

Contrast this with Toyota, where production was and is secondary to quality. “Jidoka” is one of the pillars of the Toyota production system. Jidoka means that any worker on the production line has the ability, even the responsibility, to halt the production line whenever they see a quality problem. The production line remains halted until the quality problem is fixed.

Because of the American auto makers’ lack of focus on quality, they have struggled for past three decades to compete with the Japanese auto makers and to produce products that are relevant in today’s marketplace.

Now let's apply these lessons to enterprise IT. What is the primary concern of enterprise IT? Is IT more focused on quality or on production? Cleary, enterprise IT’s focus is production: implementing new applications and IT infrastructure, and performing operational work on existing systems. Metrics in typical IT departments are designed to measure IT production work: project completion and operational uptime. And can you imagine the firestorm that would engulf any IT staffer who dared to put the brakes on an IT project because of a quality issue? As we all know, enterprise IT must never stop the production line that continually builds and runs IT systems! There is no concept of Jidoka in enterprise IT.

Most enterprise IT shops have a hard time even defining quality. In other words, IT people don’t seem to know what quality means! Many IT folks harbor the notion that IT quality involves producing bug-free software or running systems with uptime at five 9’s. In reality, the quality (the fitness for use, the ability to satisfy the customers’ needs) goes way beyond those rudimentary notions.

How does enterprise IT measure its products’ quality, fitness for use, and ability to satisfy the customers’ needs? The answer is that, in general, enterprise IT doesn’t. Enterprise IT, just like our friends in the American automotive industry, has been geared for production at the expense of quality.

If enterprise IT were to begin measuring its quality, how would it go about that? To answer that question, one need only ponder a few basic concepts: What makes an information system useful? Why does the business pay for information systems? What do the customers of information systems need? The answer to all of those questions is “useful business information”.

An information system’s quality is not determined merely by its lack of bugs and its operational uptime. An information system’s quality is determined by the quality, completeness, accessibility, clarity, relevance, accuracy, timeliness, and overall usefulness of the information that it provides. An information system that provides useless information is useless, like an airplane that can’t get into the air -- utterly unable to satisfy its customers’ needs.

I know of lots of people in the IT industry who reject this idea of quality, and who maniacally focus on production instead. In effect, they say to customers, “If you aren’t getting the information that you need out of your existing information systems, let us produce another system for you.” I also know of lots of people in American automotive industry who rejected the idea of quality. They maniacally focused on production, and in effect said to customers, “If you aren’t getting the quality that you need out of your existing American car, let us produce another American car for you.” Eventually, automobile customers went to other sources (such as Toyota) to get high-quality products.

Are customers of enterprise IT going to other sources in an effort to get high-quality information products? You bet they are. Have you ever heard of “shadow IT” and “software as a service”? How about “cloud computing”? I personally know of one division at a large corporation that recently chose a SaaS product just so that they would no longer have to work with their enterprise IT department. Instances of businesspeople going around their IT department by adopting SaaS solutions are commonplace.

We in enterprise IT find ourselves at an interesting crossroads. Do we continue to focus on production at the expense of information quality? Or do we begin to focus on information quality at the expense of production?

When cloud computing finally arrives, I believe the choice might be imposed on enterprise IT. When technology becomes readily available in the cloud, how much demand will there be for those enterprise IT departments that focus needlessly on the production of more technology while neglecting the quality of the information that the technology is supposed to produce?

 (Source: Flickr, http://www.flickr.com/photos/gsgeorge/351029183/)

Those enterprise IT departments could end up looking a lot like Detroit.

Cloud Computing: Strategic End or Valuable Means?

Blogger: Lyn Robison

Cloud computing is a strategic endeavor. And like any strategic endeavor, understanding the conditions for success is the difference between success and failure. It is deceptively easy to lose sight of the strategic goal and to let the means by which we can pursue our goal become an end unto itself.

The struggle to implement information systems has become an end unto itself for many enterprise IT departments, without much consideration of whether or not those systems lead to any strategic goal. Likewise, cloud computing comes along, and implementing cloud-based infrastructure and applications becomes an end unto itself, instead of a means that we can use to achieve some desired outcome.

If cloud computing is indeed a means to an end, what is its end?

For those who don’t know the conditions for victory -- for those don’t know the goal behind implementing cloud-based infrastructure and applications -- their chances of success with cloud are pretty slim. When you know the conditions for success, success becomes possible.

If we could identify why the business pays for IT systems in the first place, that might suggest a path to success for cloud computing.

Even though the business asks their IT people to implement and operate IT systems, systems and technology are not all that the business wants from their IT department. Businesses pay for information systems not because businesspeople love technology, but because businesspeople need information to make decisions and do their jobs effectively. Clearly, businesses expect their IT departments to be proper custodians of business data and they expect information systems to provide businesspeople with useful information for making business decisions and for performing business processes.

So, if an IT person properly thinks of implementing cloud-based infrastructure and applications as a means, and providing useful information to businesspeople as the end, then that IT person understands the conditions for success with cloud. (And that IT person stands head and shoulders above all of those IT people who think of cloud computing as an end unto itself.)

The following blog posts suggest a few thoughts on data management and information delivery that work well within the cloud computing paradigm:

• Enterprise Data and “Which one?” vs. “What kind?”
• Three Guys Walk Into a Bar Code... 
• Are your assets fungible?
• Dear Mr. President, a Data Model for my Electronic Health Records Nearly Killed Me
• Change is Good
• Why would you ever want to do that?
• The product of an IT department
• It's all about Semantics

And, as always, please feel free to contact us in person by requesting a dialog via the Burton Group web site.

Enterprise Data and “Which one?” vs. “What kind?”

Blogger: Lyn Robison

Every competent IT department does data modeling and therefore knows what kind of information the buiness requires and what kind of data structures hold the enterprise’s information.

I realize that many IT departments have not performed adequate data modeling and don’t yet know “what kind” of information they have, but I am going to mention the need to go beyond type and to begin identifying instances. When dealing with enterprise information, it is often more important to answer “which one?” than “what kind?”

As I explained in my “Are your assets fungible?” post, when it comes to enterprise information, instances are often just as important as types – and sometimes more so. When you can identify the instances within your enterprise information, you can manage important business information across data silos. You can begin to do silo-bridging instead of silo-busting.

Imagine if you knew whether “Customer 57” in one silo is the same as “Cust XYZ” in another silo. Businesspeople could begin to do cross-silo joins of customer information. Now think about vendors/suppliers. Your enterprise could begin to consolidate purchases across departments to get better pricing and terms. Think about products, assets, employees, policies, decisions, etc.

In my Hippocratic Oath for Computer Systems post, I mention the fact that if information has to go from one human being, through a computer system, to another human being, the computer system should not get in the way. The computer system must not distort or damage the information. Sometimes this means that the computer system should not try too hard to understand the data, because if the computer data model is inadequate, the information will be distorted going into and coming out of the computer system. When transmitting information between humans, transmitting the instance without mucking with the meaning is often the best thing for a computer system to do.

Change Is Good

Blogger: Joe Maguire

Some people consider master data management (MDM) initiatives to be a sign of failure on the part of IT:  If the systems had been designed properly in the first place, we wouldn’t need MDM techniques to clean up the mess.  As my expressive young nephew would say, this is wrongedy wrong wrong. 

Many—perhaps most—data integration problems originate outside the realm of IT.  A casual scan of the daily newspaper can yield stories about data-integration problems in unexpected places, such as the obituaries or the fine-arts pages.

On April 30 of this year, 90-year-old Venetia Burney Phair died at Barnstead, in the county of Surrey, England.  She studied mathematics at Newnham College, Cambridge, and went on to become a chartered accountant and a teacher of math and economics.  But her greatest accomplishment occurred on March 14, 1930, when as 11-year-old Venetia Burney she proposed that the ninth planet in our solar system be called “Pluto.”  For this accomplishment, Mrs. Phair received a substantial New York Times obituary—in the neighborhood of 15 column inches.  (Remember this day; it might be the last time you ever encounter the unit “column-inches” used by someone who is not a historian discussing the quaint era of printed newspapers.)

By all accounts, Mrs. Phair lived admirably.  Pluto, on the other hand, has had a rougher time of it.  Pluto received one of the most widely publicized demotions in history.  It is our most famous ex-planet.  The hapless orb is not even unique: another ex-planet is Ceres, demoted to an asteroid in the middle of the 19th century when astronomers realized that there were hundreds of celestial bodies similar to Ceres.

By demoting Pluto on August 24, 2004, the International Astronomical Union created a far-reaching data-integration problem.  Textbooks, almanacs, and educational posters would have to be reprinted. Drop-down lists of the planets would have to be adjusted.  Board games about the solar system became outdated.

(On the plus side, Gustav Holst’s seven-movement orchestral suite “The Planets” would once again have one movement for each non-Earth planet in our solar system.  Holst wrote the suite in the early 20th century, before Pluto was discovered but well after Ceres had been demoted.  Why only seven movements? Holst excluded Earth because his metaphorical motivation was astrology, not astronomy.)

In demoting Pluto, astronomers were acting reasonably—doing what is right for their community of expertise.  Their motives were pure and utterly blameless.  IT personnel who are inconvenienced by the resulting data-integration problem have no cause to complain.

In fact, IT personnel should expect such disruptions.  Here’s another one:  The Antoinette Perry Awards for Excellence in Theatre, more commonly known as the Tony Awards, have created an interesting problem with the nominees for the 2009 award for Best Performance by a Leading Actor in a Musical.    There are five nominations:

1. David Alvarez, Trent Kowalik, and Kiril Kulish in Billy Elliot the Musical as “Billy Elliot.”
2. Gavin Creel in Hair as “Claude.”
3. Brian d’Arcy James in Shrek the Musical as “Shrek.”
4. Constantine Maroulis in Rock of Ages as “Drew.”
5. J. Robert Spencer in Next to Normal as “Dan.”

The problem occurs at the top of the list.  Three actors starring as Billy Elliot share the arduous, eight-shows-a-week load by alternating performances.  (A fourth actor, Stephen Hanna, plays the role of “Billy’s Older Self” in every show.  Hanna is not included in the Award Nomination because his part is considered to be a distinct role.)

The three-way shared nomination causes all sorts of problems.  Naturally, any structured rendering of the data that expects each nomination to consist of a single nominee will have to be redesigned. 

The disruption extends far beyond the storage structures.  Formatted presentations (e.g., reports and forms) about nominees will also need to be redesigned.

Even business policies and procedures can be affected. In previous years, each Tony-award voter could cast a ballot in a particular category only if he or she had seen all the shows.  Applied to the three-way nomination for Billy Elliot, the business rule is ambiguous.  Are potential voters required to attend five performances (one for each nomination) or seven (one for each nominee)?  The answer, according to the Tony Awards administration committee, is five.

That answer might seem strange, but that is immaterial to this discussion.  What’s important here is the need to ask the question.  Such questions—questions that clarify seemingly well-understood phenomena for which software has already been deployed—are commonplace.  Data-integration problems are not exceptional; they are the norm.

In acknowledgement of this state of affairs, software engineers are often encouraged to “plan for change.”  That can mean a lot of things.

One way to plan for change is to accurately predict the future.  Here, the state-of-the-art is immature.  Astrology might suffice as a metaphorical framework for orchestral suites, but it’s not so good for anticipating changing business conditions.  Other approaches are needed.

One result of the desire to plan for change: Software engineering practice, including modularization, information hiding, separation of concerns, generalization, abstraction, …  Software designs can be judged on how well or poorly they honor these principles.  That is, engineers can honor these principles by creating code that is appropriately generalized, abstract, modularized, etc…

Beyond these principles, there is another way to plan for change:  to expect change and to have in-place processes and techniques for coping with it.  These processes will include data governance; the techniques will include master data management.

In the absence of reliable seers, time machines, and other ways to peer into the future, the best approach is to classify the various potential changes to data requirements into abstract patterns, and to develop techniques that can apply to those patterns.  For example, two such patterns follow:

• Pattern name:  A maximum cardinality constraint changes from “One” to “Many.”

• Pattern name:  An enumerated type loses a value.

These patterns can be a linchpin of data-governance and MDM initiatives.  Data-governance processes can include decision points based on the type of problem pattern encountered, and MDM solutions can be planned based on the kind of solution pattern required.  The two patterns listed above correspond to “the Pluto problem” and “the Billy Elliot problem” respectively.

Allow me to predict the future: Over the next few months, I’ll be contemplating such patterns as they apply to data-governance and MDM initiatives.   I’m especially looking forward to describing some of these patterns at a day-long workshop on Master Data Management to be presented at Catalyst 2009 by me and my colleague Joe Bugajski.

Are your assets fungible?

Blogger: Lyn Robison

Some assets are fungible, and some are not. Fungible means that the asset can be freely exchanged or replaced with another of like nature or kind. Oil is fungible. One barrel of oil is considered identical to, and can therefore be replaced by, another. Other assets, such as grain, lumber, and ¼” sheet metal screws are fungible assets. There is no need to keep track of instances of these assets, just their quantity.

American dollar bills are fungible. One paper dollar is just as good as another. Dollar bills do have serial numbers, so you can go to Where’s George and see where a particular dollar bill has been. And the Treasury Department probably uses the serial numbers somehow. But in the business world (even though it seems like a dollar isn’t worth a half-a-buck) one dollar bill is just as good as another.

Used cars, OTOH, are not fungible. One 1987 Ford Taurus is not just as good as another. Automobiles have vehicle identification numbers, because it is important to identify each individual vehicle, because they all have different options, different histories, etc. Therefore, used cars are non-fungible assets.

When we, as IT professionals, build a database to hold important business assets – such as, say, a customer database, it is tempting to think of that data as fungible. It is tempting to think of filling up that database with data the way that we might think of filling up a barrel with oil. Sure, inside the boundaries of that system, we realize that we need to give each customer record a primary key, but it is tempting to use some auto-increment field to automatically generate that pk for each customer record, and then fill ‘er up!

The problem is that customers are not fungible: one customer is not just as good as another. It is vital, therefore, to identify each customer, and to do so beyond the boundaries of any individual IT system. This is in essence the data silo problem: the inability to identify non-fungible assets across data silos.

I know of a large non-profit organization (a church, actually) that owns thousands of buildings all around the world. I say “thousands” because they don’t know how many buildings they actually own. Multiple IT systems contain information about buildings: construction systems, maintenance systems, financial systems. Each of these systems uses its own pk to identify each building, and there is no way to reconcile these individual, non-fungible assets across the data silos. How do they manage these buildings if they don’t even know how many they own? The answer is, not as well as they ought to.

This is the problem that Burton Group’s MODS (the Methodology for Overcoming Data Silos) is designed to address. It gives you a methodology for identifying non-fungible assets across data silos.

Think this isn’t a big deal? Think about a large enterprise that could finally identify all of the vendors/suppliers from which the enterprise buys good and services. They could begin consolidating purchases with each supplier to get better prices and payment terms and save hundreds of thousands, if not millions of dollars. And this is just a small example of the value of tracking non-fungible assets across silos. Every dollar spent on CRM systems is a dollar spent (and often squandered) trying to solve the data silo problem.

Now think of the ability to reconcile non-fungible assets across data silos with regard to structured and non-structured data. If you could identify non-fungible assets beyond individual system boundaries, you could combine data about that asset from every system in the enterprise, including structured as well as non-structured data. This is another concept behind MODS.

We have published some guidance on MODS here. We will talk more about it at Catalyst. And you can look forward to additional guidance on MODS in the near future.

I've looked at Cloud from Both Sides Now

Blogger: Lyn Robison

Does anyone believe that cloud computing is going to deliver better business information to businesspeople?

When I ask that question, the answers I usually get are “no” or “kinda”. The people who answer “no” tell me that cloud computing deals with the cost side of the IT ledger: cloud is designed to reduce IT costs. The people who answer “kinda” tell me that cloud will make IT more agile, and if IT is more agile and responsive, businesspeople could conceivably get better information, because the feedback loop between businesspeople and IT will be shorter. The “no” answer I can believe, but I have my doubts about the “kinda” answer.

Don’t get me wrong. I am all for reducing the cost side of the IT ledger, and I am definitely in favor of IT becoming more agile. Cloud promises to do both of these things, so be sure to put me down in favor of cloud computing.

But when I hear people talk about driving down IT costs or making IT more agile, I can’t help but wonder when we as IT professionals might start working on the value side of the IT ledger. My reaction to all of this cheap-and-agile talk is, “Oh great, more bad data, cheaper and faster. The business is going to love that.”

From what I can see, IT delivers value by delivering useful information to the business. When considering the value side of the IT ledger, good data coming from IT systems is good and bad data coming from IT systems is bad. And in this case, “good” and “bad” both carry with them real consequences.

If you doubt the dire consequences of IT systems that produce bad data, check out my friend and colleague Joe Bugajski’s life-threatening experience with bad data here and here. Also take a look at bad data’s smoking gun that triggered the financial meltdown from which we are all currently suffering.

The reaction of IT people to these particular examples of bad data is often, “Those are business problems and are outside the scope of IT.” To me, that statement is wrong on so many levels that I have trouble figuring out how to respond to it. If you sincerely believe that IT should not try to be part of the solution to problems like these, I have no idea what to say to you. If, OTOH, you think that maybe IT should try to be part of the solution to the problem of IT systems that produce bad data, then I have some exciting ideas to share with you. (You can contact me directly, or you can visit the DMS home page.)

From what I can see, when we as IT people look at cloud computing, we should be eager to use it to reduce costs and become more agile. With cloud, IT’s technical infrastructure can perhaps fade into the background. But then what? When cloud finally makes technology a commodity, where does an IT department go next to improve itself in the eyes of the enterprise it serves? It seems like IT departments will have to use cloud another way: IT people will have to use cloud to deliver better information to businesspeople. IOW, IT people will have to use cloud to start thinking more about “I” and less about “T”.

“It’s tough to make predictions, especially about the future”(Yogi Berra), but when cloud computing becomes pervasive, enterprise IT people might have to become either “I” people or “T” people. In the future, “T” people might all go to work for cloud providers, and “I” people might all go to work for the business, leaving no one in the traditional enterprise IT department. Or, perhaps enterprise IT departments will transition from their current groups for “Plan”, “Build”, and “Run” into just two groups: “I” and “T”. The “I” people will help businesspeople get valuable business data into and out of the cloud, and the “T” people will manage the internal and external systems behind the cloud.

It seems clear to me that concentrating solely on the cost side of the IT ledger would be very shortsighted for an IT industry that is populated with lots of visionary people. For the good of our industry, somewhere, somehow, sometime, someone in the IT industry is going to have to devote some serious attention to the value side of the IT ledger.

So, when you consider cloud computing, be sure to look at cloud from both sides: technology and information, IT costs and IT value. Enterprise IT groups will need “I” people and “T” people to work on both sides of the cloud if we are going to satisfy the business with cloud computing.

Can old-school BI deliver?

Blogger: Lyn Robison

I gotta wonder whether old-school BI -- the way we have been doing BI -- can actually deliver the information that businesspeople need to make effective decisions. Here's why:

Humpty Dumpty’s data is in pieces, and all the data warehouses and business intelligence applications can't put his data back together again, because most of those pieces of data were never designed to fit together in the first place.

To be useful, data must accurately represent reality, and to represent reality, everything must be related. Much of the source data for business intelligence applications today comes from disparate, unrelated data silos. The notion that we can consistently create accurate pictures of aggregate reality using puzzle pieces from different puzzles is demonstrably overoptimistic.

Sure, BI and DW vendors create products that let us munge data from disparate silos together, but does the resulting information goulash actually reflect reality?

It seems to me that to be useful for analysis, individual silos of data need to fit within a larger information fabric. Burton Group has produced some guidance on this recently, and will produce more in the coming months. But I would like to hear your thoughts...