Thanks,

The Informatica Team

ShareThis

We all know how mandates such as Sarbanes-Oxley place a burden on many businesses, by requiring that they be able to document the reliability and quality of data. Most major mandates, which have now been in place for several years, have given rise to a whole industry dedicated to reporting. In many companies, the equivalents of small departments have been kept busy 52 weeks a year doing little more than generating reports and reviewing data to meet compliance requirements.

Obviously, things can't go on like this. Rather than spending money to just keep simply meeting requirements, many companies are seeking to better integrate compliance into their day-to-day operations in a more automated, systematic form. In doing so, they seek to go far beyond meeting the letter of the law, to take the opportunity to improve and streamline their own processes - which will pay off in battling the challenges of an increasingly competitive marketplace.

By eliminating the silos that have separated data across the enterprise, as well as the silos that have pigeonholed the compliance efforts intended to gather and report this information, organizations can make impressive strides in moving forward with greater agility. In the process, automation can reduce the burden of paperwork and manual processes that drive up the costs of compliance.

Such "sustainable" compliance management can be built on top of three disciplines that already exist within most businesses today. These include governance, or the oversight of corporate activities and processes; risk management, or the identification, assessment and monitoring of risks and controls; and compliance management.  This integrated approach - known as Governance, Risk, and Compliance Management, or GRC, takes its three namesake disciplines and takes a more holistic approach to increasing information visibility and management.

Most importantly, GRC brings together teams of people that normally would not be working with each other. The distinct categories of governance, risk management and compliance were often run by separate groups of specialists. Companies increasingly recognize that there needs to be a single focus –that finance, IT, security and operations teams need to be engaged in a common purpose of bringing greater flexibility and transparency to the way data is managed and dispersed throughout the enterprise.

Because the ultimate goal of GRC is to deliver higher-quality information, there's an important role for IT and data managers within the process. In fact, while many early GRC initiatives were led by auditing and finance departments, IT and data management are increasingly taking on a leadership role. Forward-looking companies are encouraging greater interaction between their IT and finance departments to devise strategies and automate and streamline the compliance reporting process. In fact, the governance aspect comes into play as managers from various functions need to be brought together to address compliance management.

As Lee Dittmar, a principal with Deloitte Consulting LLP, and a thought leader in GRC, observed: "As leaders strive to meet the raised bar on corporate governance, to achieve better risk mitigation and to meet increasingly complex compliance challenges, a common element is recognized as being critical: high-quality information. They need the right information, at the right time, at the right place, and in the right form. They need relevant, timely, accurate, transparent, and reliable information."

This requirement for higher-quality information "puts intense focus on IT's role as a key enabler for improving GRC connectivity - helping uncover its collective synergies and boosting support of stronger, more efficient businesses," Dittmar adds. "Yet CIOs and IT managers find themselves still wrestling with organizational fragmentation and resistance issues, such as ongoing complexity in the corporate silos and continuing manual processes. It's difficult to create a more ideal environment, in which decentralized units are bridged and systems and controls exist on a common platform when they're not free to fully explore all of the possible interrelationships and common dependencies inherent in GRC."

In fact, Dittmar relates, eight out of ten decision makers in a Deloitte survey still had misgivings about their ability to better leverage their companies' financial information in forward-looking planning a strategy. "This analytical ability to gain insight from experience is needed to drive better modeling, planning, and forecasting," he said.

Last year, as part of my work with Unisphere Research, I conducted a study of members of the Oracle Applications User Group (OAUG) to assess the depth of IT and data managers' roles within the emerging GRC process. The survey found plenty of awareness of GRC as a unified concept - four out of ten respondents were aware of GRC. At least 40 percent had some adoption of GRC principles taking place within their enterprises, a figure that rose to 60 percent among the largest companies.

Not surprisingly, time, paperwork, and money were seen as the greatest obstacles to GRC initiatives among the companies studied. Half of the respondents still relied on manual tools and procedures to meet GRC objectives. The main applications of choice to handle GRC processes included word processing documents and spreadsheets. Even though most respondents to the survey were fairly enlightened about GRC, they reported that it had yet to be embedded with ongoing business processes - and was still treated as a one-off activity.

