May 13, 2025 • 22 mins
Welcome to another edition of The Disruptor Podcast!
This is part two of our two-part series.
In this episode, Zengines CEO Caitlyn Truong returns to reveal how her team simplifies the high-stakes challenge of mainframe modernization.
She also discusses the challenges of mainframe modernization and how Zengines helps enterprises de-risk legacy systems with smart data lineage.
Key Topics Discussed:
- Why legacy mainframes still dominate large enterprises
- Common missteps that derail modernization efforts
- How Zengines turns “black box” systems into readable data
- Real case studies from banking and industrial sectors
- Key strategies to reduce project risk and cost overruns
Key Insights / Quotes
- “Enterprise data lineage is a beast—start small with a clear use case.”
- “We help teams reverse-engineer the mainframe into business requirements.”
- “Every test case break used to spawn three more questions. Now they get answers in minutes.”
- “It’s not about replacing mainframes—it’s about de-risking what’s already working.”
Zengines' Disruptive Way:
- Providing business analysts with AI tools for automating data mapping & changes.
- Minimizes large teams, speeding up data conversion
- Prioritizing tasks earlier in the process
- Lowering costs and boosting productivity
To learn more about Caitlyn and Zengines, visit their website (Zengines.AI) and connect with Caitlyn on LinkedIn.
In Part 1 of our conversation, Caitlyn and I discuss how Zengines disrupt organizations by automating data conversion. Listen here: Disruption in Data: Why Digital Migrations Fail and How to Succeed.
Comments or Questions? Send us a text
***
Engage, Share, and Connect!
Spread the Word: Valuable insights are best when shared. Share this episode with peers who may benefit from it if you find it insightful.
Your Feedback Matters: How did this episode resonate with you? Share your thoughts, insights, or questions. Your engagement enriches our community.
Stay Updated: Don’t miss out on further insights.
Subscribe: You can listen to our podcast, read our blog posts on Medium, Substack, and LinkedIn, and watch our YouTube channel.
Collaborate with The Disruptor and connect with John Kundtz.
Got a disruptive story to share? We’re scouting for remarkable podcast guests. Nominate a Disruptor.
Thank you for being an integral part of our journey.
Together, let’s redefine the status quo!
Tips are welcomed and appreciated, too!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:01):
Disruption and Data Transforming, migration and
Modernizing Mainframes.
Hi everyone, I'm your host,john Kuntz, and welcome to
another edition of the DisruptorPodcast.
For those new to our show, westarted this series back in
December 2022 as a periodicsegment of the Apex Podcast.
Our vision was to go beyond theconventional wisdom by
(00:23):
confronting the status quo andexposing the raw power of
disruptive thinking.
Today, in part two of our show,we welcome back Caitlin Truong,
ceo of Zengens, as we explorehow her company disrupts
organizations, automates theend-to-end data conversions.
We will discuss valuable adviceon the pitfalls, the mistakes
(00:45):
that many executives make whenattempting digital
transformation.
Welcome back.
Speaker 2 (00:50):
Thank you so much, john.
Speaker 1 (00:51):
Before the break, we were discussing the broader
challenges of data migration.
In part two of the show, wewill focus on a particularly
complex area modernizing themainframe systems.
Caitlin, let's dive into theunique challenges and solutions
to bring to the table whentrying to do mainframe
modernization.
Many people believe themainframe was a thing of the
(01:13):
past.
Having spent 38 years at IBM, Iheard that, probably for 25 of
those years, but, as you know,they persist in many
organizations, especially largeenterprises.
Some of the largest banksaround the world, large
institutions, still heavily relyon the mainframe and there are
(01:35):
specific challenges andopportunities and I'd like you
to dive into what those might bein the context of mainframe
modernization in a digitaltransformation.
Speaker 2 (01:46):
Thanks, john.
I fully agree.
Of all my clients and customersfrom Vengeance and all my
consulting years, I know thatcustomers have always indicated
that mainframes are highlyperformant, highly reliable.
So I don't think that's themain driver of some of the
opportunities associated withmainframe modernization.
(02:07):
Really, I think it's aboutde-risking that legacy
technology right the fact thatit was written decades ago and
some of those SMEs aren'tavailable.
Whether it is because there arenewer code bases so you don't
have as many people who know thelanguages with which were
written in some of thosemainframes long ago.
(02:27):
Whether it's because what waswritten back then and again
remember some of these 60 yearsago just weren't as many
standards, so it's maybe moredifficult to maintain some of
those code and programs from wayback when.
It's really about de-riskingthe business, more so than it's
a problematic area.
I think the product andtechnology is fantastic.
(02:47):
It's just a need for businessto ensure they are resilient and
staying relevant Organizationsall of the ones that you're
talking about, across allindustries.
They're looking to exploremainframe modernization and
taking different flavors.
Some cases they are keeping thesame build functionality of
programs and just rewriting itin different languages, and in
(03:10):
other cases they aredecommissioning or sunsetting
those old systems and moving tovended cloud-based software
solutions.
Part of that, if they're movingto SaaS, is that they feel they
can benefit from constantlyreceiving software updates and
they can be absolved of nothaving to maintain the code and
programs themselves.
(03:31):
Those are key drivers and I'mseeing a lot of those in banks,
insurance companies, industrialcompanies, etc.
Speaker 1 (03:38):
It's amazing how much COBOL code is still out there.
The people that built thosesystems they're not around
anymore.
I was working in a bank inSouth Africa.
They had built a tier four datacenter.
They were trying to move theirmainframe-based core banking
system out of a tier three datacenter.
They spent a lot of money onthis really fancy new data
(03:59):
center but they couldn't findthe time to do the data
migration.
They couldn't take the systemsdown.
The amount of time it wouldtake to analyze the data was not
within their downtime window.
They made multiple attempts tomove but couldn't do it because
they were running the corebanking system.
I know this is a major problemand concern with any sort of
(04:23):
mainframe modernizationinitiative, whether you're
trying to move to a differentlocation or if you are trying to
refactor some of these oldCOBOL programs and applications
that were written 40 years ago.
So how do you specificallyaddress these complexities in
mainframe data migration andmodernization?
Speaker 2 (04:44):
I was looking at the stat, there are more lines of
COBOL code in existence than anyother programming language.
It is still true, there is avoluminous amount of COBOL code
still in existence.
So all of those things.
There's an interesting casestudy.
There was a bank looking tomodernize and move to a new core
(05:05):
and payments system and theywere converting off the
mainframe.
Unfortunately, this story is apainful one where they weren't
able to because the mainframewas a black box to them.
They tried to migrate some ofthe accounts over to this new
vended software.
When they tried to go live,they actually shut out customers
out of their bank accounts forover a week.
(05:26):
This was very bad.
They could not complete thisbecause it was so terrible they
had to shut down the program.
Now they are managing twodifferent systems.
The old mainframe core is stilllive and then a number of
accounts are still now on thenew system.
As you can imagine, thebusiness case was not realized
at all.
Some of those executivesunfortunately lost their jobs.
(05:49):
That's why I think it wassomething we ran into when we
were working with a customer.
We were brought in to help themwith a conversion While we were
there.
Oh, my goodness, this mainframeis a black to the business.
How will I convert if I don'tknow how to answer whether or
not that rule is right or wrong?
Zengens said, because of ourcore product and our ability to
ingest certain things andactivate metadata to be smart,
(06:13):
let us see if we can give this ashot.
So we did and evolved.
We created a second product, asecond capability.
It's our mainframe data lineageproduct.
This is specific to helpingteams get through that
modernization effort.
I'm not a refactoring tool, I'mnot a porting tool.
I ingest the schema, I ingestthe metadata, I ingest the code,
(06:36):
the full code base, includingthe JCLs.
I use all of that to get a datalineage information base.
But we are actually a researchtool.
We allow business analysts tounderstand business calculation
logic and the various conditionsthat caused it to use this calc
statement versus this calcstatement.
(06:57):
It empowers the business to beable to reverse, engineer what's
inside that black box intobusiness requirements for them
to execute a conversion.
The business analyst can havetheir sets of test cases that
they want to run through thesystems right, because they want
to turn the new system live.
It's a new vended product andin their test case they will run
(07:19):
a scenario where they run atransaction through the old
system and a transaction throughthe new system, old system
being the mainframe.
If the output is the same, allgood.
They will use out-of-the-boxbusiness rule from the software
of new product.
Unfortunately, they run into alot of breaks.
Where the values are old systemlegacy mainframe says the
(07:40):
output is negative five and newsystem says the output is five.
At this point in time, thebusiness says who is right?
Is it that we have a rule orsome variation or some specific
business rule that we need tomake sure we account for, or is
the software system wrong in howthey are computing this
calculation?
They need to understand whatwas in that black box to make a
(08:04):
decision.
Today that process looks likethe business writing a question
and sending it to the mainframeSMEs and then waiting for a
response.
As the mainframe SME canascertain, that mainframe SME is
navigating and reading throughCOBOL code, traversing module
after module, looking at go-tos,lookups and reference calls.
(08:24):
It takes some time to come back.
When the business gets thatanswer they say, okay, that's
helpful, but now you've spawnedthree more questions and so
that's a painful process for thebusiness to feel like they are
held hostage a bit to the factthat they can't get answers
themselves.
So this is what Zengens diddemocratizing that knowledge
base and making it available forbusiness to get answers so they
(08:46):
can successfully complete thatconversion.
Speaker 1 (08:49):
That's incredible.
I think we might have workedwith the same customer or know
the same customer.
I've heard that story a bunchof times myself the more I talk
with you.
I really wish you guys werearound back in 2015 when we were
trying to do all these work,but it's obviously the times
have changed and you'veleveraged your knowledge and
(09:12):
technologies to help with theseprojects, which I think is super
cool.
What are some of the criticalsuccess factors for
organizations undertakingmainframe modernization projects
?
What would you recommend to anexecutive that says I want to
move my core banking systems offthe mainframe and put them
under another cloud-based system?
Speaker 2 (09:30):
Yeah.
So I would say that it isimportant always upfront, make
sure that there is anunderstanding of what you're
converting.
Make sure there's anunderstanding of the right use
case, the right scope, amount,etc.
If it's going to touchsomething, you have to
understand the full lineage ofthe mainframe itself.
How do you understand all ofthe interdependencies or what
(09:53):
are the ramifications?
If you're only looking to decomone area, there's probably
threads to other modules andprograms.
First, to make sure there'sclarity and understand what's
important to realize from an ROIperspective.
Second, have a guiding strategyand design these mainframe
(10:13):
workhorses.
You have a lot of functionalityin them.
I've never seen it be a big bang.
My personal experience.
I've seen phased approaches.
When it is, it's a bit of well,I'm going to modernize this guy
, but that means I need to feeddata out of the new system back
to the old system to keep itcurrent, because some aspects
are still live on the mainframe.
(10:33):
Have the right plan design, beagile about it.
And then I say employ a tool.
You do need data lineage and Iwould say something that we
learned going through thisexperience with our customers is
that it's not lineage at facevalue that the business needs If
you're going to go through theconversion, you need the tool to
(10:54):
help you answer questions, andI think that's really what was
the sticking point, because itwas not just oh, I just need the
traversal pattern, theinterdependencies.
That wasn't the only thing thebusiness needed.
The business and engineeringteam, when they had to do the
research themselves, found thatthe first question you get isn't
always the only question or theanswer you needed.
(11:17):
Right, you start with aquestion that might cause you to
unpack other questions and thenyou might need to step back and
look at a visual to understandthe full map of the potential
impact area.
So, having a tool that allowsyou to answer questions
associated with going throughchanges, how can you be sure
that you are now able to answerwhat was built?
(11:38):
Why was it built, how was itbuilt, what were those rules, so
that you can be sure that youcan successfully decommission
portions of the program safely.
Start small, start withsomething that you know you can
convert and move.
Celebrate those successes,because it is possible and we're
seeing great results.
Something I would emphasize,john, is that the team attempted
(11:59):
to rewrite everything that wasin the mainframe.
There was just no way that theteam attempted to rewrite
everything that was in themainframe.
There was just no way that theorganization could finish that
job in our lifetime.
It's all of these modules, allthese reference to thousands and
thousands, tens of thousands ofother modules.
So then it was okay, we'll onlyresearch the things that break
those reconciliation issues.
And even that took two monthsfor one inquiry to come back
(12:22):
from the team, probably becausethey have to manage and run the
Mayfirm itself.
So what we saw was they wantedto make sure there was a way to
get answers quickly and reducethat dependency on me's.
It became something that allowsthem to understand or shed a
light into the black box.
Speaker 1 (12:44):
It makes a ton of sense to me the use case, the
use AI for the data lineageinvestigation or analysis.
So, as you said, it takesforever for a human to do it
because they have their day jobs, but it's a lot of work.
If you can leverage an AI largelanguage model to help you
(13:05):
figure out the lineage, youshrink the time needed to figure
that out, which allows you thetime to actually do the data
migration, data conversion ormainframe modernization
initiative.
Am I saying that correctly?
Speaker 2 (13:19):
Yeah, the fact that the data lineage tool becomes an
asset to the team to allow themto answer questions, because I
found that they had a variety ofdifferent questions.
You just don't know what mightcause the break in your test
cases and obviously you need toget through all the test cases
for you to feel comfortable thatyou're ready to go live.
This was the point that I wastrying to emphasize around the
(13:40):
value.
Also, john, one of the thingsthat I'm very excited about is
from a results perspective.
The business team presentstheir dashboard at the steering
committee and program reviewevery couple weeks.
They are not yet in the testingnear go live phase.
They showed that when they hadtheir breaks those times when
(14:05):
the test case did not get to thesame result between old system
and new system answer why thebreak existed is down to 0.4%.
Every time they ran into abreak, they have a tool and the
ability to answer why that breakis there.
Then business can make adetermination Do I want to do
(14:26):
something about that break?
Do I want to make sure that thenew system accounts for that
rule, because maybe it's aspecific treatment Whenever this
transaction shows up?
I need you to do this veryspecifically and software
company might not have thatquote unquote customized rule.
The business can now find it inZenges.
They can say yes, it must betrue.
Therefore, software company,please add this to your list of
(14:48):
things that you need to includebefore we go live, so the
ability to catch that upfront,as opposed to not knowing it,
waiting until you're in testingyour goal live or parallel run
and then discovering thesethings.
That's why you will encounteroverrun project, overrun cost,
overrun, delays, et cetera.
It's because you just couldn'tanswer it upfront.
(15:09):
What I like to emphasize hereis the value is you're
de-risking the program overall.
You're able to say I can answerit.
What I like to emphasize hereis the value is you're
de-risking the program overall.
You're able to say I can answerit, I know why it happened and
I can account for it and Ishould not encounter that break
during parallel.
Speaker 1 (15:25):
If they have the data upfront, they can make a
business evaluation or abusiness decision on the risk
right.
Is this risk worth paying moneyand time to fix or can we live
with this risk?
That's as opposed to finding itout on the back end when
something actually breaks.
That's the beauty of givingsomebody a platform or the
(15:46):
ability to shift thisdecision-making to the left.
Let the business unit say, okay, I can live with this or I
can't live with it.
Speaker 2 (15:54):
I need you software vendor to account for it.
This is where engineers aremost valuable, which is let's
build right.
Their time should be spent onthe build portion as opposed to
helping with the hey, write theright query so that someone can
tell you whether or not youwrote it right and whether or
not it looks the way thatsomeone wants it to look.
So, tying back to our firstconversation, when you do find
(16:17):
that break and say I need theproduct, the new system, to be
able to handle this, here it is,and now I know the business
rule.
Please make sure that you addthis to the product.
Speaker 1 (16:31):
Excellent.
One last question what's thefuture of the mainframe in the
enterprise and how do you guysfit into that future?
Speaker 2 (16:39):
I do think when I say de-risk, I think that we not
only de-risk a modernizationprogram, john, but we also
de-risk business operations,because I think, as I said from
the beginning, it's not that thetechnology doesn't work, it's
that the resources and theability to understand what was
there was becoming moredifficult and scarce.
So if you have a product and acapability to be able to back
(17:05):
into that, to get the knowledgeto understand it actually, then
if your technology is working,great.
It's really about educating anew workforce.
I think if organizations arelooking to keep mainframe and
they just want to make sure theycan have a workforce that can
manage that you have an abilityto understand, shine a light
(17:25):
into that black box of enginesand then use that to be a way to
teach new engineers.
The requirements are there.
That is de-risking businessoperations overall and still
saying mainframe has its placeand it's more what business
wants from a operationalmanagement of that type of
(17:46):
technology.
So that's one.
And then the second thing isthere's also businesses that
have made the decision to moveforward and again I don't think
it's about the technology, Ithink it's a hey.
Saas products means I don'tneed to worry about keeping the
code based grid and as there arenew capabilities out of that
software, I can adopt that.
So that's a benefit to a lot oforganizations looking to adopt
(18:07):
SaaS based solutions.
If you are modernizing well,then the future of how engines
can help there is.
We're just looking to make surethat we're continuously adding
more and more capabilities tosupport all the variations
inside mainframes, so the factthat there's mainframes and
mid-ranges and the differentcode bases from COBOL to RPG and
PL1 and assembler, etc.
So we just want to make surethat we can support
(18:30):
organizations and be really goodat saying we provide you the
ability to have a light in thatblack box.
I'd be the best at mainframedata lineage.
Speaker 1 (18:40):
Wow, this is great stuff.
Thanks for sharing all that.
I appreciate all your insightsand your experiences, and it's
fun talking about the good olddays of the mainframe as well.
But so my last question really,is there anything I haven't
asked you that you'd like toshare before we wrap the show up
?
Speaker 2 (18:57):
On the mainframe data lineage side, the most
important thing is to rememberthat enterprise data lineage is
a beast of an effort not justconnecting the mainframe but
trying to connect the mainframeto all the other applications
you have in-house.
It's hard and the question isfor what value and for what use
case?
Make sure you start really withunderstanding why you're asking
(19:17):
for day balanage and have thatuse case be small enough that
you can be successful.
The hardest area of enterprisedata lineage is the black boxes,
ie the legacy tech, and themost important thing that I
would say is to get started.
Organizations and teams can sit, imagine, design and talk about
it for a long time.
You'll learn and get more valuejust by doing.
(19:41):
You might make mistakes becauseyou didn't plan for all of it,
but you're at least alreadystarted, not waiting to discover
all of it through planning.
Speaker 1 (19:51):
Great advice, I agree , how to eat the elephant one
bite at a time.
How can people learn more?
Speaker 2 (20:00):
about you and your services?
What are your socials?
What's the best way?
Thank you.
John Zenzens' website iswwwzenzensai, with a Z in front
of the word engines plural.
And, by the way, we had AI wayfrom the very beginning, before
a lot of these other companies.
I'm on LinkedIn so folks canconnect with me or send me a
direct message and we haveinformation as to how to reach
(20:22):
out to our team, to get a demoand work with us, to go through
a POC or a trial, because I knowthat in this world, everyone
likes to see how it works and wewould be delighted to have
people give it a shot.
When it comes to dataconversions, it doesn't need to
take an army.
Everyone can do it themselves.
It's for the business user.
So if we start to change themindset and say, hey, this can
(20:45):
be self-service, that's what I'mhoping to move to, so that
everyone can change faster canbe self-service.
Speaker 1 (20:52):
That's what I'm hoping to move to, so that
everyone can change faster.
Excellent, this has been agreat interview, a great show.
You're so energetic, you're soknowledgeable.
It's just really a pleasure tohave you as a guest on the
Disruptor.
So, everybody listening, pleasedon't forget to connect with
Caitlin on LinkedIn, check outtheir website and Caitlin.
Before I wrap it up, I alwaysgive the guest the last word and
(21:13):
then we'll say goodbye.
Speaker 2 (21:16):
Thanks, John.
First I wanted to say thank you.
We had so much fun and yourlisteners should know just what
an interesting and knowledgeableperson you are.
I had so much fun learning fromyou in our conversations.
And then also just to say thatit's all about gratitude, right.
I appreciate the opportunity tospend time with you, that
you've made time and space forme and for Zenges, and that this
(21:40):
experience of building acompany and hopefully looking to
really deliver value to people.
I just believe data is solvable, and so let's help people focus
on other things when they wantto change and let's make the
data not something they have toworry about.
Speaker 1 (21:55):
All righty everybody.
Thanks, caitlin for being onour show.
I'm John Kuntz and thanks forjoining this edition of the
Disruptor Podcast.
Have a great day, guys.
Take care Thanks.
Disruption and Data Transforming, migration and
Modernizing Mainframes.
Hi everyone, I'm your host,john Kuntz, and welcome to
another edition of the DisruptorPodcast.
For those new to our show, westarted this series back in
December 2022 as a periodicsegment of the Apex Podcast.
Our vision was to go beyond theconventional wisdom by
(00:23):
confronting the status quo andexposing the raw power of
disruptive thinking.
Today, in part two of our show,we welcome back Caitlin Truong,
ceo of Zengens, as we explorehow her company disrupts
organizations, automates theend-to-end data conversions.
We will discuss valuable adviceon the pitfalls, the mistakes
(00:45):
that many executives make whenattempting digital
transformation.
Welcome back.
Speaker 2 (00:50):
Thank you so much, john.
Speaker 1 (00:51):
Before the break, we were discussing the broader
challenges of data migration.
In part two of the show, wewill focus on a particularly
complex area modernizing themainframe systems.
Caitlin, let's dive into theunique challenges and solutions
to bring to the table whentrying to do mainframe
modernization.
Many people believe themainframe was a thing of the
(01:13):
past.
Having spent 38 years at IBM, Iheard that, probably for 25 of
those years, but, as you know,they persist in many
organizations, especially largeenterprises.
Some of the largest banksaround the world, large
institutions, still heavily relyon the mainframe and there are
(01:35):
specific challenges andopportunities and I'd like you
to dive into what those might bein the context of mainframe
modernization in a digitaltransformation.
Speaker 2 (01:46):
Thanks, john.
I fully agree.
Of all my clients and customersfrom Vengeance and all my
consulting years, I know thatcustomers have always indicated
that mainframes are highlyperformant, highly reliable.
So I don't think that's themain driver of some of the
opportunities associated withmainframe modernization.
(02:07):
Really, I think it's aboutde-risking that legacy
technology right the fact thatit was written decades ago and
some of those SMEs aren'tavailable.
Whether it is because there arenewer code bases so you don't
have as many people who know thelanguages with which were
written in some of thosemainframes long ago.
(02:27):
Whether it's because what waswritten back then and again
remember some of these 60 yearsago just weren't as many
standards, so it's maybe moredifficult to maintain some of
those code and programs from wayback when.
It's really about de-riskingthe business, more so than it's
a problematic area.
I think the product andtechnology is fantastic.
(02:47):
It's just a need for businessto ensure they are resilient and
staying relevant Organizationsall of the ones that you're
talking about, across allindustries.
They're looking to exploremainframe modernization and
taking different flavors.
Some cases they are keeping thesame build functionality of
programs and just rewriting itin different languages, and in
(03:10):
other cases they aredecommissioning or sunsetting
those old systems and moving tovended cloud-based software
solutions.
Part of that, if they're movingto SaaS, is that they feel they
can benefit from constantlyreceiving software updates and
they can be absolved of nothaving to maintain the code and
programs themselves.
(03:31):
Those are key drivers and I'mseeing a lot of those in banks,
insurance companies, industrialcompanies, etc.
Speaker 1 (03:38):
It's amazing how much COBOL code is still out there.
The people that built thosesystems they're not around
anymore.
I was working in a bank inSouth Africa.
They had built a tier four datacenter.
They were trying to move theirmainframe-based core banking
system out of a tier three datacenter.
They spent a lot of money onthis really fancy new data
(03:59):
center but they couldn't findthe time to do the data
migration.
They couldn't take the systemsdown.
The amount of time it wouldtake to analyze the data was not
within their downtime window.
They made multiple attempts tomove but couldn't do it because
they were running the corebanking system.
I know this is a major problemand concern with any sort of
(04:23):
mainframe modernizationinitiative, whether you're
trying to move to a differentlocation or if you are trying to
refactor some of these oldCOBOL programs and applications
that were written 40 years ago.
So how do you specificallyaddress these complexities in
mainframe data migration andmodernization?
Speaker 2 (04:44):
I was looking at the stat, there are more lines of
COBOL code in existence than anyother programming language.
It is still true, there is avoluminous amount of COBOL code
still in existence.
So all of those things.
There's an interesting casestudy.
There was a bank looking tomodernize and move to a new core
(05:05):
and payments system and theywere converting off the
mainframe.
Unfortunately, this story is apainful one where they weren't
able to because the mainframewas a black box to them.
They tried to migrate some ofthe accounts over to this new
vended software.
When they tried to go live,they actually shut out customers
out of their bank accounts forover a week.
(05:26):
This was very bad.
They could not complete thisbecause it was so terrible they
had to shut down the program.
Now they are managing twodifferent systems.
The old mainframe core is stilllive and then a number of
accounts are still now on thenew system.
As you can imagine, thebusiness case was not realized
at all.
Some of those executivesunfortunately lost their jobs.
(05:49):
That's why I think it wassomething we ran into when we
were working with a customer.
We were brought in to help themwith a conversion While we were
there.
Oh, my goodness, this mainframeis a black to the business.
How will I convert if I don'tknow how to answer whether or
not that rule is right or wrong?
Zengens said, because of ourcore product and our ability to
ingest certain things andactivate metadata to be smart,
(06:13):
let us see if we can give this ashot.
So we did and evolved.
We created a second product, asecond capability.
It's our mainframe data lineageproduct.
This is specific to helpingteams get through that
modernization effort.
I'm not a refactoring tool, I'mnot a porting tool.
I ingest the schema, I ingestthe metadata, I ingest the code,
(06:36):
the full code base, includingthe JCLs.
I use all of that to get a datalineage information base.
But we are actually a researchtool.
We allow business analysts tounderstand business calculation
logic and the various conditionsthat caused it to use this calc
statement versus this calcstatement.
(06:57):
It empowers the business to beable to reverse, engineer what's
inside that black box intobusiness requirements for them
to execute a conversion.
The business analyst can havetheir sets of test cases that
they want to run through thesystems right, because they want
to turn the new system live.
It's a new vended product andin their test case they will run
(07:19):
a scenario where they run atransaction through the old
system and a transaction throughthe new system, old system
being the mainframe.
If the output is the same, allgood.
They will use out-of-the-boxbusiness rule from the software
of new product.
Unfortunately, they run into alot of breaks.
Where the values are old systemlegacy mainframe says the
(07:40):
output is negative five and newsystem says the output is five.
At this point in time, thebusiness says who is right?
Is it that we have a rule orsome variation or some specific
business rule that we need tomake sure we account for, or is
the software system wrong in howthey are computing this
calculation?
They need to understand whatwas in that black box to make a
(08:04):
decision.
Today that process looks likethe business writing a question
and sending it to the mainframeSMEs and then waiting for a
response.
As the mainframe SME canascertain, that mainframe SME is
navigating and reading throughCOBOL code, traversing module
after module, looking at go-tos,lookups and reference calls.
(08:24):
It takes some time to come back.
When the business gets thatanswer they say, okay, that's
helpful, but now you've spawnedthree more questions and so
that's a painful process for thebusiness to feel like they are
held hostage a bit to the factthat they can't get answers
themselves.
So this is what Zengens diddemocratizing that knowledge
base and making it available forbusiness to get answers so they
(08:46):
can successfully complete thatconversion.
Speaker 1 (08:49):
That's incredible.
I think we might have workedwith the same customer or know
the same customer.
I've heard that story a bunchof times myself the more I talk
with you.
I really wish you guys werearound back in 2015 when we were
trying to do all these work,but it's obviously the times
have changed and you'veleveraged your knowledge and
(09:12):
technologies to help with theseprojects, which I think is super
cool.
What are some of the criticalsuccess factors for
organizations undertakingmainframe modernization projects
?
What would you recommend to anexecutive that says I want to
move my core banking systems offthe mainframe and put them
under another cloud-based system?
Speaker 2 (09:30):
Yeah.
So I would say that it isimportant always upfront, make
sure that there is anunderstanding of what you're
converting.
Make sure there's anunderstanding of the right use
case, the right scope, amount,etc.
If it's going to touchsomething, you have to
understand the full lineage ofthe mainframe itself.
How do you understand all ofthe interdependencies or what
(09:53):
are the ramifications?
If you're only looking to decomone area, there's probably
threads to other modules andprograms.
First, to make sure there'sclarity and understand what's
important to realize from an ROIperspective.
Second, have a guiding strategyand design these mainframe
(10:13):
workhorses.
You have a lot of functionalityin them.
I've never seen it be a big bang.
My personal experience.
I've seen phased approaches.
When it is, it's a bit of well,I'm going to modernize this guy
, but that means I need to feeddata out of the new system back
to the old system to keep itcurrent, because some aspects
are still live on the mainframe.
(10:33):
Have the right plan design, beagile about it.
And then I say employ a tool.
You do need data lineage and Iwould say something that we
learned going through thisexperience with our customers is
that it's not lineage at facevalue that the business needs If
you're going to go through theconversion, you need the tool to
(10:54):
help you answer questions, andI think that's really what was
the sticking point, because itwas not just oh, I just need the
traversal pattern, theinterdependencies.
That wasn't the only thing thebusiness needed.
The business and engineeringteam, when they had to do the
research themselves, found thatthe first question you get isn't
always the only question or theanswer you needed.
(11:17):
Right, you start with aquestion that might cause you to
unpack other questions and thenyou might need to step back and
look at a visual to understandthe full map of the potential
impact area.
So, having a tool that allowsyou to answer questions
associated with going throughchanges, how can you be sure
that you are now able to answerwhat was built?
(11:38):
Why was it built, how was itbuilt, what were those rules, so
that you can be sure that youcan successfully decommission
portions of the program safely.
Start small, start withsomething that you know you can
convert and move.
Celebrate those successes,because it is possible and we're
seeing great results.
Something I would emphasize,john, is that the team attempted
(11:59):
to rewrite everything that wasin the mainframe.
There was just no way that theteam attempted to rewrite
everything that was in themainframe.
There was just no way that theorganization could finish that
job in our lifetime.
It's all of these modules, allthese reference to thousands and
thousands, tens of thousands ofother modules.
So then it was okay, we'll onlyresearch the things that break
those reconciliation issues.
And even that took two monthsfor one inquiry to come back
(12:22):
from the team, probably becausethey have to manage and run the
Mayfirm itself.
So what we saw was they wantedto make sure there was a way to
get answers quickly and reducethat dependency on me's.
It became something that allowsthem to understand or shed a
light into the black box.
Speaker 1 (12:44):
It makes a ton of sense to me the use case, the
use AI for the data lineageinvestigation or analysis.
So, as you said, it takesforever for a human to do it
because they have their day jobs, but it's a lot of work.
If you can leverage an AI largelanguage model to help you
(13:05):
figure out the lineage, youshrink the time needed to figure
that out, which allows you thetime to actually do the data
migration, data conversion ormainframe modernization
initiative.
Am I saying that correctly?
Speaker 2 (13:19):
Yeah, the fact that the data lineage tool becomes an
asset to the team to allow themto answer questions, because I
found that they had a variety ofdifferent questions.
You just don't know what mightcause the break in your test
cases and obviously you need toget through all the test cases
for you to feel comfortable thatyou're ready to go live.
This was the point that I wastrying to emphasize around the
(13:40):
value.
Also, john, one of the thingsthat I'm very excited about is
from a results perspective.
The business team presentstheir dashboard at the steering
committee and program reviewevery couple weeks.
They are not yet in the testingnear go live phase.
They showed that when they hadtheir breaks those times when
(14:05):
the test case did not get to thesame result between old system
and new system answer why thebreak existed is down to 0.4%.
Every time they ran into abreak, they have a tool and the
ability to answer why that breakis there.
Then business can make adetermination Do I want to do
(14:26):
something about that break?
Do I want to make sure that thenew system accounts for that
rule, because maybe it's aspecific treatment Whenever this
transaction shows up?
I need you to do this veryspecifically and software
company might not have thatquote unquote customized rule.
The business can now find it inZenges.
They can say yes, it must betrue.
Therefore, software company,please add this to your list of
(14:48):
things that you need to includebefore we go live, so the
ability to catch that upfront,as opposed to not knowing it,
waiting until you're in testingyour goal live or parallel run
and then discovering thesethings.
That's why you will encounteroverrun project, overrun cost,
overrun, delays, et cetera.
It's because you just couldn'tanswer it upfront.
(15:09):
What I like to emphasize hereis the value is you're
de-risking the program overall.
You're able to say I can answerit.
What I like to emphasize hereis the value is you're
de-risking the program overall.
You're able to say I can answerit, I know why it happened and
I can account for it and Ishould not encounter that break
during parallel.
Speaker 1 (15:25):
If they have the data upfront, they can make a
business evaluation or abusiness decision on the risk
right.
Is this risk worth paying moneyand time to fix or can we live
with this risk?
That's as opposed to finding itout on the back end when
something actually breaks.
That's the beauty of givingsomebody a platform or the
(15:46):
ability to shift thisdecision-making to the left.
Let the business unit say, okay, I can live with this or I
can't live with it.
Speaker 2 (15:54):
I need you software vendor to account for it.
This is where engineers aremost valuable, which is let's
build right.
Their time should be spent onthe build portion as opposed to
helping with the hey, write theright query so that someone can
tell you whether or not youwrote it right and whether or
not it looks the way thatsomeone wants it to look.
So, tying back to our firstconversation, when you do find
(16:17):
that break and say I need theproduct, the new system, to be
able to handle this, here it is,and now I know the business
rule.
Please make sure that you addthis to the product.
Speaker 1 (16:31):
Excellent.
One last question what's thefuture of the mainframe in the
enterprise and how do you guysfit into that future?
Speaker 2 (16:39):
I do think when I say de-risk, I think that we not
only de-risk a modernizationprogram, john, but we also
de-risk business operations,because I think, as I said from
the beginning, it's not that thetechnology doesn't work, it's
that the resources and theability to understand what was
there was becoming moredifficult and scarce.
So if you have a product and acapability to be able to back
(17:05):
into that, to get the knowledgeto understand it actually, then
if your technology is working,great.
It's really about educating anew workforce.
I think if organizations arelooking to keep mainframe and
they just want to make sure theycan have a workforce that can
manage that you have an abilityto understand, shine a light
(17:25):
into that black box of enginesand then use that to be a way to
teach new engineers.
The requirements are there.
That is de-risking businessoperations overall and still
saying mainframe has its placeand it's more what business
wants from a operationalmanagement of that type of
(17:46):
technology.
So that's one.
And then the second thing isthere's also businesses that
have made the decision to moveforward and again I don't think
it's about the technology, Ithink it's a hey.
Saas products means I don'tneed to worry about keeping the
code based grid and as there arenew capabilities out of that
software, I can adopt that.
So that's a benefit to a lot oforganizations looking to adopt
(18:07):
SaaS based solutions.
If you are modernizing well,then the future of how engines
can help there is.
We're just looking to make surethat we're continuously adding
more and more capabilities tosupport all the variations
inside mainframes, so the factthat there's mainframes and
mid-ranges and the differentcode bases from COBOL to RPG and
PL1 and assembler, etc.
So we just want to make surethat we can support
(18:30):
organizations and be really goodat saying we provide you the
ability to have a light in thatblack box.
I'd be the best at mainframedata lineage.
Speaker 1 (18:40):
Wow, this is great stuff.
Thanks for sharing all that.
I appreciate all your insightsand your experiences, and it's
fun talking about the good olddays of the mainframe as well.
But so my last question really,is there anything I haven't
asked you that you'd like toshare before we wrap the show up
?
Speaker 2 (18:57):
On the mainframe data lineage side, the most
important thing is to rememberthat enterprise data lineage is
a beast of an effort not justconnecting the mainframe but
trying to connect the mainframeto all the other applications
you have in-house.
It's hard and the question isfor what value and for what use
case?
Make sure you start really withunderstanding why you're asking
(19:17):
for day balanage and have thatuse case be small enough that
you can be successful.
The hardest area of enterprisedata lineage is the black boxes,
ie the legacy tech, and themost important thing that I
would say is to get started.
Organizations and teams can sit, imagine, design and talk about
it for a long time.
You'll learn and get more valuejust by doing.
(19:41):
You might make mistakes becauseyou didn't plan for all of it,
but you're at least alreadystarted, not waiting to discover
all of it through planning.
Speaker 1 (19:51):
Great advice, I agree , how to eat the elephant one
bite at a time.
How can people learn more?
Speaker 2 (20:00):
about you and your services?
What are your socials?
What's the best way?
Thank you.
John Zenzens' website iswwwzenzensai, with a Z in front
of the word engines plural.
And, by the way, we had AI wayfrom the very beginning, before
a lot of these other companies.
I'm on LinkedIn so folks canconnect with me or send me a
direct message and we haveinformation as to how to reach
(20:22):
out to our team, to get a demoand work with us, to go through
a POC or a trial, because I knowthat in this world, everyone
likes to see how it works and wewould be delighted to have
people give it a shot.
When it comes to dataconversions, it doesn't need to
take an army.
Everyone can do it themselves.
It's for the business user.
So if we start to change themindset and say, hey, this can
(20:45):
be self-service, that's what I'mhoping to move to, so that
everyone can change faster canbe self-service.
Speaker 1 (20:52):
That's what I'm hoping to move to, so that
everyone can change faster.
Excellent, this has been agreat interview, a great show.
You're so energetic, you're soknowledgeable.
It's just really a pleasure tohave you as a guest on the
Disruptor.
So, everybody listening, pleasedon't forget to connect with
Caitlin on LinkedIn, check outtheir website and Caitlin.
Before I wrap it up, I alwaysgive the guest the last word and
(21:13):
then we'll say goodbye.
Speaker 2 (21:16):
Thanks, John.
First I wanted to say thank you.
We had so much fun and yourlisteners should know just what
an interesting and knowledgeableperson you are.
I had so much fun learning fromyou in our conversations.
And then also just to say thatit's all about gratitude, right.
I appreciate the opportunity tospend time with you, that
you've made time and space forme and for Zenges, and that this
(21:40):
experience of building acompany and hopefully looking to
really deliver value to people.
I just believe data is solvable, and so let's help people focus
on other things when they wantto change and let's make the
data not something they have toworry about.
Speaker 1 (21:55):
All righty everybody.
Thanks, caitlin for being onour show.
I'm John Kuntz and thanks forjoining this edition of the
Disruptor Podcast.
Have a great day, guys.
Take care Thanks.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Boysober
Have you ever wondered what life might be like if you stopped worrying about being wanted, and focused on understanding what you actually want? That was the question Hope Woodard asked herself after a string of situationships inspired her to take a break from sex and dating. She went "boysober," a personal concept that sparked a global movement among women looking to prioritize themselves over men. Now, Hope is looking to expand the ways we explore our relationship to relationships. Taking a bold, unfiltered look into modern love, romance, and self-discovery, Boysober will dive into messy stories about dating, sex, love, friendship, and breaking generational patterns—all with humor, vulnerability, and a fresh perspective.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com