Veracity Solutions presents: Continuous Modernization

Natalie: (00:00)
Good afternoon, everyone. Carahsoft Technology would like to welcome you to our AWS Webcast. Before we get started, please note that all your lines have been muted to reduce any background noise, and we hope you take full advantage of the chat pod on the screen to ask any questions throughout the presentation. If we are unable to get to your questions, our team will certainly follow up with you offline. This webcast is being recorded and the copy of the presentation will be emailed to you.

Natalie: (00:23)
Just to tell you a little bit about Carahsoft, we are a trusted Government IT Solutions provider delivering software and support solutions to federal, state, and local government agencies. Carahsoft maintains dedicated teams to support sales and marketing for all of its vendors, including AWS, VMware, Palo Alto Networks, Dell EMC, and Splunk. Our contact information will be at the end of the presentation, so please don't hesitate to call or email us for any of your needs. At this time, I would like to introduce our speaker for today, Lonnie Buchanan. And Lonnie, the floor is all yours.

Lonnie: (00:56)
All right, well, thank you very much. I really appreciate that. I'll just get started here. I want to share up my screen here. We'll just get started here. Fantastic. Well, welcome everybody. My name is Lonnie Buchanan. I'm the chief architect and executive security director for an organization called Veracity Solutions. I've been asked to speak about continuous app modernization, and I'm sure a lot of you guys are going, wow, that is an exciting subject. While it may not necessarily be the most exciting subject in the world, it is an important subject. Now, let's get started here.

Lonnie: (01:35)
Okay. First of all, who am I and what do I do? Well, like I said, I'm the chief architect and executive security director here at Veracity. My role is I look for the obvious. As we know, there's certain things in life that are very obvious, and that's what I do, I try to discover those things. In the realm of software and in technology, there's a lot of obvious things that we often overlook and we often miss. Now, over the last 40 years or so, we've spent a lot [crosstalk 00:02:04].

Natalie: (02:03)
Hi Lonnie, I'm sorry. I cannot see your screen right now.

Lonnie: (02:07)
Oh, let me try this here.

Natalie: (02:10)
There we go.

Lonnie: (02:11)
A little better there. Okay, fantastic. Sorry about that, everybody. Basically, as I was saying is, what I do is I look for things that are very obvious. Over the last 40 years or so, we have collectively, as an industry, spent the last 40 years coming up with new processes and methodologies, that all we do is we tend to go on and change later. Some people, they actually change processes quicker than they change the code that the process supports. As we continue to look at how things are evolving in technology and how they are evolving in the industry, we keep coming back to a certain core set of very obvious and common strategies that we present from.

Lonnie: (02:56)
Now, today, what I want to do is I want to a look at certain things that should be very obvious in the realm of continuous modernization of applications and technologies. Today, we're going to look at the obvious why and the obvious how, and the obvious processes, and some of the tools and feature sets that AWS is able to provide with us. With that, let's just kind of get going here and get started. The first thing is let's begin with the why. Now, why in the world would you want to focus on a continuous process of modernization and why would we place it within the context of legacy systems?

Lonnie: (03:36)
Because what we mentioned here is legacy systems themselves. The first thing we have to understand is, what is legacy? Now, when I started this presentation, I started looking around, I said, okay, I need to give everybody a really good definition of what legacy is. For my grammar viewers out there, legacy, when I look it up as a noun, and anybody that has legacy is fully aware that a noun is a person place or a thing, and that their legacy is definitely a person place or thing. But as I began to look, one of the things that I kept seeing over and over and over again, that legacy, by definition, is a gift.

Lonnie: (04:16)
Now, I don't know about you, but I don't ever feel that any legacy that I've ever worked with is a gift. That's kind of an obvious answer. But what is legacy, and do you actually have it? Because that's the first place we have to deal with. Gartner gives us a really practical answer in that. The term legacy in their definition refers to systems that have outlived their functional usefulness or have been superseded by newer alternatives or have been, or will be replaced. Now, That's a fancy term that is kind of generalized and everybody can put it out there.

Lonnie: (04:57)
What is legacy? Do I really have legacy, and what is it? Well, I'm going to break it down to something a little bit simpler to understand. First of all, legacy is just a mean old dog. Now, you go, what in the world are you talking about? Anybody that is dealing with legacy right now that is having to fight legacy or archaic systems or systems that just aren't doing what they're supposed to do know exactly what I'm talking about. Legacy is just a mean old dog that you have to deal with. Now, legacy doesn't start out as a mean old dog. Okay? It starts out as a puppy. Something that we wanted, something that we desired, and we're happy with. But legacy doesn't stay that way.