AMR Research estimates that the entire GRC market will total about $32 billion this year, up more than seven percent over 2007 levels. John Hagerty, AMR analyst, reports that most of this spending is going to labor and implementation costs, versus software and systems.

Thus, it's no surprise that for most respondents, time - or lack thereof - is the main burden placed upon them in supporting compliance activities. Staff, for example, must be allocated to address ongoing compliance reporting. The OAUG study, in fact, found that most large companies assigned anywhere between four to five full-time employees to manage their compliance processes. Another 29 percent said GRC processes impose additional cost burdens on their organizations - including increased costs for labor, contractors, and overtime pay to handle all the additional reporting and interfacing between business units.

Approaching GRC with manual tools and processes, of course, doesn't promote long-term sustainable compliance, or business value. Instead, the result is duplication of effort and ineffective risk management. Instead of automating repeatable processes, organizations end up constantly rebuilding and throwing money at the same reports over and over again. Every quarter when compliance reports are due, new efforts need to be geared up. An integrated and automated approach to GRC turns to technology to make the process more transparent and seamless.

As Dittmar reported, GRC brings to light the need to be able to transform overwhelming amounts of data coming in from all corners of the enterprise into "information that serves as a strategic asset of the business."

ShareThis

To paraphrase the Paul Simon song, there must be 50 ways to integrate your enterprise data. In recent years, companies have made all kinds of attempts to integrate both their applications and data - employing techniques from sophisticated enterprise application integration projects all the way down to manual hand coding. However, while most of these approaches work at least some of the time, few, if any, are delivering real agility for their businesses.

Recently, I had the opportunity to moderate a Webcast - sponsored by Informatica and hosted by ebizQ - which explored in detail an emerging approach, called data services, which ties into service oriented architecture (SOA) and creates a data abstraction layer that addresses the complexities seen across enterprise data environments.

Leading the Webcast were Ash Parikh, principal product marketing manager for Informatica and a highly regarded industry speaker and author, and David Ramos, director of business intelligence and analytics for LinkShare Corporation.

In his presentation, Ash urged closer collaboration between the enterprise data management and emerging service oriented architecture (SOA) worlds. (John Schmidt recently provided a nice overview of SOA here at the EDM blogsite.)

Ash observed that current approaches to enterprise data management have worked well from an application point of view, but have been ineffective for enterprise data. "They're the wrong tools for the right job," he said.  The problem, he explained, is that while many of these solutions do a great job of addressing issues at the application layer, the data layer still remains an untamed frontier.

"There has been a proliferation of business services such as BI apps and portals," Ash explained. "There are various integration technologies out there such as EAI, which are very application centric. They do a remarkable job of handling integration challenges at the application layer." However, he continued, while spectacular progress has been made in this area, enterprise data has been a poor cousin. Current integration efforts assume, incorrectly, "that the data that has been served up to these businesses services is of the highest quality," Ash explained:

"There is little or no reuse of the data, and there are inaccuracies and inconsistencies. These services did not address various data latency requirements and data volume needs. The confusion has been sorted out at the upper layers, but still exists now at the data layer. Along with that comes poor governance of enterprise information sets. This doesn't make an effective foundation for enabling business agility."

While EAI itself is a vast improvement over manual coding of integration code, it falls short when it comes to addressing requirements within the enterprise data layer. "That leaves limited extensibility or reuse across various projects," Ash said. "There's no way to know the origin of data, or how it's being used. It requires elevated levels of ongoing maintenance. There's no support for data movement, and there's no easy way to automatically detect changes in various data sources."

While SOA can pick up where EAI left off, SOA alone will not address the vexing issues of enterprise data integration. "SOA promises to deliver business agility by breaking down barriers between silos of applications, and by reusing business services," Ash said. "However, if the data stuck inside silos is bad, is stale, or is inaccurate, imagine the calamity. The silos may disappear, but then data from many different applications becomes co-mingled."

