Listen to my podcast with Jennifer Briscoe, Vice President and CTO of SquareTwo Financial, where she is responsible for the technical and strategic direction of the company's software platforms. In this podcast we discuss the lessons learned from SquareTwo Financial's Oracle SOA implementation, and how following best practices isn't always the way to go.
Listen to or download the 5:31 minute podcast below:
---TRANSCRIPT---
PS: Can you tell me a little bit about SquareTwo Financial as a business as well as its existing IT infrastructure?
JB: SquareTwo Financial is dedicated to making distressed assets whole. A distressed asset in this case is any kind of charged-off debt. It could be credit card debt. It could be student loan debt, medical debt, etc. Our sole focus is accelerating financial asset recovery through industry leading asset modeling, award-winning technology, and our pioneering legal partner's network, which works with consumers to remedy their outstanding debt. SquareTwo uses a proprietary software system that spans the partner network and utilizes the power of analytics to optimize the return on investment while minimizing the cost associated with asset management.
The system was designed to handle any type of asset ranging from student loans, to medical debt, to credit card debt. The platform is capable of managing the entire lifecycle of asset recovery starting with acquisitions and finishing with liquidation. The system is comprised of a rich user interface sitting atop a service oriented architecture. It rides on top of Oracle's Fusion Middleware platform. The user interface was written using Oracle's Application Development Framework Version 11g and it runs on IBM Blade servers with Linux.
The services layer primarily utilizes Oracle's BPEL Process Manager and it too sits on IBM Blade servers with Linux. The databases are primarily Oracle 10g running on Solaris. The platform interacts with a number of our corporate systems including Informatica, Microsoft GL offering, which is Navision, and SaS Enterprise Miner.
In addition, it interacts with our document management system. We have a reasonably homogeneous environment in the data care but once you get up into the application stack, it becomes a much more heterogeneous environment.
What prompted SquareTwo Financial to first consider SOA?
Well, as I mentioned, SquareTwo has a very heterogeneous application stack that the asset management system had to interact with so that was one compelling reason. In addition, the platform was required to integrate with over 20 outside vendors. The Service Oriented Architecture offers better agility and ease of integration in that type of environment. In addition, we have a strong need for human intervention as well as workflow automation. A Service Oriented Architecture, in particular BPEL, offers a more flexible means of service orchestration in support of both human and automated workflow.
Now what benefits did SquareTwo Financial gain from implementing an SOA infrastructure and would this will help other organizations?
The two biggest benefits we saw that could be applied elsewhere were one, a measurement framework that can be used to create a culture of reuse through incentives and two, real examples of success as a direct result of not following best practices in every case.
So the big question is did SOA help control costs and did it help with corporate decision-making?
It did help control costs in two ways. First, having a tightly integrated technology stack such as you get with Fusion Middleware saved us thousands of hours of development by using the out-of-the-box tools for integration rather than having to build our own. The second way it helped us control costs with through service reuse. Once we had our core set of services, ne service creation became the exception while new ways to orchestrate existing services became the norm.
In addition, corporate decisioning was also improved through the use of business process modeling. Our business partners were able to more thoroughly analyze the impact of a particular decision by seeing its downstream impacts on existing processes.
What are some of the real world lessons that you learned with this SOA implementation?
The first less that we learned was focus first on your business process, don't underestimate the importance of the role business process modeling plays in determining proper service granularity. That service granularity has a direct impact on service reuse as well as performance of the platform. Two, consider ways to incent reuse within your development culture. This requires careful monitoring in a granular way to measure the impact of service reuse either in terms of dollars or in terms of development time.
The third lesson we learned and had to keep in mind throughout the program was that SOA is really a design paradigm. It seeks to decouple business function from process and presentation. And in so doing, there is no one right way so we need to be willing to color outside the lines and know when to apply best practices and when not to based on your specific environment. Best practices and ivory tower thinking don't always align with the business problem at hand.
And the last lesson that we really learned was designed for business capability in its current and near-term state, meaning that performance optimization should be data driven rather than theory driven. You know what your business is capable of doing today and can make a reasonable forecast on what your business going to be capable of doing three to six to perhaps nine months from now. But anything further than that truly is a theoretical and one should design only with respect to data-driven performance optimizations.
Everyone has their favorite way of using the internet. Many of us search to find what we want, click in to a specific website, read what’s available and click out. That’s not necessarily a bad thing because it’s efficient. We learn to tune out things we don’t need and go straight for what’s essential.
www.onlineuniversalwork.com