WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=uA4ah-dVHvU

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/uA4ah-dVHvU.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.560 --> 00:00:13.920
My name is Gareth Yoder.

s3
00:00:13.920 --> 00:00:17.520
I'm the cash program technical lead here at Vanguard.

s4
00:00:17.520 --> 00:00:22.120
I help oversee four to six teams in the cash program.

s5
00:00:22.120 --> 00:00:27.280
This is no cash left behind, a Vanguard modernization journey.

s6
00:00:27.280 --> 00:00:37.840
This journey really starts after we delivered our cash plus offering to our Vanguard brokerage account clients, and we launched that in 2022.

s7
00:00:37.840 --> 00:00:47.600
And after we did the launch, we started to get the whispers that modernization is now coming down the pipeline, and that will be our next major project.

s8
00:00:47.600 --> 00:00:51.480
How many here have legacy code bases?

s9
00:00:51.480 --> 00:00:52.160
Right?

s10
00:00:52.160 --> 00:00:52.920
That's a lot of you.

s11
00:00:52.920 --> 00:00:57.280
How many of you wish that legacy code base would just modernize?

s12
00:00:57.280 --> 00:00:57.560
Right?

s13
00:00:57.560 --> 00:00:59.600
Many of you would say the same.

s14
00:00:59.600 --> 00:01:10.160
So, looking here at the journey, we're going to go through this timeline in today's presentation, but I want to first talk to you what a cash ledger actually is.

s15
00:01:10.160 --> 00:01:17.920
A cash ledger involves all money movement transactions into our Vanguard brokerage accounts from the outside world.

s16
00:01:17.920 --> 00:01:22.680
It also involves cash being moved between accounts.

s17
00:01:22.680 --> 00:01:26.960
And so, the payment rails, think ACH, wires, and more.

s18
00:01:26.960 --> 00:01:31.920
We support the web channels, mobile channels, and batch channels.

s19
00:01:31.920 --> 00:01:38.720
Our system runs in an active-active multi-region fault-tolerant ecosystem.

s20
00:01:38.720 --> 00:01:44.520
And our services will receive upwards to 30 million calls per day.

s21
00:01:44.520 --> 00:01:52.040
Our clients will generate a half million ledgers every day as well.

s22
00:01:52.160 --> 00:02:03.080
And so, as we start to go down this modernization approach, we broke it down into three pillars: a data migration, a producer migration, and a consumer migration.

s23
00:02:03.080 --> 00:02:09.840
But, because this was an enterprise priority, we had to do all three in parallel.

s24
00:02:09.840 --> 00:02:17.920
So, now, as we look towards the research analysis, remember we're at the beginning of our timeline, the AI tooling wasn't there.

s25
00:02:17.920 --> 00:02:28.640
And so, oftentimes we would work with mainframe engineers, and we would work with architects to try to determine what that data schema model would look like.

s26
00:02:28.640 --> 00:02:40.200
And there was a turning point in this modernization journey, and that's when we had our legacy codebase being available to our AI tooling via an MCP server.

s27
00:02:40.200 --> 00:02:43.160
And now we saw faster feedback loops.

s28
00:02:43.160 --> 00:02:57.640
What was taking 7 days for a mainframe engineer to go into the code, do their analysis, and then kind of and come back to us for an answer, now could all be done via an AI tool prompt.

s29
00:02:57.640 --> 00:03:06.560
And what we saw was that the feedback loop was reduced from 7 days down to 15 minutes.

s30
00:03:06.560 --> 00:03:13.519
It was a huge win for our product owners, our technical leads, and developers alike.

s31
00:03:13.519 --> 00:03:20.600
They all contribute this tool to helping our modernization succeed.

s32
00:03:20.800 --> 00:03:23.120
So, let's talk about data modernization.

s33
00:03:23.120 --> 00:03:33.200
We utilize the standard CDC change data capture approach that's common in industry, and we had to then scan both databases.

s34
00:03:33.200 --> 00:03:36.000
A team did daily audits.

s35
00:03:36.000 --> 00:03:50.800
We first made sure we had strong consistency by verifying the row level data counts, and then we ensured that we had strong integrity by checking the individual columns, making sure that the amounts matched from the legacy

