Organizations have been implementing factory elements for years using a combination of custom workflows and standard Informatica functionality. If we go back to PowerCenter 6 or earlier, some organizations implemented shared capabilities and self-service portals using custom metadata extensions and custom user interfaces.  Every successive release of the Informatica platform has added more and more out of the box capability to the point were Informatica 9 is the most sophisticated “out of the box” factory yet. 

To be clear, there is always room to add even more automated capability so the ICC staff and Lean Integration teams will continue to have opportunities for even greater efficiency and improvements in productivity and cycle-time, but the out-of-the-box functionality is a huge step in enabling highly efficient integration assembly lines. As a refresher, here are the 7 lean principles:

1. Focus on Customer, Eliminate Waste (i.e. "green")
2. Continuously Improve 
3. Empower the Team
4. Optimize the Whole
5. Plan for Change and Mass Customize
6. Automate Processes and Deliver Fast
7. Build Quality In

Let’s compare these principles to the primary themes and focus of Informatica 9: SOA-Based Data Services, Pervasive Data Quality, and Business-IT Collaboration.  Business-IT Collaboration is critical for focusing on the customer (the business IS the customer) and eliminating waste.  Business-IT Collaboration involves empowering business teams by supporting self-service capabilities such as the ability for the business to profile data, create business rules, and monitor data quality without the typical dependence on IT.  Wasted activities are eliminated due to the “High-Fidelity Collaboration” capability, meaning that metadata artefacts are shared between business and IT and appear to each in the manner appropriate to their needs, yet they are still operating on the same objects. This reduces waste because translation problems don’t crop up like they used to when the business works with spreadsheets which need to be translated into implementation-level details by IT using different tools. In other words, in Informatica 9 “quality is built in” from the start rather than being “inspected in” during an integration test.

Pervasive Data Quality systematically builds quality in. Different roles such as stewards, architects, developers, etc. have role-appropriate tools to understand and improve the quality of data. These tools support all data types (customer, product, vendor, accounts, etc), have built-in AddressDoctor Version 5 capabilities and geo-coding, and have full read/write access capabilities – in short everything the Informatica platform can access at high performance.  What’s more, the tools have the ability to manage the business rules around data quality as part of the integration layer rather than have the logic contained elsewhere. This enables loose coupling and rapid change in support of the Lean plan for change principle.

SOA-based Data Services further allows loose coupling with the data services layer which dramatically helps on the plan for change front.  Whether wishing to read or write data using SQL or Web Services, with small messages or large datasets, in real-time or in batch, the “multi-modal data provisioning services” (which means that the same data object definitions can be used for all these different styles of access through a common definition and platform), means less waste because the simplified management of these capabilities is in one place.  Further simplifying management is the ability to administer the policies governing the SLAs of these data objects in one place.  With this Data Services layer, companies will be able to eliminate the integration ‘hairball’ far more effectively, by reducing the waste which comes from the complexity of the historical point-to-point approach.  Further, having data profiling capabilities available at the fingertips of architects and developers reduces waste because of the in-depth understanding of the data at the point in time when the data service abstraction layer is being defined.

To complete the picture, following are the Informatica 9 themes and key capabilities which support the Lean integration principles:

SOA-Based Data Services

• Multimodal data provisioning services
• Universal data discovery services
• Policy-based data services governance

Pervasive Data Quality

• Unified role-specific tools for stakeholders
• Comprehensive support for all tools for nearly all purposes
• Open to all applications

Business-IT Collaboration

• Business Empowerment
• IT Productivity
• High-Fidelity Collaboration

The next big thing – Lean Integration and the Integration Factory are now here.  No more excuses for anyone to hold back.

It’s your organization’s most important proprietary asset. Are you really managing it that way?

The answer for most companies is “No”.

So how have we arrived at this place we find ourselves in, and why do we need another solution?

Quite simply, because we need to focus on driving the most competitive advantage out of our data.  We’ve become addicted to our computers and we have built systems for the business time, after time, after time.  Today most business users are presented with numerous applications that purport to provide the most timely, relevant and trustworthy data.  The problem is, they don’t.  There, I’ve said it – computer systems today cannot be trusted, they do not deliver the data that the business user wants and they do not provide it in the timely way that business users need it – no wonder business users are fleeing to the clouds!  The trouble is that we are about to make the same mistake again – numerous new systems now running on other people’s infrastructure with multiple versions of the truth.

