CIOs say that 80% of developers’ time is spent on the operations and maintenance of applications. Only 20% of their time is spent on innovation.
This loss of time obviously impacts the business. Consider lost revenue due to missed opportunities, lost productivity in team members, and compliance challenges. Your development team may be spending much more time on their release cycles than they need to. And these operational inefficiencies often end up costing your business more in overhead costs.
In early April 2023, we co-hosted a webinar with AWS to tackle the challenges of outdated, legacy software and how to take your initial steps in modernizing them.
A few key takeaways:
- Migration and modernization are not the same thing.
- Modernization is a journey, not a project. There is no start or end date.
- Consider the 7 “R’s” as a starting point and strategy.
- Always operate within AWS’ Well-Architected Framework.
We shared several of our best practices for application modernization, built through the experience of 400 client engagements in just five years.
Check out our recording of the webinar below to get the full details. If you have any questions or would like to start a modernization journey with our team of experienced cloud architects, contact us to start the conversation
Learn how modernizing your applications or migrating to the cloud can help you stay ahead of the curve in today’s ever-evolving technological landscape. In this webinar recap, cloud experts from Soliant Consulting and AWS discuss how an iterative approach to modernization can enable your business to innovate, grow, and increase resilience.
Speakers: Dean Bryda, Application Modernization Development Specialist from AWS & Adam Russ, Associate Cloud Practice Lead, from Soliant Consulting
Explore the benefits of app modernization and cloud migration and how to approach them in a way that aligns with your business objectives.
Claudia Hritcu, Senior Partner Development Specialist, AWS (00:2):
Hello everyone, and thank you for joining. We have an informative and engaging session all about modernization for you today. Our speakers from both Soliant Consulting and AWS will share their insights and expertise on how modernizing your existing applications can help your business not only innovate, but also grow and become more resilient.
Joining us today to provide practical advice on the journey to the cloud and its benefits is Adam Russ, a cloud practice lead from Soliant Consulting and Dean Bryda, Application Modernization Senior Partner development specialist with AWS. If you have any questions during the presentation, please feel free to enter them in the chat, and we will try to get to as many as we can. We will also be asking poll questions throughout the presentation and ask that you please answer them. With that said, I’ll stop here and pass it over to Dean and Adam to formally introduce themselves.
Adam Russ, Associate Cloud Practice Lead, Soliant Consulting (00:55):
Thanks, Claudia. Just wanted to say a quick thank you for to everyone for joining us here today and welcome, and I’m looking forward to what Dean has to present. And, again, just thank you for being here with us. We’re glad you’re here.
Dean Bryda, Application Modernization Development Specialist, AWS (01:10):
Thanks, Adam. Hi everybody. My name’s Dean Bryda with AWS. Thank you, Claudia, for the great introduction. We have a few slides we’re going to cover today. Hopefully not too many. We’ll keep it very interactive and again, as Claudia said, please post your questions. So that’s the most important thing that we can do, right? We’re here to make sure that we answer your questions for you, provide some insights, but more importantly, answer some inquisitive questions that you have. So, with that said, we’re going to get started
From an agenda standpoint. Well, we already got the first one done, so I guess we’re off to a good roll, right? We’re going to review really why modernization and migration is important, not important to our customers, but also to our partners. We’re going to talk about the pillars of modernization and building a strategy. We’ll talk about how once that strategy is in place, how we’ll scale that across the organization. T
hen Adam’s going to provide some insights on Soliant’s success and the things that they do from a partner perspective. So just to make sure that everybody’s interactive and that we don’t have a lot of robots attending this one, we’re going to start right off with a poll question. May seem a little, a little weird, but we’re going to start right off with a poll question. So would you mind teeing that up for us?
You got it. So the question we have here is, are you attending this session because you have identified a need for application modernization at your organization? We’ll leave it open for about 30 seconds for folks to respond.
So it looks like everybody’s awake or their robots are working pretty furiously. We have a lot of answers coming in, so appreciate that.
Give it about 10 more seconds.
All right. Thanks everyone for answering.
Excellent. Thank you. So it looks like we almost have a 50-50 type response on that question. It’s a lot of folks are here because they have a lot of modernization and migration types of initiatives happening.
So really I love starting with a question of why, right? So why are we here in the first place? As Amazonians, we’re taught through our culture to always ask the question why and peel back to onion as much as we can with our customers. So as part of that process, what we try to do is uncover different types of issues and challenges our customers are having. And of course, our goal is to build great solutions that address those different types of challenges that they’re having. So why not ask the question why when we start this conversation around migration and modernization.
So based upon the different types of hundreds and thousands of different types of customers that we talk to, really it comes down to a common thread across the board. The majority of the time spent by our customers really is about operations and maintenance of their IT systems and clearly on enough time on innovation. And we all know that innovation as the value add and your core competency as a business owner to be able to make those strides and make those advancements in your area where you don’t want to be spending your time is on IT systems, maintaining and, and keeping them up to speed.
So what are some of those type different types of characteristics and issues? So why, what are we spending so much time on, right? Why is modernization important to me? Well, if, if you, if you need to put them in a couple discrete characteristics, the easy way to look at is from a point of view that says, if I’m spending that much time not innovating, not spending that much time on the core competency of my business, what am I spending my time on? Well, I’m spending a lot of time on probably IT, infrastructure maintenance, long release cycles, trying to roll out new products, new releases.
What does that really mean from a business standpoint? That really means that I’m losing revenue, I’m losing my flexibility to be agile, to bring new markets to bear, to new services and features to bear to my customers, which really means I’m losing and I’m degrading my competitive edge.
I have over my competition, right? So as we, as all business owners are always looking over their shoulder and making sure their competition is staying far, far but near, so we understand what they’re doing, there’s always that competitive edge that we want to keep. The second point really is about where are we spending our time when it comes to lost productivity? Again, if my good people are spending more time on the IT side of the house and having to maintain these different types of infrastructure, what’s that doing from not only from a resource standpoint, resource allocation, but also from a cost perspective.
And what type of skill sets do I need to maintain to be able to carry that burden, that IT infrastructure or application maintenance to be able to provide those services that I need to keep my business up and running? And the third one really is about what’s critical to all of us, right?
I really don’t have to explain security, but the inability to support change compliancy and security regulations. And it doesn’t mean that you have to be in an industry that has security and regulation compliancy to it. All industries, all companies, all businesses have to think about security as the number one priority nowadays. And nobody wants to be on the, on the, on the news the next morning. So, very large concern for, the majority of our customers. Almost all our customers bring up security as where they’re spending their dollars and where they want to see the biggest advantages in, in positioning for modernization in their environment.
So again, what do we need to do from a customer perse perspective? Well, we, we want to be able to provide that agility and innovation to be able to deliver value to our customers. Again, success is based upon what we’re delivering to our customers, not based upon how shiny our computer systems are or how good our applications are.
So we want to make sure we get to market faster. And we do that through having the right automation, the right systems in place to be able to do that. Of course, it is part of our business, but it’s not the only spending business unit within our business. We want to lower the total cost of what it takes to maintain and to be able to deliver these services that are required high performance and scalability. A very interesting point with that characteristic is most people think about performance to scalability as in to build out, right?
We always hear the stories about the day of super Bowl Sunday and how we need to grow our business because of that da that model, and be flexible and be able to shrink back down. What most folks don’t think about is really the flexibility to shrink. And right now seeing that we’re all sort of going through an economic downturn right now and people are really cost conscious, would it be nice if we had the IT infrastructure in place that we give us the opportunity not only to grow as we need to, but also the shrink as we need to.
Providing that performance of when we need it, and also that scalability when we need it, but actually make it elastic so we can move back and forth in the last one. Again, security by design security is day zero for us. We look at it from everywhere from the developer writing this code all the way through to the application residing out in the environment.
So a common question we hear from customers is, well, if this is all important, what does success really look like? How do we kind of benchmark ourselves? And really, there is no golden rule of how you benchmark yourself. You really have to look at your own environment and everyone’s a little bit different. But if I had to look at different characteristics of what you should be looking at in your environment as quick hits and things you should be looking at first.
Well, the first thing is always how fast can I go to market and what does that mean to me? Well, fast the market is not just simply how do we release applications and services to my customers as quick as possible, but it also means what is the complete cycle that I need to do internally before I can release that service to my customers?
Usually that complete cycle involves multiple different types of environments, multiple different types of developer groups and multiple different types of systems. To be able to provision that, provision that infrastructure to get those developers ready so they’re actually productive on day one, providing the, the software that not only can we deploy it very quickly, but also we can incrementally update it as needed, that we can look at the security boundaries of it and understand it all the time and understand what, understand what the security boundary is and understand what the governance roles are on that.
Then once that service is out in the environment, what does it look like? We all know things change and it’s, it’s not going to be the same as it was on day one. So what’s their observability standpoint of that application and how do I measure that and how does, how do I actually do that?
And then the last one, it really talks about what is the, what does the organizational look like? What are the standards? What does the tooling look like? Do I have a consistent process? Does my organization adopt cloud native technologies or am I still working in that legacy type of mode where everything is either start and stop and start and stop. Looking across a customer’s environment, if I can look at those different types of categories and make some judgment calls of where I think they are, we feel these are the ones that you should be looking at and really benchmark yourself against how far are you down the modernization path and where you want to be on, on your modernization path.
So getting back to the why, right? Why is this important to me? And what we talked about, a lot of the things that maybe are a little difficult to measure, quite honestly. I mean, of course we can measure capital costs pretty quickly and a lot of people do that very quickly when they have the move to cloud type initiative. But how do I measure all this agility stuff and how do I measure cost of downtime and loss of productivity and hiring skill sets and things like that? Well, we have, there’s industry leaders, our analysts that provide different types of benchmarks and they’ve really looked at modernization in a good light. So what’s really compelling, and forget about the percentages and stats a little bit, but look at them from a proportion standpoint. Because we know every analyst may have a different angle.
And you yourself, if you look at a total cost of ownership model, you may have your own ideas of how you actually measure that. But if I’m looking at this, I’m looking at proportionally that I’m knowing that I’m decreasing drastically my incidents per year. I’m deploying much faster and I have a nine month payback.
Now I can argue maybe in is not nine months, maybe it’s 12 or maybe it’s even shorter than that. But what we’re finding out is across not only our experience, but also across our analyst experience that when people modernize, and we’ll talk about the difference between migration and modernization or how the, those terms are being used, but when you truly modernize that cloud-native culture that you’re implementing has a very quick payback and a lot of projects that you do within it. We all know that sometimes that payback is not in nine months or definitely not in the first year.
Now we get to the good stuff, right? Migration and modernization is that a lot of people use it as the same term. I know sometimes in every conversa most of the time in some type of conversation, somebody throws out the word migration modernization and you’ve really got think about it for a second and go, what do they mean by that? It, they’re not used synonymously across the board, not at least in our AWS conversations. We really think they’re two really discrete different types of functions.
And although they’re unique discreet functions, they can be put together. so we’re not saying that there’s not a purpose for both of those, but let’s first of all understand that your, your journey or your path to modernization is a complete cloud adoption journey. Very similar to how customers in the past have adopted cloud and they say they went through a full cloud adoption application modernization actually is a part of that cloud adoption journey.
If you look all the way to the left and we start looking at different types of application portfolios, we have of course our legacy applications, regardless of how they’re built, that their pure monolith sitting on virtual machines or maybe have some on-premise container type of legacy applications, whatever it may be, moving to cloud as incremental provides incremental value.
In our words, a migration is a lift and shift, it’s a rehost, it’s a re-platform type of activity. When you go through that, you’re gaining incremental value. Your level of effort went up a little bit because it takes an activity to get to cloud. It doesn’t happen, you know, overnight doesn’t happen with a click. But at the same point, your business value went up, right? So you may have gotten away from having to manage virtual machines or manage the infrastructure as the physical infrastructure, and you moved it over to AWS and it’s sitting on EC two today, which is great.
So you leverage cloud to reduce some of the overhead and burden. But at the same point, what was the value of business that you gained from that step? Well, there was business value, but the level of business value increases as you modernize. And to us, you look at the application portfolio, you understand the application, you make good decisions, and it’s not a migration step and then a modernization step to cloud native.
It is a journey that you make individual decisions based upon the application portfolio that you have; you make that decision if it’s going to be a migration or a modernization, people will tell you, your partners will tell you. if you experienced this in the past, I’m sure a best practice that you took away from your project, I know we’ve seen a lot of these is reflecting back at the end of a project, most customers will say, we should have taken the time to do the modernization as a single step rather than going through now that we have a bunch of applications that we simply picked them up and moved them to cloud. Now we have to try to go through the integration process.
What we learned is that our customers learn very quickly that you can’t really extend to the ecosystem of systems that and services that we provide that really provide that upper business value that people are looking for. You know, once you get past the initial cost savings of moving to cloud, what’s expected is you’re going to start leveraging the power of integrated services and you’re going to start leveraging the power of cloud native services. It’s very difficult to do that if you simply just took something and moved it over to cloud.
What we find out is the best practices, and people refer to as they should have taken a time when they had budget, when they had people, when they had a time window to do it, to be able to actually modernize an application, put it where it should be, and you can modernize a and there’s different ways to do that as we see, if we move from left to right, again, the level of effort goes up, but the business value goes up.
So as you take that application and maybe refactor, take pieces of it, integrate it into the cloud, integrate it into the ecosystem of services that we have, or maybe do the complete rewrite, although again, that level of effort goes up, that business value exponentially goes up with it. And what does decrease, which is good news. Nobody ever likes to hear decrease unless it’s usually it’s money. But, what does decrease is the operational responsibility to the customer, right? So as you move more cloud native, the heavy lifting, the overhead disappears. We take on that responsibility and hopefully you’ll see that what you gain is the agility and innovation side of the house.
We talked about what the analysts have done in the past and we talked about how it’s a little difficult to be able to measure things when it doesn’t come to say, sweating legacy costs or looking at capital costs, right? Something that’s easy that a bookkeeper can do, it’s hard to really measure productivity, right? It’s hard to really measure business agility. Well, we can measure somewhat when it comes to downtime, how much downtime would cost a business, but that’s sometimes it’s hard to do too. But we have ways to do that. We have calculators to do that and methodologies to follow. Soliant has methodologies to follow. You really need to take a look at it because especially now in these times; what we hear form the majority of all our customers right now is, How can I justify a project to my management?”
I can justify it as long as I show what the value is to the business, and it needs to be tangible value. It’s easy to say, I’m going to save a percentage off the bottom line. It’s harder to say I’m going to save a percentage of agility or innovation. But we have ways that we can demonstrate through a business model. Obviously today is not the day to talk about complete business models, but we have ways that we can walk you through it. We can help you justify what a modernization project really means and how you can bring that to management and what the real value add is.
So what we’re talking about here is not a lot of smoke and mirrors. We do have how we progress from left to right, as you can see very simply from the slide; it’s that boomerang action that we’re really interested in, right? As we go from left to right, as we go from the standard lift and shift, and we go from simply taking workloads and moving them to someplace different. When we start modernizing using cloud native technologies, we start gaining all those efficiencies that we love to see, which is around agility, innovation, and reducing cost.
All right, that gives me a chance to take a sip of water. Why don’t we have another poll?
Our second poll question is, which of these drivers are most important to your business? We’ll give everyone about 30 to 45 seconds to respond. All right, thanks everyone.
And the drum roll is replacing legacy infrastructure. Business agility ranks very high. That’s great. What’s surprising is cost optimization is a little bit lower than expected. A lot of times you hear a lot of people just talk about cost optimization as a reason why. So it’s good to know that there’s a lot of value add and people recognize the value add of modernization outside of just cost.
All righty, so let’s talk about the pillars of modernization. So now we get into a lot of the fun stuff, right? So a lot of people ask, well that’s great you talked about modernization and why we should do it. But actually how do we do it? It’s because it really is cultural. This whole modernization, like any transformation project that you go through, they’re not easy to do. but we think there’s a coup, there’s three key pillars that you should be looking at, and it really comes down to the basics. It comes down to people, it comes down the process in automation, and it comes down to technology. Let’s dive right into it, and let’s talk about people.
Some say the people part of modernization is the hardest part, and most have gone through any type of very large organizational structure change. So you can relate to that comment. Our experience is, is that if you look at cloud native cultures and trying to change it in a customer’s environment, you really need to start at the organizational level. And we’ll dig a little bit deeper into the organizational level, but very simply, if the way to look at it is the way you’re organized is usually the way that people work. So that could be a good and a bad thing.
Historically, very large organizations, the ones with the really large umbrellas, they start out and expand very wide to a point that you can’t even see everybody on one page of a slide deck, right? That org chart is so wide, it takes two slides. Those type of structures work pretty hard when it comes to cloud native.
And only the reason is that they’re usually structured around very specific stove pipe type of activities and not functional activities. As we know in it, now that the functional structure is the most important part. If our organization structure is geared around a certain business unit, such as, well, I’m not going to throw out any names, but say it’s business unit type specific structures, it’s very hard for those business units to work with other business units. So therefore you kind of lose that functional type of structure and the way to work. And so what we see is if you’re organized in a legacy environment, it’s very hard to move to cloud native. And so we have a suggestion on how to kind of change that organizational structure, even though you don’t have to go through a full reorganization on that.
But if you think of it as if you are more aligned to a functional standpoint, you’re probably asking, “Why aren’t we talking about microservices now? I just thought we were just talking about people a second ago.” Well, they’re kind of related in a way, if you look at it conceptually, right? For the folks who love to get very granular in technical, they know what microservices are.
A microservice is one of the key components of modernization, and they serve a purpose. Microservice are pretty much the smallest element of functionality in theory, right? Of reusable functionality that you can have that they’re loosely coupled together, they work together, but they’re loosely coupled and they work independently and they provide a lot of great strengths that you don’t get from when you build something that’s all connected in very large in nature. You get the ability to be able to change very quickly, very small units of the application without really taking the application down.
So you can make incremental change very easily. And without all those co-dependencies, you can get a lot of work done. You get a lot of things done. There’s a lot of agility there. So let’s use that same type of logic back in our organizational structure. And the way we look at it, it’s called a two pizza team. And if you read anything about Amazon, you’re probably well aware of what two pizza teams are. But if you haven’t, it’s a pretty easy concept. I love the idea that comes down to pizza, by the way. It’s one of my favorite foods.
But the organization structure of what you’re working on should be really no more people than can feed can be fed by two pizzas. Now, to me that would be two people, because I could eat a full pizza by myself. But if you think about it from a theory standpoint, right?
A large pizza usually feeds between four to five people. If you have two of them, you’re talking about eight to ten people. Twelve you know. I guess the actual number is really not that important, but you, you understand the concept, right? So it’s small decentralized teams very similar to that microservice, right? That microservice works very independently. It’s very small. It’s one of the smallest factors of functionality. That’s how we want to build our teams, make them very nimble.
You know, as the pizza team hasn’t been divided by any type of organizational structure; it’s functional. These people come together, they bring their specific skill sets. We’re minimizing a whole social constraint that we just talked about a second ago. And the autonomy is all about really making decisions, right? This pizza team can make its own decisions; it can move very quickly. That’s the whole concept of the DevOps culture, the whole cloud native culture.
And we work independently; in our case, at least, we work very much in an independent startup type of, philosophy where these pizza teams can pretty do anything they want. Now, we know that that’s probably not going to be true for every single business and may not be true for your business. But if you just use the concept of small, nimble teams that are functionally aligned, not organizationally aligned, I think you’re off to a really good start.
All righty, so let’s move away from the people part of it for a second. Let’s move to something maybe it’s a little bit more easier. And that’s the process side of it. The process side is really easy. Automate, automate, automate, automate. That’s the whole, the whole concept, right? And that’s what we think we bring to cloud for people.
We have a ton of different services that allow us to automate into enable self-service at scale. And you can — I don’t have to read the technologies off to you end for the folks who are very familiar with AWS — you may use almost all these systems, different types of services today.
But across the board, across the lifecycle of the application, there should be different processes that have automation built into them. And we’re going to talk a second about the difference between automation and, guardrails and toll gates and things like that. But basically it’s all about do you have the tools and the processes in place to make sure that you have a streamlined process. Think about the weakest link in any chain. The chain strength is based upon the strength of all the links put together, not just a single one.
So if you have a very weak link in this case, maybe provisioning orchestrates the weak link, and the whole chain, the whole life cycle of that application is going to be weak. And so it’s important to look across the spectrum of everything that you do and understand how you’re resolving each one of those. Or, what is your plan to resolve or automate that process?
Technology is probably the reason why you came in the first place, right? everybody gravitates to the technology side. I love the technology side, but, as we just reviewed, it’s only a piece of the piece of the puzzle. It’s only one of the pillars. But let’s talk about the technology. So the, the famous saying — I’m sure you heard this a thousand times before – “You want to build apps, not infrastructure.” You want to do more with less. You, you want to make the whole developer experience very seamless and transparent.
How do we really do that? Well, there’s a couple different ways that we do that, but it really does start on your application portfolio. If anybody comes in and tells you this is the way you’re going to change your application portfolio across 100% of your apps, of course that’s crazy. Nothing’s a 100%, and nothing even leans to 80%. But what we can tell you is that application portfolio assessments are probably one of the most important things you can do.
As the saying goes, you want to measure three times and cut once. So that saying goes very similar to how you manage apps. You want to assess, assess, assess, and then you want to execute, right? Nothing better than a good plan. And so, and what we find out too is surprising enough, a lot of your applications can be retired or they should have a plan for retirement.
So, it’s not always about migrating or modernizing your applications; it’s really about making good decisions on the application suite that you have, understanding how they’re being used, and understanding what your other alternatives may be, and then what the plan is going to be for that application itself.
We love to think that everything you do will move to serverless to land a serverless, right? The least of the infrastructure overhead that you can have, that’s cloud native, almost utopia, right? But we know that’s not reality for all your application suites. It may make sense to move things in a lift and shift environment. It may make sense to re-platform, say maybe to containers due to the use case that it’s in, where containers is a long term because we know the value of containers and what that does too.
But regardless, there’s the, the common approach to all these really is understanding your application suite, making good decisions and putting together a consistent model across your infrastructure and making that very automated and seamless to your developers.
Here we go. Let AWS do they heavy you lifting; we have a ton of different services. How many? The total number, I don’t know, don’t ask me. There’s a ton of them. I can’t keep up on that type of stuff, but I can tell you that regardless of what the integration is that you’re looking at, whatever use case is, I’m sure we have something that kind of points in that direction to it. I can tell you from the most obvious standpoint when you’re looking at cloud native technologies, as you can see, the diagram clearly shows, you can do more.
And you want to go all the way to the right, to less. Lambda functions is pretty much, hey, your developer writes code, and it executes what happens behind the scene. It’s handled behind the black curtain. Nobody really knows, but the service is executed and run and there’s no infrastructure heavy lift for you to maintain. There’s very little for you to maintain actually when it comes to that. But it, again, across all our different services, it could be from the compute side of the database side or the analytics side. We have a ton of different services that takes that heavy lifting, that burden off you and makes it more cloud native, which makes all your integrations much easier too, if you think about it.
Yes. The next poll question we have is, which AWS service is most critical to your business. We’re going to go ahead and share that now. We’ll give everyone about 30 seconds.
This will be interesting. It’s almost like watching a horse race. You want to go, man, have two out in front. He’s got two lines ahead. Fargate, fargate, Fargate, parge. No lamb’s coming up.
Lambda, Lambda, lambda, Lambda.
We have an upset coming here. The upset is unsure and easy too, maybe. Yeah,
We have “unsure” coming in is the upset of the day.
Thanks to everyone for answering. Appreciate it.
I live up by Saratoga flat track, Saratoga, New York horses. That’s where that humor comes from.
Scaling modernization. So scaling I think is the, I wouldn’t say the most important, but I think it’s the most entertaining. I love when we get to a scaling motion because that means you’ve proved out a lot of different types of tactics and techniques. You have an idea of where you want to move, but you really want to get it to a much bigger emphasis, bigger scale. You want to move it across the enterprise.
So you started small with those little pizza teams and now you’re at a point that you want to make this clear direction open to everybody in the organization. So talking about six steps here, and we could probably add ten more to it, but to make it very simple one, I think one of the most important things you can do, I have some past experience where I’ve actually gone through and went from a brownfield environment, very structured, as I mentioned before, very structural organization.
And I went into a, converted, a complete engineering team, a global engineering team to cloud native. One of the first things that we did, we established a cloud center of excellence. Probably one of the most important things you can do. And I say that only from, a point of view that it allows you to put a structure and put, put a visual entity to what you’re about to do and provide some type of governance and control board. We’ll talk about down the road a little bit when you do scale out what happens to that cloud center of excellence.
But what we are trying to do at this point is you’re trying to get all your stakeholders together, you’re getting all your representation across your organization, and you’re creating a board that you can come to a common level, mindset to setting those standards. Setting those objectives are understanding from all the stakeholders what they’re bringing to the table and what they, what their expected outcomes are.
Quick wins. when you start with any type of transformation, right? Of course you want to tackle the hardest problem that you have in your organization. You probably don’t want to do that though. What you’re looking for is to gain moment gain positivity, gain success. To do that, you want to find yourself something that’s important to everybody, but at the same time, something that’s, that it’s almost, it’s a hundred percent attainable.
You know, if you work hard, you’re going to get it. And you want to be able to get that quick win because you want to be able to turn around and communicate to people why you’re doing this and show your results of how you got that done. You want that quick one to show that quick result. You want to bring in your leadership support, of course, stakeholders and any type of projects, very important, but you want to make sure that your leadership support is bringing their opinions, their, their observations, and what their desired outcomes are.
And that’s being built into your CCOE (Cloud Center of Excellence). So you want to establish that clear vision from your leadership so you know, when you have those quick wins and as you progress down your cloud native journey and you have continuously have good wins, that you’re showing positive results back and your leadership’s there to be able to support you. And when you don’t have a quick win, and when you have a little bump in the road and we like to call those, lessons learned and pivot, when you have those, you still have leadership to support, to support you during that activity. Best practices, there’s a ton of information.
We offer a ton of information from AWS, everything from technology to implementation to reference architectures to reusable, infrastructures, and code templates. We have a ton of stuff. I think we have so much stuff that people don’t understand how much content we actually have, but this is where you can rely on your AWS team, rely on partners that you trust like Soliant.
Partners like Soliant have the expertise; they can show you what it takes to be successful. And they’ve gone through and have seen what isn’t successful. They have gone through some of those bumps in the road, used their lessons learned, used them to, to get through that project. Evangelize communication is key. People will fear cloud native and transformation projects, I should say transformation in general, right? If you’ve been through a transformation project at any scale, you know that it’s change. It’s, it’s scary. People don’t like scary things. They don’t like change. They like things that are very repetitive and common and they feel nurtured. so you need to evangelize and you want to evangelize to a point that you’re showing people, this is a positive thing. Look at the stakeholders we have on board who also feel it’s a positive thing.
Look at our quick wins, the good things that we’re doing. Look how this is benefiting the business. Make it to a point that if they’re not included in your project, that they feel they’re left out of something. So that’s how far you should evangelize. And then the, probably the last one is really, once you have some successes and you’ve created that, that community of cloud nativeness, that culture, think about how you’re going to reorganize in it.
The CCOE is I think a function that should stay around it to some, but a lot of folks have taken it to, you know, maybe we can learn from the first five steps to reapply different organizational structure or maybe the CCOE or some type of entity body should be decentralized and move across the organization. So there’s lots of different ways, but basically reorganize is really look at what you’ve done in the past, evaluate and then pivot if you need to, to be more successful.
And we talked about forming the team a little bit. You really do need to pick the right people, especially when you’re forming a cloud native culture. Don’t pick the person who doesn’t like change, who likes to come in every single day and look at the same screen and check the boxes and go home that night. I’m not trying to stereotype anybody, but we’ve all worked in environments where there’s people that endorse collaboration. They like change, they like things that are moving in a positive direction and they’re not afraid to learn something new.
And then we have other folks who just don’t feel comfortable doing that. Don’t form your team with people who don’t want to do things differently. It’s an obvious thing. But a lot of people include members because maybe they have a skillset that they can’t give by without, or maybe politically they need to include somebody in their team because they’re the right person they should have on it.
Try not to, because what you’ll find out is you want a bunch of positive people with change culture that’s, that’s running through their bloodstream to be able to take your, to make you successful. And so picking the people really is really key and, and important, very similar to how we pick our leadership people too. You want to pick the right leaders who endorse change, who, who have felt some pain points. They feel comfortable that you’re the change agent within the organization. It can make things happen.
Pick the right leaders that are going to move your project forward with you and it’ll support you because not everything’s going to go the right way the first time. And you’re going to need somebody who’s going to support you in the bad times. And with the good times. We already talked about the quick win. Quick wins. I’m not going to talk about too much on those, but avoid the one-offs and the really weird stuff, thinking that you’re just going to get it out of the way. Pick something that you think you really can make a change to that’s important and that you can really communicate and socialize and evangelize out to everybody. And also that you can measure too. Nothing’s really important unless you can measure it.
Iterate, iterate, iterate. I mean that’s a, that’s the agile framework, right? I mean, this is cloud-native, it’s the core culture of what we do. You want to iterate, iterate. And you know, as the saying says too, fail fast, pivot, move forward type of thing. Lessons learn from what you failed, move forward. So, with all those different types of things we have, this goes back to the best practices. We have a ton of best practices that you can follow. So hopefully we will decrease the percentage of times that you fail, but hopefully you will fail because that’s the way you’re going to learn. So fail, quick, pivot, move on. Keep moving forward. Keep your cloud native evangelism moving forward. It’s important.
We already talked about leadership support, how important it’s to pick the right people. Alrighty, I think, the hook is coming out and my time is almost up, and I’m going to hand it over to Adam soon. But if I can ask you to take three things away from the conversation that we had, it’s really about migration and modernization is not the same thing. And it is a journey. It’s not a project, it doesn’t have a start date and an end date. It’s a complete journey. So please treat it like a journey. if you treat it like a journey in the beginning, you’ll be more successful. in think about those three pillars. you may not be able to address all three pillars at the same time. You may have an obstacle with one or two of them, but look at the three pillars.
See how you can address each one of those, and make a plan based upon those. And, you know, and don’t do it alone. We have AWS people. You have AWS, customer account teams that can help you, AWS professional services. We have all the best practices that we publish, and we have great partners. And I’m going to let a great partner speak. I’m teeing Adam up to take you through just a couple more content slides to talk about the good stuff that Sian does and how, you know, you should leverage client.
Thanks a lot, Dean. I wanted to say a big thank you to Dean and Claudia and Maria for making this possible with us and collaborating with us on this. We’re very, excited to be able to work with them and AWS on our journey to the cloud. But before I move forward, I’d like to throw a poll up here real quick in regards to if you all feel this content is helpful or if it’s something that you’d like to see in the future from us. Claudia, if you don’t mind throwing that up there, and then I’ll just keep talking. Folks can answer that and just help us understand whether or not we can focus our efforts and provide valuable feedback like this. Our valuable content is based on your feedback in the future.
So, thank you very much. want to talk to you today in these last remaining minutes that we have about why we feel that Soliant Consulting is uniquely positioned to help our SMB clients achieve some success with cloud migrations and application modernizations. And since 2004, Soliant has been working with a wide spectrum of clients, anywhere from SMB all the way up to enterprise and everywhere in between. but we really feel like SMB is our sweet spot. We know the challenges they face, we’re able to work with them collaboratively to solve problems, and really can understand the challenges that they face because we are an SMB as well. So we, we kind of feel like we understand where they’re coming from and where they’re trying to go. And so we feel like our shared experience between us and our clients really matters.
Also, we feel like, having a legacy background is also extraordinarily valuable when we are working with, with SMBs. So understanding, you know, the legacy of our clients, where they’ve come from, where they’re trying to go, where they’re currently at, and also coupling that with our legacy of our history and the things that we’ve learned along the way, we really feel like that is, is very important and, extremely valuable in our interactions with our clients. With all of the things that we do and the things that we are as a service provider. We’re not a product vendor. I want to make that very clear. We we’re not trying to push any particular product onto our clients. We’re a consulting vendor that has a plethora of technologies that’s available to us. And AWS in particular is a great tool in our tool belt.
But we don’t have a bias when we go toward an engagement with a client. We don’t have a specific collection of pre-built vertical services that we’re trying to sell to people. We’re trying to sell them results and achieve collaborative results with them. So, I think that’s really key and something that we’re really proud of — being able to engage with our clients on the basis of legacy and, and understanding where they’re at, where they’re, where they’re trying to get to.
In the past five years, Soliant has launched out on a journey with AWS, and we’re privileged to be in an AWS partner for advanced tier services. There are lot of fantastic partners out there. We understand that there are a lot of choices that people have when they’re choosing a partner, but we’re very happy to be an advanced tier partner and we’re committed to doing even more in the future, as it pertains to our investment in the cloud and what we can offer to SMBs, when it comes to these areas of application modernization and migrations to the cloud.
So we are an Immersion Day partner, we’re part of the Solutions Provider program and also the AWS Cloud Formation Delivery program. So these are some of our investments, just a couple of our investments that we’ve put into our practice at AWS and something that we’re really proud of.
We are also on the AWS marketplace, and you can find us there if you’re looking for information about some of our services. We’ve worked with so far, just within the AWS space in these last five years, over 400 clients that we’ve had successful engagements with. And, we’re hoping to do even more in the future and really build upon our success there.
We’ve invested in our people considerably. We’ve got over four 40 AWS certifications within our ranks. So going from business accreditations, technical accreditations, all the way up to specialty certifications like networking or our solutions architect professional and associate type folks.
So, we’re, we’re really investing in this and, and we’re very much invested in being able to provide quality services to our customers. We understand that when we’re working with, with SMBs, the majority of our customers do not do a full migration to start. And I want to make it very clear that we view much of this as multiple steps over time. We will make sure that we’ve got a good vision of where our clients are at and what their challenges are. We try to develop a iterative roadmap for success for them so that we can get them in, get them a quick win, and, make sure that we’ve got space for them to grow in the future. So, we understand that methodologies grow over time, and we want to make sure that we accommodate that, in an effective way.
We’ve got the perspective for that. We want to make sure that we’re, we’re keeping that in mind with our customers. That, that we’re trying to take them on a journey. We’re not trying to jump in, a hundred percent at the beginning. We find that that’s not necessarily where our success usually lies. We are usually successful, just getting that light step in, providing value and, kind of showing the way there. So we do leverage your legacy, as I mentioned before. We try to leverage the past in regards to what our clients are good at, what their applications do well for them, and then we learn how we can supplement cloud technologies in there and really fit a great solution with cloud technologies using AWS. And, we’ve found that’s very successful for our clients.
One thing that we really try to focus on is the seven Rs for, for our cloud engagements. And I’d like to take this time to offer an e-book. We’ve put an e-book together. Claudia, drop that in there. It’ll show there, I believe, on the bottom left hand, side of your screen there, if you’d like to take a little bit more time to learn more in depth about some of these things that we’re talking about. So these are the seven Rs as it pertains to, to what we’re doing here. So, rehost, refactor, replatform, repurchase, relocate, retire, and retain.
But we really try to focus on three of these, for the most part, rehost, refactor, and replatform. So the example that I can give is, you know, in, in a case where your applications are working great for you, maybe you’re facing some issues with hardware that a rehost would fit that bill to where we don’t have to make any changes to your existing applications, but we can, we can provide you incredible value by being able to just simply rehost that in a reliable infrastructure.
Or, if we’re refactoring, if we’re taking something that needs some enhancement, it works, it’s got a good core to it, but we’re able to go in and supplement it with cloud technologies. That’s a refactor or maybe a mix of both where we go in and re-platform things and do kind of a mix of both of those. So I’d encourage you to grab that ebook if you’d like to read a little bit more about that. It’ll, hopefully be an asset to you. So we’re happy to provide that. I’d like to present a just a few examples of the work that we’ve done for our clients recently. We’ve got some time constraints today, so we won’t go super in depth, but I’d like to give you at least a glimpse and a sampling of some of our recent work that we’ve done.
And these are good examples. calling back to those seven Rs, or in this case, the three Rs that we’re dealing with. Vanguard Cleaning Systems of Portland had a legacy application that was experiencing some fragility as it pertained to hardware. And they didn’t really want to go in and make that expenditure.
They had some other issues with the software that they wanted to solve their office team of around 12 employees would frequently be unable to use this core app business application, which scheduled and processed appointments and service requests from their customers. They relied on a tape backup system in this case that would frequently they would need to utilize for disaster recovery as a result of their service crashing frequently, those would’ve to be rebuilt. This resulted in downtimes often of up to a day or more, so pretty significant for them, and something that impacted them greatly.
So what we did in this case, we did a roadmap with Vanguard, which resulted in a project that included a new EC2 server that rehosted their application workload to — along with a file server component that allowed them to access and share their corporate documents and application — dependency across our organization. And then on the backup side, EC2 snapshots took the place of their old tape backup system. This resulted in their ability to theoretically, restore from backup in 15 minutes or less, which reduced that day or more of downtime significantly that they were experiencing previously. I would point out that they haven’t had to rely on this yet. So far, things have been extremely stable and, they’ve gone from having this fragility and their service crashing frequently to being very stable; they haven’t had to rely on, on their backups.
We’re monitoring that for them and taking care of that for them on the back end. Another piece of this that we implemented for them was a VDI solution using Amazon workspaces, which included, ad services and group policies that supported different components that we implemented there. So that gave their employees a virtual workspace to work on and access all of those services, within the VPC there, in the cloud. So overall, this was a pretty straightforward project, but this demonstrates what I’m talking about. When it pertains to rehosting, we were able to do a rehost or a lift and shift that moved their application to the cloud very quickly. And, without making any changes to their core software, we were able to give them some success getting into the cloud there.
The second, example I’ll bring you to is Ellis Coffee. Ellis Coffee’s a great customer of ours. They’re a coffee roaster that’s based in Philadelphia, and they came to us because they’re looking for a partner who could help them rethink their legacy web portal that was based on largely an on on-premise, accounting software. So their partners are in the hospitality industry, such as hotels and things like that, who would submit regular orders, for coffee beans on their existing website. Then they had a van route in the area that would fulfill those orders. They wanted to make some enhancements to their site, but it really wasn’t going to work out so great because it wasn’t forward compatible. And, the application relied on some web scripting that was pretty tightly coupled to their legacy accounting software. So, in this case, we performed a refactor of that site.
And so what we did was we moved the legacy process into a cloud native structure that’s decoupled from that legacy accounting software. And we were able to work with their legacy, program, application programmer to, refactor, and rewrite how that data exchange worked. So we moved that portion over to an RDS database in the cloud so that their React front end now relies on admin APIs that are totally decoupled and pointing back to that accounting piece. But the benefit here is that if there’s an ISP, connection issue or they have an hardware issue, there are no dependencies there. Their website can continue to function and they’re achieving some great efficiencies and stability in the cloud as a result of that. Also, another great thing about this is that, if they decide ever to move away from that legacy accounting piece, they’ll be able to do so.
Because it’s extremely for forward compatible. That was a really key part. They also wanted to add, in the future, some self-service shipping and online payments. But what we advised in this case was that they wait on that. Let’s get their infrastructure stabilized first before we make any other major changes. I also heard that we’re about to tackle those shipping and payment aspects here soon in a new phase of work. So that’s a great example of, when we’re talking about a refactor, which allows them to modernize more in the future but to get that stability, quickly and get things shaped up for the future. So this was a great project for us. Then third, Art is Love, which is formerly Kalisher. They create and commission original art pieces for spaces all over the world.
They’re a longtime customer of ours. And, as their customer base expanded, their team approached us with a unique hosting and functionality need for their business. What we ended up developing was Art Lab, which is a web application that we rewrote for them. That includes a sophisticated search function across a library of images. So previously they were on a WordPress type of a site that presented issues, not in the least of which was how it handled those images. It didn’t really handle those well. We were able to move their image library over to S3, which was a huge factor, because when an image is uploaded into S3, it automatically triggers the creation of several thumbnails, runs, different processes, and extracts keywords from the art using Tech Extract, which is an a another AWS service.
From that, we create an elastic search catalog. That pro produces a corpus of search terms along with which their librarian is also able to enter in keywords and deal with that as well. So we move them over from a full-stack server-based infrastructure to something that’s now serverless and cloud native. It also utilizes Cloud front, so that gives them great performance and reliability across all regions. Instead of being limited to that traditional architecture, this solved their issues nicely for them and also sets them up for new improvements that we’re actually starting on very soon for them as well. So it was a great example of a little bit of both of those Rs that we talked about. And then the last example I’ll give you today about some of the work that we do for our clients is about our MSP platform, Soliant.cloud.
It provides that light step into the cloud for our customers, where we can help them manage, build, or develop production systems that we help manage and support within our MSP. and we’ve got some pretty specific products that are a great fit for our MSP, such as Claris FileMaker. Many of you who are on this call may, may be familiar with that we’re a platinum member of Claris, which is an Apple subsidiary. But we’re able to leverage AWS to provide what we believe is a world-class leader in FileMaker hosting that no other vendor is able to offer. Because within this MSP, we were able to leverage AWS services that support other services, such as our OptiPlex family of products that really accentuates and supports the cost optimization and sustainability pillars of the AWS well-architected framework.
It really gives us that competitive edge to be able to provide great service to our clients in an MSP type of type of an environment. So those are just a few examples of how we feel like we’re uniquely positioned to help our SMB customers achieve that success. And I know we kind of sped through it, but, you know, we’re, we’re trying to solve deep and complex problems while still providing the flexibility, cost-efficiency, and really a path forward to the future. With that, we’re going to include a link at the bottom here for you to, if you have questions.
If there’s, a particular question that you have that you’d like to get a get answered or you’d like to find more details about, maybe some examples of things that we’ve worked on in the past, or if you’d like to receive a free consultation for your journey for the cloud to the cloud, we’d be, more than happy and delighted to be in contact with you. So utilize that if you can. Our direct contact information is listed there as well as our general information line. So thank you so much to everybody who joined us today. Thank you again to Claudia and Dean and Maria and, also you folks.
Thanks again, Adam and Dean for presenting today. Thank you all for attending. If you, again, are interested in next steps as Adam mentioned, please hit the speak with an AWS with our AWS team in the lower left hand corner of your screen, and complete the requested fields. We look forward to connecting with you all sometime in the future. Again, this concludes our call and thanks and have a great day.