s36
00:03:50.800 --> 00:03:57.120
to the modern, making sure that the account information would match or the state withholding, the federal withholding.

s37
00:03:57.120 --> 00:04:02.440
All of the attributes in the legacy database had to match to the to the cloud.

s38
00:04:02.440 --> 00:04:11.920
A major tip here is that you don't want to over-engineer the solution because as modernization would complete, this code would then get deprecated.

s39
00:04:11.920 --> 00:04:15.200
Now, let's talk about producer migration.

s40
00:04:15.200 --> 00:04:21.840
Our producers called our infrastructure in three ways from the legacy state.

s41
00:04:21.840 --> 00:04:23.800
One was through a service request.

s42
00:04:23.800 --> 00:04:27.200
The second was an API that wrapped that service request.

s43
00:04:27.200 --> 00:04:38.240
And the last and probably the most daunting was direct table inserts because we would see data appear in our database and we weren't sure how it got there or who produced that data.

s44
00:04:38.240 --> 00:04:47.440
So, we took that common data schema and we put it onto a gateway that wrapped our APIs that would do our cloud data inserts.

s45
00:04:47.440 --> 00:04:53.640
Now, take your modernization journey as an opportunity to reimagine your data ecosystem.

s46
00:04:53.640 --> 00:04:57.600
We took concepts from FinTechs such as item potency.

s47
00:04:57.600 --> 00:05:03.080
We also ensured that we had strong consistency across multiple writers.

s48
00:05:03.080 --> 00:05:08.640
And so, we used utilized a similar paradigm to what a Snowflake ID would provide us.

s49
00:05:08.640 --> 00:05:13.480
We are reimagined and we didn't do a lift and shift.

s50
00:05:13.480 --> 00:05:18.120
Now, we have a modernized producer offering available.

s51
00:05:18.120 --> 00:05:20.120
How do we get our producers?

s52
00:05:20.120 --> 00:05:26.600
We had 35 producers that had to then modernize to our ecosystem.

s53
00:05:26.600 --> 00:05:33.160
Early on, we had to produce manual documentation to facilitate this transition.

s54
00:05:33.160 --> 00:05:42.400
And as the AI tooling became available, we provided that documentation in our company's wiki, but then exposed it via the MCP server.

s55
00:05:42.400 --> 00:05:51.600
And that was really great because what it did was we used to have many teams having chats with us, and we had to try to keep all of those organized.

s56
00:05:51.600 --> 00:06:08.200
Now that communication and that back and forth could all be done via the prompt on the producer side, and we saw that the number of chats and and producer support that our team was doing was greatly reduced when we had the MCP available.

s57
00:06:08.440 --> 00:06:16.320
The AI tools also did a really good job of transitioning state from the legacy ecosystem to the cloud.

s58
00:06:16.320 --> 00:06:27.520
We made our cloud ecosystem, the ledger enums, to be human readable versus just ledger status codes in our legacy ecosystem.

s59
00:06:27.520 --> 00:06:36.880
And so, our AI tooling did a really good job at bridging the gap of the intent from the legacy ecosystem to the cloud.

s60
00:06:38.120 --> 00:06:42.520
So now let's look at the consumer migration path.

s61
00:06:42.520 --> 00:06:48.320
We had three ways to access consumer level data.

s62
00:06:48.320 --> 00:06:53.880
We had real-time use cases, batch use cases, and streaming use cases.

s63
00:06:53.880 --> 00:07:04.080
And the commonality here is that we provided a schema registry, no matter which channel that your uh consumer would access that data.

s64
00:07:04.080 --> 00:07:16.000
And so, for a funds available, that's our most that's our most uh heavy traffic uh real-time API, and that goes into determining what is the balance that's displayed on your account.

s65
00:07:16.000 --> 00:07:25.120
They're going to be calling us via GraphQL, and they're going to subscribe to only the attributes that meet their use cases.

s66
00:07:25.280 --> 00:07:30.440
Now, for batch use cases, think of reconciliation or data analytics.