The issue isn't simply about enabling access to data across the enterprise, Ash said. The greatest challenge enterprises face is ensuring the quality of the data that becomes accessible as a result of SOA. "Enterprise data is complex, it's about volume, latency, and many formats. It requires that as part of SOA, data be treated as a strategic enterprise asset that addresses the various data integration challenges."

The way to accomplish this purposing of enterprise data assets within a SOA environment is through the delivery of "data services," Ash continued. "Data services is a highly flexible simple and cost-effective solution that provides the model and standards-based reusable abstraction layers that lower the complexity of delivering data from silos. Data services deliver a single consistent view of all enterprise data at the right time."

From a technical viewpoint, a data service is a modular and reusable well-defined business relevant-service that leverages established technology standards, he adds. A data service "enables access integration to right time data throughout the enterprise and across corporate firewalls. Data services create an abstraction layer to all analytical, operational information, and serves it up to other abstraction layers, which could be an [enterprise service bus]," he says.

Many organizations today are struggling with the complexity of multiple systems and data sources.  The combination of data services delivered within a service oriented architecture framework offers relief and far greater agility from the slower and more expensive methods that prevailed in the past.

ShareThis

Healthcare is one of the last industries where you hear the term MDM (Master Data Management) mentioned. Most IT industry analysts, software firms and consulting organizations are geared towards your typical company that sells products to people or businesses. MDM examples are always getting a master list of products or cleansing your way to a consistent list of customers, which is not exactly the mindset of healthcare organizations. But lack of MDM is precisely what is adding untold costs on healthcare organizations (and ultimately on all of us) and inhibiting these organizations from improving the quality of health care services at an affordable cost.

Let's divide the healthcare industry (simplistically) into insurers and providers (we will position pharmaceuticals, biotechs and medical device companies as life sciences). Many of the large insurers have invested in data warehousing and data integration, but smaller insurers, i.e. regionally based HMOs (healthcare maintenance organizations) and healthcare providers, such as hospitals and physician groups, have fledgling efforts or have been bogged down in many of the issues below.

Healthcare organizations have significant data consistency issues regarding the following data subjects:

• Patients
• Physicians
• Procedures
• Diagnosis codes
• Service Rates
• Pay for Performance (P4P) measures

Each insurer and each healthcare provider tracks this data differently. The problems are magnified because healthcare is regulated on a state by state basis along with federal and industry regulations. Throw in privacy and security concerns to exacerbate what healthcare groups need to deal with.

Most healthcare organizations, even large ones, are an affiliation of generally small physician groups. These groups may be your local doctor's office, i.e. primary care physicians (PCP), specialists or emergency room (ER) providers. Often these groups do not have a lot of IT resources at their disposal.

Data flow is often flat file transfers between insurers and healthcare provider organizations, as well as from the individual physician groups and the larger provider organization. These flat files are generally not standardized and change each year when contracts are renegotiated between insurers and providers. This is an industry where you typically are not in control of your source data. It is thrown at you and you have to deal with it.

The need for an MDM is significant at healthcare organizations. The benefits from MDM are

• Data consistency
• Productivity
• Enabling more cost effect patient care

It is remarkable when one looks at the amount of resources devoted to manually dealing with inconsistent master data throughout health care. People in this industry do an amazing job of dealing with it, but it is often a time-consuming manual effort with much reconciliation. Having an MDM program would improve overall productivity and enable organizations to process and react more quickly to patients, insurers, employers and physicians.

A hidden jewel of an MDM effort though is enabling health care organizations to provide more proactive care. I have seen healthcare providers develop data solutions oriented to specific populations of patients who have diseases, chronic conditions or are at specific risks. These solutions may be for diabetes or asthma, for instance.

