>

This browser is no longer supported.

For a better viewing experience, please consider using one of our supported browsers below.

How To Approach Your Application Modernization Strategy

Every company is already a software company. Every company has some sort of IT foundation and software development they’ve done in-house or through a third party. And with the cloud growing at a fast pace, more companies are looking for better, more efficient use of applications and infrastructures. Rich Kopeikin, Director, Cloud Architecture with Prime TSR, and Ed Keen, DevOps Director with Burwood Group, discuss ways in which app modernization can transform how companies build and deploy software, as well as their approach to the modernization of applications within the enterprise. Listen to the full podcast here:

How to Approach Your Application Modernization Strategy

Below is a summary followed by a full transcript of the recording. 

What is application modernization, and why do companies need it?

  • Every company is already doing software development. It’s natural to want to modernize their applications.
  • There are many different reasons companies modernize. It could be for security reasons, performance, and/or scalability.
  • Expectations are changing. For example, reliability expectations are much higher. You used to be able to take down systems for eight hours. Now it’s much different.
  • Digital has accelerated the need to move quickly and be agile with software development.
  • Modernization has grown because of cloud computing, but in some cases, it makes sense to be on-premise or hybrid.

What are the overall benefits of application modernization?

  • Speed-to-market is a big deal and has become more important than ever. With modernization in place, you can build new features faster and more securely. You don’t need to shut systems down to perform upgrades.
  • DevOps + automation capabilities make things faster and easier.
  • Infrastructure as Code (IaC) is also helpful in building and automating the creation of new environments. 
  • Modernization doesn’t just fix the current problem; it builds a great foundation for change in the future.

Recommendations when starting a modernization journey.

  • Do a proper discovery to understand your current landscape and challenges.
  • Build a roadmap of where you want to go. 
  • Make sure your foundation is set up properly.
  • Hire the right talent with the right skills (production experience helps a lot).

Read the Transcript

Host

Welcome to another special podcast. We have a member from the Burwood Group and Prime TSR, we have Ed Keen, who is a Director of DevOps at Burwood Group, and we have Rich Kopeikin, who is Director of Cloud Architecture at prime TSR. So thank you both of you for joining and today's topic is going to be something that's on everyone's mind, especially if you're involved in technology and building software, which is app modernization and you two have no app modernization in and out. And that's why I'm pretty excited about this. So I want to start with the softball question, what is that modernization and why do companies need to invest in it? And more importantly, what happens if they don't invest in it?

Ed Keen | Director of DevOps Burwood Group

I'll start with one of my favorite quotes is Sasha Nadella from Microsoft a few years ago, referred to every company is a software company now. And it's never been more true. All of the companies that we work with, whether they're in retail, finance, industry like manufacturing, higher Ed. All of them are doing software development to some shape or form. Whether it's for their internal customers or for their external customers. With them doing that application modernization is all about having them do it in the most efficient, scalable performance, reliable manner. Whether they're building new applications or whether they're still managing and maintaining and continuing to grow their existing applications. So that's probably the best starting point that I have. 

Rich Kopeikin | Director, Cloud Architecture

Yeah. Yeah. I was going to say that you said it was a softball question, Robbie, but honestly that is... it may sound like a softball question like what is that modernization but no, it's interesting to think about it. Can't have a little bit more complex answer because it's a lot of different things to a lot of different people. But basically certain companies have different problems with their software. I'd say every company is a software company, but there's tons of different problems. You could have your software just isn't usable, it needs a UI UX facelift if it's for your customers, maybe it's not performing. So it needs to get faster on a day-to-day basis, maybe it has peak periods where you have a bunch of customers rush in like those websites on black Friday. That always crash. You need those to be super scalable, but you only want to pay for that power during that time. So you need them to be elastic as well, being easily able to scale up and easily be able to scale back down. And sometimes you just want to improve the basic languages and foundations and frameworks that the website's written on or the applications is written on, just so that you're taking advantage of the new latest greatest features that helps you maintain it. So modernization to me, obviously it has a lot to do with cloud nowadays with moving and getting people leveraging cloud services and technologies, but it also... is a lot of other potential things that depends on what is the problem with your application, is what it boils down to for me. What's your heartache? What are your users hate? What do you hate? Can you not get development done fast enough? Is this process too long, too slow? Is the data not right? So it really is all-encompassing to me. So what is it? It's a harder to answer what it's not almost.

