1
00:00:00,000 --> 00:00:05,620
Welcome to the first Cloud and Culture episode of 2021. I am Derek Harris from VMware.

2
00:00:06,520 --> 00:00:12,100
And I am Danielle Burrow from VMware. If you're new, this podcast focuses on the process of

3
00:00:12,100 --> 00:00:18,160
application and IT modernization through the lens of Tanzu Labs, previously called Pivotal Labs.

4
00:00:18,740 --> 00:00:23,200
Over the years, Tanzu Labs experts have helped hundreds of companies and organizations,

5
00:00:23,620 --> 00:00:27,920
big and small, build better software and adopt modern development practices.

6
00:00:28,200 --> 00:00:33,800
This tradition carries on today as Tanzu Labs experts help clients get up to speed with cloud

7
00:00:33,800 --> 00:00:40,160
native computing and the flexibility and resiliency it provides. And on that note, our guest for this

8
00:00:40,160 --> 00:00:45,580
episode is Felicia Schwartz, who walks us through the process of analyzing application portfolios

9
00:00:45,580 --> 00:00:50,520
and building a plan for how to get started with modernization, whether that's a full refactor or

10
00:00:50,520 --> 00:00:56,180
simply lifting and shifting onto a modern platform like Kubernetes. As she explains, organizations get

11
00:00:56,180 --> 00:01:01,740
hung up on trying to boil the ocean or focusing on applications that don't align with the business

12
00:01:01,740 --> 00:01:07,140
objectives, driving their modernization efforts. So having a good, actionable plan is critical.

13
00:01:07,980 --> 00:01:13,420
Absolutely. So stick around and listen to Felicia dive deeper into portfolio analysis now.

14
00:01:14,280 --> 00:01:19,980
So Felicia, thank you so much for joining us today. Let's just dive right into just a quick

15
00:01:19,980 --> 00:01:24,420
introduction of who you are and what you do here at Tanzu Labs.

16
00:01:24,940 --> 00:01:31,460
Sure. Thank you, Danielle. My name is Felicia Schwartz. I am a solution lead as part of Tanzu Labs.

17
00:01:31,980 --> 00:01:39,120
I have been working on helping enterprises, large and small, modernize their portfolio of applications

18
00:01:39,120 --> 00:01:45,560
so they can take advantage of the capabilities, primarily cloud capabilities that are out there

19
00:01:45,560 --> 00:01:51,540
today so that they can continue to grow their business. I've been working as an application

20
00:01:51,540 --> 00:01:58,360
portfolio director for many years in the Wall Street, most of the time on a major Wall Street

21
00:01:58,360 --> 00:02:05,120
firm, leading teams of architects and engineers, building applications, supporting them, updating them.

22
00:02:05,120 --> 00:02:08,220
And now I'm helping multiple clients in that journey.

23
00:02:09,780 --> 00:02:16,340
Awesome. And I bet, you know, you've, it sounds like you've worked both, you know, internally at a

24
00:02:16,340 --> 00:02:21,240
company and then you've worked as, you know, a consultant as a part of Tanzu Labs, helping other

25
00:02:21,240 --> 00:02:29,400
companies do this. And I'm wondering, you know, from your perspective, when an organization is setting

26
00:02:29,400 --> 00:02:36,340
out to do like a large app modernization initiative, like what, what makes it so hard to get started?

27
00:02:36,460 --> 00:02:41,240
Like, what are some of those stumbling blocks that you and, you know, that, that companies often

28
00:02:41,240 --> 00:02:41,840
encounter?

29
00:02:43,840 --> 00:02:50,020
Most of the time, customers are very interested in the outcomes that they hear about. We talk about

30
00:02:50,020 --> 00:02:55,480
the value benefit of the cloud, but a lot of them don't know how to get started. And they spend a lot

31
00:02:55,480 --> 00:03:04,320
of time overanalyzing what to do, how much they should do. And they, they boil the ocean. Some of

32
00:03:04,320 --> 00:03:10,340
the skills on their team are not the future set skills because they're supporting production

33
00:03:10,340 --> 00:03:16,440
applications. So the technologies that are in place today are not where they want to go. So they do a

34
00:03:16,440 --> 00:03:23,540
lot of planning upfront to the point where it's some analysis paralysis. So we help get, we help

35
00:03:23,540 --> 00:03:29,640
customers get started to say, do as much as you need to do, plan what you need to plan, and then start

36
00:03:29,640 --> 00:03:36,400
executing, learning from what's going well, learning from what might not be going so well, and get

37
00:03:36,400 --> 00:03:43,280
started. That that's the hugest stumbling block to get a stumbling block to get started on this journey.

38
00:03:43,280 --> 00:03:48,280
All right. And one of the things I understand that that's important is to actually help

39
00:03:48,280 --> 00:03:53,620
organizations walk through, like, what are their, like all, like kind of do an analysis of their

40
00:03:53,620 --> 00:03:59,620
application portfolio and figure out, you know, what's the most important applications to modernize or,

41
00:03:59,620 --> 00:04:06,480
or otherwise, or otherwise, you know, rank or, or, or, or figure out a plan, I guess, for going forward. I mean,

42
00:04:06,480 --> 00:04:09,620
you talk through kind of how, how that works, how to walk through, we used to like,

43
00:04:10,120 --> 00:04:13,420
obviously analysis paralysis, right? If you have, you know, a thousand applications,

44
00:04:14,120 --> 00:04:17,620
you might want to modernize all of them eventually, like, how does that process get started?

45
00:04:18,100 --> 00:04:23,260
Absolutely. And we've really been helping customers with this, because we found that they would spend

46
00:04:23,260 --> 00:04:29,400
a year to try to do that analysis. And as we all experience in COVID, things can change in a year.

47
00:04:29,620 --> 00:04:34,960
And if you spend all that time upfront, you know, doing planning, that the world changes and all

48
00:04:34,960 --> 00:04:41,240
your planning is for not. So we do help them to say, let's understand where your business is today.