By bringing in historical clinical or demographic data related to patients tied together through consistent master data and taking advantage of predictive analysis, health care providers can proactively help their patients rather than waiting for the next episode when the patient's health has worsened. Many insurers are linking Pay for Performance (P4P) programs with these kinds of efforts because a healthier patient is a great goal by itself but better health also means lower health care costs.

The MDM silver bullet product has not been invented for healthcare industry but these organizations should not despair. There are concrete steps these organizations need to take.

• First, healthcare organizations need to examine where they are spending their resources on handling inconsistent master data and focus their efforts on those areas.
• Second, the efforts need to be in collaboration with business operations, physicians, insurers and IT, and need to involve defining master data and performance metrics.
• Finally, such organizations need to leverage their data warehousing and data integration efforts.

ShareThis

The most recent TDWI Boston Chapter meeting focused on how companies should approach and implement Master Data Management (MDM). Although the meeting had a keynote presenter and panelists with strong industry expertise and experience, the key to the discussions were the questions and insights of the audience attending the meeting.

The Boston chapter, with industries representing financial services, insurance, high tech, medical devices, biotech, retail, professional services and consumer products goods companies offers a diversity of perspectives about the challenges and benefits of addressing MDM.

Two key insights kept being reinforced during the discussions:

1. Leverage, Leverage, Leverage

Any company that will benefit from tackling MDM has most likely already been attacking the problem but not in the focused manner that MDM needs to truly be successful. But the biggest mistake that people saw with their peers and early adopters was the belief that MDM was something different than before.

Too often MDM is pitched as a "green field" opportunity with some solution as the "silver bullet" to one's problems. This approach fails to leverage past efforts from a business and technical perspective, thereby creating the potential for yet another application and data silo.

And, more importantly, failing to realistically assess the shortcomings and successes of existing efforts in making master data consistent is a sure fire way to plan to fail, i.e. repeating the failures of history is inevitable if you fail to learn from them.

Participants suggested looking at existing data warehousing and data integration efforts to leverage data, technical and people resources. Learn from the past.  Turn your joint IT and business efforts to define and manage data into a full-fledged  data governance program. If you have already started that type of program, expand  it and tie it into business successes (below).

2. Business Value

There needs to be specific business value derived from your MDM efforts. Catch phrases like "360 degrees of the customer" or "single version of the truth" are great marketing slogans but are esoteric and will become the brunt of jokes if they don't help you achieve real business value that can be measured. You can use these slogans to rally the troops and to get funding for the MDM efforts, but don't fall into that trap of believing your own sales pitch.

Your MDM will undoubtedly provide business ROI. Participants stressed that you should seek out those business opportunities and target your MDM towards them. Focused MDM efforts are more likely to get business participation, a critical success factor, to help you be on track to building your MDM program. Trying  to boil the ocean, i.e. trying to solve everyone's problems all at once,  generally fails to solve anyone's problems.

There are countless business processes or analytics that can be and are improved  by implementing MDM in your company. Find them, document them and determine  the business ROI that you can quantify or qualify. Get the business people involved  to be your customer references to sell the MDM program.

Success breeds success.

ShareThis

SOA has nothing to do with technology. It has everything to do with defining and managing the business as a collection of service functions and information exchanges. A business may be viewed as an internal organizational unit within a large company that provides services to other other units and consumes services from yet other groups. Or if you view the business as the company overall at the macro level, then you could define and manage the business as a collection of services consumed from its supply chain and provided to its customers.

All of these service interactions require information to be exchanged. The information may be verbal or written, structured or unstructured, and is governed by service level agreements which may be explicit (contracts) or implicit (based on past behavior or industry norms). For example, a customer orders a hamburger (verbal information exchange), receives the order within a few minutes (implicit service level in a fast food restaurant), and pays with a credit card (structured information exchange).

All of the service flows inside a company or outside in the supply chain can be described (modeled) as functions with information inputs and outputs. Furthermore, a holistic model of all the functions in an enterprise or supply chain and the information exchanges between them will quickly identify which services are used by more than one consumer and therefore are opportunities for re-use and for investment in process improvements. This is a service oriented architecture.

