WebServices dot org

Six Years of Loose Coupling: Lessons from a Very Early SOA Adopter

SOA is still in its infancy, so it’s quite remarkable to come across a company that has had a fully functioning SOA for the past six years. What can such a veteran operation teach the rest of the world about SOA?

I recently had the opportunity to speak with Scott Metzger, CTO of TrueCredit, a subsidiary of TransUnion, which set out at the turn of the century to launch an e-business with reusable, cross-enterprise business assets. Of course, in those medieval days, the architecture wasn’t even called SOA.

What did this pioneering SOA look like? In 2000, the company migrated from a Microsoft software stack, with SQL Server, IIS, ASP.COM, and COM objects -- a “monolithic application approach,” as Metzger puts it – to homegrown standards that integrated a Java-based application portfolio. “We went though a rearchitecture process and enterprise architecture plan, where we defined our standalone services, developed our own communication stack and services manager to get to a reuse goal.”

The company deployed a common layer of services that were accessible to its transactional consumer-facing applications, CRM applications used by call centers, and even white-label solutions offered to other financial services firms. “The core of our SOA strategy is around reuse,” Metzger said. “We reuse the same service infrastructure, and just focus on whatever application vertical is needed on top of that services framework.”

The company has deployed about 20 applications that leverage reusable services through its SOA. “We identified a number of key business processes that are common to almost every application that we have -- payment processing, user management, identity verification, credit scoring, credit merging, and credit monitoring,” Metzger says. “These are the Lego blocks that we can reassemble in different ways for customer-facing products, but the key ingredients are very the same under the hood.”

A conversion to Web services and an industry-standard platform in 2003 lightened the load for the company’s IT department. “We wanted to stop maintaining our own SOA stack, and leverage commercially available technologies that sat on top of J2EE,” Metzger explained. “We were spending half of our time on writing and maintaining code for infrastructure that didn't map to business requirements.” At that point, the company moved its service deployments to BEA WebLogic application server, Metzger said. WebLogic had “the key ingredients we had developed for our service-oriented approach, things like XML native data types, workflow technology, and support for Web services standards.”

What does this six-year veteran see as the greatest challenge to service-orienting an enterprise? Surprisingly, it has nothing to do with immature standards, organizational politics, or spaghetti architectures. The biggest headache, Metzger says, is loose coupling.

Metzger doesn’t diminish the advantages of loose coupling of services – the bread and butter of SOA. “Loose coupling gives you a lot of flexibility in deployment and tuning, as well as the ability to reuse common components across a large number of applications,” he says. “But because of that loosely coupled nature, it's much more challenging to instrument in that kind of environment, from production monitoring and analysis point of view.”

A traditional application environment has been more of a monolithic deployment, making performance monitoring and management much simpler, Metzger explains. “With the monolithic applications, there are good profiling tools, and because everything is one big chunk, you can trace transactions back through the whole application to see all the interactions. But in a service-oriented approach, now you've got this runtime that's supporting not only the new application that you’re deploying, but 15 other applications that have been historically running.”

Metzger offers these words of advice: “You need to trace the interactions across these loosely coupled implementations to see: is the new application creating measurable load on an existing service? With this new architecture, and where Web services have really proliferated -- both ones you develop internally, as well as leveraging externally with partners – you need to be able to see across loosely coupled boundaries, and be able to see the interaction between the tiers in the context of one application versus another application.”

The industry is now undergoing a very intensive push into SOA, which calls for not only effective governance of the way services are designed and built, but also for management of these services across organizational and intra-organizational boundaries. The actual day-to-day performance of an individual service may be directly out of your reach, but the impact on and interaction with the rest of your service ecosystem is something that can, and must, be managed.