Just think about it for a minute – which version of “Customer record” do you really, absolutely trust?  Is it the one that comes from your old creaking order processing system?  Or is it the one in your sales support system, or maybe the one in your CRM, or your financial system, or the one in that custom built application that went live last month but still needs tweaking, or is it the version in your new cloud-based SaaS application running .. well … no idea where really!

In fact, we have ended up with an IT hairball that is costly to maintain, precarious to modify and fragile.  This house WILL come tumbling down if we don’t do something about it.  SOA was going to fix the problems – but the original designers forgot about the data.

You see, our IT infrastructure has become commoditized – it no longer matters where the IT infrastructure is.  On-premise, hosted on Amazon or underneath the latest fancy cloud computing service.  Indeed, applications are becoming commoditized.  It’s the data that matters, it’s the data that provides the competitive advantage, it’s the data that ultimately lets you understand who your customers are, what they have, how they work and what they can buy.  It’s the data that allows you to run marketing campaigns to promote your goods and services, it’s the data that is moved between enterprises, it’s the data that represents health care records, it’s the data, it's the data, it's the data.

As one of our salespeople so eloquently put it to me, “Follow the data - it’s all about the data”.

Today with Informatica 9 we are launching an infrastructure platform that will, quite literally, transform your business and transform your world because, for the first time ever, you can really focus on becoming a data-driven enterprise.  It is designed to help IT deliver timely, trustworthy and relevant data to the business.  This is not a job for IT alone – it is about the Business and IT collaborating together more effectively, driving out data quality issues and delivering data to the enterprise in the most timely and applicable format – whether that is in traditional IT systems or in the internet cloud.

Welcome to Informatica 9, welcome to YOUR data.

Since recently attending the Gartner MDM Summit, reading the latest report on MDM Trends from Forrester, and speaking with several customers, a few trends are starting to emerge:

• There is no one single technology that will help organizations solve all of their MDM challenges
• While some MDM products are supporting multiple domains, they are still either customer-centric or product-centric
• Analytical style of MDM is gaining in importance, and
• The common challenges across all data domains and hub styles are data integration and data quality

At Informatica, we have been working with many customers that are seeing these same trends as well. They are selecting different approaches and tools for customer master and product master, sometimes even different tools for operational and analytical MDM applications. But the common threads are data integration and data quality:

Data Integration

• Access to multiple systems inside and outside the firewall
• Ability to handle multiple latencies from real-time to massive batches
• Tracking the metadata history, lineage, and audit trails

Data Quality

• Profiling source system to understand what you are starting with
• Identity Matching to detect duplicates
• Address Validation for all countries of operation and customer locations
• Cleansing and Standardization to ensure data consistency and accuracy across all attributes
• On-going monitoring and data quality scorecards to bring continual visibility to the program

When you look at the Informatica solution set you will see that we provide the capabilities that span these requirements. It’s an opportunity to help our customers be more successful by laying a foundation for MDM that provides a consistent integration layer across all data domains while applying data quality to existing data and having those same data quality rules applied at the point of entry.

What do you think? Is having a consistent foundation for all MDM projects important?

In my previous post To Successfully Service-Orient, Data-Orient First!, I shared the input I received from architects and IT managers, to serve as a handy check-list for ensuring a solid foundation for success in service-oriented infrastructures.

The following are the data-orientation capabilities they recommended as a first step in successfully service-orienting an infrastructure:

1. Easy access of all relevant data, including new or rapidly changing data sources
2. Seamless processing of data as batch, change data capture or real-time, including handling large volumes of large data sets
3. Proactive identification and resolution of data inaccuracies
4. Application of complex data transformations on the data
5. Delivery of data, exactly when it is needed, as a standards-based data service

We also discussed scenarios across industry verticals where there was a compelling need for timely and trusted data delivered as a service. However, what we did not discuss was how to data-orient a service-oriented infrastructure. In order to bring the best real-world information to you, I went back to the source – the same architects and IT managers who deal with complex data-centric issues on a day-to-day basis.

The recommendations were rather prescriptive in nature, centered on solving the problem holistically rather than looking for quick and dirty solutions, as should be the case. So let’s take a look at each of these recommendations and I will leave it to you to deduce what the effective solution should look like…

Recommendation #1: Start with a data integration platform that enables universal access to all data sources, be it structured, semi-structured, unstructured, cloud, partner, master, Web services…whatever it is. Also consider if you need to quickly on-board new data sources, or take advantage of data that changes rapidly. The bottom line is that there needs to be a way to include all the data you can possibly get to, in the fastest, secure and most reliable manner possible.