Lonnie: (05:41)
It begins to grow up. What happens is, is how do we prevent our cute little baby puppy from turning into a killer? Well, it's obvious, we give it proper care and proper training. Legacy has to be trained and has to be cared for. These older systems, just like you have problems with a dog that's not properly trained, so does a system that's not properly cared for. What kind of problems do they have? Just exactly like when we're training with the dog. Systems that are not cared for can be costly. They can be risky. They can give us security issues. They can be time consuming or slow in their process.

Lonnie: (06:21)
They may no longer fit the business needs. They may have high negative impact on the business, or other systems may be better suited to do the same job, or they may be completely closed off making it a lot harder to get to the data or the functions very difficult to get to. But here at Veracity, what we continue to see over and over again is that the number one reason that legacy systems fail is because those systems are not designed or built to match the rapid change of pace and the modern demands of digital business.

Lonnie: (06:54)
Basically, your system can't keep up with the rate of change. Your world is changing faster than your system. Let's look at a couple of little numbers here to get an idea of how fast things are changing, especially with governmental agencies today. Recently, TechRepublic published these particular numbers, that 72% of government executives say that outdated IT systems are hurting their ability to respond to changing demands. 79% say that the age of their IT systems negatively impact their mission. These are real world examples. These are real numbers, and these are probably things that are affecting you also.

Lonnie: (07:37)
You probably have outdated systems or you have systems that just can't respond quick enough. Gartner also gives us some numbers to look out into the future a little bit. By 2024, Gartner predicts that over 40% of the public sector knowledge workers will be permanently working from home. Now, this is a result of the recent pandemic, many people changing to remote workforces, but this is going to contribute up to about 20% in capital cities' economic decline. So, we're seeing more and more people move home and work from home.

Lonnie: (08:16)
By 2023, the prediction is over 60% of governments will have tripled citizen digital services, but less than 25% will be integrated across organizational silos. We all saw that, that huge demand that hit in the middle of the pandemic, of people going home and then needing to do their work remotely, no longer coming in person and no longing having that human interaction. Now, people have moved to digital resources and digitally online. If you have software in your legacy, and if you have technology in your legacy, if you have legacy, well, guess what? You probably have some problems.

Lonnie: (08:59)
Those are the things that we need to deal with, and you probably recognize that you have these problems, that's why you're attending this particular webinar today. Let's talk a little bit about the how. Now we know why we need to be modernizing our systems, and modernization should be focused on a continuous modernization, but how do you do it? What do you do with your systems? Now, we at Veracity, we advise organizations to instead take an iterative approach, a gradual approach that focuses on providing digital business support and value in a timely manner. But the simple answer is, at the beginning, is you start by simply understanding what you currently have and where you are going with it.

Lonnie: (09:47)
There are certain metrics, okay? If you're going to make some decisions and you're going to move legacy into some type of modern realization, you have to have something to measure to get and make those particular decisions. In most cases, there's about six primary values that can help guide your legacies toward a new and brighter future. It's basically the concept of fit, value, agility, speed, cost complexity, and risk. Now, there are different approaches that allow people to modernize their systems. Each of those approaches have ... They have good side, they have a bad side, they have benefits, they have different aspects that you have to take into consideration when we talk about modernizing your system.

Lonnie: (10:39)
Let's take a peak at some of these different ways that we can modernize an existing legacy system. Obviously, the first thing that you can do is you can replace it. Now, I've put these in the order that we typically see these. This is usually the first thing that people want to do, is they want to replace it. And we're replacing it ... It has typically a high cost and high risk associated with it. Replace will have the highest impact and effort on the business. Basically, you are changing the underlying core system. This is the most radical of all the solutions.

Lonnie: (11:16)
You're abandoning what you've done for a long time or for previously to take on something that you may only have a limited knowledge of, and so that increases the risk associated with that. The other side we see people do is they rebuild it a lot. Well, of course there's also risk and cost associated with that. Rebuild has a little less cost, but it does tend to have a higher risk associated with it. Are you sure you are doing the right thing? Are you sure your product is better than your competitor? Is your product better for you than an off the shelf product? In this context, rebuild simply means to build the original design again, using more modern language or method. Just take the old and make the old new.

Lonnie: (12:02)
It often looks the same, but under the covers, it typically runs better. A third way that we see people approaching modernization is what we call refactoring. Now, refactoring is really just cleaning up and optimizing underneath it. Refactoring the existing product is kind of a middle of the road approach. Really, all you're doing is fixing known problems in the code. Many go with this approach because they feel they can clean the existing problems up quicker than rebuilding or moving to something else. However, refactoring may only bring limited, or maybe even no new functionality, so you have to decide if you need new functionality in your product.

