Monthly Archives: January 2008
It’s the data (integration) that enables BI
Ben Worthen in his Wall Street Journal “Business Technology” blog “The Death of Gut Instinct” discusses how:
“For the third year in a row, CIOs (surveyed by Gartner) said that ‘business intelligence software,’ which organizes and analyzes the data companies collect, was their top tech priority.”
Ben further comments:
“…information-technology departments have used those (previous BI) projects – which usually involved building a giant data repository and installing software that can look for trends in that data – as stepping stones to greater glory.”
I am very excited by the continuing growth of business intelligence and performance management efforts across enterprises of all sizes and all industries. There is real business value to these projects. Business people realize it, not just IT folks.
There is something, however, that concerns me because it is either being left unsaid or, worse, being taken for granted. Business people, and in many cases industry analysts and pundits, associate an IT project with the customer facing software. An IT project is then considered a Business Objects, Cognos or Hyperion project rather than, say, a financial data warehouse project.
(more…)
Why the “E” in EDW (Enterprise Data Warehousing)?
Since launching the EDM blog in early 2007, we have focused on a wide variety of data management, Informatica usage and technology topics. In 2008, I will also be discussing my experiences and research in Enterprise Data Warehousing, an area that our customers have used our software and solutions to great success.
Enterprise Data Warehousing is a term that has been around for a long time. In the mid-90’s, Bill Inmon preached an enterprise approach to data warehousing that was based on a central repository of corporate data. With the technology at the time, success was only attainable by a few elite organizations at extreme levels of funding. Informatica pioneered an incremental data mart approach that led to years of prosperity in the Data Warehousing market for Informatica and customers using our technology for their data warehousing related projects.
(more…)
IQ and Information Product Specifications Quality
One of the root causes of poor quality information is defects in the data definition, specifically the “information product specifications.” Because information is a product of our business, manufacturing and service processes, the analogy of an “information product” is real, and the requirement for quality in “information product specifications” is a critical requirement for Information Quality.
This blog is the first of a series of three blogs on the critical quality characteristics (or measures) of information quality required to achieve Total Information Quality Management.
- Information Product Specification Data Quality
- Information Content Quality
- Information Presentation Quality
What constitutes the “Information Product Specifications” data?
• Information standards
• Data names
• Data definitions
• Attribute valid value set or range of values
• Value format for structured attributes (VIN, SSN, Product Codes)
• Business rule specifications of constraints on data
• Information Steward accountable for data definition quality
(more…)
The Disconnect with Data Integration and SOA
Many companies are building Service Oriented Architecture (SOA) initiatives apart from data integration projects. Since information is one of the key ingredients to creating business value from SOA initiatives, how could this disconnect be occuring?
A few characteristics of IT projects are causing this application stovepipe to happen.
First, IT has, for decades, continually developed applications or implemented infrastructure on a project-by-project basis. Rather than viewing their enterprise holistically, companies continually look at their projects with a narrow focus. Although this limits scope and maybe improves a project’s chance to be completed, it is shortsighted since too much overlapping or conflicting work occurs.
Second, IT has a tendency to segment its work by the technology that is used rather than what processes are being built. IT assumes that since SOA is “new,” it must be different than all the “mature” data integration software technologies such as ETL, EAI and EII.
Finally, companies keep looking for the “silver bullet” of technology to solve all their data problems. Why work on an overall data integration approach when SOA solves it all with no mess or fuss? If only you could buy data integration in a can!
What should companies do?
• Establish an Integration Competency Center (ICC) that has responsibility for an enterprise architecture
• Develop an overall data or information integration architecture
• Implement the data integration architecture using SOA along with ETL, EAI, EII and data quality software
SOA can provide tremendous business benefits if driven by implementing a data integration architecture that provides business people with the information they need for running and managing the business.
But if SOA is driven solely as an infrastructure or technology initiative do not be surprised if the business group questions its value and pulls funding when they don’t see an ROI.
Happy New Year! And the Business Value of Data Lineage
Happy New Year! I look forward to discussing a myriad of Enterprise Data Management topics with you this year. My work with customers never stops and I’ve made a 2008 resolution to share as much of their success as possible. I’ll start with one of the oldest but least addressed problems in Data Integration.
Have you ever asked yourself or been asked, “Where did that number come from?” or, if you’re in IT, have you been confronted by your business colleagues with “Those numbers don’t make sense!” I find these to be very common questions that consume hours and days of business and IT analyst time. Think about it, at the grass roots level of every company or organization, the amount of time spent deciphering numbers from reports is staggering.
This challenge starts from the very beginning of intelligence gathering, underlying data from operational systems. It’s why the first step in any data integration project (DW, Migration, MDM, Consolidation, etc…) is to understand and map out the nature and location of the data appropriate for the business problem at hand. An estimated 70 percent of the time spent on any corporate application development is dedicated to finding, identifying, reconciling, and verifying data, and then determining the consequences of modifying the data. This is what makes traditional integration projects so time- and resource-intensive—and what makes metadata so useful in exercising internal control or streamlining a myriad of related activities. The recent Informatica Release 8.5 launch highlighted “data lineage” for helping IT resolve questions for the business as well as providing “self service” for answering data-related questions for analysts and developers.
(more…)
MDM is not a product
Rob Karel, Forrester Research, Inc. (FORR), wrote an interesting year-end review of his 2007 Master Data Management (MDM) forecasts in the Forrester Information Management blog on December 26th. Rob hits on a few themes that I am constantly discussing with clients and colleagues:
“While all of the product development, marketing, and M&A activity coming from the MDM vendors is interesting and entertaining, the most valuable and insightful information about the evolution of the MDM market comes from the Forrester customers I speak to every day. Unlike my coverage of more mature data integration technologies like ETL where vendor selection is the most common question asked, I rarely field questions about MDM vendor selection. Regarding MDM, these customers are more concerned about data governance, organizational readiness, architectural strategy, business case development, prioritization, and the biggie — do we really need to worry about MDM? If so, why?
What does it all mean? I’m happy to report that it means you are asking the right questions at the right time. …be sure your organization is prepared to deal with the cross-functional and technical complexities of adopting a master data management strategy….”
My contention has always been that MDM is not a product solution, but a process with the key ingredients being people and politics. If you don’t have data governance and an organization ready to commit to an ongoing effort to implement and keep MDM going, then it does not matter what product you buy.
(more…)
Loading ...