Recommendation #2: Make sure that the platform you choose to use can effectively support any latency of data processing, be it batch, near real-time or change data capture and real-time. Why? This is because in the real-world, data is processed at different latencies at different points in the enterprise. Without a single environment that can address all the nuances involved you will be forced to use and maintain a tangle of integration technologies.

Recommendation #3: Understand that large data volumes are different from large volumes of large data sets and plan accordingly. Technologies that handle large volumes of small messages typically do not do a good job of handling large volumes of large data sets. Bear in mind that a technology that handles large volumes of small messages has its own place in an SOA, so complement it by a technology that processes large volumes of large data sets efficiently.

Recommendation #4: Place a value on the importance of the trustworthiness of the data that is consumed by your applications and business processes. If you feel that it is inefficient and expensive to find out after-the-fact about inconsistencies and inaccuracies across all your data, then you definitely need a more proactive approach. Look for a platform that can provide integrated data profiling to proactively identify issues and also fix these issues, regardless of the complexity.

Recommendation #5: Make a list of all the complex transformations that you need to do on all your enterprise data. Any integration technology can typically handle simple format conversions, however, if you have the need for more complex transformations such as aggregation, joining, lookup, etc., or need to enable structure conversions, industry format conversions or even data masking or obfuscation of specific portions of the data, you probably need something more sophisticated.

Recommendation #6: Take a hard look at all your consuming applications. Take an inventory of the way each of these applications consume the data. Is it through Web services, or do they only understand SQL? Ideally, this should not matter to the data integration platform you choose. The data integration platform should be able to deliver timely and trusted data, in exactly the way it is needed by each application.

Recommendation #7: And finally, make sure that your applications are insulated from the underlying data sources. What this means is that if the underlying data sources change, you do not have to re-build the integrations. A solid data integration foundation would provide the necessary standards-based data abstraction to all the underlying data, so that, if and when things change in the data layer, the applications are adequately insulated.

Additionally, what I did note was a common thread across all the above suggestions, that there needs to be a single, integrated platform that can deliver all the capabilities outlined. This makes sense, as all these recommendations were made with time and cost savings in mind. If a separate technology were to be employed for each of these capabilities, the very basis for employing a service-oriented approach would be compromised, which would be to enable agility through simplicity and flexibility.

Oh, I almost forgot. There is one last prescription that the architects shared – probably one of the most important from an architect’s point of view – that the platform must support and drive the reuse of data integration logic. More on this highly important topic, in my next blog posting.

]]> http://blogs.informatica.com/perspectives/index.php/2009/10/27/how-to-get-started-with-data-orientation-what-architects-told-me/feed/ http://blogs.informatica.com/perspectives/index.php/2009/10/27/how-to-get-started-with-data-orientation-what-architects-told-me/ http://feedproxy.google.com/~r/InformaticaPerspectivesDataServices/~3/CCR5zdRf4gM/ http://blogs.informatica.com/perspectives/index.php/2009/10/21/managing-data-as-an-asset-part-2-walking-the-walk/#comments Wed, 21 Oct 2009 16:18:42 +0000 Judy Ko http://blogs.informatica.com/perspectives/?p=533 In my last posting, I wrote about how we often talk about managing data as an asset, but that one of the major barriers to actually doing so is the difficulty in putting a monetary value on the data.

A somewhat more tangible, if no less complex issue, is that the processes and tools for managing data as an asset are often not in place. Data governance is often defined in terms of managing data as an asset, and this discipline, while still nascent, is evolving rapidly. Many companies have started to define and standardize on data governance processes, as well as formalize data governance roles such as data stewards. But we’re a long way from maturity here.

Moreover, the technology infrastructure that underpins these processes is still inadequate in most organizations. Examples of some of the typical gaps:

• It can take an inordinate amount of IT effort just to access the data in some legacy systems—that’s if you can even find the data you need in the first place. If you can’t get to your asset, it has no value.
• The different business applications in a company have different technical requirements for how they consume the same data. In theory, data should be the ultimate reusable asset. But if you can’t reuse it, are you getting the value you should?
• Ideally the business is supposed to be responsible for data quality, but what is the state-of-the-art tool for them to analyze and cleanse data? Right now, usually spreadsheets. Do you have the means to add value to your asset?
• There is no method for technically enforcing policies around data quality, privacy, etc. How can you protect your assets if you can’t enforce policies for it?