Lonnie: (12:45)
This is really one of the areas where you need to make that particular decision. Another thing that we see a lot of people do, and not necessarily as much as the previous, is just repackaging. This one has been really popular over the last few years. Just repackage it. Put some API interfaces around it, let it go. For those fans of the strangler pattern, this is a really good place where you could use that pattern. Also, if you're thinking about doing this, look at decoupling when you reach this point. The effort tends to be low, the architecture sample with low cost and low risk. However, you typically do not gain a lot of new functionality or limited ...

Lonnie: (13:31)
There's a limited use of new technologies associated with it. Then we kind of move into some of the more radical things that we see people doing. We see people re-platform. This is really just a move to a new platform. This one can be a tough one. We see people doing it, but actually not with that much success. A lot of times people will try to re-platform, thinking they're going to get a lot of new functionality, which they typically don't do, and then they end up with kind of a mess, and they either have to try to figure out a way to get it back on the old platform or bring in someone else to help them get it onto a new platform.

Lonnie: (14:10)
There may be just little technology gains that may come from some new underlying platform enhancements or into some new platform features. However, the language problems are still going to exist. You're still needing to spend money and effort and put money into it. So, be careful in the re-platforming. Make sure that's a direction that you want to go. Another thing we see is, and you hear a lot of people talk about this, is re-hosting, moving to the cloud. Re-hosting is the old lift and shift model that we've talked about for years. It's just moving it up to the cloud. It really doesn't buy you any new functionality and there's very little to no technology gains.

Lonnie: (14:50)
However, when it's done properly, it can have some of the lowest risks and lowest gains. This is one of the biggest areas that most of the cloud vendors will warn you on, is that a lift and shift is not necessarily going to fix the inherent problems that you have around your legacy systems. Be really careful whenever you're looking at a re-host. Then of course, finally, the big one, the one that costs the most money, that costs the most effort usually is around re-architecting. It's a complete rebuild of the new platform in the code. Basically, whenever you get to this type of thing, you look at the complete design over and you re-architect it.

Lonnie: (15:29)
I've listed it as a moderate cost because in the grand scheme of things, if you have failures around re-hosting or any of the other ones, the cost add up just as much. So, sometimes the end result of people who try to re-platform and rebuild at the same time, they end up redesigning the entire thing anyway. Re-architecting has a moderate risk and cost associated, but once again, that's only if it's done correctly. So, it does have some of the highest technology and architectural functional gains, but it's also the one that most people shy away from due to the potential complexity associated with it.

Lonnie: (16:07)
However, I do recommend it, if you're going to re-architect, to spend time planning. This is a good place to think about domain-driven design patterns, where you can logically align the IT resources with the business bounded context. If you're thinking about doing a re-architect, really think about that, plan it out, spend some time on that on the front-end before you really start going. Now, when you look at this, you have to say, okay, you've presented me several different options to move legacy into a modern system. Well, which one is the best process?

Lonnie: (16:41)
Well, you know what? That's something you're going to have to decide. You have to think about, how long are you going to keep your systems? How long will the business even need the system? How much does it cost? Do I lose a competitive advantage if I don't change? But don't be fooled. A lot of people look at the current cost, but failed away the longterm benefits. An outdated system with functionality that's not kept pace with business or digital transformation requirements will not keep pace by simply cleaning up the interface or adding a reporter too. It's like the old saying, if you put lipstick on a pig, it's still a pig. Okay?

Lonnie: (17:18)
Well, that was kind of interesting of different ways to do that. But now we need to talk about ... I know what I need to do, and I know some ways of doing it, but just because I upgrade, won't it just get old again later? One, I'll just be dealing with these problems again, somewhere down the road. If I don't keep an eye on it and keep fixing it, then I'm going to have these problems, just like the example that I showed with training the dog. If you don't constantly work with that dog, that dog can start to cause problems. You've got to remain consistent on that.

Lonnie: (17:55)
In order to prevent legacy from dragging your organization behind, you need to adopt a continuous delivery methodology that requires a continuous modernization. Now, I want to go back to some of these numbers that we talked about before a little bit. In the federal agencies, there's some really interesting facts that have just recently come out. In a recent survey, 91% of federal agencies say they feel that digital transformation is essential to offering a seamless citizen experience. I'm sure that you've seen the same type of thing.

Lonnie: (18:32)
However, the flip side of that says, 83% say that agencies digital transformation strategies are not adapting fast enough to keep pace with the rapidly evolving environments. Basically, what these types of numbers tell us is that, everybody knows they've got a problem, but they're struggling with being able to keep up with the problem. As new features are introduced in, by the time they get in, they're already old and they may not necessarily be meeting the need. How do you fix it? Where do you start with this? Well, what you have to do is you have to adopt what we call a continuous modernization mindset.

