Dreamforce 2019 - 5 takeways from SunTrust's open banking journey to API-based integration

Yesterday, US regulators gave the final green light to the merger of BB&T Corp and SunTrust Banks to form Truist Bank, which when the transaction closes next month will become the sixth-largest US bank, serving more than 10m households. In a session yesterday at the Dreamforce conference in San Francisco, delegates heard about an IT initiative that will play a crucial role in the future of Truist — the introduction of an API-based integration strategy to enable open banking.

The goal of the project has been to open up banking data to trusted partners and offer a wider choice of flexible, innovative services to customers. But as anyone who's been involved in any initiative to open up application programming interfaces (APIs) to the outside world will know, there's a lot of transformation work that has to happen internally first. David Shonk, Senior Vice President of Enterprise API Strategy and Delivery Manager at SunTrust gave some insights into key learnings along the way.

1. This is not a technology play

The biggest takeway — this is about people, process and culture much more than it's about technology. Creating a marketplace where people can self-serve API-based resources is a completely new channel for the bank, he explains:

If you go into this thinking that this is a technology play, you won't win. This is not [like] a Microsoft .Net to Java transformation. This is all about engaging stakeholders across your your businesses, and your technology providers, security and operations teams, in such a way that we can fundamentally transform the capabilities that we're bringing to bear.

What we basically put in play is the idea that through APIs, through the marketplace, and through this concept of an open banking platform, we're creating a new delivery channel, just like online banking, just like mobile banking. We can then use that digital platform to enrich experiences with our clients and with the people that we deal with on a daily basis.

2. APIs need a consistent approach

An important part of that shift in mentality has been to think about the customer experience. A traditional banking approach has been to build each type of contact as a separate transactional experience. The goal of an API-based approach is to offer many different touch points that all operate in a consistent way.

By building this digital platform, by creating these APIs, by turning these APIs into products and evangelizing what they bring, we offer a many-to-many relationship and we then begin to move away from this singular, one-dimensional aspect. By virtue of that we get a huge set of value propositions that we can then extend in a lot of different directions ...

We truly believe that we can, through this concept, increase the quality of what it is that we're delivering.

3. Internal APIs are part of the landscape

One early learning was that, while the impetus for moving to an API-based model is to enable business owners to have quicker times to market, technology teams also have to follow the same model.

We wanted to build an API-based technology platform as a single platform — that gives us a lot of flexibility in how we use it. By virtue of that, we're then treating these APIs as first-class digital products. These products have product managers and it's their job then to build the ROI, to build the marketing plans and to build the communications plans around each of these.

In going through the process over several months, we came to a stark realisation that our internal integration API's are all going to have internal integration product owners. It's just not practical to get a business person excited about taking ownership of an integration API.

That meant that technology teams have had to learn to communicate the benefits of what they're building, he adds:

What we've seen historically is that our technology teams are really good at delivering technology value. But we're pretty terrible at being able to communicate the benefits of that technology value.

4. A Center for Enablement sets the tone

A key part of the methodology recommended by API platform provider MuleSoft is to create a Center for Enablement (C4E) which acts as a central resource to for people building APIs:

It's an adoption mechanism that allows us to be able to drive, across the enterprise, a common set of governing practices around what it means to manage the lifecycle of an API, what it means to onboard a delivery team who's going to use the MuleSoft platform, and then what it means to be able to evangelize and to share, both inside the technology team and across the business teams, the ideas that are going on. It allows us to be able to move forward together.

Without a C4E in place, devolving the ability to develop integration APIs out to teams across the business is a risky move, says Shonk:

What I'm thinking is, I just gave the developers sticks of dynamite to go blow themselves up with! We don't want to do that. We want to be able to control the forward momentum in such a way as to govern a well-thought process. We're using the concept of what we call delivery coaches, where I will take my senior architects and embed them in your delivery teams in order to help you go through the onboarding process. That helps them you know, get acclimated to it and it gives us then the ability of being able to scale it much, much quicker.

5. You have to move on from SOA

The MuleSoft platform has enabled Suntrust to build a timeless CI/CD pipeline which means that code testing and delivery can be 100% automated, says Shonk. This is part of enabling a bottoms-up approach to development that simply wasn't possible under the old service-oriented architecture (SOA):

If someone wants to reuse one of my SOA web services, there's a cost of doing so. Because of the change management practices associated with those web services, there's a lot longer delivery time than what there would be if we bring to bear a self-service consumption model ...

I was a champion of the SOA paradigm for a very long time and it got us to where we are today, but it's simply not capable of being able to get us to where we need to go in terms of this digital transformation. We need to move away from assisted delivery to self-service, we need to move from a consumer-specific point of view to a provider-specific point of view, bottoms up ...

We've always been really good at design-time governance. Part of what we want to move is into the world of run-time governance, in order to shorten those delivery cycles.

As part of creating the infrastructure to support an automated pipeline, Suntrust has been able to refactor a lot of its integration landscape, optimizing existing Cast Iron and DataPower integration services to reduce the number of separate instances and moving from 17 separate physical instances to less than five logical environments that map back to the remaining physical instances elsewhere in the organization.