ED KEEN | Director of DevOps Burwood Group

I think there's a couple of things that come to mind with your answer Rich, which were speed to market. So as you start building modern applications or you look to modernize your existing applications, you want to be able to push new features faster. So you want to move away from yearly or quarterly releases and start being able to push new features, maybe the daily, or maybe multiple times a day like a lot of the larger companies are doing. And then there's also reliability now as well. I was talking to a potential customer yesterday and they are modernizing their IT and technology shop and stack and their people, the leadership team's expectations of reliability for them are infinitely higher than their previously. Previously they would be able to take the system down for eight hours a week or a month. Now everybody expects it to be up and running a hundred percent of the time. And the only way you can do so is by using latest technologies, latest processes, latest languages, etcetera.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Yep. Yep. And that's a good point as well that you made me think of then in that when people wanted to be doing these releases more often, obviously their key core skillset and key core of focus needs to be on your development operations DevOps in order to do that and that it almost to me goes hand in hand with that modernization nowadays, because I just cannot imagine almost working out any project without having some basic, if not it almost immediate do advance DevOps capabilities because you just can't... It makes things so much faster, so much more repeatable. Automation and DevOps to me are almost synonymous. And for all the great reasons that everyone knows that automation is amazing, that's what DevOps it helps you do get those out there faster. So I know I am little bit probably tangent data tailgated, but to me they're almost building out those new and great capabilities to be able to get stuff out to market faster like Ed was saying is just as important to me as modernizing the app itself. It's almost like a dual monetization, you've got to modernize your DevOps and modernize your app at the same time.

ED KEEN | Director of DevOps Burwood Group

And modernize your technology group you nailed it Rich with bringing in DevOps and then DevOps not just alone, right? Principles like agile and then within the tooling and capabilities that of the people will see a synonymous with DevOps, things like infrastructure as code. Stop modernization your technology group. Stop not having people no longer click in the user interface to provision of VM and start being able to... you make use of cloud services as well. So writing infrastructure as code, doing so using more elastic services that are available with the cloud providers.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

And that's the thing nowadays, as well is that why take an application that's been written in a bunch of... that's been around for 20 years and the code is legacy and it's spaghetti and it's a mess and no one can update it. And then some people take an application like that and they write it as spaghetti mess in a new framework. That's just... Sure, it's... there's been certain things you take advantage of to get there, but you're not getting any increased speed to market out of doing something like that, it's just as hard to be maintainable. So things like I'd say the infrastructure as code, you start putting those into place and other processes into place and automated testing and the place. And then what you've built yourself is not only fix whatever problem you're initially having, but you've also built yourself a great foundation for change for the future. When you do that infrastructure as code, Hey, you want to add another server. You want to spin something up in another region. You want to add some power to the CPU you want to even change clouds from one cloud to another. You have that foundation right now to do that like that. Where... So if you're going through this big monetization, you're not building out those things to make your life easier for the future. You're really missing out on a big part of the modernization process.

Host

Yeah. I was going to say Rich, when you mentioned the spaghetti code as well, a big part of this as well is moving away from that tightly coupled spaghetti code into to break it apart from the monolith and breaking into microservices so that teams run their interdependent and services where that... Hey, they can have true ownership off. They can maintain their own backlog for their applications and their services. They can be responsible for their own deployments. You can have alerts go to that team. They can be doing application performance management and truly own their applications and their services and have them again, like decoupled from the rest of the application teams as well. It provides a lot more autonomy and ultimately happier software engineers.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Yep. Yep. And Robbie, you'll have to get used to me and Ed, we don't need you anymore. We'll just take over.

Host

I don't know where to go. What am I here for? This is it, you guys are... This is a great party, the amount of passion and this subject like I said, which is actually this conversation is a really good segue into the next question, because if I listened to you, if I'm a CIO of a company and I'm listening to both of you, I'd go, "You know what? This makes a lot of sense. There's nothing I would say that you've said wrong." Which is a good segue to this next question is, what are the challenges of doing this? Obviously the benefits are there, right? There's... no one's going to say no to, "I love to move quicker, more efficiently, have stable releases and do things iteratively, things like that." But what are the real challenges that companies face when they do this?

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

