I recently had the opportunity to chat with Scott Metzger, CTO of TrueCredit (a subsidiary of TransUnion). TrueCredit has a very compelling story to tell, and lessons to be shared, because the company has had a functioning SOA since the year 2000.
At the time the SOA was started (though it wasn’t called SOA at the time), TrueCredit, then a division of Lehman Brothers, had launched a direct-to-consumer e-business channel, and sought integration and reuse of any and all business assets. “We actually developed our own service-oriented stack at first, and then began adopting third-party solutions and standards around 2003,” Metzger related.
TrueCredit’s SOA supports about 20 discrete, and most transactional, applications that support the company’s call centers, as well as security through online identity verification. The company runs SOA-based services on BEA WebLogic, connected to an Oracle database, running on Linux-on-Intel servers.
Performance monitoring becomes a vital issue with SOA because, Metzger points out, because there’s a “penalty” that comes with reuse of loosely coupled services. “Since SOA is very loosely coupled, it gives you a lot of flexibility and deployment and tuning, the ability to reuse common components across a large number of applications,” he observes.
“But the challenge is because of the loosely coupled nature of SOA, it's much more challenging to instrument in that kind of environment, to monitor production. You're not looking at everything on one box.” Changes in or degradation of performance for one service could break many applications within the SOA. “You need to trace the interactions across your loosely coupled implementations to see whether a new application is creating measurable load on your existing services,” Metzger said. “Or, if you made a change to a service to accommodate new requirements for the new application, is that change negatively affecting the existing applications that are leveraging that same service?
Lately, TrueCredit has been working with CoreFirst from OpTier to help optimize its service levels by improving transaction throughput and response time. Performance bottlenecks are sometimes more difficult to identify in SOA as well, Metzger points out. “When you have performance issues, the first questions are, ‘what tier is the bottleneck in?’ ‘Is it in the centralized in the Java application tier, or the database tier, or is it really an interaction between the two?’”