If organizations say that data is one of their most valuable assets, they need to start walking the walk. They need to actually invest in the processes and people to formalize data management, and they need to update their technology infrastructure to support those processes. At Informatica, we say that companies who are walking the walk by making these investments are “data driven”. (We didn’t coin this term– Thomas Redman has an excellent book called Data Driven, which discusses many of these concepts.)

You’ll be seeing more in the future on this concept of “data driven” with the Informatica 9 launch. Stay tuned.

I recently had the opportunity to moderate an Informatica Webinar, hosted by ebizQ, featuring Dave Linthicum, CEO of the Linthicum Group and one of the world’s leading authorities on SOA, Cloud, and application and data integration, and Ash Parikh, Informatica's SOA and data services evangelist. (And a contributor here at the Perspectives site.)

Dave, who literally wrote the book on “Enterprise Application Integration” back in the 1990s, says EAI  and ESB approaches are not suited for today's high-transaction data integration needs, and have great limitations. But still, many organizations persist in attempting to plug in these types of solutions into vexing business problems that require a more holistic architectural approach. “There are a lot of people trying to put square pegs into round holes,” he says. “I'm seeing almost an epidemic out there in the world of service oriented architecture and enterprise architecture and architecture modernization.”
(Dave also talks about the challenges in introducing data integration into SOA efforts in a post here at the Perspectives site.)

Dave says that while the square-peg-in-a-round-hole approach will work for a while, it's far more costly in the long run. “With EAI and ESB technology, there are certain instances and problem domains where they're a fit,” he explains. “But you need to understand there are certain limitations that are part of that technology that should be considered. Ultimately, if you don't consider them and pick those technology approaches anyway, you're going to start running into walls that are very difficult to back up and get around as you move the architecture forward.”

“It’s very easy to write a check for this stuff. It’s very easy to put it on a server, and it’s easy to start coding to it, and putting adapters around it. But down the line there's so many dependencies that are put into the technology – it’s very difficult to uncouple them out of the problem domain. After two or three or five years of inefficiencies, and issues with the technology, these approaches can cost you millions of dollars, and even cost you the success or failure of the architecture.”

Along with the issues of data integration, EAI is not equipped to manage data quality, and thus may taint the performance of SOA. “EAI will enhance overall efficiency of the business process,” Ash pointed out. “EAI will only propagate corrupt information in real time across your information systems. Sure, EAI can process messages as fast as possible across applications. But what if the information is incorrect?  Your entire process will be fed with corrupt information, such as wrong mailing address, wrong person, wrong quantity.”

Dave says that he's finding clients “in droves” that are missing these requirements. “They typically drive with technology, so they have the technology in mind before they even look at the requirements,” he says. “Even going as far as calling something an 'ESB project,' which is silly. It’s a data integration project.” Data needs to be available to the enterprise, and it must be traceable and auditable, Dave says.

Data integration is beyond the reach of EAI and ESB solutions. Ash advocates putting data integration into a data services layer abstracted from physical databases. “It would be very tough for EAI to create a holistic view of data across heterogeneous data sources,” he says. “What would solve the problem is a centralized data abstraction layer.” Such an interface can “deliver a single view, regardless of the type or location of the data source.”

This data services layer in what can be loosely termed as a SOA stack, Ash observes. “Data services can be this compelling technology that sits inside this stack to enable SOA to finally realize its true potential. A single centralized layer that would eliminate all the hand coding, and solve the complexity.”

“Start with the architecture,” Dave advises. “You need to understand your own issues, and look at your own business requirements. And ultimately that's going to lead you do to the right technology.”

“At the end of the day, there are things you need to consider, as you go through data integration architecture,” he says. “Understanding how information is going from system to system. You need to look at your requirements in detail.”

Just recently, I created a quick one question survey and sent it off to a number of application and enterprise architects as well as IT managers at leading enterprises. The question was:

• What are the top three things on your mind as you architect or re-architect your infrastructures?

There was a common thread across the responses that I received:

• Service-orientation or an architectural approach to increase the speed and agility of how IT responds to a business’ requests,
• Doing more with less or something to that effect, and
• An easy way to leverage all relevant information, when it is needed and how it is needed

When I saw these responses, the pragmatic part of me started to build a list of questions in my head and I decided to call a number of these professionals and get the real scoop on their selections.

Here is what I heard…

