USAA Integrates Applications and Data Across Platforms Using RESTful APIs
UP CLOSE
Customer: USAA
Headquarters: San Antonio
Business: Financial services
Challenge: Integrating applications and data across platforms
Solution: Using RESTful APIs to open communications channels between backend and client-side resources
Hardware: Eight IBM z13 systems
Software: IBM WebSphere Application Server
“There’s gold in them thar hills!” an old and enduring U.S. miner saying goes. It can apply today, as organizations are finding and taking advantage of new market opportunities by leveraging legacy applications and their data to more efficiently mine those opportunities.
That’s the case with financial services provider USAA. “We needed to be able to quickly react to new or emerging technologies, such as mobile. So, because our system of record is on the mainframe, we had to develop a way to make it—just as we would with any other server—generally accessible,” says Keith Wilson, technical architect, USAA.
To do this, the organization decided to develop, in lieu of traditional web services, a mainframe-based RESTful API framework that would allow it to more efficiently integrate its vital back-end, classic applications with more modern interfaces—in a fraction of the time and cost it would have taken in the past.
Future Demands
Founded in 1922 by 25 U.S. Army officers, USAA, headquartered in San Antonio, Texas, initially insured other Army officers’ automobiles after traditional carriers turned them down because of the hazardous nature of their positions.
Today, USAA has 12 million-plus members and customers. Supporting mainly the military community, members and customers can take advantage of USAA’s growing number of financial services, including banking, investments and insurance.
Supporting its operations is a fleet of eight IBM z13* systems, responsible for production, development, testing, and backup and disaster recovery (DR). Most of USAA’s mainframe-based homegrown applications—including for auto and property insurance, financials, investments, banking, and life and annuities insurance—were written in C++, COBOL and PL/I. Some have been around for nearly 30 years.
These decades-old applications are mission-critical, both for internal USAA operations and its members. As a result, making all applications more usable and accessible was essential for meeting across-the-board computing expectations.
In an effort to modernize this environment and provide cloud-based solutions, USAA could have rewritten its applications or purchased packaged software. But its existing applications were expressly tailored and updated for USAA’s unique business flow and represented its consolidated system of record. Getting rid of them would have meant the loss of a battle-tested legacy, but keeping up with always changing user wish lists is no small chore in the classic-app world. It can take months and sometimes years to alter monolithic applications and update them, only to discover they’re already out of date. And so the cycle repeats.
As Wilson notes, “Today, you expect that your software stack is going to change more frequently than it had in the past, when you had to put a lot of effort and time into updating your applications. So you need to align to industry-standard development tools, technologies and processes that aren’t restricted to your particular environment, allowing you to leverage what you have and make it much easier to meet future computing demands.”
Hybrid Platforms
To meet its goals, USAA needed to adopt a mechanism by which its developers could integrate applications across the stack as needed and then deliver the results, even via the cloud, to a variety of essential environments, such as advanced web browsers and mobile clients. After establishing this outline, USAA began looking at RESTful APIs, which allow users to deliver and populate back-end resources—including applications and databases—as web services.
“We needed to be able to provide an efficient way to get back to our data and apps. Already, a lot of service interactions within our walls are on the middle tier, so we have many resources running in the IBM WebSphere* Application Server environment,” Wilson says. “To augment that, though, our first goal was to provide back-end capabilities in a RESTful way such that we can introduce change quicker. If the decision is made to re-platform or if we get something off the shelf or if something comes from a cloud implementation of an application, we want to integrate all of that without impacting our clients.”
By developing RESTful APIs, USAA would have a foundation in place that allows it to develop and deploy back-and-forth application integration within days or weeks instead of months or years. This permits the company to leverage its large amount of data and the 30 years’ worth of investment in existing programs, no matter the language used to develop them. This could all be done without creating new integration interfaces every time a new business capability was requested and no matter the platform on which the resources are located.
“Some of what we’re going through involves changing platforms from the mainframe to a middle tier. The services and data may still be on the mainframe, so we’re essentially developing a hybrid platform that will mostly involve Java* and whatever else we need to surround the data residing on IBM Z*,” Wilson notes.
But as USAA learned early in its RESTful journey, some new Java applications would run perfectly fine on the IBM z Integrated Information Processor while others—which may have had heavy I/O or a lot of inter-language communications with non-Java programs—would fall back to the general processor. So the question became: Did USAA want to use Java for all new applications, or just for some parts?
Open and Standardized
Another issue the company had to address was whether new Java applications could communicate via custom USAA-developed infrastructure pieces that would continue to be used for its mainframe-based business applications.
Wilson soon discovered the answers to those questions. As he explains, “If you can develop an application using just Java, it’s worthwhile doing so. There are some challenges involved in the intermixing of Java with non-Java you have to overcome, but if you’re running under CICS*, there are some good APIs that can call out to non-Java programs from Java programs that work pretty well.”
The larger solution, however, came in the form of RESTful APIs. Open yet standardized, embracing defined formats such as XML, HTML and JSON, RESTful APIs can be built to meet developers’ particular needs, across different application types and their supporting platforms, including the mainframe and the cloud.
“I don’t think anyone can survive the ‘now’ demands of their consumers, users and, in our case, members, if they don’t deploy an open-architecture environment. At this point, it’s become an essential part of offering services that make a difference to end users. Without it, you may be doomed,” Wilson says.
And this isn’t mere hyperbole. If an organization can’t develop and roll out new services in a timely fashion, its competitors might. As with USAA, they’re getting an immediate leg up by quickly meeting market demands and, when using open RESTful APIs, future proofing themselves when it comes to creating as yet unknowable technologies.
For its part, USAA is slowly and deliberately rolling out RESTful APIs on a use-by-use basis. For example, it’s phasing it in for service-rep interactions, including for mobile and browser applications. Other use cases are either in the proof-of-concept stage or have already been or are soon to launch, as in the case of its internal service-rep programs.
Flexible and Mobile
Just as a grizzled and gleeful miner might shout “there’s gold in them thar hills,” modern-day organizations of many stripes are expressing similar sentiments by opening their once-closed resources to the world. And the benefits seem endless, whether it’s quickly offering new services, speeding up development time, or integrating years of data and legacy applications across platforms.
For its part, USAA’s goal is to REST-enable as many capabilities as it can, regardless, for example, of which platform its core applications and data are residing on—the mainframe, in this case.
“This will give us greater flexibility and mobility to handle the demand of our capabilities to service our members and service reps, introduce quicker change, improve the user experience and enhance the development experience in our programmer environment,” Wilson notes.