Informatica Perspectives

In the post "SOA's Last Mile Part III: How to Address SOA's Hidden Data-Centric Pitfalls Effectively," David Lyle spoke about some high-level approaches to handling the data-centric pitfalls in an SOA.

I would like to introduce you to the solution…what I call data services, a flexible and cost-effective technology that can be the cornerstone of an SOA and EIM strategy by simplifying the complexity of both integrating diverse enterprise data that exists in individual silos as well as delivering a single, accurate and consistent view of all enterprise information, at the speed of business.
[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]

In one of my earlier posts I discussed the need for a sophisticated data services-driven technology serving as the foundation for SOA and BPM.

When I was poking around the web recently, I ran into a powerful statement by Michael Blechar from Gartner, covered in the DAMA keynote, titled Survival of the Data Management Fittest:

"Data and processes are intertwined. It will fundamentally change the way organizations think about your roles, and your roles are going to need to evolve".

At this year’s Data Management Association (DAMA) International Symposium,
Michael is quoted saying that:

"In this world there's a very loosely coupled user interface from the assembled services that in turn share access to data. SOA exposes data issues to more people, places and processes, and what I tell companies is that without a focus on information management and meta data management they're going to fail."

It is in speaking to numerous customers, prospects and technologists that I had gathered that without accurate, consistent and timely information, SOA and BPM deployments will face serious information-centric hurdles, affecting the cost-effectiveness and success of the project. As we move towards more agile architectures, I believe that we need to grow typical process-centric approaches to include information centricity as well.

As Michael states:

"Where we are going is beyond the first generation of BPM and SOA [that is process-centric]," he said, "to the next generation of SOA that is information-centric."

Observe that the key word here is "information-centric." Reading such statements from Michael and many others definitely validates the strategy I have been defining for building out an effective IT infrastructure that can benefit from the flexibility of a services and process-driven approach, in the data integration layer. Simply wrapping data access with a web service does not qualify as a sophisticated data service and hence, stringing together such simple services with a BPM tool also does not guarantee agility.

As discussed in Services to Orient your Enterprise Data Layer, Joe McKendrick is of the opinion that neither SOA nor enterprise-application integration alone can effectively handle the enterprise data layer. However, data services delivered within an SOA framework can create a data-abstraction layer to address the complexities seen across enterprise data environments.

I have always said that without serving up good quality, consistent and timely information as a data service or a comprehensive data service built using a sophisticated data integration platform, SOA and BPM deployments will not be able to deliver on their promise of agility.

What are your experiences? What kind of information-centric issues have you run into in your service-oriented deployments? Is inaccurate, stale and inconsistent information passing through your IT infrastructure holding you back?

 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.

In my previous post I made a statement that SOA and BPM overlooked the complexity of integrating fragmented enterprise data. As I looked around me across the vast expanse of the World Wide Web, I ran into someone else who says it exactly like it is – Michael Dortch.

In a recent post titled The Big Mash-Up, Continued: What Does BPM Want? in the BPM in Action Blog, Michael says that there are two things that matter the most. In his own words:

• “Need the First: The ability to base every business action, decision, and process on the most accurate, consistent, secure, and timely information available, without fail.
• Need the Second: The ability to answer the “Journalism 101” questions about that information – who’s using what, when, where, why, and how – accurately and completely, on demand at any time.”

He goes on to say that “Processes developed, enforced or revised based on inaccurate, inconsistent, or just plain wrong information are opportunities to make what we called sardonically in my young analyst days ‘career-limiting decisions.’”

So, as I have been saying, when it comes to leveraging the power of paradigms such as SOA and BPM, it does come down to accuracy, consistency and timeliness after all.

What do you think?