Note that to this point I have not said anything about technology. Technology is an implementation detail which by most definitions is not “architecture”. Architectures are the plans and models – not the systems that result from them. There is of course such a thing as “technology architecture” which, in the case of service-based information exchanges may include protocols and standards such as SOAP, XML, WSDL, HTTP, MQ and REST among others.
When IT professionals speak of SOA, many of them are actually talking about technology architecture. My point is this – unless you take a business view of service orientation (which has nothing to do with technology) you shouldn’t call it a service-oriented architecture. If the focus of your SOA is on the technical implementation details, then you should call it application integration architecture or something like that.

This is the root cause of the trough of disillusionment when it comes to SOA. SOA has been promising lower costs and agile business processes for years, but the enabling technologies alone won’t provide the benefits (except by accident). Business flexibility and service re-use arises from a clear view of the business as a set of service functions and information exchanges. Once you understand the business in this context, the opportunities for technology solutions to support the business become clear and the path out of the trough of disillusionment and onto the plateau of productivity is illuminated.

ShareThis

The most recent TDWI Boston Chapter meeting focused on MDM (Master Data Management). The keynote presentation titled “MDM: Data Salvation or the Next Round of Silos?” was followed by a panel discussion. The panelists included representatives from IBM, Oracle (Hyperion), SAP (Business Objects) and Kalido.

In keeping with TDWI principles, the panel discussion concentrated on the how’s and why’s of MDM in customer situations and avoided sales pitches. I moderated the panel discussion and was very impressed with the panelists’ knowledge and insights on their customers’ experiences in approaching and implementing MDM.

The panel discussed the most common characteristics that customers who are experiencing success in their MDM efforts have:

“Educated consumers”

There is a men’s clothing store that has an ad that says an educated consumer is our best customer. That is absolutely true in MDM. Companies that have been involved in data warehousing and enterprise data integration understand the complex and conflicting world of trying to get consistent, comprehensive and current master data or conformed dimensions in DW terminology.

Significant business participation

MDM is not a program that can be undertaken with IT alone. In fact, if you do not have business participation in the beginning there is little chance of success. IT has to sell the MDM program to the business and get real resource and time commitments.

Data governance program

Data governance is more important than what products you use to implement MDM. The old saying about garbage in, garbage out (GIGO) is absolutely true in MDM. You can’t cleanse data nor make it consistent unless you can define the data, business rules/transformations and performance measures you wish to use across your enterprise.

Enterprise Data Integration

Companies that have been implementing enterprise data integration efforts can leverage those efforts in their MDM program. They have gained an understanding of the complexities that a formal MDM effort will entail. For these companies MDM is not a new thing but simply taking their EDI efforts to the next level.

MDM is a journey and companies that have been in the trenches trying to address the problems of inconsistent data are well-positioned to take the next step.

ShareThis

Many thanks to Loraine Lawson who wrote an insightful article on her blog Classifying Integration Initiatives as Tactical or Strategic Her posting got me thinking. 20 years ago we didn’t need Integration Competency Centers – now we do. What changed?

From my perspective, there are three key drivers:

First, organizations have gotten bigger. The Fortune 500 companies today are much larger in terms of revenue, number of employees and global operations than Fortune 500 companies in the 1980’s. This conclusion is based on personal experience and anecdotal evidence. If readers of this column have seen any studies or statistics on the growth of large enterprises, please speak up.

Second, data diversity and volume has been growing at an exponential rate. We now have data in multiple formats such as video, images, audio, and text to name a few – and in multiple protocol formats and multiple languages. On the volume front, I recall an article from a few years ago that stated that manufacturers of storage devices would ship more than 22 exabytes (22 million trillion bytes) of hard disk capacity in 2005 - which is four times the space needed to store every word ever spoken by every human who has ever lived. In a relatively short number of years we’ve seen data storage capacities move from megabytes, to gigabytes and terabytes – now we’re talking in petabytes and exabytes. And coming soon are zettabytes and yottabytes.