s67
00:07:30.440 --> 00:07:36.840
We have our data warehouse that will expose data share views to each individual consumer.

s68
00:07:36.840 --> 00:07:43.720
Each of the consumers tells us their use case, and we provide a a view that's specific to their data needs.

s69
00:07:43.720 --> 00:07:56.040
This This was supported by our data governance team that strongly advocated that only the consumers that need the certain data attributes, they should only see uh those pieces of data.

s70
00:07:56.040 --> 00:07:58.680
Our last piece was around streaming.

s71
00:07:58.680 --> 00:08:05.520
We have a Kafka event topic that we would stream all of the inserts and updates to that database.

s72
00:08:05.520 --> 00:08:15.520
Our fraud teams were able to take take advantage of this technology to provide real-time data ingestion into their fraud tooling.

s73
00:08:15.520 --> 00:08:18.200
We provided at least once delivery.

s74
00:08:18.200 --> 00:08:27.200
And so, our concepts of item potency that we did through the producer side, we carried forward through the event streaming.

s75
00:08:27.200 --> 00:08:36.280
And so, as they subscribe to at least once delivery, we made sure that they had item potent safe uh operations.

s76
00:08:36.280 --> 00:08:46.520
So, that if a batch job would would fail halfway through the process, those teams could retry, and we can ensure that we don't have uh duplicate ledgers being created.

s77
00:08:46.520 --> 00:08:54.880
But, the at least once delivery from the eventing side ensured that they had all of the ledger events that were created.

s78
00:08:57.839 --> 00:09:05.320
Now, when we onboarded consumers, we had 50 different consumers across our organization that needed our data.

s79
00:09:05.320 --> 00:09:15.640
At Vanguard, when you onboard an application, you need to have a three-character application code to register to onboard.

s80
00:09:15.640 --> 00:09:21.760
This application code describes what your application is and and what it performs.

s81
00:09:21.760 --> 00:09:23.600
But, we took it a step further.

s82
00:09:23.600 --> 00:09:34.800
We requested that our consumers would provide us a description and a business case justification for their need for the data.

s83
00:09:34.800 --> 00:09:46.320
And so, think about if I am a trade order that needs a cash ledger to fill fulfill the cash obligation of the trade, that could be a business use case.

s84
00:09:46.320 --> 00:09:51.440
Or for a retirement account that needs to do a a required mandatory distribution.

s85
00:09:51.440 --> 00:09:59.920
A 529 account could do a contribution to their college tuition account.

s86
00:10:00.000 --> 00:10:13.880
By grouping together all of these business descriptions, now the AI tooling can compile that together and provide an accurate description of what use cases have been modernized in our ecosystem,

s87
00:10:13.880 --> 00:10:18.920
as well as we now have what is the top business functionality that we support.

s88
00:10:18.920 --> 00:10:27.400
We can also take it a step further by asking what is the impact if our SLAs are breached.

s89
00:10:27.400 --> 00:10:42.960
And this is critical because if you're in a major incident and if we see an app code that starts to go go below the five nines of availability, we can go in and we can see, okay,

s90
00:10:42.960 --> 00:10:46.480
a batch application we may have hours to respond.

s91
00:10:46.480 --> 00:10:56.400
A real-time API where there's a client on the other side that's receiving errors, we have minutes and time is of the essence to self-heal.

s92
00:10:56.400 --> 00:11:11.800
We're continuing to evaluate how we can get faster response times by combining the business use case justification into our observability and and log traces.

s93
00:11:12.000 --> 00:11:26.400
So what we've learned, we've learned that although we started this journey before the AI tooling was even available, we adapted and continued to adopt the newer technologies.

s94
00:11:26.400 --> 00:11:32.200
This greatly aided in our research, in our development, and our testing.

s95
00:11:32.200 --> 00:11:41.480
Today our cash program, 90% of our engineers utilize these AI tools on a daily basis.

s96
00:11:41.480 --> 00:11:46.160
Our teams use multi-agent workflows, and we have shared knowledge bases.

s97
00:11:46.160 --> 00:11:51.040
We're continuing to evolve this AI harness to meet our modernization demand.