49
00:04:41,460 --> 00:04:46,400
Let's build, let's help you build a model to be flexible so that as things change,

50
00:04:46,400 --> 00:04:50,400
you could see the direction you need to go. So we are helping with, we want to help with

51
00:04:50,400 --> 00:04:55,200
create a roadmap that gives you the outcomes you want and a place to get started.

52
00:04:55,620 --> 00:04:59,740
So we've been doing a portfolio analysis, which a lot of companies have done something,

53
00:04:59,840 --> 00:05:04,460
but we've taken a different angle to it is time is of the essence. A lot of the companies,

54
00:05:04,460 --> 00:05:10,000
if you have existing applications, you're competing with startups. If you wait too long,

55
00:05:10,000 --> 00:05:15,980
the startups don't have that existing legacy portfolio and tech debt out there,

56
00:05:16,320 --> 00:05:20,940
they're going to get ahead of customers. So we need to act fast. So we'll, we'll work with clients

57
00:05:20,940 --> 00:05:25,940
to really analyze what's the most important to think to your organization. Every company has like

58
00:05:25,940 --> 00:05:33,100
their, their top goals for the year or for a five-year plan. Let's clarify them. And some of them could

59
00:05:33,100 --> 00:05:37,880
be, I need to shut down a data center. That's part of their goals. Some of it could be, I need to start

60
00:05:37,880 --> 00:05:42,920
a new business. We work with a lot of customers that are trying to attract new clienteles, especially

61
00:05:42,920 --> 00:05:49,740
in the finance world. How do I get the millennial generation to want my products? So there's all

62
00:05:49,740 --> 00:05:56,400
these different directions that companies want to go to technical, non-technical. We help customers

63
00:05:56,400 --> 00:06:01,460
go in there and say, let's pick number one or number one and number two, let's stack rank these.

64
00:06:02,140 --> 00:06:07,260
And then we can look at your applications to say, which are tied to these? And we don't have to go

65
00:06:07,260 --> 00:06:13,140
through every single one of them, but let's work with a group of people that are interested in moving

66
00:06:13,140 --> 00:06:18,600
to the cloud or improving them, making their applications more resilient. Let's find ones

67
00:06:18,600 --> 00:06:23,900
tied to strategic business initiatives. And then we're going to help you assess the difficulty of

68
00:06:23,900 --> 00:06:29,300
getting the results you need for these applications. It could go in many directions based upon these

69
00:06:29,300 --> 00:06:35,820
goals, but that's how we can help narrow down the focus to say, let's do this thing. Let's get

70
00:06:35,820 --> 00:06:39,680
started. And then let's take the learnings to the next most important thing to you.

71
00:06:40,240 --> 00:06:45,960
Yeah, that makes sense. And, and it sounds like the process must be somewhat dependent on what the

72
00:06:45,960 --> 00:06:52,640
client is trying to do. Like I imagine if, you know, maybe they have a really large portfolio of apps

73
00:06:52,640 --> 00:06:56,720
that they want to just move right away because they have to get out of their data center. Like maybe

74
00:06:56,720 --> 00:07:01,700
there's a somewhat different approach or, or is it a similar approach regardless?

75
00:07:02,220 --> 00:07:08,940
We take a similar approach in terms of how we start gathering information, how we, the solutions of

76
00:07:08,940 --> 00:07:14,260
what to do will be changed based upon it. For instance, in the example you gave, we've worked with

77
00:07:14,260 --> 00:07:19,420
clients who had both. Let's shut down a data center and a data center is applications. It's also data.

78
00:07:19,500 --> 00:07:26,140
There's a lot to that. We've also had customers who had 10,000 applications that they wanted to move to

79
00:07:26,140 --> 00:07:32,520
the cloud. The goals, there's a lot of commonality in terms of what we were going to do, but the

80
00:07:32,520 --> 00:07:39,120
prioritization is very different. I would target the data center that's shutting down. We have a date,

81
00:07:39,400 --> 00:07:44,680
we're restricted by a date. If that date is the top priority for them, I may not get to the final

82
00:07:44,680 --> 00:07:50,140
solution for an application, which may mean like we need to re-architect this application because some of

83
00:07:50,140 --> 00:07:56,700
the business problems are so complex, you can't just move it to the cloud and get results you want. But if

84
00:07:56,700 --> 00:08:03,100
they're date driven, we may say, step one is just let's move it. It may not improve the performance you

85
00:08:03,100 --> 00:08:09,180
want from this application, but if your goal is to get out of a data center, that's the solution for you.

86
00:08:10,860 --> 00:08:15,500
One of the things I wanted to ask was what modernization typically means to an organization,

87
00:08:15,500 --> 00:08:18,960
if it means refactoring or just switching platforms, or in some cases, it sounds like

88
00:08:18,960 --> 00:08:24,580
it's just, initially, it might just be as simple as moving to the cloud. So can you walk through like

89
00:08:24,580 --> 00:08:29,540
what, but yeah, so it sounds like modernization takes on a different meaning depending on what your

90
00:08:29,540 --> 00:08:30,560
business goal is.

91
00:08:30,980 --> 00:08:35,820
Absolutely. Modernization can mean exactly what you're saying. I'm modernizing the platform it

92
00:08:35,820 --> 00:08:39,640
runs on. So when you look at the world of Kubernetes and containers,

93
00:08:39,640 --> 00:08:45,100
I could be taking an application and I could be containerizing it, moving it through a pipeline,

94
00:08:45,100 --> 00:08:50,900
and that's modernization. I'm not changing any of the code in my application. I'm just making it so

95
00:08:50,900 --> 00:08:57,160
that I have one code base, and I've got resiliency so that I could scale up as needed. That is part of

96
00:08:57,160 --> 00:09:03,300
modernization. Some of it could be the application and the way the logic in the application is flawed,

97
00:09:03,300 --> 00:09:09,620
and it's very slow. It may take 10 minutes for my application to start up. So I really need to get

