juanjo tugores - Fotolia
While admitting the glow is off the once-hot service-oriented architecture (SOA) approach, information architect John O. Biderman sees it as a cornerstone for bringing backroom data-warehouse data into everyday operations.
But for such projects to succeed, data management professionals have to take a leadership role in planning and building a data services layer of software to support enterprise data integration needs, said Biderman, a senior information architect at medical insurer Harvard Pilgrim Health Care in Wellesley, Mass. In the past, he added, SOA has too often been the province of programmers, with data specialists on the outside.
"My message is that SOA initiatives should no longer be viewed as software development challenges. They instead should be seen as big data integration challenges," he said.
Biderman draws from experience gained during a multiyear application update in which Harvard Pilgrim replaced a legacy system that had hardwired integration between applications with a more flexible set of loosely coupled services, or components, to manage billing, enrollment, claims processing and other applications.
When data meets SOA
The service-oriented approach involved the use of XML schemas, which must be designed correctly for SOA to be successful. But, Biderman said, canonical data modeling standards must be established upfront so that developers' efforts to build SOA APIs have structure. To that end, fairly early in the project he and his Harvard Pilgrim colleagues settled on an enterprisewide logical data model to represent the organization's data.
That served as the basis for a canonical model for data services. Putting that in place helped the other people working on the SOA initiative, he said, adding that the canonical model "informed other groups' work on messaging models" that drove integration of different services components.
Part of the work included documenting the data resources that services could utilize. That, in turn, led the data architecture and software development teams to build and maintain a services repository that, in Biderman's words, "is not unlike a traditional metadata repository."
Taking an approach that is defined by data requirements can also save work, he said. In developers' push to get things done, they may create too many XML schemas -- but using an enterprise model as a guide to building such schemas can reduce the total number that are designed, according to Biderman.
In early work done without resorting to the enterprise model of the data services layer, the Harvard Pilgrim developer team created some XML schemas that included every data element that could possibly be useful, he said.
Biderman said the schemas created subsequently -- the ones based on the canonical model -- have proved stable over time. "Sometimes they have needed to be extended, but they didn't need to be wholly refactored," he said.
Keep on the SOA-side
SOA's road has been rocky over the years -- at one point, it was even declared "dead" by Gartner analyst Anne Thomas. Biderman is quite aware of SOA's tarnished reputation.
"A lot of SOA enterprise projects crashed and burned. But you can learn from the ones that work," he said. "In a way, SOA today is ripe for adoption."
While SOA may have taken some hard knocks, often some form of it has been applied in dealing with IT legacy systems, as in the Harvard Pilgrim case. Yet, the services approach can lay a foundation for more than application modernization.
It also can be a useful steppingstone to a cloud services architecture, according to David Linthicum, a senior vice president at consulting company Cloud Technology Partners in Boston. Enterprises' data-rich applications will more easily move to cloud computing if they adhere more closely to service-oriented methods, he said.
"SOA became a bad word for a while. The reality is it's a good way of doing systems," Linthicum said. An SOA, he added, can underpin a data services layer that in turn provides a valuable way to leverage tiered data analytics approaches for better cloud utilization.
For his part, Biderman sees SOA evolving to the point where developers have a more informed view of the data part of the services equation. "If you take a more data-centric approach to SOA, and involve the data management teams and resources, it is likely to save you time and money," he said.
Learn about the role of semantics in information architecture
Will big data and governance find common ground?