s98
00:11:51.040 --> 00:12:06.920
We have the concept of a team brain that as engineers are are building out product features, that knowledge goes into a common storage where it's now accessible by all members on the team.

s99
00:12:06.920 --> 00:12:16.000
And if there's an engineer that has just joined, they can tap into this common knowledge base, and now they have the same context in their prompt as an engineer

s100
00:12:16.000 --> 00:12:19.880
that has been here for the last 5 years.

s101
00:12:20.440 --> 00:12:28.840
Now, when you're in a modernization process, maintaining two code bases is challenging.

s102
00:12:28.840 --> 00:12:33.480
And what you'll want to do is you'll want to continue to fix forward.

s103
00:12:33.480 --> 00:12:36.360
Don't fix the past.

s104
00:12:36.360 --> 00:12:51.320
As you encounter bugs that have may have listed have existed for decades, continue to fix the modernized state and allow that to be the incentive for your producers and your

s105
00:12:51.320 --> 00:12:55.120
consumers to modernize to the cloud.

s106
00:12:55.120 --> 00:13:01.640
Now, this will throw off your audit logs, so you'll want to have white listing available, and that's really critical.

s107
00:13:01.640 --> 00:13:12.920
And the last piece is ensure that you have the right metrics, alarms, and traceability, because you're going to review those often as your product continues to grow.

s108
00:13:12.920 --> 00:13:16.920
Now, because this is a leadership track, I want to call out five main points.

s109
00:13:16.920 --> 00:13:24.000
Number one was make your knowledge make your legacy code base AI queryable.

s110
00:13:24.000 --> 00:13:32.760
That exposing that via an MCP server, our legacy code base it cut that research cycle time and gave quicker feedback loops.

s111
00:13:32.760 --> 00:13:34.960
That's 7 days down to 15 minutes.

s112
00:13:34.960 --> 00:13:37.160
That was a huge win.

s113
00:13:37.160 --> 00:13:40.640
Treat your migration docs as part of your product.

s114
00:13:40.640 --> 00:13:52.080
It needs to your migration docs are just as in critical as your business functionality because that's what all of your producers are going to utilize to onboard to your application.

s115
00:13:52.080 --> 00:14:01.120
Eventually, yes, those will get deprecated out but for that interim process those migration docs are critical.

s116
00:14:01.240 --> 00:14:05.920
Reimagine and don't lift and shift is is the third point.

s117
00:14:05.920 --> 00:14:19.200
The consumers and producers that we had the most trouble onboarding to our modernized state were the ones that wanted to do a direct lift and shift transfer of old to new

s118
00:14:19.200 --> 00:14:32.160
versus those that took a moment to step back and say, "How could we better evolve our product by taking advantage of the modern capabilities that the cash ledger ecosystem

s119
00:14:32.160 --> 00:14:34.160
provides?"

s120
00:14:35.160 --> 00:14:40.560
The fourth component is adopt AI incrementally.

s121
00:14:41.560 --> 00:14:46.680
As the AI tools arrived, you continue to enhance your product.

s122
00:14:46.680 --> 00:14:51.400
There's never going to be a perfect starting point in the world that we live in today.

s123
00:14:51.400 --> 00:14:59.400
The important thing is that you get started and you continue to enhance and adapt as the technology changes.

s124
00:14:59.880 --> 00:15:03.360
Last piece is observability is non-negotiable.

s125
00:15:03.360 --> 00:15:07.800
You need to know who's producing your data and who's consuming your data.

s126
00:15:07.800 --> 00:15:20.800
And this is ever more important as your product goes to BAU and once the modernization is complete, your teams will now have to support this as their uh daily operations.

s127
00:15:21.920 --> 00:15:24.640
Thank you very much, all.

s128
00:15:24.640 --> 00:15:26.040
If we have time, we'll take questions.

s129
00:15:26.040 --> 00:15:27.600
Otherwise, I'll be outside of the room.

s130
00:15:27.600 --> 00:15:29.320
You can connect with me later.

s131
00:15:29.320 --> 00:15:32.075
And thank you again for the opportunity.

s132
00:15:32.075 --> 00:15:34.075
[applause]