Lonnie: (19:09)
What that is, it's the culture, it's the process, and it's the tools that are used to develop your product in a continually evolving manner. Just like the example of the dog I gave you, you keep training and you keep working with your systems. Now, many of you are really familiar with probably the DevOps cycle. It's gained a lot of popularity over the years. It's very well accepted. It's very well-practiced. So, we understand that just moving to the cloud is not the finish line. Just by moving into AWS, you're not necessarily fixing the problems that you have, and so what you need to do is you need to develop methodologies and processes that allow for your systems to continually evolve.

Lonnie: (19:57)
A lot of people, they look toward DevOps to bring more modern practices to their systems. All DevOps is, it's just a set of practices that aim combined software development and IT operations. However, it does also bring several other features to the mix, and these include shortening the development life cycle and providing what we call continuous delivery. Let's look at it a little bit more practical here. Now, when we look at a modern pipeline, a modern delivery pipeline, basically there's two cycles, two primary cycles to it. One is what we call the delivery pipeline and the other one is the feedback loop.

Lonnie: (20:38)
Within the delivery pipeline, we have build, and test, and release as our primary objectives. Then, in our feedback loop, our primary objectives are planning and monitoring. Now, in that delivery pipeline, like we talked about, build, test, release, and these are the critical features, especially in DevOps. You will see that there are many features, there's many tools out there, there's many people that talk very heavily about the build, test, release cycle. However, what we continue to see is a failure at the plan and monitor in the feedback loop. This is where we see people that are struggling to be able to continue to modernize and keep their systems up and running.

Lonnie: (21:21)
First of all, let's take a little bit of a dive into the delivery pipeline. Now, once again, build, test, release, those are the primary things you need to keep focused on. Fortunately, for us, AWS provides a lot of tools available to encourage us to use DevOps to help us through those particular processes. So, AWS provides things like elastic container services for Docker, AWS Config for policy as a code. We have cloud formation for infrastructure. We have Lambda, which is very, very popular around serverless compute. Systems Manager around configuration management. There's CodeCommit around Git Hosting, and Elastic Beanstalk, especially around web app management. There's a few features or a few tools that really, really bring out the ability for us to build those particular pipelines.

Lonnie: (22:16)
The first one that you should be well aware of is AWS CodeStar. Now, CodeStar enables you to quickly develop and build and deliver applications on AWS, and it provides a unified user interface. It enables you to easily manage your software development activities in one place, and you can set up your entire continuous delivery tool chain in just minutes, and it allows you to start releasing code faster. This is a very, very useful tool, especially for people that are just starting to get their stuff moved to the cloud and just starting to use continuous modernization. CodeBuild is really a wonderful one. It's a fully managed build service and it compiles the source code, it'll run test. It produces software packages that are absolutely ready to deploy.

Lonnie: (23:06)
You don't need to provision or manage or scale your own build servers. Code builds skills continuously and processes multiple builds concurrently. So, your builds are not left, just sitting there waiting in a queue. Once again, another one to take a peak at. CodeDeploy, when we talk about automated code deployment, especially when we're talking about continuous integration and continuous deployment, those types of things, CodeDeploy allows us to automate code deployments in any instance, including the EC2 instances and on-prem servers. It makes it a lot easier for you to rapidly release new features.

Lonnie: (23:43)
It helps you avoid downtime during application deployment, and it handles the complexity of updating all your applications. CodePipeline, it's a continuous integration, continuous delivery service for fast, reliable application and infrastructure updates. Code pipeline builds tests, deploys your code every time, and it's based on release process models that you can actually define. It enables you to rapidly and reliably deliver those features and those updates. These basic tools really, really are going to be foundational for you in your original deployments of those build cycles, of actually getting your software or your product ultimately to your customer, to who needs to use those particular services that you're offering.

Lonnie: (24:34)
Like we talked about before, there's an often overlooked one, and that is that feedback loop. The feedback loop is extremely critical, and we need to make sure that when we're planning out our systems, that we have a good continuous feedback loop. Now, once again, AWS offers lots of really good tools that we can use in this space. Monitoring tools, for example, cloud and network monitoring. We have CloudWatch available to us. Distributed tracing for those of you that have used x-ray, and then of course, most people understand CloudTrail around activity and API monitoring. These types of things are really, really useful.

