In a field like financial services, where competition is fierce from incumbents and digital-native startups alike, committing to application modernization—as well as building new apps to address new opportunities—is a no-brainer. The more difficult decisions come around how to build these applications while staying within the bounds of industry regulations, corporate goals, shifting cybersecurity threats, and internal processes that can favor the status quo over real progress.
Enter Swift. The beauty of using a process like Swift to guide modernization decisions—and doing it with a team like VMware Tanzu Labs, which has seen the good, bad, and ugly inside similar organizations—is that it’s an opportunity to innovate (and to avoid risk) by thinking holistically about what you really want or need from an application, and what the best routes are for delivering those requirements. The answers to whether you need to break down organizational walls, ditch the mainframe, or adopt the latest whizbang technology aren’t preordained, but rather are functions of what will lead to an application that does what it’s supposed to do.
We recently published a series of Cloud & Culture podcast episodes on Swift, featuring Swift expert Shaun Anderson and some of his colleagues from Tanzu Labs. The first episode—highlights of which you can find here—focuses on defining Swift and explaining the process. The second episode, which is the focus of this post, is about the experience of working with clients to apply Swift in financial services.
You can listen to the whole episode in the player. Keep reading for some highlights.
Recognizing patterns from firm to firm
Here’s what Anderson had to say about the type of knowledge he and his colleagues glean as they work closely with clients that, as unique as they might feel, actually share many of the same issues and hurdles:
“I think [pattern recognition] is one of the benefits of having that top-down approach, thinking about how the systems want to behave. Because the more that we’ve been involved with various types of financial services companies, you do start to see that there are patterns that repeat themselves, even though everybody's their own little snowflake.
“It's things like, compliance is always there. As an example, in the U.S. when you're applying for a loan or a credit card or something like that, there are requirements that didn't use to exist, that do now, that you have to do an OFAC check to see if the applicant’s on the terrorist watchlist ... or if they're in a country that the U.S. has banned business with, something like that. But the solution to those becomes a similar pattern.
“So when we start to see that, ‘Hey, both insurance and consumer lending have the concept of an application, and they have a concept of either decisioning—’Do I have enough information to say, yep, this person approved for a loan?’—or underwriting—‘Yes, they qualify for our product.’ With all of those kinds of patterns, you start to see flavors repeating themselves, which is nice because it means . . . you're at least part-way there—‘Hey, at this other customer, this worked well for that same core capability.’ And it helps validate that that was a good direction to start going. Or you start to see that [you] went through this rapid feedback loop and you realize, ‘Well, maybe we didn't implement that the best way, so we should make a change at the next opportunity.’
“But those same patterns repeat themselves, both from a business capability and need standpoint, and the design of the system that evolves to model or make that part of the system actually work.”
You can keep your mainframe
Another important thing to understand about modernizing financial services applications is that they probably don’t need a complete overhaul, especially if doing so would be more trouble than it’s worth. A classic example of this is the debate about what to do with mainframe workloads: Any reasonable value proposition for modernization would suggest that they need to go away, but the reality on the ground is often that they’re deeply entrenched and actually quite effective at the job they were designed to do.
Here’s Anderson’s take on that very topic:
“In a lot of cases . . . the mainframe is rockin’ at the rate calculations for insurance or this particular component, but it's not very good at backing up a web app or a mobile app on somebody's phone. And so what we'll do often is discover that unless there's a desire to say, ‘We want to get rid of the mainframe experience completely,’ [is] say, ‘Well, here are some core capabilities that totally make sense to run in the cloud now. And maybe the number crunching, for example, we'll just keep on the mainframe. Or we'll even modernize that, but have it more efficiently optimized for just the small capability it's used for.’
“And so it doesn't always go away, but that's actually good because you're more effectively using it, just like any other software system.”
Tanzu Labs’ Felicia Schwartz was also a guest on the podcast, and shared the experience of working with an insurance industry client whose process for generating customer quotes involved mainframes and faxes:
“Taking that component [and] understanding ... the North Star, where it needed to be, we could focus on breaking that one piece away from the mainframe, iterating on that in weeks, getting that piece automated, and using the latest technology ... to use their APIs instead of faxes. And it allowed quicker turnarounds. The bulk of the application still resided on the mainframe, but the capability was quickly put in place that [addressed what] really was a roadblock for the customers.
“The process within Swift of seeing the big picture, where it needs to go, where the pain points are, allows you to make those quick changes first.”
More on the Swift Method
Ready to untangle the core business applications hindering a better experience for your customers? Learn more about Tanzu Labs and contact us at tanzu.vmware.com/application-modernization.
About the AuthorMore Content by Derrick Harris