I can take a shot at this one first. So for me there's a few things. The first one is what... getting to what your end state wants to look like. You definitely should be thinking about that long-term plan. You know that you're not going to be able to get there, but where do you want to be going, have that map. And sometimes it's harder than it looks because what I found really recently, as well. There's all these great services and cloud technologies and resources that app it's exploding, everybody knows and learns about it and they want to use them because they sound sexy and cool. And it is really easy to develop solutions now that work and by stringing together these technologies in different ways, but what is difficult is actually developing the right solutions. I found that it really takes some time at the white board some longer conversations, some real time and process before you just start going and doing to get the right design for the application at the end of the day. And it's not the worst thing if I would say a lot of people don't do that and they get away just fine. They build an application that works. It goes, it perform and they get it over the line at the end of the day. But it's just not what they could have done up front. So the first thing is doing that design up front. The second thing is getting that roadmap from A to B. And that goes into that what Ed was talking about with the previous question, what are microservices and a bunch of other technologies. It's a lot on that, Ed I'm going to let you talk too because actually you're a little bit better at taking those, at least doing the kickoff by taking those initial applications that are legacy and doing the quick improvement, getting bing for your buck right out of the gate with them. Right?

ED KEEN | Director of DevOps Burwood Group

Yeah, to elaborate on that. I probably got two main points here. So the first to be the cost slash investment in doing the application modernization and the second would be skillset. So make sure I can keep my memory going on each of these. So for the first one then it does require an investment in modernizing your application. So we have a customer, a local customer here at Burwood's who spent a year and a half. They had a feature freeze of a year and a half on their main application, which means that they push no new features. They weren't able to innovate or do anything new with their main application for a year and a half as they completely rewrote it. And they rewrote it to ran it on Google's Coobernetti's engine or GKE I think Google cloud. They did it always microservices, and they went live and it's gone phenomenally well, but that was it. It took a year and a half worth of investment. They couldn't be happier. The CEO, the CTO, the team of engineers this is a huge success but for the CTO, two, three years ago when he made a pitch to the board. We need to do this, that must've been an incredibly hard pitch. Try to tell anybody that we're not going to do anything new for a year and a half, we're going to fix our stuff. That's a hard sales pitch to make.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Very hard sales.

ED KEEN | Director of DevOps Burwood Group

That's an extreme case of feature free for a year and a half, but with the larger applications I get it really obviously can be that long.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Yeah, yeah. That goes right to reminds me on and this seems to be a little common too, because we're working with a customer right now. There's a large software as a service company who has a product that a lot of people use and it's very hard not to give their customers those updates that they're asking for, but that's what the company essentially had to do to ride the ship in the near term. They had to pitch something similar to what Ed was saying. Now, I think it was about three to four months is what they did, which was still a shock to them. I could only imagine a year and a half what they said about that. But they actually called the project spray paint, which I thought was interesting and it was just like, "Hey, we're going to take all the garbage and we're going to spray paint over it and have a blank canvas afterwards." That was the general idea of it. And, but no, afterwards it's great. They had their... at least they had a stable amount of automation. They had good environments built out. They had their processes worked out and then after that, they were able to continue enhancing and modernizing on top of that. But it just needed... you really need to stop production sometimes in order to get all that done, like Ed said.

Host

And that's a good segue into this question actually, which is because we were talking about modernization strategy and things you can do. When a customer comes to you and says listen, "We have several apps or all of our platforms need to be modernized as opposed to we just have this one app particularly needs to be modernized." How do you approach that I guess from an organizational perspective we come in there and says, "We want to modernize everything." How do you assess that? Or help them view their journey?

ED KEEN | Director of DevOps Burwood Group

