Informatica Perspectives

Now that the $700 billion dollar Troubled Asset Rescue Program (TARP) has been approved by the government, firms on Wall Street are preparing themselves for even more oversight and scrutiny by lawmakers and taxpayers. Survivors from the market meltdown will be required to establish tighter controls, policies, standards, and processes for managing and delivering trusted information for decision making, auditing, and regulatory reporting than ever before. [Read more]

In Chris Cingrani's recent post the question: "Data quality, does anyone care?" was posed. The answer is yes, of course people care about data quality – in fact, there are a lot of good reasons why a lot of people should care very deeply about data quality. Let’s look at the most recent example of where data quality makes a big difference, and that is in the federal election process. [Read more]

Over the last few months, I have had a number of discussions with clients at various stages of planning a data quality initiative. Some clients are just starting to take the data quality plunge, while others are evaluating how to leverage the successes of past projects into building out a formal data governance initiative. When I start talking to clients about their goals around data quality, I often start with the same basic question, regardless of where they fall from a maturity process around data quality. The question is simply – does the business care?

[Read more]

This blog post is part two of an ongoing series highlighting the importance of data in a Service-Oriented Architecture (SOA). I look forward to hearing your thoughts and input on the subject.

I'm back. It's been a little longer than normal, longer than I would have liked. Perhaps that’s because 'addressing SOA's data-centric pitfalls' isn’t easy. (Really it’s because I’ve been working on other things. But let’s get back to the topic at hand.)

One of the benefits of the SOA approach is the ability to think top-down about problems. The usual approach is to work tightly with the business to define your processes from a business perspective, leading to clearly defined services that the business understands and you can implement together.

This is wonderful and has a clarifying symmetry that Software Engineering has been trying to achieve since the days of CASE. But now, here we are in 2008 with the SOA standards defined and the tools available to potentially achieve this vision. Ah, finally, the integration hairball will be contained and life will improve immeasurably for all!

But as I talked about last time, one of the reasons that things aren’t that simple is the data-centric pitfalls. And addressing this problem is not easy if you want to take a long-term, enterprise-oriented approach.

In talking with folks who have walked down this path, struggled with data problems, and are trying to think holistically about a workable longer-term solution, three themes come up again and again: [Read more]

Governance is a tricky and ill-defined area. For example, in the emerging SOA space, listen to the drumbeat of messages from consultants, analysts, and vendors, and the message is clear: Service oriented architecture won’t work without governance.

However, establishing effective governance has been a vexing challenge, with a lot of disagreement and debate amongst governance proponents. [Read more]

 It is "all about the data" is the response to this blog post by Joe McKendrick on ZDNet

I couldn't have said it more eloquently than as described below:

"The data is a pivotal piece of an SOA (most IT approaches, really), and is often under-served by SOA initiatives and projects. Data is diverse, duplicated, dispersed, dirty, and just generally chaotic. You need to rationalize it into meaningful business information for the rest of the architecture to work well. This is the data abstraction layer that Ash mentions. This is not an ESB, but rather a data services layer that feeds an ESB and other components in the architecture."

In my previous posts and in the webinar that this post refers to, I have stated that SOA promises to deliver business agility by breaking down barriers between silos of applications, and by reusing business services. However, in speaking to a number of customers and prospects, it is becoming very clear that if the data stuck inside silos is bad, is stale, or is inaccurate, it does not matter if the most elegant architecture or technology is used. Data is at the heart of the modern enterprise and as pointed out in the referenced blog, data integration is the "pivotal" piece that can ensure the availability of accurate, consistent and timely information.

Doing top-down SOA governance is much harder that talking (or writing) about it. In my recent blog article Escaping the SOA Trough of Disillusionment, Dave Shearer reinforced the main argument that there is insufficient focus on SOA as a business concept by commenting that “a Burton Group report found 4/5 SOA implementations in their study group failed because they addressed technology integration adequately and business integration inadequately.”

But the challenge remains.  Exactly how can you go about implementing a governance mechanism that engages business executives – the ones that control the investment decisions – in a practical way?  Is there a proven methodology that actually works, or is top-down SOA Governance just one of those phrases we throw around without any meat behind it? [Read more]

In my last post, I talked about the enterprise integration challenges that still challenge enterprises, even if they have moved processes to cloud computing or Software as a Service providers.

Will integration issues dampen the enthusiasm around cloud computing? What's the role of data environments in these new scenarios? To address these questions, I recently had the opportunity to speak with Chris Boorman, chief marketing officer with Informatica, and Ron Papas, senior vice president and general manager for Informatica On Demand, about the enterprise data management implications of this growing trend. (Chris also recently posted some of his observations here.) [Read more]

In one of my earlier posts I mentioned that in order to effectively enable business agility, businesses need access to information at the speed of business, or what is called "right-time" information.

In that post I had also introduced the terms "Right-Time Information" and the "Information Latency Continuum."

In the recently concluded TDWI World Conference in San Diego, my colleague John Haddad recorded a podcast with Claudia Imhoff where he spoke on data latency issues, including the need to deliver data in real-time so organizations can operate at the "speed of business."

Listen to John Haddad speak about the "Information Latency Continuum" and the business value of timely and accurate information delivered across a range of latencies, real-time, near real-time and batch.

Maintaining product lists is often cited as a great example of Master Data Management (MDM). Many companies that manufacture or sell products need to get a consistent list of products for a variety of business reasons. The business value includes tracking what you sell to customers and also how you manage your supply chain. Product firms create products organically (internally) and through acquisitions. In both cases, each product line has, at least for part of its life, been operated as a separate business. At some point in the product life and sales cycle, business conditions dictate a transition into the company's product portfolio. Although managing product lists is not always a simple task, it is only the tip of the iceberg for companies that design or engineer products. These companies have a need for a more complete PIM (Product Information Management) solution that extends far beyond simple product lists.

If you design or engineer products, then you need to track product designs and configurations that evolve and change over time. This applies to many manufacturing industries from high tech, consumer products, defense, and automobile to even farm machinery. These designs and configurations are likely scattered across many databases and often unstructured data sources. This data is not stored in your classic data warehouse (DW) or integrated through your run-in-of-the-mill ETL tool. You need to think outside your typical DW effort and determine how to get that data integrated into your PIM solution.

I did work for a farm machinery company many years ago. Their product data issues involved configuring combines, harvesters and other machinery that cost six and sometimes seven figures. This data challenge was not a trivial endeavor. These farming machines are highly customizable by the agricultural organizations purchasing them. The vendor needed to track what was available, what was sold and to whom. The customers needed to know what was available for their agricultural needs, have those machines built and then be able to service them for years.

What have these companies done and what should you do if you are just starting to design and implement a PIM solution?

• Get your data warehousing and data integration in place to support the classic product, sales and customer data stored in your various source systems
• Work with your engineering and product design groups to understand what they have in place to manage engineering drawings, specifications, configurations and all the associated versioning
• Get your sales and customer support organizations to define the PIM requirements
• Implement a data governance effort to get a handle on both your structured and unstructured data
• Leverage data integration capabilities that can handle the variety of data supporting PIM

The business benefits are to both the top line (increased sales) and bottom line (managing and reducing costs) when engineering and product design firms implement a PIM solution.