* An enterprise architect at a global sporting goods manufacturing company, told me that the IT organization had just completed a three-year project to service-orient its infrastructure in order to help streamline operations. However, he told me, they were stuck and didn’t know how to move ahead as this new infrastructure, which included an ESB, could not support large files. Large files are used by the company to move their business critical order and product data once a day across their supply-chain management systems.

* An application architect at a leading financial services company had a problem with the quality of the data that was being delivered to his reports. As is their tradition, his company had just completed another round of acquisitions, and once again his reports were missing crucial customer data from the newly acquired company. Although the IT organization had service-oriented its infrastructure based on state-of-the-art technologies, it was a challenge to quickly understand what was in the new data sources and handle any inaccuracies and inconsistencies.

* Another enterprise architect from a large insurance company couldn’t hide his frustrations about the fact that every time something changed in the underlying data layer, the impact was huge. Every time a data source was changed or replaced, which was frequently, the integration logic in the consuming layers had to be rebuilt. He wanted a way to easily abstract the data layer from these frequent changes. According to him, the ideal solution would be for this layer to provide the necessary insulation and deliver all relevant data as reusable standards-based service.

* The enterprise architect at another large insurance company felt that there was no way to easily deliver an accurate, single-view of business entities such as “CUSTOMER,” “PROVIDER,” and “MEMBERSHIP” data, to their web portals. What they were able to achieve within their implementation was enabling the access of data across the diverse data sources and delivering the data as a Web service. But, when it came to doing complex transformations or ensuring that the quality of the data was as required, they had to resort to hand-coding or other sub-optimal means.

It is becoming increasingly clear that any effort to service-orient an infrastructure needs to start with a hard look at data integration. In his recent blog entitled “Understanding Data Services In Context Of SOA", David Linthicum says that “Working from the data up to the services within SOA is clearly a best practice.” There seems to be a crystal-clear message here that “data integration” needs to be top of mind for anyone architecting their infrastructure for speed and agility.

So, if you are looking to service-orient your infrastructure, I would suggest that you data-orient first by doing a 5-point check to make sure that the foundation has the following capabilities:

• Easy access of all relevant data, including new or rapidly changing data sources
• Processing of data as batch, CDC or real-time, including handling large volumes of large data sets
• Proactive identification and resolution of data inaccuracies and inconsistencies
• Application of complex data transformations on the data
• Delivery of data, exactly when it is needed, as a standards-based data service

In my next blog, I will dig deeper into each of these requirements.

David covered some of the limitations he has encountered over the years with the way Enterprise Integration Application (EAI) and Enterprise Service Bus (ESB) technologies deal with the integration of data, deployed in a SOA initiative.

I found the content covered by Dave to be very interesting as it fully related to some of the real-world experience I had gained over the years working with customers. Based on my experience, EAI and ESB technologies typically manage process integration and transactional event-based message movements in a publish/subscribe environment. But when it comes to the manipulation of the data itself, these technologies quickly reach their limits leading to a hand coded approach or at best, abusing the capabilities of the EAI/ESB.

Fortunately enough, some of these companies were able to leverage the data integration capabilities of the Informatica Platform to enable a number of key capabilities that were missing in EAI/ESB.

Here are the key capabilities that the Informatica Platform can seamlessly address with respect to the limitations of EAI/ESB:Bulk data movement scalability

• Rich metadata capabilities
• Set-oriented data transformations
• Codeless environment
• Non-intrusive database transaction detections
• Ease of deployment and modification

These valuable capabilities, from an IT perspective, provide immediate return on investment to the SOA initiative by providing the right way to enable data integration development and reduce the costs of maintenance.

But it is the second round of capabilities that brings the most value. EAI or ESB technologies are meant to propagate transactions over queues in the quickest way possible. In other words, if the data associated with a transaction is corrupt, then this same corrupt data will get propagated to all the applications, having significant impact to the business process.

The Informatica Platform can provide a data quality firewall to the company, ensuring that corrupted information does not enter the business transactions. Or, it can provide data quality checks as a service to the applications (also known as Data Quality point of entry) so that the information is verified in the earliest step of the process.

Finally, all these data integration patterns such as bulk processing, transaction capture, set-oriented transformations, or data quality certification can all be delivered as a standards-based service to the EAI/ESB. This is a great starting point for implementing a data services foundation in an SOA strategy.

I strongly recommend you take a look at this webinar.