98
00:09:09,640 --> 00:09:15,040
into the way I've designed my application so that should it go down, when it comes back up,

99
00:09:15,100 --> 00:09:20,900
it comes up faster and it's not 10 minutes. So my end user experience is very positive,

100
00:09:20,900 --> 00:09:27,740
where a container may not improve that. So modernization is a generic term that based upon

101
00:09:27,740 --> 00:09:33,220
the outcomes you're looking to drive, will dictate what it means to you. And it's usually a combination

102
00:09:33,220 --> 00:09:37,700
of things. For any organization, there are some applications you're going to say,

103
00:09:37,880 --> 00:09:43,100
I just need to move these to the cloud. Some applications saying, I really do need to re-architect

104
00:09:43,100 --> 00:09:49,540
them. And it really is driven ultimately by the business needs for that application because IT is

105
00:09:49,540 --> 00:09:54,560
there to support business. So the decisions and the outcomes is part of when we do a portfolio

106
00:09:54,560 --> 00:09:58,840
assessment. It really is going to drive is the end of the day, if you're successful,

107
00:09:58,940 --> 00:10:00,180
what does success look like for you?

108
00:10:00,600 --> 00:10:07,060
So I would imagine that, you know, I mean, prioritizing your applications and what you're

109
00:10:07,060 --> 00:10:10,640
going to modernize and how you modernize it, it sounds like, I mean, it's really complicated

110
00:10:10,640 --> 00:10:17,000
because there's so much, you know, related to the business that you need to know and how that

111
00:10:17,000 --> 00:10:23,500
directly ties to these applications. I guess, like, is that one of the reasons why it's so hard for

112
00:10:23,500 --> 00:10:29,320
organizations to prioritize how they're doing this work? Or what are some of the reasons for,

113
00:10:29,560 --> 00:10:33,340
you know, just they're kind of getting stuck with this?

114
00:10:34,100 --> 00:10:39,580
So one is people making this a priority. People in organizations are busy. This is an added

115
00:10:39,580 --> 00:10:44,600
additional thing for everybody to work on. Making that decision is hard. And if you want to stack

116
00:10:44,600 --> 00:10:49,400
rank everything, that's a very hard thing because people will think many things are important.

117
00:10:49,960 --> 00:10:55,680
So challenges coming up with that decision. And we do that upfront. Like we want to get aligned. Let's

118
00:10:55,680 --> 00:11:00,620
have those conversations. If you're working with multiple business owners that everybody thinks

119
00:11:00,620 --> 00:11:08,380
this is most important, let's drive those and let's get aligned. That's where people get stuck off in

120
00:11:08,380 --> 00:11:12,960
the time. What's the most important thing to do. And then understanding that the difference between

121
00:11:12,960 --> 00:11:18,480
how long is it going to take to get to the final outcome? And do you have that time? And do you have

122
00:11:18,480 --> 00:11:24,040
the people with the skill sets to make the changes? So for instance, if you decide this application

123
00:11:24,040 --> 00:11:31,680
is very brittle, it's very hard to change. The technology is so dated. We don't have a lot of people who know

124
00:11:31,680 --> 00:11:39,860
it. The real goal is to really re-architect this in a way that's simpler to maintain. That may be a great

125
00:11:39,860 --> 00:11:47,640
outcome, but that takes a long time. So making sure everybody understands the outcome you need today,

126
00:11:48,360 --> 00:11:55,540
maybe step one in a longer journey and accepting that like this is a journey. It's not something that

127
00:11:55,540 --> 00:12:02,280
starts and ends. It'll continuously evolve. So getting everybody in the mindset of let's get started.

128
00:12:02,920 --> 00:12:08,900
Let's dedicate some people to work on this. We don't have to know every application that's out

129
00:12:08,900 --> 00:12:15,160
there before we get started. We have to get started and share the learnings. It's an agile way of doing

130
00:12:15,160 --> 00:12:22,440
the assessment that people have to be bought into and be willing to try. Yeah, I was going to say,

131
00:12:22,500 --> 00:12:28,220
it sounds like just getting that momentum seems like a critical thing with anything. What's the

132
00:12:28,220 --> 00:12:33,500
result we can get to and just build off of? Yes, rather than boil the ocean and try to undertake

133
00:12:33,500 --> 00:12:39,720
something that you haven't been undertaking, right? For years or decades, but now today we'll just flip

134
00:12:39,720 --> 00:12:46,100
a switch and it's going to start. We oftentimes get clients who will say like, we need to assess those

135
00:12:46,100 --> 00:12:51,980
10,000 applications that we know we have to go to the cloud before we do anything on them. And we try to

136
00:12:51,980 --> 00:12:56,740
change that around is why? Why do you have to look at all of them? Let's take some that you know. And

137
00:12:56,740 --> 00:13:01,700
I haven't found a customer that doesn't know what some of those critical applications that are very

138
00:13:01,700 --> 00:13:07,160
painful to them that go down all the time or whatever their criteria is. They all have something that

139
00:13:07,160 --> 00:13:11,740
keeps them up at night, that they get the calls at 3 a.m. They know they've got to think about those

140
00:13:11,740 --> 00:13:16,500
first. Let's start with that, right? That's going to give you great results. You'll learn so much

141
00:13:16,500 --> 00:13:21,120
about the possibilities and the options out there. And then you could take those and apply it to the

142
00:13:21,120 --> 00:13:29,720
9,995 others. Yeah. So what are, what about the process of actually doing the modernization work

143
00:13:29,720 --> 00:13:35,680
after this portfolio assessment? I mean, is there, is there kind of a common approach to this?

144
00:13:36,060 --> 00:13:42,900
Yeah. Yeah. Okay. So, so yeah, great question. We like to do a quick analysis to get started,

145
00:13:42,900 --> 00:13:48,900
but then we want to execute on it. We usually will come up with applications to say, you know,

146
00:13:48,900 --> 00:13:52,900
we follow the five hours, which is like some of applications, you know what, you're ready to