Yeah, I'll jump in on this one, Rich. So we have a maturity model that we apply to our customers around where they're at on their digital transformation or application modernization journey. So we can help place them where they are help show them where they can get to and what the journey there looks like. But a lot of it starts with discovery. So we'll go in discover their applications, build like an application inventory and a map of the end of dependencies that dependencies on the infrastructure they're running on. End up having to go through some interviews with application owners, start to understand some of the dynamics between the teams as well, because it's not just a technology challenge here. There's a people challenge as well. There's a different way of working for a lot of people as they move to agile, move to continuous integration, they move to some microservices and away from the monolith. And so understanding the dynamics between the teams and what people and process hurdles it might hit as well it's a good starting point.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Yeah, absolutely doing that upfront analysis is key to just do that discovery and learn what their current environment and structure is. Nowadays, some companies or organizations most likely have already a cloud footprint, but what does that cloud footprint look like? How stable are those foundations? Does that need to be built out? Before you could even start to move more up there in general. And then after that you also need to look at... Really for me it comes down to figuring out what their identity is. That company's technology identity, which again goes to discovery. You would have applications are you're leaning towards this type of framework technology, this type of framework, or do you have stuffs spread across the board? And then after that we're... what's your future identity look like? So you really have to think long-term there and strategic before making any quick decisions. But certainly what we do is come in and do that analysis upfront. We do a full report. We give everybody key decision points of the, "Hey, we want to make sure our thinking is right here. Please validate it. Some of these things we can't answer for you, it really has to come from you. But after that happens, then after that we're all prepared to hit around running." And maybe I'm patting myself on the consultants in general on the back. Yeah, one of my old buddies project managers of a former company, he used to love to say we come into companies and we work with their IT shops and we just run circles around them is what we do all day long. We could produce things... Just the real limiter is having them get out of our way or if we need them to rely on them for something, because we are all ready to rock. That's what the consultant motto is, is, "We're... Your money is our time." And we want to get it done fast for you.

Host

Yeah. It's kind of thing we've seen this happen before. We've seen how the story has played out and we're just here to help you not play out that same story because we know you can be there. And let me... out of my curiosity. So when we say the app modernization, does that by default mean cloud? Can you do monetization without cloud?

ED KEEN | Director of DevOps Burwood Group

Absolutely. Cloud provides a great framework for a lot of this stuff that we're talking about here with being able to run platform services, "Hey, you no longer need to run and support, like an underlying virtual machine that ends up getting abstracted." And so it makes it easier for engineers to deploy applications to a platform in the cloud. But you can do a lot of that on premise with private cloud. Some of the tools we've talked about with Terraform for example, for infrastructure code, you can use Terraform with VMware and start doing infrastructure as code in your own premise environment and your data center.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Yep. Absolutely and even the smallest things, if you take just the UI itself, if you're on, let's say maybe a Java spring framework or if you're... Which is a tightly coupled MVC style framework or .net MVC framework, another tightly coupled model view controller type framework, just taking out that UI piece and go and do a spot type application, a single page application using angular or react or view. Decoupling that UI piece from your backend piece, you're doing monetization right there and it doesn't matter if you're doing that on the cloud or not. And really when I think about it you could work your way backwards there just go over the pieces really quick. One is that getting yourself decoupled and getting a nice responsive framework. The next one Ed has been talking about microservices, you can define all your microservices on prem. There's no reason that you can't do that on prem. When you start really defining the open API specifications, using things like swagger that's how you, again, decide what your domains are going forward for each of your microservices on the backend, you would use Kubernetes there's nothing to say that Kubernetes can't. Kubernetes runs just fine on prem for spinning up and down various work and even in the backend, you have no Sequel databases and various other data stores that you could really run. They're cloud just has made all of these services so much easier to use and so much more out of the box and so much more elastic and scalable, that's really why we love to use cloud nowadays, but there's nothing stopping you from doing all this stuff on prem and to move from the cloud. It's just so much easier on the cloud.

Host

Oh yeah. I was just trying to fish it out. If you were being biased or this is a... But it sounds like you could still modernize on prem and-

ED KEEN | Director of DevOps Burwood Group

Absolutely. Robbie, just to jump in you definitely can, if you've got an investment in your on-premise infrastructure and you want to get the most out of that investment, you can can definitely do so by applying a lot of the automation, a lot of the modernization we're talking about here. You can bring in... If you want to run a Kubernetes on premise, there's a number of different ways of doing that. If you want to run it on premise and in the cloud, you can use tools like Googles and for those to be able to do so. There's a scale and again, leverage that exist in hardware investment.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

And absolutely, that you supplement with the cloud while keeping you on-prem. And that's a great... that's an amazing model too. Absolutely.

