Creating a Strategy to Achieve Quick Wins in your Migration and Learning from those Experiences to Improve your Solution
The current pandemic has shown how important remote-first cloud approaches are for an organization. But tackling a cloud migration can be a daunting task. John and Adam discuss how to develop a strategy and how to break down the migration process to into quick wins, so that your organization can iterate and learn to achieve a solution. They also discuss the importance of engaging users into the process and how to approach that task, as well as the importance of taking a “One Team” approach.
Adam: I’m your host Adam D’Angelo and I’m joined by my co-host John Janek. How are you John?
John: Another sunny day in Northern Virginia. Happy to be here.
Adam: Still a social distancing in your house over there?
John: Oh yeah. Oh yeah, as much as we can, try and get out for walks in getting on the stationary bike. We’re lucky it’s it’s been, it’s been an interesting dialogue as Virginia slowly starts to open up. Except for Northern Virginia, so it’s been interesting to watch. How ’bout you.
Adam: Yeah, we’re trying to make the best of it, enjoying family time together, trying to figure out ways to keep the kids occupied and entertained. It’s always a challenge, and even more so when you can’t go to a playground or have other little playmates to spend your time with. So we’re making it work. The nice thing is, you know, on the work front, you know obviously were very busy right now, right? and I know you and I’ve been working a lot on cloud migration strategy. Not only how to pick the best cloud provider, but once you’ve already made your decisions how to move forward and I wanted to spend a little bit of time chatting with you. Kind of about some of our thoughts that we’ve had recently because I know a lot of our customers are interested in this and we’ve been spending a lot of time chatting with him about. Cloud migration and the approach to move their legacy data center systems into the cloud. How’s that sound?
John: Yeah, I think it’s right on it. It’s very timely, right? Because if there’s one thing we’ve learned out of the pandemic, it’s been that if your technology is not ready for remote-first cloud-smart approaches, you are not going to succeed as an organization, right? So we were very lucky in that we had been working on Teams, and we’ve covered this in previous podcasts, is our technology stack was already kind of built for this kind of a model, so we transitioned practically without missing a beat. In fact, I think you know we had an all hands last this week yesterday. I think it was yesterday, and in our CEO was saying how fantastically we had pivoted. And that’s not true for a lot of our government clients. It’s not true for a lot of others, so we’ve been very blessed and very lucky that we’ve been able to rotate into this new space with very little impact or operations. And I think Adam, to your point, now is the time as we’re starting to get adjusted to what is a long-term approach to digital for the workforce for actually doing business look like this is where cloud suddenly becomes a whole lot more interesting because like we talked about many times in the past.
Technology is only valuable when it drives the business. When it’s valuable for the business, what is that value look like and how do we describe it? There’s been no better time to have a conversation around cloud, right?
Adam: Oh yeah, that value proposition with the cloud is a complicated one. Especially, We’re not just talking about moving one or two systems, but your entire enterprise, potentially to the cloud. And what that looks like. And the road map for that is complex, and the path to migration and operation in the cloud is challenging, there’s no doubt in my mind to that right.
John: Yeah. So when an organization looks at cloud, right. So you’ve done a lot of very specific migrations inside of DHS. What are you thinking about? You know there’s just a ton of experience that we’ve drawn from inside the company over the years and we have a few kind of very interesting insights around that right. What’s been your experience in some of these big moves? What are your top lessons learned and what do you want to share with others? Because I think that’s where we really start getting value for the whole communities where we start talking about, well, this is what I saw, this is what was valuable, right?
Adam: Right, right, you know it in my mind there are probably, you know, four distinct phases that you likely you know, iterate over, right? You know we’re trying to be agile about this whole thing, obviously, so it’s guess, test, revise, but you know a little bit more formalized than that, right? And I think that first main bucket is really developing your strategy, right? It’s understanding what exists in your enterprise architecture, bringing all the stakeholders to the table understanding what their definition of success looks like, understanding the operational requirements SLAs of your systems. Because a lot of systems are used not only inside an agency, but you might also have external users as well. So what are they potentially paying for or what have they signed up for? You know, what your cloud provider offers as well. You know, I think that’s possibly an overlooked piece of the strategy right? You know when you’re when you’re making a decision, whether it’s to go to AWS or Azure or GCP, you know they all offer some unique tools, unique ways that they will bill you or support your organization. So there are a lot of considerations, and obviously that’s part of that something that feeds into your IT strategy when you’re putting together that cloud migration strategy. I think those are all very important considerations that you need to dive into.
John: Yeah, when you’re talking about the different cloud models too right now, we’ve got this whole discussion around multi-cloud, right? So now it’s not even a simple as “Oh yeah, we’re going to pick a AWS over Azure because there’s more cutting-edge technology there, or we’re going to pick Azure because there’s more seamless transition for Microsoft systems, or were going to pick GCP because of the maturity of the AI and computational engine,” right? Instead, instead now you’re also being asked to deal with this whole other layer which is, “Hey, these cloud providers all have strengths in different areas. How do we mix and match capabilities in order to best to meet our mission need, in order to best think about how do we move forward?” And you’re having some really interesting conversations with organizations like Red Hat and Kubernetes. You know, and their OpenShift platform in Azure’s containerization stuff that they’re still developing.
And then the whole entire serverless conversation, right? Which in theory, although it’s not in practice yet, but in theory serverless should allow us to go into multi-cloud a lot easier. But we’re still seeing a maturation of that space, right? So I think you’re right, the strategy is super super important.
Let me ask a question related to that, because this is always something, as somebody who’s done a lot of strategy in his professional career, people don’t feel like strategy is a predilection to action, but nothing could be further from the truth, right? What do you think about, how do you make strategy actionable? Not in the doing thing, but how do you make people feel like as you’re talking about strategy as you’re taking these different steps, you are doing things, right?
Adam: Well, yeah, there’s definitely a few ways to tackle that as well, and I think really one of the most important things to attempt to do, especially when you’re looking at a very large, daunting task such as a system modernization effort or a cloud migration effort, is to identify those quick wins, right? That nothing is going to make you and your customer an all your teams feel better than getting some wins under their belt, or frankly some losses, right?
The sooner you can get into action and learn from that, whether it’s a success or failure, the better off you are going to be, and I think the more confidence everybody is going to have as you continue to move forward, right? So I think, while you’re going to spend some time doing strategy sessions and engaging with stakeholders and understanding the lay of the land, you know really, what you also want to be doing up front and early is just starting, right? In my mind, one of the first things you should do is try to find that candidate system, the one that’s kind of isolated from the others. That hey, you know if the migration doesn’t go successfully, or there is some downtime, no big deal. Start there, move it to the cloud. Just pull the plug and load the code up into a EC2 server, figure it out, right? And just start attacking the problems as they come up, because that will immediately feed back into that strategy phase, and give you the chance to go back to your customer and say, “Hey, look, this is what we tried. This is what we learned. This is how we’re going to change our course of action,” and that’s the kind of responsiveness that I like to be able to provide our customers when we are working through some of the very complex problems that you’re likely to encounter as you’re moving systems to the cloud.
John: Yeah, and that’s a really a spot-on iteration cycle, right? We want our strategy to evolve as we are hypothesizing, testing, evaluating, validating. Right? As you thought through these different things, you know there’s quick wins or how we test the strategy. Is the strategy right? Do we need to course correct? Again, amidst all of these different things that are constantly evolving, right? I mean, just look at what’s happened in the cloud space over the last 12 months, and you can say to yourself a strategy you wrote last year is completely irrelevant now, right? So how do you talk about these quick wins? Well, what is a small system isolated by itself, right? What does that look like, right? How do we talk about those sorts of things? How do we figure it out? What is a quick win? Where do those systems live?
Adam: Yeah, I mean that’s not a one size fits all answer right. I I’d like to think that, you know, if we’re engaging with the CIO or CTO at an organization that hopefully they and their staff probably have some ideas, and we can certainly talk them through how to potentially identify a few of these systems. But in my mind, obviously they are not mission critical systems right there? Not systems that have a requirement of five nines up-time, right? I mean, that’s probably not your ideal candidate to move first. But there is still that idea of being able to just take any system that’s largely disconnected, you know, so I’m not talking about a whole complex microservice driven architecture with, you know Kafka or something else in the middle of it that’s doing all this communication, because that’s going to be very difficult to test if you’ve been successful in moving that to the cloud. I’m talking about probably your typical monolithic application, a database, and maybe it doesn’t even have any web services that it offers up to any clients. And just kind of taking that application, putting it into your cloud environment, and just seeing how it performs, right. There’s a lot you’re going to learn from that, right? How’s that connectivity from your data center into the cloud? Are your users experiencing latency? What are some of the issues that you’re seeing immediately? Because that’s a great place to start, you know, informing your strategy from the get go.
John: Yeah. And that’s a really good question too, because all too often you know the government sets the strategy, and then they carry out the strategy, and then they realize there’s a problem. And so there’s this whole breaking momentum that happens, and then they have to go back and re-configure things. And what you’re describing is a much more a ideate prototype test. Retrospective into a new iteration. Right? And I think there’s a lot of value in that. So we talked about like different kinds of targets. Different targets are going to vary depending on the organization for quick wins. When you’re thinking about that, that can be as simple as a lift and shift, right? I know that’s like not en vogue at the moment, but it really can be as simple, as like you said, take this system. It’s like a database in a front-end server and stick it in the cloud. You know, think about how you’re going to stick into the cloud. If you’re using AWS, put some CloudTrail around it. Put some thresholds for monitoring. You know I had a recent conversation with an organization where they wanted to stand up all this HADR stuff in the infrastructure as a service, and we had a long conversation about well, how do you diminish the requirement to do that for the infrastructure as a service implementation, by using some of the services that are included in our package like CloudTrail and CloudWatch, and all these different components.
You know, I think that’s an interesting conversation too, because it really does get people thinking about the strategy across the different lines of effort, right? Not everything is going to be a re architecture to cloud native in the in the in the cloud, right? We’ve talked about that. Lift and shift is also OK as a first step, it’s something you have to do, and for some platforms it may be the only thing you do, right.
Adam: Right, that’s absolutely right. That’s why in my mind, and you know, as our company has put together kind of a framework to work through this process, it is not very prescriptive, right? Because that IT strategy entirely depends on what’s driving your migration. For example, one of our customers their, probably their main driver to get to the cloud, was they actually had to vacate the data center that they were in. So as opposed to moving all their systems from one data center into another data center and then potentially eventually moving into a cloud or multi-cloud environment, they decided, “OK, here’s the date where we have to be out of the data center. Let’s use this.” Whatever it was, 18 months and just go to the cloud instead, right? So that’s a forcing function to how you’re going to view your strategy. There’s going to be a lot more lift and shift in that strategy versus re-architecting for cloud native or serverless or a variety of other options, right? But you know, so you really have to understand what your constraints are to make the right choices. And again, it’s not a one size fits all—all systems are the same. It’s usually pretty close to a system by system or portfolio to portfolio strategy you’re working on developing.
John: Yeah, I’ve always felt the constraints in a lot of ways. You know, we’ve talked about this a little bit in some of our innovation discussions. Constraints are so important to coming up with new ways of looking at a problem, right? And if you really understand what the bounds are around an issue, in a lot of ways, constraints are even more important than your requirements. Because if you if you can’t re-architect the system, if you can’t afford the licenses, right? Those constraints all drive the conversation around what could that to-be state look like? And I think those are just so important. So we’ve talked a little bit about strategy being a combination of predilection to action through experimentation. Understanding constraints for a particular thing to move. How we’ve talked about discovery in the past. The variety of different things we’re going to deal with in that process. What have been some interesting experiences where it didn’t work? Or where you had to learn. I think there’s a really interesting, and we’re going to talk about the whole process in another episode, I think, but we’ve talked a lot about the things that we’ve been seeing. It’s important to reiterate this is based on all of our experience in the company based on years of doing this, right. So what hasn’t worked well to get us to this point?
Adam: You know what are the biggest breakdowns that I’ve seen. This is true of whether you just kind of modernizing a system or migrating a system to the cloud, is really getting those stakeholders on the same page, the same wavelength of understanding. We work in an environment where we support a lot of mission critical systems, so the end users of these systems are usually quite demanding in terms of keeping their systems operational. They don’t want any crazy changes other than the changes the they’d like to increase usability. Things that give them value, and oftentimes an end user to a system that is being migrated might not really see something that they feel is an increase in business value over the course of a migration effort. So a lot of communication needs to be done there. And engagement with those stakeholders so that they understand why the system is being moved. They are kept completely up to date with things that are happening on that migration effort because it’s very easy for them to be discontent, and cause problems frankly, right? Before you know they go up their chain of command and the next thing you know your team is being diverted from the migration effort task to have to implement new features and new reporting capability.
And one of the big impacts to that change in direction during an effort like this is the impact morale for a team. And I’ve seen it time and time again where teams start becoming a little disenfranchised with the whole effort because their Sprint to Sprint work is changing so dramatically. One minute they are busy learning and implementing Chef cookbooks, and then the next Sprint they’re being told, OK, well we need to add a new React front end to this application. It definitely has an impact to the team. Dates change frequently because all of a sudden you know some end user says, “well, we can’t be without, you know, our system for this long, so we want to push this data by two months.” And then the team is working overtime to try to get things accomplished. So I think one of the largest negatives that we’ve experienced is typically around team morale.
So a lot of what we try to do upfront with our customers now is get on that same playing field. Make sure that there’s a lot– I’m talking a lot–of communication about what’s going to happen, when it’s going to happen, why it’s happening, and also the how, right? I don’t like to get two technically into the weeds with all stakeholders, but I feel like many are more interested in some of the how details then you might expect. And if you start pulling them in, you really start putting bringing them onto your team as opposed to them feeling like “well, I’m on my team, and those contractors are on their own team, and they’re not working on things that matter to me as the end user,” so we want our work to matter to them. We want them to understand that “hey look, when this system goes to the cloud, these are going to be some of the benefits.” Right? Ultimately, I think when you’re able to communicate that and create that level of engagement, you’re also going to help protect your team from some of that context shifting that can really happen often on some of these efforts where you’re trying to move an entire organization into the cloud and yet you still have users asking for features, and sometimes you just have to keep switching back and forth between tasks and it becomes very disruptive, very unproductive, and really can hinder and potentially compromise the entire effort altogether.
John: Yeah, I think this talks a lot to the importance of integrated teams. You know, I realize that even today we struggle, organizations–especially in the government, want to think in terms of “well, here’s the technology organization and here’s the business organization.” But the reality is that these things are so closely intertwined, right? We talk about this in commercial context all the time. That if you’re not a technology business first, you’re not going to be in business very long, right? And I think the government is still really struggling with this concept that no matter your mission, technology is at its core. So we constantly have this ebb and flow, right, of like who are the business users and the mission users who actually need to get the work done, and how do we connect, and bring forward their concerns and ideas and thoughts and impressions in order to make it a real exploration where they are engaged, and they understand the problems from the technical side as well, right? Because it’s a little bit of a back and forth. It’s not just a one-way street.
I think when you look at some of the changes that are happening in government with trying to bring more technologists from the commercial sector into government. Again, it’s this idea of like we need to bring government to this realization that it is a technology centric mindset. It’s a digital transformation, and so we have to bring those groups together in meaningful ways.
Adam: That’s absolutely true. And you know, I’m super respectful of the mission and the work that goes into keeping these organizations running and the work that they do. And I think it is very important to really make sure that we all feel like we’re on the same team at the end of the day. And even if they might be performing some sort of field operations and you’re an IT contractor supporting that, well, look frankly you need to understand what they’re doing. And I do think it is important that they have an idea of what that technology is doing on the back end. And I’m not saying they need to be technical, but I’ve been amazed, any time we’ve gone through modernization or migration effort, the closer we get to those end users in that process, the more the more successful the effort typically is. They become more understanding of what we’re going through. They are more eager to help and support any way that they can, and it’s amazing how goodwill and at flattening of the organization and creating that kind of one team approach really goes a long way to making difficult tasks much, much easier.
John: Yeah, yeah for sure so. So we’ve got a discussion around strategy—Understanding what do different toolsets look like? What do different approaches look like? You know, there’s a question, I think, that we want to get into, which is like, OK, what does the inventory look like, right? Well, I’m sure we’ll get to that when we talk about discovery, right? And then we talk a little bit about the fact that we have to be together to do this, right? And these are all these are all very important strategy conversations, right? Because if your organization culturally isn’t ready for kind of integrated teaming, in this idea, the technologists are going to work alongside your delivery personnel for the on the mission side. These are these are important questions to ask, right? These are important things to think about, because we really have to have an approach that gets us moving forward. When you do that, right, innovation increases, technical adoption increases, user functionality increases. Most importantly, though, what we’ve seen time and again is user acceptance and user satisfaction increases, right? And that’s again talking about mission value, right? The single biggest benefit of running integrated teams in all of these conversations is when you do it right, the value increases to the people who are actually doing the work, because they feel like they are a stakeholder and have been involved the entire time.
Adam: Yeah, absolutely John, that’s a great point. And I also want to go back to, you know, culture, right? You mentioned culture and it’s something that we talked about a lot on this podcast, actually. And I think one of the big cultural terms these days is DevOps, but that’s exactly what we’re talking about here, right? Not DevOps as tools, not building a CI/CD pipeline–that stuff is fantastic and everybody should be working on that—probably. But more as that flattening of an organization, right? Busting those silos, making sure your operations, teams, infrastructure teams, testing teams, security teams–of course, and your developers are working together with those end users to really kind of form a One Team Approach.
You’re going to have to do it in these migration efforts because everybody’s going to have skin in the game and making sure that there’s alignment between all those different components is essential, right? You know, if you have your infrastructure team who is being tasked by this division lead, and saying “This is our next milestone, this is what we need to work at.” But then you have your development team and they were working on, yeah, I don’t know, re-platforming something, but they need to be able to test and they don’t have permissions to spin up the right infrastructure. Well, you know, then you start winding up with this conflicting goal in mind, right? Even though we’re all working together to migrate the system to the cloud, if you have different teams operating their own silos with their own milestone targets, well, you’re going to have to have some trouble there. That’s going to be a big problem for your migration effort. Which also leads me to the point of if you’re as an agency going to move, and just kind of migrate your entire–or most of–your enterprise into the cloud it’s going to be very disruptive. And as opposed to finding ways to minimize the disruption, I say ride the disruption right? I’m a huge proponent of kind of these champions coming in at the executive level within Government and making sure that they’re shaking things up right? We’ve had some great CIOs within the DHS space over the last few years. Have really done a fantastic job of just trying to change the way they think about delivering software and developing software and leveraging this disruptive moment in time where we’re all thinking about how to move systems forward and creating organizations that are inherently more agile than they were before, embracing that kind of DevOps culture, silo busting. So, I say let the disruption benefit your organization, and use that as a tool to help move forward the way that you guys do work.
John: And learn from it, right? I think the other part that is really interesting, and we’ve seen a couple of good use cases, so I want to draw out something specific you said, which was “build the culture,” right? So, you have an opportunity, and again tying it back to everything we’ve talked about, strategy, test, iterate, you have an opportunity here to find that quick win. Build a team around that quick win. That’s not just the right people, but the right access and capabilities, right? And this is so critically important, it is tough. It’s so tough for the government to do, right, because the government is highly bureaucratic and the idea of giving a bunch of working level people the ability to just bust through lines of bureaucracy in order to get stuff done, is to some extent, anathema, right? It doesn’t make sense. It doesn’t fit into the model, but the reality is that it has to. We have to be able to do that in order to move things faster. So if you take that quick win give it a team that’s got the right capabilities so that they can do that whole lifecycle from stand up to deployment, and then learn and back again. Then, and this is the part that’s been interesting for me, because I don’t feel like we’ve done a whole lot of this really well in the government. We’ve seen lots of good examples of quick wins, right teams, right capabilities, moving out, right, 18-F, USDS, lots of examples, and I think USCIS, right? CBP is doing some great stuff like lots of specific examples inside government, inside DHS, where you’re seeing lots of really good examples of that. But we’re not doing as much as we probably should. Is that whole iterating back into the strategy, I haven’t really seen a whole lot of that where a use cases done, and then we learn, and here’s what we learned, and here’s how it’s going to affect the strategy. Instead, we still see these strategies as these big, iconoclastic discussions. Here’s how we’re going to move forward, rather than saying we’re going to continue to iterate through it, right?
Adam: That’s right, that’s right. And without naming any specifics here, I’ll tell you that you know we had this one large migration effort and we were able to work with the CIO shop to establish a Tiger team, right? We took a scrum team of developers who were on our contracting team, and we were able to embed some of the operations, folks security folks, and infrastructure folks on to our team–or I don’t want to say our team–I mean, our collective team really, and work together as a Tiger team to kind of get established one of those quick wins, right? And the win was not moving a system to the cloud. The win was understanding how these different contractor teams can and should work together, right? Because they are on different contracts and those different contracts have different goals and their own ways that they measure achievement. So, trying to figure out ways to get teams to work together that is mutually beneficial. Not to not just the contractors, but especially to the government, and what you can learn from it. Because that was really how you kicked off while you were saying there. The goal is to learn right? And what are we learning as this Tiger team right? What have we really learn from this quick win? What defeats? Do we suffer along the way? And how does that inform our strategy as we continue to move forward and that feedback loop we are always talking about right? Shorten that feedback loop. And make sure everybody as an organization can learn from it.
John: Yeah, I think that’s really the key. And you know, I think we’ve talked about some of the lessons that that the company has learned over the years, that you’ve learned, that I’ve learned over the years, and how to approach that. It’s really about making sure that as you’re going through these different phases, that you’ve got that feedback loop. And it’s just struggle because people are stubborn, and people have opinions, and perspectives, and change is really, really hard, right? So, I think that’s probably a really good place to kind of leave the conversation, because how you think about that culture and changing that culture in giving that culture the ability to start in a small little incubator like a Tiger team that’s doing a specific quick win, and then using that as a ramp back into the overall strategy, is how you’re going to do it right? That’s how you’re going to get to the next level.
Adam: Yeah, that’s right, you’re not really just modernizing your IT infrastructure. You are modernizing, the way your organization thinks about IT, right?
John: Yeah Yep, Yep. So when we you know so I think we want to talk a little bit more in the future about some of these things too, you know this is kind of been the big set piece. Really, for our next conversation, I think we should get really into the discovery because in order to do quick wins, you have to have an inventory, right? You know, and it’s really, it’s really funny because nobody thinks inventory is exciting, right? Nobody says agile and inventory in the same sentence, right? But we talked about this earlier in that if you don’t have constraints, you don’t have any idea of what’s possible. And one of the single biggest constraints is your inventory, what do you actually have? And I know you’ve put a lot of thought into this. I know we’ve learned a lot of lessons over the years, so I think the next time we get together we need to spend some time talking about what does discovery look like in this kind of an approach where we’re trying to get these learning loops built up. How do we actually make discovery meaningful? How does that sound?
Adam: That sounds great. John. Yeah, I’m enjoying this conversation. Let’s continue it with that topic of discovery the next time we get to chat.
Adam: Alright, well thanks for joining us on another DevCast. We’ll talk next time about cloud migrations and how to discover what assets you have, and how to prioritize what you may or may not need to move.
John: So, don’t forget. We want to hear from you. So if you’ve got thoughts on our experiences, insights that you want to share, you can definitely, you can definitely write to us. Drop us a line. Tweet us. We’re always listening, so it’s super interesting conversation, Adam. And I’m looking forward to the next one.
Adam: Likewise, ‘til next time.
John: Yep, see you later.