147
00:13:52,900 --> 00:13:57,500
retire them. Let's not touch them at all. It's not worth the investment to move on them. Others will

148
00:13:57,500 --> 00:14:03,320
say, you know what, this application is pretty stable. It doesn't change that often. We just need to be

149
00:14:03,320 --> 00:14:07,420
able to scale up at peak times in the retail industry. Black Friday was always a time where

150
00:14:07,420 --> 00:14:14,160
you'd see a lot more volume. So we may containerize that and we'll, we'll start with one. We'll put

151
00:14:14,160 --> 00:14:19,080
together a way of doing it. What we like to do is create something that the rest of the organization

152
00:14:19,080 --> 00:14:24,820
can learn from. So we'll work with customers side-by-side to say, here's how we containerize

153
00:14:24,820 --> 00:14:28,980
that. Here's the pipeline we're putting into play. And we'll show them using the technology and the

154
00:14:28,980 --> 00:14:34,600
tools that are out there, how to do that. We solidify that with what we call a cookbook,

155
00:14:34,760 --> 00:14:38,820
which is something that the customer holds onto and they share it within their organization.

156
00:14:38,940 --> 00:14:44,780
So that becomes a repeatable pattern, whether it's containerization of an application, or if you have

157
00:14:44,780 --> 00:14:49,840
to actually go into the application and change code to make it, to improve the performance of the

158
00:14:49,840 --> 00:14:56,440
application of itself, we do the same thing. We'll make the changes. We'll, we'll create a recipe on all of

159
00:14:56,440 --> 00:15:01,160
the changes, what we did with their code, and then we'll share it with the rest of the organization.

160
00:15:01,420 --> 00:15:06,940
So you expedite those changes because oftentimes what we find is the problems you find in one

161
00:15:06,940 --> 00:15:12,660
application tend to be in multiple applications. So if you have to find a way to solve it, you know,

162
00:15:12,700 --> 00:15:17,940
in application A, there's probably like hundreds of applications that will have that same solution.

163
00:15:18,000 --> 00:15:23,500
And it's much faster to implement the solution over and over again than it is to create the solution

164
00:15:23,500 --> 00:15:30,380
the first time. So you mentioned a few components of, of the application, right? Like the code itself,

165
00:15:30,720 --> 00:15:33,880
their business logic, and then there's the, the architecture, there's the platform,

166
00:15:33,960 --> 00:15:38,680
there's probably the development process. Do you, what, is there a, I mean, is something more common

167
00:15:38,680 --> 00:15:43,920
or do you see, is there like, I'm curious what the interplay is between all the different elements

168
00:15:43,920 --> 00:15:48,020
of actually running an application that come into play? Cause I'm guessing, yes, it's not just like

169
00:15:48,020 --> 00:15:52,580
you're rewriting the business logic every time, excuse me, or you're, or you're deploying it to

170
00:15:52,580 --> 00:15:56,200
Kubernetes every time, right? It's like, there must be some sort of a balance.

171
00:15:57,480 --> 00:16:01,860
It really depends upon the outcomes you're looking to get. So oftentimes when we're looking at doing a

172
00:16:01,860 --> 00:16:06,380
portfolio analysis, we're looking at existing applications. We're going to look at what's

173
00:16:06,380 --> 00:16:10,600
the future of that application and what are the challenges in the application? If it's very

174
00:16:10,600 --> 00:16:17,300
business critical and it's going to be changing, we'll tend to go down a path to make sure it's easy

175
00:16:17,300 --> 00:16:21,240
to change. So that's where we'll tend to go down a path to say, you know what, it makes sense to

176
00:16:21,240 --> 00:16:29,380
modernize this. You use like 12 factor applications to make this cloud native because you need that.

177
00:16:29,380 --> 00:16:35,240
And we'll drive those. We do come up with like a guidelines and a decision matrix for customers to

178
00:16:35,240 --> 00:16:41,220
say, if this is business critical, if the application is going to change, here's the road

179
00:16:41,220 --> 00:16:47,240
to go down. So it's easy for them to continue on this journey on their own and looking at more and

180
00:16:47,240 --> 00:16:53,320
more applications. So there is consistency. We work with them. We work with a customer often enough to

181
00:16:53,320 --> 00:16:58,520
make sure they are the ones driving what's the solution they need. So there are some basic,

182
00:16:58,520 --> 00:17:04,200
like let's, you know, rehost these. These applications make sense to rehost. These are

183
00:17:04,200 --> 00:17:09,600
applications that totally need to be re-architected. They're so big, they're so clumsy. And here's ones

184
00:17:09,600 --> 00:17:15,080
that need some modernization in terms of like tweaking to the business logic or tweaking to the

185
00:17:15,080 --> 00:17:20,080
performance issues in the application, but they don't need to be totally redone. There's just

186
00:17:20,080 --> 00:17:25,940
performance issues on there. So there's a couple of main paths we go down, you know, just rehosting

187
00:17:25,940 --> 00:17:32,100
them, moving them to a Kubernetes container, making tweaks to the existing application all the way to

188
00:17:32,100 --> 00:17:36,660
the more extreme of re-architecting or totally rebuilding if the business logic has changed that

189
00:17:36,660 --> 00:17:42,420
drastically. Yeah, that makes sense. And it sounds like, you know, there's probably different levels

190
00:17:42,420 --> 00:17:50,020
of like, you know, app development expertise at these different organizations within these different

191
00:17:50,020 --> 00:17:53,860
organizations and what they're able to kind of take on or maybe what they want to take on.

192
00:17:53,860 --> 00:17:59,700
Yes. So we look at things from three different lenses. When we go down this modernization path

193
00:17:59,700 --> 00:18:04,980
with customers is, what are your goals? Where are you trying to go? And I think it's the topics we

194
00:18:04,980 --> 00:18:10,100
were talking about a lot so far is, where are you going to? What's your five-year plan? What's their