Lonnie: (25:16)
Just recently, on March 2021 of this year, AWS has released the DevOps monitoring dashboard. This particular solution automates the processes for monitoring and visualizing CI/CD metrics. It gives the ability to track and measure the activities of the development teams. It allows leaders to measure the impact of their DevOps initiatives, and it makes data-driven decisions to drive continuous improvement. This is going to be really well accepted and really well adopted by the dev ops community, because it's going to give them a visual of what they are actually able to do and see, and moving through the DevOps cycles. Here are some examples of those metrics that are available now.

Lonnie: (26:08)
Code change volume metrics, mean time to recover metrics, change failure rate metrics, deployment metrics. For example, the code change volume metrics, they indicate the code change frequency, so developers and source code control. Such as like what we see in code demand, so you can monitor that now. These metrics will give dev ops leaders a better visibility in the coding activities of the development teams. They can answer questions such as, who made the most number of code changes and what repositories are the most active over time?

Lonnie: (26:43)
Another one is the meantime to recover metrics. Those present outage metrics and the average time it takes to restore a service from a failed state. They help leaders correlate change activity to system stability and track problematic applications and identify opportunities to improve the stability of applications. That change failure rate metrics, those indicate how often deployment failures occur for an application, and they can help track the code quality of their development teams and drive improvements from there. Then, of course, those development metrics, they just present data about the application deployment such as deployment state, whether it failed or not.

Lonnie: (27:23)
All of these together are going to give an incredible dashboard that we haven't been able to see before without creating a lot of things on our own. So, there's a huge, huge benefit, and we can see all the new features of how AWS just continues to supply new features into the DevOps cycle. Now, we went through all that to get to where we're at right now, because the thing that I have to stress, that I have to just re-edify and just drive home is the plan. I've saved the best for last. The plan is the heart of continuous modernization. And you know what? It obviously should be. Let's be honest here, the tools are actually easy. AWS and other partners provide a vast array of technologies that can allow organizations to build, deploy, and monitor new solutions.

Lonnie: (28:22)
But there is another part of all this, and that is the planning. Planning is critical, because if you don't have good plans in place, you're not going to be able to implement those tools and you're not going to be able to do successful deployment, and what's going to happen is you're going to end up in exactly the same vicious cycle that you are already with your legacy. Let's talk a little bit about the planning responsibility. Who's responsible for this planning? Well, the first thing I have to say is, hey, we're all in this together. We all have to learn to rely on one another. The business has to learn to rely on the technology department. The technology department has to learn to rely on the business. This is the same vicious cycle that we have been in for years. We have to learn to reassess, reassess the systems together.

Lonnie: (29:14)
The business needs to tell the IT department what works and what doesn't work. IT needs to be able to tell the business what works and what doesn't work, and then guess what we do? We'd redo it over and over and over again. Planning is something that is, it can be very task oriented, but it's also very much a cultural change. For way too long, there has been a lot of separation between the business and between IT. We need to allow the people who know what they're doing to do what they do. That's pretty obvious. IT people know IT, business knows business. So, the business needs to be able to present the business case to IT, and IT needs to be able to present the technology business, and they need to be able to work in conjunction with each other.

Lonnie: (30:05)
We're not on separate sides of the fence. We're together on this, and in the planning phase is where we come together and where we learn to work together to be able to deliver the best product possible. Now, the technology is only as good as the plan. There's still products that have to be evaluated each time they come out and so there needs to be a new plan developed each time. When we release, let's say we release an application, we have to take a look at it and say, okay, where is the application at right now? Is it still in heavy development or is it in conversion, or is it in maybe a multi-stage release?

Lonnie: (30:52)
This information should give, both IT and the business, a snapshot of the current state. Both IT and the business need to worry about, where is the application app? Is it running faster? Does it meet the new need? Does it have new functionality? Where are you out right now? You need to understand the current state when it goes into production, and this needs to be a continuous process. Every single time it's released to production, both IT and business have to come together and assess, what is the state of the application? Is it doing what we want it to do? Is it in process of where we want it to be? And is it growing up to be the application we want it to be?

Lonnie: (31:34)
Now, in the past, many have planned really big upfront designs, and then created work that had this really clear beginning and a really clear ending, and all that. That's the thing of the past. Just get over that. Now, IT and business need to work together and continually improve and refactor the application. Gone are the days of where we have this clearly defined beginning and this clearly defined end. We need to be continuously watching and continuously monitoring the applications over and over and over again. The next thing we need to do is now we have this release, right? So, how does it affect the business? In the past, oftentimes, IT we go, okay, there you go, there's your program, and walk away from it.