The trouble comes in when attention is centered on the “S” in SOA, which stands for services. Those charged with building architectures and systems, who focus on the notion of a service as delivering functional behavior, neglect the need to manage the underlying data. In many cases, data quality and consistency issues quickly arise, and the agility that SOA should provide is limited by the need to alter services directly after the underlying data has changed.

Most in the SOA community understand that data services provide controlled interfaces to underlying data, but typically don’t understand the strategic value of data services to the SOA. Data services, if created and leveraged correctly within the context of a SOA, should provide a wide variety of features including data quality assurance, data governance, and, most importantly, the ability to support data abstractions.

Data abstraction is the key. It allows you to fix issues with the existing physical databases within the data service itself. Moreover, you can combine many different databases, and even unstructured information, into a single unified view of the data that is more representative of the business. Done right, this provides a huge strategic advantage to business and enterprise IT, including the ability to change the underlying databases without driving changes to the applications that leverage the data services. Volatility exists within a single domain, and thus provides agility. Agility is the core value of a SOA.

However, moving to data services is not an easy path. You need to consider the design, implementation, and the right enabling technology.

The best practices around data services design are about moving from the top down. I suggest that you understand the data model at a logical level first, focusing on the business entities such as Customer, Sales, Inventory, etc., and then on the best physical/virtual structure that binds into those entities. Once that occurs, then you can link that physical/virtual structure to the physical database or databases.

Moving from the logical to the physical provides a few major advantages:

• You’re not constricted by the limitations of the existing physical database, or databases.
• You’re focused on the business purpose first, and then on the technology implementation.
• The logical design is durable over a long period of time, where the physical design typically exists within many instances of the database structure, and is where the changes typically take place.

What’s surprising to me is the number of people working on SOAs who don’t understand the value of data services. Working from the data up to the services within SOA is clearly a best practice, and what I see repeatedly in the successful use of SOA. We’ve been at this for awhile now. We need to get a clue.

Before I start on this extremely polarizing topic, I really want to ask the question – do you want your SOA to be ineffective or die before it has a chance to live?

As I mentioned in an earlier blog, SOA does have a significantly big "blind spot," which so often gets ignored due to the sheer size of the vehicle you are riding in – which I define as – the complexity of your enterprise infrastructure, the various avatars or stakeholders that are directly or indirectly impacted by integration challenges, departmental divides and ownership issues, debates around modernization, and of course, budget, time and resources.

Hopefully you answered the question with an emphatic NO!

I am not sure that anybody out there wants all their good money to go to waste after investing it in anything and everything that even remotely sounds like SOA. Such is the power of this paradigm called SOA, so rich in its roots and its promise that it is usually very difficult to "stick to" making a case against it, because on paper it promises you the agility that you are after.

But, the real question is whether your SOA is doing all that it promised it would. Is it able to round-up all its knights in shining armor, the EAI, ESB, BPM products of the world to ensure that it will deliver the most fresh, the most consistent and the most accurate information to its end users – the web portals, the composite applications, the business intelligence tools of this world?

As David Linthicum says in "Lack of Focus on Data Killing SOA" his recent blog post, What's missing within most typical SOA projects is the focus on the data, and that is killing SOA. Since the "S" in SOA, means service, most architects focus on the service definition, abstracting the existing data into collections of services, but don't pay much attention to the data within the architecture. Not good."

I couldn’t agree with Dave more – although SOA is about "architecture," most of us get caught up in handling the "service" piece of it and forget that the key to a good architecture is its foundation – the "data."

In his blog, Dave goes on to say: "The truth is that most failed SOA projects can be traced to the lack of a data level understanding…"

What we don’t need is for SOA, which has so much promise, to die before it has a chance to live. Instead, what we need is a way to enable SOA to achieve its full potential by co-existing with its components and offering some much needed help around the integration of data.

I mentioned this in an earlier blog, Enough Already About What is SOA? Let’s Discuss Some Real-world Myths About SOA … that by taking away all the headache that comes with integrating heterogeneous data sources spread all across the enterprise and beyond; by proactively ensuring that the data that flows through the pipes is of the greatest quality; by seamlessly handling all the complex transformations and structure conversions that are needed and then processing this data the way it needs to be processed, be it for processing large data sets, or capturing changes as they occur or in real-time - you can then easily and seamlessly deliver this data as a standards-based service or a data service.

This is what SOA needs – a solid foundation of timely and trusted data delivered as a data service – so that it does not die before it has a chance to live!