195
00:18:10,100 --> 00:18:15,380
one-year plan? We marry that with, let's look at the technology that's in place in your applications.

196
00:18:15,380 --> 00:18:21,700
Are we talking about like a COBOL DB2 application that probably needs to be written? Or are we looking at

197
00:18:21,700 --> 00:18:28,980
something that's a few years old? How complex is it? How many proprietary licenses are in there is a goal

198
00:18:28,980 --> 00:18:34,260
to get rid of the proprietary. So we'll look at the goals in the business landscape. We'll look at the

199
00:18:34,260 --> 00:18:41,860
technology landscape. And we've created many tools. We've created as well as collated through the open

200
00:18:41,860 --> 00:18:48,340
source environment to kind of do an assessment of like, let's dig into these tools. We look at security.

201
00:18:48,340 --> 00:18:53,700
Like, so how complicated is it going to do to do any of these things on it? And then the third lens we

202
00:18:53,700 --> 00:18:58,740
look at is, let's look at your organization. Do you have the skills in-house? Do you have enough people

203
00:18:58,740 --> 00:19:03,300
available to work on these things? So we need to bring that in. And that also helps with the

204
00:19:03,300 --> 00:19:08,980
prioritization because you may say this one thing is really important, but you may have nobody available

205
00:19:08,980 --> 00:19:14,260
to work on it. So it may take a little longer to get started on something like that. So the

206
00:19:14,260 --> 00:19:21,780
organizational capabilities and desire and bandwidth is that third element that we have to look at to get

207
00:19:21,780 --> 00:19:27,540
started. And when you say bring people out, I mean, is that a hiring situation? Is that a consulting

208
00:19:27,540 --> 00:19:33,300
situation? Is that a, maybe we need to retrain or otherwise educate people internally?

209
00:19:33,300 --> 00:19:39,540
I think it's a combination of things. When you, when you get started, the best thing we can have

210
00:19:39,540 --> 00:19:44,260
working is people who understand your applications. It's very hard to go in on a modernization if you

211
00:19:44,260 --> 00:19:50,180
don't know what's in the application. So yes, having people that know it, having people that have the

212
00:19:50,180 --> 00:19:55,620
technology. If we talk about some of like the real old stuff, like the mainframe applications,

213
00:19:56,260 --> 00:20:00,980
they may not have anybody who really understands how this code works or, or understand to be able

214
00:20:00,980 --> 00:20:06,020
to go through an application to understand it. So that's gonna, that's gonna direct one of the

215
00:20:06,020 --> 00:20:12,180
challenges when you get to a scaling model. So we talked about a data center migration or, you know,

216
00:20:12,180 --> 00:20:17,780
moving 10,000 applications to the cloud. Oftentimes that's bringing in partners. So you need to bring

217
00:20:17,780 --> 00:20:23,220
the partners in and you may need to upskill some of the people on your team at the same time

218
00:20:23,860 --> 00:20:28,740
while you're bringing partners in. So maybe your team will, will be the subject matter experts,

219
00:20:28,740 --> 00:20:34,660
but you need more people than you have available or that you have on staff to do these changes.

220
00:20:34,660 --> 00:20:40,100
So it's a combination of let's, let's find the picture that works best for you based upon who

221
00:20:40,100 --> 00:20:45,940
your employees are, what are the challenges and projects they may be working on, as well as,

222
00:20:45,940 --> 00:20:48,580
do you have partners in place that could work with you on this as well?

223
00:20:48,580 --> 00:20:55,860
And this might be a little tangential, but like how have the tools or the platforms available today

224
00:20:56,500 --> 00:21:00,980
improved on this over, over years past? I just think even just from the infrastructure perspective,

225
00:21:00,980 --> 00:21:06,260
as we went from VMs to cloud to, to containers and Kubernetes, like, theoretically, it should be

226
00:21:06,260 --> 00:21:10,660
getting easier to make these moves or re-architect, right? I would think, but to some degree,

227
00:21:10,660 --> 00:21:15,620
it also adds complexity, right? Because each new thing is, in some ways, more complex. I'm just

228
00:21:15,620 --> 00:21:17,060
curious how that, how that plays out.

229
00:21:17,060 --> 00:21:22,980
There's always new tools. Every day, new tools come out and the goals of the tools are to make

230
00:21:22,980 --> 00:21:28,740
things easier. We've created tools to do deep dive introspection into VMs to see what's on a VM for a

231
00:21:28,740 --> 00:21:33,780
data center move. There's tools that look into applications to see what are all the integration

232
00:21:33,780 --> 00:21:38,740
points in the applications that it needs to talk to so that we, if we move to the cloud, an application

233
00:21:38,740 --> 00:21:43,060
to the cloud, we don't have performance issues that, you know, we're talking to something in a data

234
00:21:43,060 --> 00:21:49,140
center. So the tools are continuously improving to give you visibility and to make as many of the changes.

235
00:21:49,140 --> 00:21:54,340
Oftentimes, when you start getting into applications, there are tools out there that do it. But what

236
00:21:54,340 --> 00:21:58,580
we found is you still need people involved to kind of help make those right decisions. For instance,

237
00:21:58,580 --> 00:22:04,980
this tools out there that do code converters from like, you know, from like, even say Cobol to Java,

238
00:22:04,980 --> 00:22:09,460
they do a good job at converting it. But then it's really hard to support those Java applications.

239
00:22:09,460 --> 00:22:13,220
So the tools are getting better. And I think every day they continue to improve.

240
00:22:14,100 --> 00:22:19,300
Yeah, I'd say the goal, maybe it's 80% of the way the tools will be there to help migrate things over.

241
00:22:19,300 --> 00:22:23,860
And then you'll need the people understanding it to kind of finish the journey.

242
00:22:23,860 --> 00:22:28,020
Right. I would imagine that, you know, that kind of prioritization based on business

243
00:22:28,980 --> 00:22:34,180
outcomes and business goals, that's really a people conversation, I would guess.