Lonnie: (32:18)
Do we really have a new offering? Is it going to be beneficial for the business? Did we miss something? Maybe is the business moving in a different direction? Is it changed since then? Does it match the desired outcome that the business wanted. Application and product owners need to have a strong, interactive relationship with application architects and developers? The user's voice needs to be taken into consideration, and as the next iteration of the application is planned, both the business and the technology teams need to understand, what is the business objective? In the past, business changes often resulted in increased complexity, but now the business needs to work, or improve, or simplify the business. IT can work alongside to improve, and even simplify the product.

Lonnie: (33:09)
No longer should IT work on a project from one project to the next project. Because now the needs of the business are better understood, IT can be part of the process and add more value to the overall organization. The next thing we need to do during these planning phases are we need to define the target. Now we know what was released and we understand the business objectives, but where do we go from here? An application that's not growing is an application that's dying. That doesn't mean that it's growing fat, it means it's growing smart. Growing in a way that benefits the entire organization. A plan means you have a direction, and when that direction is clearly understood by all the parties involved, the plan will produce results.

Lonnie: (33:57)
Now, all parties can focus and agree on the state of the product and all parties can play a part in that target becoming the reality of that. So, we needed to find a target. Assess the application, understand what the business needs and where the business is going and define a target out of every single cycle of planning. Finally, you need to write all that down somewhere. You need to keep up with that, and you need to project beyond just the iteration that you're in. You need to look for the long-term state. What the business wants and needs and what the business wants next, and where do we go from here, we need to plan how to get there. Sometimes we want to do too much in one cycle and sometimes we may want to do something new.

Lonnie: (34:43)
All this has to be considered in where we're going. You need to plan the trip, and the roadmap provides the clear, agreed upon direction for the product itself. These four things are critical in planning out your next iteration. Assess the application, assess that product when it comes out of the cycle, understand where is the business, where is the organization, where is the agency moving in the direction they're going in? And then define that target in front of you and plan the roadmap on how to get there. That roadmap may include several iterations or several cycles or several sprints, whichever way your method of planning is. Then finally, we have to look at now, after we've went through all these particular things, what do we know now?

Lonnie: (35:29)
What did we learn when we went over this? Well, the most important thing that we've really learned is that modern practices are not restricted to technology-related departments. Modern practices are not restricted to business-related departments. Digital transformation requires the entire business. It requires a continuous app modernization that requires the entire business input, and the continuous and app modernization never, ever, ever stops. Above all, keep it obvious. There should have been nothing in this presentation that I presented to you that was not obvious. These are all things that you should recognize in your day-to-day activities, but hopefully, along the way that I gave you, a couple of things to help you in your journey and help you move forward.

Lonnie: (36:17)
Then, obviously, don't be afraid to change the world. You're going to go out there, and there's going to be people that are afraid to move from legacy. There are going to be people that are afraid to make changes. There are going to be people that are afraid to take on the next thing. So, you as a leader in your organization, whether it be business or IT, you have to help hold the hands of people to get there, and sometimes that means that you may not be the most welcomed person to some of the meetings, and so you have to be prepared for that. We have left the world of big projects and we've moved into a world where development and cycles never actually ever end. So, those modern applications require for a continuous modernization methodology. With that said, I'll take any questions if we have any questions. No questions?

Natalie: (37:26)
I think we have a couple of questions. Let me pull up the Q&A right here. (silence).

Natalie: (38:13)
All right. Our first question is COVID forced the business world into more of a remote work model, but government agencies have been a slow adopter. How do you address this in modernization?

Lonnie: (38:25)
Okay. Well, that's a good question. Well, first of all, the pandemic was basically a wake-up call for a lot of agencies. I think we can all agree on that. A lot of agencies and a lot of organizations have become really painfully aware of systems that have been running since Y2K. In some cases, we've seen systems that were built as far back as the '90s. Historically, these systems have just basically been status quo. They got to put them in a corner and they keep running, but the pandemic actually changed all that. Consumers of those outputs and those systems, they went home and they couldn't get the information that they needed in the same way, and so that became real pain. The pain of having to work with those systems that couldn't meet the demand, it's making leaders now take a new look at these systems.

Lonnie: (39:17)
Also, for those of you very familiar, you've probably been dealing with, there is an incredible heightened security threat in the world today. And many agencies are actually being forced into making the changes also. These legacy systems have ... They have products or they have applications, or they have interfaces that are easily breachable, that are not necessarily well-protected. So, when you send the remote workforce home and you couple that with heightened security, these are two of the primary drivers that's requiring people to look at modernization. I hope that answered that question. Any other ones?

Kelsey Cook: (40:32)
Here's another question. What are some of critical modernization projects federal agencies should be considering right now?

