Turning a Data Modernization Strategy into a Data Monetization Program
January 17, 2023
We recently sat down with Tom Eck, Sr. Vice President of Digital Transformation at Fiserv, to discuss his extensive experience in application development.
This wide-ranging conversation covered topics including the definitions of digital transformation and a digital-first company, how Fiserv is planning to monetize (and not just manage) their data, and how application development teams need to modernize to best support the development and deployment of modern, cloud native applications.
Below is an excerpt of the key points covered during the chat.
Q: Let’s start by asking your opinion about digital transformation. What does that term mean to you?
Digital transformation encompasses many types of transformation, including cloud transformation. But digital transformation is much broader than the sum of its parts. Only part of it has to do with technology. To digitally transform, we need to start relying on more modern platforms such as YugabyteDB, other types of container management platforms, and, of course, the public cloud. But, digital transformation is broader than that. In any technology problem or project, tech is only about 25% of the challenge, and digital transformation projects are no different. To get the most “juice out of the squeeze” (if you will), we really need to address things like culture, mindset, and methodology.
Those three, along with inertia, are some of the most powerful forces in the universe. Everyone deals with the inertia of established methodologies and mindsets— the “this is the way we do things” or “I know this, and I don’t wanna change.” But, you might also have an organization where different business units sometimes operate in silos and are not completely aligned. So, in addition to all of the other technical things we’re trying to do, you have to get those things right simultaneously. And that is really hard.
Q: Let’s zoom in on the business. Fiserv is a data-first company. Can you talk about what Fiserv does and what it means to be data first?
At Fiserv, we call ourselves the world’s largest fintech. We are in the business of moving money, and we move about 1.5 trillion US dollars a year. During peak loads, that’s approximately 4,000 card swipes per second. That part of the business came to us from our acquisition of First Data. What Fiserv brought to the table is core banking software. With all the transactions we process and all the banking transactions we support, we throw off a lot of “data exhaust.” This data exhaust opens up a lot of possibilities for us to expand our portfolio, offer a wider variety of data products, and monetize our data.
We are in the early stages of getting this data monetization program in place. We’ve been leveraging our data (along with a healthy dose of AI and machine learning) to help combat fraud, better understand consumer behavior (for, say, the next-best offer), and improve merchant analytics.
Let me give you an example. Regarding the analytics, let’s say that you own some pizza shops and want to open up one more. Where do you put it? Where’s the best location? We can help answer that question by providing data on local foot traffic based on card swipes from nearby locations.
We can do other things that help our merchants as well. For example, we offer weather data that shows (for example) that a merchant’s foot traffic is down on inclement days. This gives them the opportunity to change their employee roster for that day. Let me mention one other thing that becomes important in terms of data monetization, and that is the proper handling of data rights at the consumer level. We see that already happening in Europe and other places around the world with PSD2, etc. So, we must get that right.
Q: Let’s talk a bit about application development. How do you see it changing? How does your apps team see change, and what are you gravitating towards?
I have a very elite applications development team. We call ourselves the “Tip of the Spear”. What I mean by this is that we’re the first to get access to the modern platforms, methodologies, and nouveau-type apps being developed for the payments and financial services industry.
I operate my team differently from most of the other teams at Fiserv. I am completely into Agile scrum, and we are a very flat organization—eight engineers, QA testers, and designers. One unique thing about my team is that I have a small design agency embedded within our organization because good design is super important.
I also have product on my team, so we are truly self-sufficient. We may be small, but we’re mighty. And that’s attributed to three things. First, I have great talent and a team of people who can work well together. That’s essential. Second, we have access to the most modern technologies. That helps us go faster. The third is our methodology.
We work in two-week sprints. During sprint planning, I enforce the fact that the team is making a commitment. At the end of the two-week sprint, everyone shows their work and explains if they missed the mark, what went wrong (if something went wrong), and what could be improved on. Then everyone demonstrates what they coded.
I am also really focused on automation and patterns, and as a last point, self-service. App developers need as much self-service as possible. They don’t need 800 numbers to call if they have a problem. They should be able to do anything they need to do to be proficient, whether at 3 pm or 3 am.
Q: You work with a robust transactional system in an always-changing environment. You are looking for ways to augment, enrich, and monetize data. How do you deal with that in terms of your two-week scrum cycle to boost productivity? It has got to be challenging.
It’s a challenge and something we have to get right. But once we get it right, it becomes a force multiplier.
We are developing patterns for app developers to securely and efficiently build, for example, microservices. We’re deploying on modern container management platforms, and we’re starting to code more and more in a cloud native way. So, let’s look at some numbers I just made up to illustrate a point. They are probably not accurate but they’re in the right zip code.
If you have a developer force of a thousand people, maybe a hundred can accurately describe a 12-factor app (i.e. microservice). Maybe only 50 have ever written a microservice, and three are experts. So how do we take the expertise of those fictitious three people and spread it around? We need to codify it in some way—intellect-as-code, if you will.
How can we do that? Well, when we build these patterns, we need to bring other people into the discussion, not just people like me who are in charge of app development. We need to bring in security, compliance, and regulatory teams to put the right guardrails in place. That boosts developer productivity. It not only increases the speed they can build apps (thanks to the framework in place), but now they don’t have to be concerned about other things like security. Once we can put application developers in a sandbox with the right guardrails around them, we’ve alleviated their fears that they might shoot themselves in the foot, and they can focus on building the business logic.
Q: So, how does a distributed SQL database, like YugabyteDB, factor into all of this?
I’m a big platform guy. I see technology as a set of platforms that expose services that I need but don’t want to (or can’t) build myself. And I expect them to act like a dial tone. We need the database engineering team to look at a distributed SQL database as a platform-as-a-service for the developers if you will.
I focus more at the Java level, so I rely on our database team to become the experts and work with the distributed SQL vendors, like Yugabyte, to get that right. And I have noticed that your roadmap focuses more on developer productivity and helping developers out. And that’s great because many don’t understand the nuances of working on a distributed database. They are accustomed to working with single nodes in a certain way.
But, we have to dig a bit deeper and look at how we can bring that knowledge (from the database teams and vendors) into these patterns so that app developers don’t get it wrong. One of our challenges is that we have traditional DBAs, who make sure indexes are tuned and that backups are run, etc. Then we have the app developers who lack the expertise to identify the difference between different indexes or know which views to use. So, I think there needs to be a role that sits between those two teams— like a database programmer or database engineer.
Then let’s get the knowledge from inside those people’s heads and into a pattern. I would love to have, for example, a pattern that says “hey, you want a microservice that talks to a database?” and then it provides an option for a NoSQL or relational/SQL database. And then, the app is automatically wired up into the appropriate YugabyteDB instance, for example.
That eliminates a lot of miscommunication, misunderstanding, or even a reinventing of the wheel.
Q: The day may come when you want to automate more of those building blocks as a DBaaS. In that case, how do you envision keeping app developers informed? If they discover patterns, how would they influence the rest of the platform so that the rest of the organization could leverage them?
One of the things we invested in over the last year is our “dev studio”. This studio is a single developer portal across all of Fiserv. It replaced the many different developer portals (with their different capabilities and credentials) that support our thousands of API-enabled products (each with hundreds of endpoints). It’s a single portal for both internal Fiserv employees and the third parties that integrate with us. So, that will be our go-to place, our primary communication vehicle to clients and employees.
Our goal is to get more done with the browser and have minimal dependencies outside of that. With this dev studio, I envision a day when our internal and external developers will only need to have two browser windows open. One window will be the browser on dev studio, and the other will be their favorite IDE.
Q: Let’s talk about the business impact of distributed SQL. Can you talk briefly about the differences between building apps using a single, “traditional” database and using distributed SQL? What value do you see, both to the developer and the business as a whole?
There are two main benefits. One is economics—obviously. The second is our high availability, data consistency, and data residency requirements. We must have multiple locations and require nearly instantaneous replication across those. And we’re 24/7, and on any given day, we’re doing 4,000 card swipes per second. If something goes down, even for five minutes, it will have a drastic impact. So, it’s critical that we are resilient and can distribute geographically or across clouds or across both on-prem and cloud. That lets us sleep better at night.
Now, as a developer, I shouldn’t care about my container management system. I shouldn’t care about the public cloud underneath it. I should see a connection string, but the developer might not even need a connection string if we do this right. It’s solved automatically. That’s where we have to get to. If you don’t pick the right platform, you’re as weak as your weakest platform.
There are a lot of choices out there, and we are thrilled with the direction that Yugabyte is going, and I think it’s fair to say that I’m going to be able to sleep at night.
Q: One of the things we have done—from the beginning—is be very compatible with PostgreSQL. YugabyteDB works and behaves like it. How important is that, in your opinion?
It’s very important, and I will give you an example. We just had a set of college interns, and we gave them a problem to solve—something we actually hoped to build into a product. I told them that they were going to use YugabyteDB as their repository. They told me that they did not know what that was. I said, “Google it.” So they did, and within a few days, they were up and running with it.
I think that is an overlooked portion of developer productivity—familiarity.
Q: Let’s segway into some of the cultural aspects you mentioned earlier. What cultural changes are needed to operate in this “Tip of the Spear” model that your team operates in?
You have to be unafraid to fail; you need to embrace the unknown. One thing that I learned from my boss is to write a press release before you start a project. What’s important about that press release is that it has a date on it and will have a few sentences about what you’re going to deliver. So you’re making a date commitment and outlining key features.
That press release not only focuses you on your commitment but is also really good for transparency. It gives upper management confidence that we’re getting our job done and that we will get done what we’ve committed to—on time and with excellence.
The other thing I always say is that I always want to have a stake in the ground, and we are going to run as fast as we can to it unless and until we get some additional information. Then we will move the stake—so very much the classic cycling of an agile two-week SCRUM.
Sometimes we get that stake in precisely the right place, and sometimes we don’t. Let me give you an example of one time we did. We were building an app for financial crimes, and I gave my team three sprints. Eight developers spent about six weeks running to this stake. At the end of six weeks, I wanted to see an early version. I wanted to see what this might look like because I wanted to get it out in front of a client. So we took it to a bank client and carefully explained that this app was not even in beta. It was just in the lab; it was just freshly written code. We showed it to them, and they said, “We want to buy it.” So – wow!
That was a case where we had a stake in the ground, and we had it just right. It doesn’t always happen like that, but it did then.
