Service Oriented Architecture - SOA

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

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. One observer even 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?

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. Ash has also appeared frequently as a guest speaker at ebizQ Webcasts and conferences. 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, ebizQ’s resident authority on information management, and a respected expert 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.