Fighting 'viral data': SOA Data Integration Architect Community launched

Since it came about in its current form in the early-to-mid 2000s, service-orientation (mainly focused on applications) has existed in a separate world from data management.

Problem is, an SOA-enabled infrastructure with bad data flowing through it can be useless, and even dangerous. Remember how Neal Fishman compared SOA to a mosquito that can deliver payloads of bad data ("viral data") at lightning speed all across the enterprise -- pandemic style -- before it can be stopped?

Wanted: advocates who can bridge the chasm between the SOA and data worlds.

Now, we're seeing the launch of the SOA Data Integration Architect Community (SDIAC), an online community focused on the value of data integration and data services in agile architectures such as SOA, promising to bring the data and SOA worlds closer together. Such an organization will definitely bring support to SOA proponents struggling to address data quality issues, and data architects seeking to service-enable their environments.

One of the moving forces behind the creation of SDIAC is Informatica's Ash Parikh, a colleague of mine who has been a long-time proponent of data services within a SOA context. While Ash started the ball rolling, he prefers to take a background role in the interest of the vendor-neutrality of the group.  At least initially, Informatica is supporting and hosting the SDIAC site. (Disclosure: I am a guest contributor to Informatica's Perspectives blogging community.)

So the SDIAC will be led by none other than Dave Linthicum, an independent authority on enterprise and data integration, SOA, and cloud computing. As Dave notes in a post over at Perspectives, he views this community "as being sorely needed, considering the lack of understanding of SOA data integration out there today.Those charged with defining and building core IT architectures are not likely to understand the best practices in defining the architecture for the data up to the services, and up to the processes.They are then left with architectures that are difficult to change, and don’t completely take advantage of the data assets."

Dave also provides three reasons to consider involvement in SDIAC:

1) To become involved in the last mile of SOA – the need to deliver timely, trustworthy and relevant data using data services;

2) to network with peers and exchange knowledge; and

3) to create a nurture new ideas that will move the SOA-data services connection forward.

Another good reason for engaging with SDIAC is that it will help SOA proponents better communicate their ideas and requirements to the data folks, and likewise, helping data managers better understand the role of SOA as a way to get the right information to decision makers and applications. And, for both groups, it can help provide insights and perspectives to approach and sell data services to the business.

And, as we move deeper into emerging areas such as complex event processing and business activity monitoring, SOA can provide the framework to help assure the relevance, accuracy and timeliness of data moving through analytics systems.