Third, information technology has become more complex. One of the first principles of computer science is that re-use and decoupling of components is enabled by adding an abstraction layer. When I started my career (roughly 30 years ago), I was loading programs into computers using paper tape readers and toggle switches (I was pretty good at reading octal and hexadecimal code in my prime). But with increasing layers of abstraction – macro code to structured programming languages to 4^th generation languages to graphical integrated development tools to cloud computing in a web 2.0 environment – we have increasingly distanced the user from the underlying hardware and micro-code. Computers basically still work the same as they did 30 years (binary logic gates), but they are much more powerful, easy to use, and interchangeable which has been enabled by layer upon layer of abstractions.

The common elements across these drivers is constant change and growing incompatibility and complexity. Business processes are constantly changing with broader global scope adding many complications that are not transparent. Data definitions are constantly morphing and volumes are increasing to massive levels as everything becomes digitized and more regulated. Technology waves are constantly adding new variations and complexities without retiring prior generations.

Ergo, we have seen the emergence of integration as a new discipline which didn’t exist 20 years ago because it wasn’t needed then. In the 1980’s, integration was viewed as a one-time project discipline, not as an ongoing capability that an organization needed to sustain efficient end-to-end operations in a complex pattern of incompatible components that are constantly changing.

We could say that projects require micro-integration techniques while the complex systems-of-systems that emerge over time at the enterprise and supply chain scale require macro-integration best practices such as Integration Competency Centers. The ICC disciplines are a powerful capability, but they are non-trivial and hence those organizations that do it better than others will have a competitive advantage.

ShareThis

It seems in recent years pundits and vendors alike have been applying the 2.0 label to everything and anything emerging across the technology plain. In some cases, the new label has stuck - witness the widespread adoption of the terms 'Web 2.0' and its business sibling, 'Enterprise 2.0.'

In some cases, it’s a case of marketecture, but yet, the 2.0 identifier does convey a certain sense of maturity – that a technology is moving to a new stage of sophistication, of engagement with the business and its end users.

There have been moves afoot to identify the next generation of data warehousing as "Data Warehouse 2.0." However, there are differences of opinion as to what exactly will constitute DW 2.0, and thus no clear standard sense of direction in the market.

Some see DW 2.0 in tune with the Web 2.0 phenomena, that is, being delivered as on-demand analytical capabilities delivered via software as a service. Others see DW 2.0 as another step above the data silos of yore and moving in the direction of greater cross-enterprise capabilities. Still, other industry experts view DW 2.0 as supporting more intelligent lifecycle-oriented data stores that can archive and analyze all forms of data, structured and unstructured.

Forrester analyst Jim Kobielus, for one, relates Data Warehouse 2.0 to two emerging phenomena: (1) turnkey, analytic databases or appliances that can be dropped into an operation, and (2) analytic capabilities delivered via the "cloud" as an on-demand service.

Kobielus predicts many companies – short on staff and expertise – will turn to inexpensive analytic horsepower available via subscription-based data warehouse services. "As it becomes available from many service providers, DW 2.0 will offer an ever-expanding supply of inexpensive, plentiful analytic horsepower," Kobielus writes. "Over the coming decade, software-as-a-service (SaaS) providers will begin to offer feature-complete, subscription-based business intelligence/data warehouse services for high-performance, high-volume, complex analytics. These clouds will leverage the full virtualized, distributed, scalable, grid-computing fabric that [vendors] can bring to bear on data mining, performance optimization, and other compute- and data-intensive tasks."

Bill Inmon, the guru of gurus for data warehousing, published a definition of Data Warehousing 2.0 a couple of years back. DW 2.0, as Inmon describes it, includes "many integrated features that were never found in the first generation" of data warehouses. In addition to integrated transaction data, DW 2.0 includes qualified and edited unstructured data in several forms: integrated metadata, including both business metadata and technical metadata, online high performance data that can be updated, reference master data, profile data records, and continuous time span data.

