Amidst all the hype and buzzwords that surround SOA nowadays, it's still far too common for organizations that...
seek to integrate service-oriented architecture into their IT infrastructure to omit issues related to data integration, management and governance in their designs. As they roll out and learn to live with an SOA, however, they often discover that interoperability with other systems and solutions poses interesting problems. In fact, these problems can make interaction between systems and SOA components both vexing and time consuming.
The key is to recognize the value of the organization's data, wherever it may reside—that is, either beneath or outside the SOA umbrella—and to come up with methods that enable them to capture and transport data between its producers and consumers with a minimum of muss and fuss. This creates what Gartner calls a data-services-oriented view of SOA, and that firm predicts that this view is bound to become a critical component in SOA initiatives going forward, as well as a critical upgrade for existing ones that failed to take this view properly into account.
- They create the means to capture key data elements, interactions and semantics which not only makes it easier to move data between or among SOA components, but also documents key understandings and assumptions about the data they use (and the metadata they need).
- This offers much greater data transparency to everyone involved in the system and makes data paths and data relationships much clearer. It also points out where issues related to data consistency, data duplication or needs for normalization and reduction come into play.
- Clear abstract views of the data that flows between and among components, as well as the nature and scale of those flows, also provides the opportunity to redirect them as new business needs emerge, and as new producers and consumers of such data join into the picture.
XML and messaging protocols such as SOAP indeed make it easier to abstract the data and move it around. But they also raise the importance of where data resides, how it gains (or retains) proper context, and how to associate specific syntax, semantics and accuracy checks against the real-world information it represents. This creates the need for what some experts call "XML-centric composite data services" which handle the primitives needed to make data available in an SOA environment, including data access, integration, transformation (federation, abstraction, filtering, etc.), validation and verification, quality control, and governance. This approach lets organizations use XML-centric, data-driven workflow design tools that may then be deployed and managed using an XML-centric workflow engine.
In addition to using the right tools and applying the right business rules, it's also important for organizations to recognize that XML-based descriptions only work as well as the people who design them make them work. This means that talented, capable data architects and data governance professionals must be involved in creating the right kind of representations, as well as the processes whereby data is captured, validated, maintained and distributed. In addition to XML representation, XML-oriented databases, XQuery, and a formal data service approach to handling data within the SOA framework, as well as a dedicated team of data specialists and stewards to make sure that what's available matches what's needed, and to keep data repositories cleaned-up, refreshed and accurate over time.
About the author
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. Among his many XML projects are XML For Dummies, 4th edition, (Wylie, 2005) and the Shaum's Easy Outline of XML (McGraw-Hill, 2004). E-mail Ed at email@example.com with comments, questions or suggested topics or tools for review.