Lonnie: (40:43)
Oh, okay. This is a really good one. I'm sure that most of you agree that funding's probably the most critical aspect, right? No funding, no upgrades. Now, beyond that, most leaders are really looking at cultural changes being an issue. We've got long-term staff, they're probably used to older systems. So, we're seeing a lot of cultural changes in that area needing to come to play. Training the tech, just like the technology is moving really quickly, we need to figure out ways that we're continually training or providing instruction to the people that are doing that. Then coordination. We need to induce coordination between all parties that are involved in collaborating with all those particular parties involved. There's also a huge amount of effort that's beginning to take place around coordination with the private sectors.

Lonnie: (41:43)
Those technologies that are coming out of the private sectors, especially in AI and ML are really driving changes in the way that we are looking at technology and leveraging some of those new technologies. For any of you that have been watching the rapid change of pace around AI and the things that people are using them for, that's one of the areas that should be focused on. What should leaders do? Well, I think, first of all, leaders need to start addressing the need for change in their organization. At the same time, leaders also have to be able to change their own departments. I think those are two, probably the most critical things they need to do.

Natalie: (42:25)
Our next-

Kelsey Cook: (42:35)
Oh, sorry, go ahead, Natalie.

Natalie: (42:38)
Our next question is, what's the next big challenge for organizations and businesses?

Lonnie: (42:43)
Oh, okay. The next big challenge is the same old challenge, security. But security looks really different now. It looks really different than it did 10 years ago. We just didn't talk about the machine learning and artificial intelligence. They have dramatically changed the playing field. Beyond that, that there's lots of other advances in those particular fields that are really gaining traction, but think about it this way. If you're having attack that is being presented from an artificial intelligence, it's very difficult. You can't physically keep up with it, so you've got to be able to respond to it. A lot of cybersecurity organizations are really trying to get a handle on where those different attacks are coming from.

Lonnie: (43:34)
As far as new technologies, there's a couple of things that we're really going to start to see increasing, especially in the governmental spaces, both state and local governments. You're really going to start to see things like, believe it or not, digital twins. It's gaining a lot of popularity. To be able to replicate something in a digital environment is a whole lot cheaper than being able to replicate that in a physical environment. I'm seeing it, we have a lot of conversation going on today around infrastructure and infrastructure development, and so I'm seeing the combination of, not only AI, but digital twins also in infrastructure road development, bridge evaluation, those types of things. We're starting to see that.

Lonnie: (44:21)
Digital twins are going to play a big role over the next five to 10 years. Then of course, and I'm sure everybody's well familiar with cryptocurrency. The things that we're learning about digital ledgers that are coming out of that are going to be very important. Healthcare is rapidly beginning to embrace digital ledgers that allow for lateral movement and sharing of records across all industries, and so that's going to be another area that we see a lot of emphasis. Those big changes are going to be really impactful just like some of the numbers that we've presented. Organizations need to be able to collaborate and share data between it. If you have systems that are locked up in the old legacy that are unable to exchange that type of data, they're not going to be useful, and eventually, they won't even be able to to provide the needed data or the needed information that's required to move forward.

Kelsey Cook: (45:26)
Thanks Lonnie for that answer. Our next question is, with technology rapidly changing, how can organizations make sure that a new initiative isn't already outdated by the time of completion?

Lonnie: (45:40)
That's an interesting question because when we accept the technologies released, when we release the technology, it actually immediately becomes legacy. Okay? We need to stop thinking about outdated and dated, and start thinking about growing. That's what we really need to do. Continuous modernization takes that into consideration. Instead of looking at a system and saying a system is old, we need to shift and start saying a system is growing. Technology, as fast as it's changing and all these new initiatives that are coming out, now we've got to get into the mindset of continually growing the application. If you're not there yet, if you're not at the point, a lot of people get really nervous about CI/CD and those types of things, and they say, I'm just not there yet.

Lonnie: (46:36)
Well, once again, we encourage an iterative approach, not just jump in with both feet in. That means some smaller changes in getting people used to it. Some of those things are, if you're still locked in an old waterfall methodology of project management, you can still tailor some of those things. Some of those things can be tailored with just more frequent communication and understanding, whenever you finish a project, that you immediately bring it all the way back to the beginning and start a project over again. Anything that's being released is ... The incident that it is released is dated. We just have to get that mindset.

Lonnie: (47:19)
If we begin to approach it from an aspect that, when we release it, it just continues in that never ending cycle, we're moving it from now being available for our clients back into planning, we'll get over that concept of bogging us down in archaic systems.

Kelsey Cook: (47:42)
Thank you for answering that one as well. The next question is, so you talked about planning being a key area. What are some tools and practices we can start implementing now?

