This post was co-authored by Ying Zhe of Discover Financial Services and Neil McAllister of Pivotal.
As a major player in financial services, Discover relies on information technology to stay ahead in its fast-paced industry. In addition to our flagship credit card, we offers loans and a variety of other products and services. But as with any company, systems that once were considered state-of-the-art will eventually need to be modernized to match the pace of innovation and change.
In Discover’s case, one pain point was our aging card-acquisition app. “Acquisition” is the credit card industry’s term for bringing in new consumers and businesses as credit card customers. The software powering these mission-critical activities at Discover—based on a combination of mainframe systems and Java apps running on WebSphere—was growing out of date. The goal was to modernize it into a new, cloud-native system.
Planning For Modernization
As with any such ambitious project, however, one difficulty was knowing just where to begin. As a first step, systems architects at Discover were tasked with drafting an architecture diagram illustrating their vision of how to meet the company’s app transformation needs. This process took 3–4 weeks; yet questions remained about what was the best way to go about it.
The team I assembled had a vision of engineering a cloud-native system that can take full advantage of what cloud computing can offer. We were faced with choosing a framework that would meet the needs of our fast-growing business.
The team had initially thought to engineer our new, cloud-native card acquisition app using microservices and a set of APIs, but there were concerns that this approach might not provide the flexibility for future changes. Instead, with Pivotal’s assistance, it was decided that the new system would be built using a model known as event-driven architecture.
Get more insights from Discover's digital transformation here:
5 Tips for Modernizing Your Legacy Application: Lessons Learned at Discover
Pivotal Platform at Discover: Transformation in Progress
As the new code began moving into production, the results were dramatic:
-
Go-to-market time for new features went up by 6x faster than before.
-
Length of code deployment went from 3-4 weeks to hours.
-
Late-night code rollouts were eliminated.
-
70% reduction of customer frictions due to system errors.
The secret lay in the way loosely-coupled, event-driven systems offer a high degree of flexibility, which in turn can allow a development organization to be more agile.
Mapping Events: A Team Effort
In the event-driven model, components of a system communicate with each other by issuing messages that represent events. These events can signal various things, such as the completion of a step of a process, or a change of state in an application component’s domain. Individual components of a system can subscribe to events that signal them to take action, and those same components can also publish additional events of their own. The overarching idea is to develop business logic in a way that more accurately represents real-life workflows.
But what, exactly, were the events that characterized Discover’s card acquisition process? There was no clear map. To create one, we turned to a process called event-storming.
Developed by Alberto Brandolini around 2012–2013, event-storming is a type of brainstorming designed to tease out the events in a given domain. It’s a human process, not a digital one. It involves gathering a small group of domain experts—including product managers, developers, data managers, or whoever is most appropriate—into a stand-up workshop with the explicit task of modeling events. It typically involves lots of wall space (or paper) to do the modeling, and lots and lots of sticky notes.
With Pivotal’s help, we brought together a team of architects and business stakeholders with deep domain expertise of how the card acquisition process worked. The goal was to break down the process into individual capabilities, until the group had identified the 50 (or so) capabilities Discover needed to say it was in the business of issuing credit cards. The team mapped out, as much as we could, the customer journey of the card acquisition—not just from the customer's perspective, but the actions the customer will take as they go through the journey.
Individual actions that were identified as steps in this journey, and the triggers of these actions —for example, a customer submits personal information, a Social Security Number is submitted for verification, or a credit reporting agency is contacted for approval—would be modeled as events. Along the way, similar actions were grouped together, and these groups would come to identify the domains represented by microservices.
More Flexibility and more customers
Once we were satisfied that we had mapped out the event space, what remained was to use this blueprint to build the cloud-native card-acquisition app. What we found was that the event-driven approach delivered an application that was much more flexible and nimble than it would have been had we proceeded with our original, more API-based approach.
For one thing, the cloud-native app freed Discover from the command-and-control model that its mainframe systems enforced. In the past, oine change to the legacy app could require multiple changes elsewhere in the system. With the event-driven app, if a given component doesn’t need to respond to given events, it can unsubscribe from them. Similarly, when a given workflow needs to be adjusted, new events can be produced for components to subscribe to and consume.
Perhaps the most important technical result was the significant increase in development agility afforded by the new model. While CI/CD at Discover was being adopted in pockets, the modernized system allowed Discover to deploy code into production essentially at the press of a button. This meant the time to put new features and fixes into production was reduced from weeks to as little as hours.
Further, while the event-driven model does add some operational complexity, in that it creates more things to monitor to ensure that events are being published and consumed correctly, the added flexibility more than makes up for it.
More importantly, the modernization effort is already achieving the result that really matters: bringing more card customers to Discover. Although we are only about halfway complete in our journey to a fully event-driven application, the work so far is delivering a much-improved customer experience. Users encounter fewer problems when accessing the application, which has resulted in higher credit-card-application submission rates. For the development teams at Discover, that’s the best measure of success.