244
00:22:34,180 --> 00:22:39,300
Yeah. And there are tools, we've created tools that help us, once we have those conversations,

245
00:22:39,940 --> 00:22:46,180
to allow the flexibility to say, you know, and I use the example of COVID. When we've worked with

246
00:22:46,180 --> 00:22:53,300
clients last January, their priorities changed in March. So the flexibility of reprioritizing

247
00:22:53,300 --> 00:22:58,340
your goals and what the impact is going to be in terms of what you do with your applications and

248
00:22:58,340 --> 00:23:04,020
what the prioritization of your applications changes. So we've also built tools to capture,

249
00:23:04,900 --> 00:23:10,100
you know, what, what are those business goals? How are they prioritized? What's the impact?

250
00:23:10,100 --> 00:23:16,020
So ultimately, we want to be able to help our clients to say your business shifts. Here's how that shift

251
00:23:16,020 --> 00:23:22,820
should, should impact or could impact the decisions you make about, should you go public cloud? Should you go private

252
00:23:22,820 --> 00:23:28,260
cloud? Should you do a massive remodernization of your application? Or should you just, you know,

253
00:23:28,260 --> 00:23:33,540
move it to a container or do tweaks to the application? So we have assessment tools as well

254
00:23:33,540 --> 00:23:36,740
as tools to actually make the changes once you've made your decision.

255
00:23:36,740 --> 00:23:41,220
All right. And you've definitely touched on this, but I wanted to bring it up just expressly,

256
00:23:41,220 --> 00:23:45,620
because it's something we've talked about in a previous podcast as well, which is the importance of

257
00:23:45,620 --> 00:23:49,380
it sounds like to some degree when you're, when you're talking about educating or upskilling

258
00:23:49,380 --> 00:23:53,700
employees. Some of it is technical and some of it, it seems like is on the business side of things.

259
00:23:53,700 --> 00:23:58,340
And then we had talked about like, at some point, you know, you, if developers don't understand

260
00:23:58,340 --> 00:24:02,100
the actual business goal, right, maybe they, they're spending way too much time over-optimizing

261
00:24:02,820 --> 00:24:06,740
on some element of an application where it's good enough and then they can move on and they can move

262
00:24:06,740 --> 00:24:10,820
on to the next, the next thing. So I'm curious, you know, just, just to get a sense of when we're

263
00:24:10,820 --> 00:24:16,100
talking about the people part of this, whether some of the gaps are more technical or whether they really are just

264
00:24:16,100 --> 00:24:19,460
bridge or they're, they're, they're, they're bridging. That's about bridging that gap between

265
00:24:19,460 --> 00:24:23,060
technical and business, technical capability and business need.

266
00:24:23,060 --> 00:24:27,780
I definitely believe it's, it's bridging the gap of having, showing people a different model of

267
00:24:27,780 --> 00:24:33,540
working and working together. Agree, like it's good enough to get it done as opposed to being

268
00:24:33,540 --> 00:24:39,300
into a state of perfection, whatever perfection should mean. So I think the bigger challenge tends to be

269
00:24:40,020 --> 00:24:45,140
getting that business and understanding like business people look at the features they want in there.

270
00:24:45,780 --> 00:24:51,060
Then they may be upset if it doesn't get performance. So being able to say, Hey, on a technical side,

271
00:24:51,060 --> 00:24:57,620
I need to build this for resiliency business people. Like I want my feature. So marrying the two together

272
00:24:57,620 --> 00:25:04,740
and having that, that collaboration is so critical to the success. If you, if an IT person will say like,

273
00:25:04,740 --> 00:25:10,340
I'm building it this way because in six months from now, when the business grows, I'm building it for

274
00:25:10,340 --> 00:25:15,300
that six month future. The business people should understand this taking a little bit longer to do

275
00:25:15,300 --> 00:25:20,340
something today because it's being built for the future. But a model of collaboration, like

276
00:25:21,380 --> 00:25:26,180
we've worked with customers all the time and we, we have seen big improvements with customers of the

277
00:25:26,180 --> 00:25:31,780
collaboration between the business and technology in that iterative cycle, working together on a weekly

278
00:25:31,780 --> 00:25:36,820
cadence has gotten so much better. And then everybody gets the right outcomes they need.

279
00:25:38,020 --> 00:25:40,420
That sounds very like Pollyanna, but it does happen.

280
00:25:42,340 --> 00:25:46,820
That makes sense. As more, as more organizations kind of embrace these different ways of working.

281
00:25:48,180 --> 00:25:54,100
No, that makes, that makes a lot of sense. I was wondering kind of where and when you see most of the

282
00:25:54,100 --> 00:26:00,660
obstacles during these modernization journeys, either, you know, kind of in these initial assessments or

283
00:26:00,660 --> 00:26:05,460
during the actual modernization work, like what are some of the major issues that, that come up?

284
00:26:06,180 --> 00:26:11,380
So from a people perspective, the biggest challenge is when people get pulled off for other things.

285
00:26:11,380 --> 00:26:16,260
We're trying, you want people to focus the idea of getting something done before you move on to the

286
00:26:16,260 --> 00:26:22,580
next thing. If people don't get that chance, that becomes a big obstacle. Some of the challenges we see

287
00:26:22,580 --> 00:26:29,140
from a technical side is as we dig into changes in the code, the skill sets on the teams may not be

288
00:26:29,140 --> 00:26:34,500
where they need to. They haven't been enabled enough to really take this on the changes they need to.

289
00:26:35,060 --> 00:26:42,580
So, so there's a technical enablement component that needs to be in place so that when, when my team

290
00:26:42,580 --> 00:26:48,020
will go with work with customers, the team that we bring has the skill sets. But our goal is to make

291
00:26:48,020 --> 00:26:52,980
make sure the customer is able to take the journey on when they're on their own. The right people and

292
00:26:52,980 --> 00:26:59,300
making sure they have the right capabilities and the ability to learn is always a challenge. We also