Host

In any mentions about Google anthills. And so, the word on the street here is and correct me if I'm wrong, is that you two are pretty good at Google and then the GCP platform and anthills. Am I correct with that assessment?

ED KEEN | Director of DevOps Burwood Group

Yeah. So Beau is a Google premier partner. So we do a lot of projects with Google and all the projects we do with Google involve some element of DevOps and modernization.

Host

What makes Google different from the rest when it comes out to app modernization? What does Google's play into this?

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

What I like at least in terms of a cloud perspective. I don't know if I can say honestly that... Well, there's an application itself, that's application specific code. And a lot of applications are written custom. Some are some aren't, but anyway, from a cloud foundation perspective, what I love about Google is that they really lead you to doing things the right way, doing that infrastructure as code, or doing your automation and your API and scripting things out. Some of the other clouds you're able to click around and model your way through. And I love that to begin with you as an application developer, because I was like, "Oh, I could spin up a server. I don't need these infrastructure guys anymore." And it was so easy, but yes, I quickly ran into trouble as soon as somebody asked me to create an SSL cert or do a sub-net or something like that. I was like, "I could figure this out by clicking the buttons, but I'm pretty sure I'm doing everything wrong here." So, knowing how to set that up from the right way, you have to really understand the code behind it and all the possible features and functions of doing that. And Google really lends itself nicely to creating those, again, infrastructure as code templates, whether they're scripting or Json templates, or even the programs to create infrastructure. Again, maybe you speak a little bit better to the foundational pieces but to me what they do better is the foundations of what the app will be built on. The app itself, they have a lot of good features and functionality too with app engine, but I personally enjoy the foundational piece.

ED KEEN | Director of DevOps Burwood Group

Yeah. I find... I get in a nutshell, my experience with all three would be AWS feels like it was written with DevOps in mind that they were early pioneers with DevOps tooling. Microsoft Azure feels like it's very much aimed at the enterprise space and .net, folks who already doing .net development it can be a great fit for them. And Google personally is my favorite of all three. I find it incredibly intuitive and easy to use. They've provided very, very powerful and bleeding edge capabilities and it feels like it was written with developers and software engineers in mind. It was like, "Hey, everything that we do in Google cloud is tailored to us as engineers." So it's very intuitive for us as engineers. Yeah.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

And like you said, in the beginning, every company is a software company now. That's it, it's for a software engineers, and yes, it's great for those. A lot of these startup companies who are either going to be processing just gigantic amounts of data in the future, or spinning up an out it's... if you're building it on that platform you're doing it the right way. And couldn't agree more, Ed.

Host

A follow up question to this app modernization and Google cloud and if it's in the cloud, is it always going to be modernized? Is that... Because I know there's a premise and thing on that. So I want to talk because there's this and I can feel it right here. The vibe ready go, no, no, no. From my perspective, it feels like, "Oh, if it's in the cloud it's always going to be modernize that's always been like the pitch. So walk me through that.

ED KEEN | Director of DevOps Burwood Group

I'll jump in first. One of the things that we tell customers and prospects, when we first start talking cloud, digital transformation, DevOps application modernization is, cloud doesn't automatically equal automation and scalability and self-healing and DevOps and all of these great things, but it is this platform that can provide all of that stuff. So you need the expertise and experience to help you make the most of it that you can very easily just lift and shift virtual machines from on-premise into the cloud and they'll run the same way. It's a very inefficient way to do it, right? The cloud is designed to be for elastic scalability based workloads. So if you're going to run a machine and need fast access to storage and you need to run it 24/7, it's going to be expensive to run in the cloud. If you have something that's going to burst up and down, cloud is a great resource for that. So we work with... talked to a number of customers who have looked at, "Hey, how much would it cost for us to move our application as it is to the cloud today?" And it can often be expensive if they need direct attached, SSD storage, and they have large Sequel servers it can cost an arm and a leg for them to be able to run it in a cloud. It was also expensive for them to run it on premise too, but that's where the modernization conversation begins that how can we start breaking apart these marvelous and identifying what services would be a great fit to run as a microservice and to move out into the cloud.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Absolutely lift and shift. As you said, it's almost a... It's been a dirty term for a lot of years. Nobody likes to... They're like, oh, where do you do that? Another lift and shift. Oh yeah, I know they wanted it.