Lonnie: (47:57)
Okay. There's a lot of tools out there. The first thing we have to realize is that there's really no one-stop shop. The first things that organizations can do is evaluate, what do they have right now? A lot of vendors have been modernizing their tool suites, because these demands aren't necessarily new. They've known they're coming and so they've been adapting. And if you don't have specific tools, and obviously since we're talking about AWS, I would encourage you, because AWS actually has like a lot of tools. We just barely began to scratch the surface of the things that are available. But once again, I encourage you to start out small. Don't try to implement everything in one shot, because you're just going to get frustrated and overwhelmed. You need to evaluate, where is your biggest pain points?

Lonnie: (48:47)
That's one of the things that we do when we come alongside organizations that bring us in, is we'll do an evaluation from top to bottom, understand where they're currently at, understand what their processes are, understand what their culture is, and then we'll begin to look at, what are the small changes that we can make to get you from point A to point B. To go back to your question, you're looking at tools and practices. I highly encourage you to evaluate the AWS suite, because not only are they core component, they're well equipped to continue running. It's not like you start out with AWS and get rid of it later. These will just continue moving along with you because the AWS is continuing to put the work and the technology and the effort into maintaining and keeping those tools.

Lonnie: (49:35)
And there's a lot of people using these tools too. That makes it really good too, because there's lots of user groups and lots of people you can collaborate with. Historically, in the past, when there were a lot of grassroots organizations that sprung up around open source products or things that weren't necessarily broadly accepted, and I have to say that, in most of the cases that I've seen with AWS tools, they're well-accepted, they have a large consumer basis, and they're well vetted. So, I would say, if you want to start, the first place I'd tell you to start is, is become well aware of the tools that are available to you.

Kelsey Cook: (50:18)
Awesome. Thank you for sharing that. Last question I have for you is realistically, what timeline should we be considering for replacing legacy solutions.

Lonnie: (50:30)
Okay. Yeah, You're going to have to address it now. I mean, we talked a little bit about that in the past. Legacy is staring you in the face right now. I'm amazed by how many systems are still in place. Don't feel bad if you're running systems in place. Like we said, a lot of times you have budget restraints, but the reality of it is, is we're going through another shift in the workforce. More people are heading into retirement that have been maintaining these systems, and the demand on these systems are new. We're seeing new breaches in security, we're seeing new development methodologies, and quite frankly, we're seeing a huge demand from the consumer.

Lonnie: (51:13)
The consumer has moved to a mobile workforce. That ability to produce mobile applications or mobile technologies on systems that were designed for the '90s, those systems were never designed for mobile methodologies. So, your question of when realistically, when should you be considering? Now. Now is absolutely the time you should be considering it. Whether you're considering that on your own or whether you're considering it with an organization like us, you need to be developing roadmaps and plans and going into that planning phase. If you've never introduced a DevOps cycle into your organization and this is the first time you've ever done this, and you say, okay when I look at the DevOps cycle, it's this infinity, it's this never ending.

Lonnie: (52:01)
It goes around, around, around, so where do I start at? Your starting point is the planning, okay? That's where you start, and that's what we were covering today. You start with that, building the culture and the relationships between the people that are driving the business aspects and the people that are driving the IT, and you begin to come together and say, okay, here are the things that we want to do as an organization. And then here are the things where technology's at that allow for us to do that, and develop a really good plan. And you develop that across multiple iterations and you focus on a target, and you shoot for that particular target.

Lonnie: (52:36)
Whenever you reach that target, when you set a very clear milestone, when you understand when you have succeeded, and I think that's very important too, is you have to identify success along the way, because we live in a world where we want to say, hey, we've done what we've set out to do, and so we need to set those particular milestones in place. When the business begins to see everybody working together and when the organization is saying, hey, we are succeeding and we are delivering those needs and resources to our consumers, then you'll see the success things. When you get off this webinar, you need to start planning your legacy migration.

Kelsey Cook: (53:20)
Thank you so much, Lonnie. I'd also like to thank all of our participants for joining us today, as well as Lonnie for presenting and answering all of our questions. We hope our podcast has been helpful for you and your organization. Again, this webcast was recorded and a copy of the presentation will be emailed to you. I'll go ahead, and Lonnie, if you would like to stop sharing your screen, and I will put up our contact info, so if anyone has further questions, they can feel free to reach out. They can feel free to reach out to Serena and contact the AWS team at Carahsoft. Our contact info, as I said, is displayed. So, please don't hesitate to call or email us. Thank you everyone again and have a great day.

Lonnie: (54:12)
Thank you.