293
00:26:59,300 --> 00:27:04,980
look at code and realize like there's a lot of issues within the code itself that need to be addressed.

294
00:27:04,980 --> 00:27:11,620
And that will make, that may necessitate this taking longer. Security. Security is the biggest topic,

295
00:27:11,620 --> 00:27:16,500
especially when you talk about the cloud. How do you make things secure? And if you go into code and

296
00:27:16,500 --> 00:27:22,580
you see that there's security risks within the code itself, how do we fix that? So we've got to fix

297
00:27:22,580 --> 00:27:27,460
that. Like you, you don't want to move something to the cloud that's not secure. So that's usually a big

298
00:27:27,460 --> 00:27:32,740
stumbling block. So I'd say those are probably at a high level, some of the biggest hurdles we see,

299
00:27:32,740 --> 00:27:37,940
security, as well as capabilities within the team that will ultimately be owning these applications

300
00:27:37,940 --> 00:27:39,860
to understand the changes that are being made.

301
00:27:39,860 --> 00:27:45,140
Right. Out of curiosity, when you're talking about security issues, I mean, what is like,

302
00:27:45,140 --> 00:27:49,700
what do those look like? We've been obviously internally and externally, the security is becoming

303
00:27:49,700 --> 00:27:53,860
a much more prominent topic lately. It's, I mean, it's been in the new with that SolarWinds hack,

304
00:27:53,860 --> 00:27:59,620
right? It's like kind of rock, rock people's worlds. I mean, what is it? I mean, when I think

305
00:27:59,620 --> 00:28:04,260
about security, is it, is it in the logic? Is it in, is it in like components, just, you know,

306
00:28:04,260 --> 00:28:10,180
unpatched components or questionable tools or like, like what, what are these security issues that you

307
00:28:10,180 --> 00:28:16,340
see arising a lot? So, so I would say yes. And yes, we see a lot like secrets within the applications,

308
00:28:16,340 --> 00:28:20,020
like things are not protected as well as they should do. Remember, a lot of the applications have been

309
00:28:20,020 --> 00:28:23,780
around for a long time. So the latest and greatest things that are in place are

310
00:28:23,780 --> 00:28:29,780
not necessarily in place. They weren't around when these applications were written. So when we start

311
00:28:29,780 --> 00:28:33,620
scanning them and they, these applications may not have been changed. So some of the scans,

312
00:28:33,620 --> 00:28:38,500
security scans that go through, they haven't necessarily gone through all of these. So when

313
00:28:38,500 --> 00:28:43,140
we're trying to make changes, we're seeing these vulnerabilities in place. One of the things that's

314
00:28:43,140 --> 00:28:50,180
come out of that is we're helping clients get ahead of it. So how do you detect things in advance

315
00:28:50,180 --> 00:28:57,220
that may cause a risk from a security standpoint to your applications? So again, newer things are easier

316
00:28:57,780 --> 00:29:04,420
to protect because the technologies have improved. Older applications are, have a little bit more

317
00:29:04,980 --> 00:29:09,220
challenges to them because you don't necessarily have the time to rewrite something from scratch,

318
00:29:09,940 --> 00:29:18,100
but the security vulnerabilities that exist are, are intense. So, you know, a workaround is how do we

319
00:29:18,100 --> 00:29:24,020
get up front to see some things that are going on beforehand so that we could get ahead of it if the

320
00:29:24,020 --> 00:29:29,060
application can't support it? Well, we don't know where the application may have the vulnerabilities.

321
00:29:29,060 --> 00:29:36,340
I mean, security sounds like a huge, a huge area of focus. I'm wondering, you know, before folks even get

322
00:29:36,340 --> 00:29:43,220
started kind of on their, you know, putting together their plan for their app modernization journey,

323
00:29:43,220 --> 00:29:49,300
as you're calling it, like, what are some of the pitfalls that need to be avoided just right from the

324
00:29:49,300 --> 00:29:55,780
get-go? So I'd say a way of avoiding is every organization has their, their CISO and their

325
00:29:55,780 --> 00:30:02,420
security team in place. And historically it's been a gatekeeper. What we like to do is say,

326
00:30:02,420 --> 00:30:06,020
let's get security involved from the beginning. Let's identify the things that

327
00:30:06,660 --> 00:30:11,700
the organization feels are risks. We don't want to go down a path of making changes to be stopped

328
00:30:11,700 --> 00:30:18,100
at the 11th hour to say, no, no, sorry, this is a security risk. We can't do it. So getting everybody

329
00:30:19,300 --> 00:30:24,180
in the room at who has a, who will have a say in what happens, especially when you're talking

330
00:30:24,180 --> 00:30:30,020
like public clouds, where there's still a lot of fear or especially some on the public cloud,

331
00:30:30,020 --> 00:30:35,620
some on-prem, you've got edge technologies out there. Get the, get the people in there who have

332
00:30:35,620 --> 00:30:42,900
always had oversight from a risk compliance, a security perspective involved from the very

333
00:30:42,900 --> 00:30:49,380
beginning, listen to their concerns, understand what the challenges they've seen and that they're

334
00:30:49,380 --> 00:30:55,780
afraid of are. So as we make the changes, we can implement the right things in place to address them.

335
00:30:55,780 --> 00:31:02,340
That makes sense. And Felicia, I wanted to just ask you, you know, you mentioned a few minutes back

336
00:31:02,900 --> 00:31:09,300
COVID and how, you know, everyone had a plan last January that suddenly changed. And I'm wondering,

337
00:31:09,300 --> 00:31:16,100
you know, looking back on these last 10, 11 months, what trends are you seeing, you know,

338
00:31:16,100 --> 00:31:22,580
in the realm of atmarization that relates to how people are needing to respond to the pandemic?

339
00:31:24,020 --> 00:31:30,180
So interesting question. The types of applications that are, we're looking at now

340
00:31:31,780 --> 00:31:37,220
are dealing with the fact that people can't necessarily go in person to do things. So for