Host

Is a deadline to beat.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

You're technically in the cloud now and you get your bonus because...

Host

Because nobody knows any better. Right?

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Like I've said I have lightened up a little bit on the lift and shift, because at least then you have some foundations and you get the possibility of setting up those configurations around it. But at the same time, it's just why? You're really could be doing so much more with that project and if you're doing that, and one of my favorite things to think about is just at least wrap it in a container of some kind before you put it up there. put it in... The cloud is really based on containers and at the end of the day, and being able to run your workloads on them. And at least once you have it on that, you're able to make it a lot more scalable and a lot more elastic because yeah, if you just replicate your hardware on the cloud and get up there, you might actually end up spending more money than you would on premises, because it is sometimes more expensive to have those, all those additional capabilities there that you're not taking advantage of. So if you're not going to take advantage of them it's almost like why do it. You will immediately get a data center that is about as secure, well about as disaster proof. And as your old data center was. You get a little... It depending on how you configure it. It's literally, if your data center goes down just like their data center goes down, it's about the same.

Host

What advice would you give to, let's just say a CIO of a company that's in the early stages of... app modernization. And they said, "Hey Ed. Hey, Rich. Give me some piece of advice here. How should I approach this?" What advice would you have for them as they begin this journey?

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Make sure your foundations are rock solid, that you're doing things the right way to begin with before you start throwing stuff in there, that you're doing it the right way, that your permissions are set up, that you're leveraging those cloud native services, be thinking about the long-term and design that the right way. Don't just give somebody a credit card to start spinning up your production environment. It's a good way to do POC, but you really want some experts in there who know and have done this before. 

ED KEEN | Director of DevOps Burwood Group

Yep. Very similar from my perspective, understand where you're at. Make sure you have that solid foundation, the solid secure governed foundation upon which to build, and then build a roadmap for where you want to get to. So that you have a path you could follow, and it's a lot better organized than scattered all over the shop.

Host

That's great. Is there anything that we didn't cover that you think is relevant to anyone that's thinking about ad monetization?

ED KEEN | Director of DevOps Burwood Group

Yeah the second challenge that I see when companies are looking to modernize, I mentioned the first one is the cost of the investments in it. The second challenge is skills, experience and comfort. So for example, we work with a lot of customers who understand the concepts of containers and Kubernetes and microservices. They have some great ideas, but having not done it before, you might have an architect who's been in the same role company for 8, 10 years. So they've not done this somewhere else. They've got all the right ideas, they oftentimes they maybe just need some confidence. And then there might be folks who've never done this before. They haven't read about it before and so bringing in somebody who has the experience, the production real-world experience and the expertise and the partnerships. That's what makes all the difference. That's what helps get over that challenge of the skill set and the experience and the confidence.

RICH KOPEIKIN | DIRECTOR, CLOUD ARCHITECTURE

Absolutely having that internal champion who loves technology and is willing to take the time and effort to research the right way to do things and even know what they don't know. That's important for myself and I'm faced with a new project that like, hey, I know that this is a huge field. I understand the basics of it, but now I have to go either to have a conversation with somebody else who I know is an expert there or just read, read, read about myself. And even if I do that, I still want to have conversations with those experts who have been there and done it before. And it's a mindset as well that you need to really embrace it and there's a lot of people, great people at organizations already have been there 8, 10 years. But they've been supporting the same thing for 8, 10 years and have been unfortunately in a bubble and they'd love to get out of the bubble. They just don't know. It's hard to see how so, I do love helping those particular people, because they have a lot of energy as well to make things better as long as you're doing it the right way it's good.

Host

All right I found my two experts. If I ever modernize my organization. I know where to go. So thank you very much. Thanks Ed thanks Rich. And thanks from the Burwood group in prime TSR. I really appreciate it and I'm looking forward to this being published.

ED KEEN | Director of DevOps Burwood Group

Excellent. Thanks.

Host

Thank you very much.

 

 

DOWNLOAD NOW
About the author:
C1 is transforming the industry by creating connected experiences that make a lasting impact on customers, our teams and our communities. More than 10,000 customers use C1 every day to help them build meaningful connections through innovative and secure experiences.