Inmon arrived at his definition of DW 2.0 well before others came along, which he clarified in an interview in Data Management Review a couple of years back. Inmon explained how there is a need for a vision for the future of data warehousing, "which I believe a lot of people in the industry have wrong," he said. "It came from confusion and from vendors trying to sell products. There were people building transactional systems they were calling a data warehouse; people building federated versions of a data warehouse; people building data marts that they were calling a data warehouse. Those are just some of the renditions."

The main distinction between DW 2.0 and DW 1.0 "is that the DW 1.0 never recognized the lifecycle of data within the corporation," Inmon explained. "DW 1.0 said, 'Here's some data.' DW 2.0 says, 'Here's the data; it has a lifecycle, and each of the different portions of the lifecycle have unique characteristics.'" Another major difference, Inmon went on to say, "is the recognition that unstructured data and structured data should both contribute to the data warehouse. There is a wealth of information in the world of unstructured technology, but it has to be built properly for the data warehouse."

Dan Linstedt also delved into the promise of DW 2.0 offering the ability to manage structured and unstructured data and everything in between. He also sees Data Warehouse 2.0 offering the establishment of a common data model that can be applied across the enterprise. As he related in a recent blog post, while enterprise data warehousing is supposed to reduce the incidents of stovepiped BI approaches seen in spreadsheets and spreadmarts, many data warehouse sites may get so complex and far from its original design that end-users end up running back to spreadsheets.

As Dan explains it, the typical "star-schema" model works well and is cost effective for the first series of DW implementations. However, by its fifth or sixth iteration, things get too complex, and the original designs of the DW become lost or distorted, Dan explains. "Too many different kinds of data are added to the dimension 'to conform it to the enterprise' which distorts its original purpose." In fact, if done improperly, "each time IT increases the size of this monster, it always creeps in to higher cost, and longer implementation timeframes."

Thus, agility is lost, and "a simple 'change' that the business has to make (that used to cost $150k and take 90 days) now costs well in to the $350k range and takes six months or more, Linstedt related. What was a conformed dimension now becomes a "deformed" dimension, and has trouble meeting the business needs." As a result, the business users do their own workarounds of this clumsy enterprise beast — which means going back to relying on spreadsheets.

DW 2.0, Dan relates, "comes with the standard definitions that the industry has lacked over the years, finally and at last we have standards, definitions, and frameworks to follow." Plus, an essential piece of DW 2.0, Dan believes, is putting the right data model in place.

And, perhaps with the right data model and the associated rules enterprise-wide, it would make it easier to make a business case. Because now they can see and feel how data relates to business metrics and performance measurements. It’s no longer an abstract technical concept; organizations can actually assess how their strategies are working in operational terms.

ShareThis

This Wednesday, June 25, I have the privilege of hosting a Webinar featuring Ash Parikh, Informatica’s Principal Product Marketing Manager and a well-known author and speaker on enterprise data integration issues. Ash will be joined by David J. Ramos, Director of Business Intelligence and Analytics at LinkShare, an Informatica customer that provides online marketing services.

The Webinar, entitled Data Services - Maximizing Business Value Through Right-Time Information, is sponsored by Informatica and will be available live via ebizQ at 12:00 pm Eastern Time.

UPDATE: Archived replays of the Webcast are now available on demand.

Ash Parikh will discuss why many of the current approaches to integration - such as enterprise application integration (EAI), enterprise information integration (EII), and many manual processes still in use – are not giving organizations the agility they need to move to truly real-time, customer-focused enterprises. He will discuss an emerging approach - called data services - that creates a data abstraction layer that opens up all these formerly unreachable data stores across the organization.

David Ramos will explain how LinkShare, which handles 40 GBs of data across 300 million transactions a day, is employing Informatica technology to deliver grid-based data integration and meet the growing real-time data demands of its customers.

This promises to be a very informative and engaging session. Again, the live presentation will take place this Wednesday, June 25, at Noon Eastern Time.

Archived, on demand replay available here.

ShareThis