341
00:31:37,220 --> 00:31:44,900
instance, we, we work with one retail customer who needed to deal with the fact that people were just

342
00:31:44,900 --> 00:31:49,700
ordering online. They weren't coming into the storefronts anymore. So teaching them resilient

343
00:31:49,700 --> 00:31:56,660
ways of building their applications to allow quickly to allow for like, wait, nobody wants to come into the

344
00:31:56,660 --> 00:32:01,380
store. So we have to either deliver faster, a model that wasn't prevalent in their organization,

345
00:32:01,380 --> 00:32:07,140
or we have to have like curbside pickup. So that changed prioritizations. What people were buying

346
00:32:07,780 --> 00:32:14,500
dramatically changed. So prioritization for different types of products became important. That was retail.

347
00:32:14,500 --> 00:32:19,540
We also found that in the financial services world, bank fronts, people were getting like the FinTech

348
00:32:19,540 --> 00:32:25,540
concepts were becoming so much more important because people wanted to do things in a different manner today.

349
00:32:25,540 --> 00:32:32,580
So the prioritization changes based upon what the customers were seeing with COVID, you know,

350
00:32:32,580 --> 00:32:38,580
people not people being more online and not necessarily having the ability to go places,

351
00:32:38,580 --> 00:32:44,180
wanted them to be able to transact online and the prioritizations of what you wanted to do,

352
00:32:44,180 --> 00:32:50,580
scaling of applications, applications that you may not have had a lot to do with, needed to scale a lot

353
00:32:50,580 --> 00:32:57,380
faster. We work with some governments that unemployment, that became a real challenge. So things that they

354
00:32:57,380 --> 00:33:03,220
were able to handle the volume, and then when COVID hit, and so many people were unfortunately out of work

355
00:33:03,220 --> 00:33:10,020
and were applying for unemployment benefits, they were shut out of systems. So the, those were not

356
00:33:10,020 --> 00:33:15,380
important applications. Suddenly they became very relevant and there was a need to modernize them.

357
00:33:15,380 --> 00:33:17,060
So, yeah,

358
00:33:17,060 --> 00:33:20,660
Yeah, this seems like a good place to wrap up. And I just, I mean, I want to wrap up with one final

359
00:33:20,660 --> 00:33:24,660
question related to COVID and especially now that vaccines are available and we're starting,

360
00:33:24,660 --> 00:33:29,380
people are getting vaccinated, we're starting to come out of this, hopefully, is what, what do you

361
00:33:29,380 --> 00:33:33,940
see? Do you see, do you see any of these practices or lessons that companies have been learning during

362
00:33:33,940 --> 00:33:39,220
COVID? Like, which ones do you see really carrying over and how, you know, hopefully as a silver lining is

363
00:33:39,220 --> 00:33:45,460
that maybe processes are improved and, and the next time it's, it's even easier or, or businesses get

364
00:33:45,460 --> 00:33:47,940
better. I'm just curious what you see carrying over from, from this experience.

365
00:33:47,940 --> 00:33:53,060
So we've, we've done a lot of work remotely, obviously most people have. We've seen a lot of

366
00:33:53,060 --> 00:33:58,340
our customers have seen like, you can do things remotely while, while there's definitely zoom fatigue

367
00:33:58,340 --> 00:34:04,980
out there. People do realize hybrid model, I think is what people are looking for. I can get accomplished

368
00:34:04,980 --> 00:34:11,700
a lot in this remote world that we've been in with COVID. I think the ability to change quickly

369
00:34:11,700 --> 00:34:17,220
is really important that they're going to have to adjust to. The world changed overnight with COVID.

370
00:34:17,700 --> 00:34:22,500
So I think that flexibility, you know, personally, I think we're going to go back to a hybrid world

371
00:34:22,500 --> 00:34:26,820
where it's going to be in person some of the times, remote some of the times. I think that's something

372
00:34:26,820 --> 00:34:30,740
that people don't want to go back to being in their office all the time, but they don't want to be

373
00:34:30,740 --> 00:34:36,020
home all the time either. And how do you work successfully in that remote world? I think

374
00:34:36,020 --> 00:34:41,460
people have gotten really good at it at a necessity and technology, like tools like zoom and these

375
00:34:41,460 --> 00:34:47,700
collaboration tools that have come up that we use zoom, we use mural boards. There's so many out

376
00:34:47,700 --> 00:34:53,460
there. I think those are our habits that and trends that are going to stay for a while because they do

377
00:34:53,460 --> 00:34:58,180
have a lot of value and there's productivity there and there's employee satisfaction knowing they have

378
00:34:58,180 --> 00:35:02,740
choices. Yeah, that makes a lot of sense. And I imagine, too, it will also just continue to

379
00:35:02,740 --> 00:35:08,180
influence what types of applications companies are prioritizing when they're looking at modernization,

380
00:35:08,180 --> 00:35:12,900
because the way their customers are interacting with their products or the way their employees are

381
00:35:13,460 --> 00:35:16,020
working is really going to influence that, I would imagine.

382
00:35:16,020 --> 00:35:20,660
Absolutely. And when the world opens up, I can say, you know, you could sense that there's

383
00:35:20,660 --> 00:35:24,660
going to be a desire for people to get out in the world again, which will, again,

384
00:35:24,660 --> 00:35:30,660
impact which applications should get prioritized. So building a model that's flexible so that when

385
00:35:30,660 --> 00:35:36,340
business needs shift and they shift fast, you could change and know the direction you need to go with.

386
00:35:36,340 --> 00:35:40,180
I think that's that's one of the things we've been learning a lot. Like you need something that

387
00:35:40,180 --> 00:35:46,100
you could act fast on, but you could quickly, you know, change direction as the business needs deem

388
00:35:46,100 --> 00:35:54,260
necessary. It's the holy grail. All right. Yeah. Thanks so much, Felicia. Really, really insightful.

389
00:35:54,900 --> 00:35:58,660
Thank you very much.