How to Ensure Your Cloud Migration Effort is Aligned with the Rest of Your Business
The larger and more established your company is, the harder it is to do a cloud migration. Many companies are trying, and many are struggling to do it in a cost effective and sticky way. In fact, more than half of companies who have made moves into the cloud are already going back on-prem.
Our new COO, Philippe Bonneton, and Mike Cottmeyer sit down to discuss the challenges associated with moving monolithic legacy applications into the cloud and how an iterative and incremental change model can help you plan out a cloud migration and ensure success.
Video Transcript
Philippe Bonneton
When you move this big monolith from traditional legacy systems to the cloud and you have a whole new economic model around it that’s tied to it, right? You start selling software licenses, you disrupt the whole way of selling. The whole value chain beyond just the engineering piece gets disrupted. And so it might not be telling the client to do less. It might be telling the client, how do you de-risk all that? How do you pilot? How do you start with a much smaller batch or slice of your business and learn, build the muscle memory around it, build some of the best practices organically, the way you deliver that software, the way you sell that software, and then you expand from that.
Overview
Mike Cottmeyer
Hey everybody, welcome to our recording today. Today I’m going to introduce you to leading Agile’s new Chief Operating Officer, a gentleman by the name of Philippe Bonneton. Everybody say hi to Philippe. Philippe, say hi.
Philippe Bonneton
Hey everybody.
Mike Cottmeyer
Hey, cool. So what we’re going to talk about a little bit over the last leading Agile’s been around for about 13 years and really what we’re known for is Agile. Agile transformation, transformation at scale, the ability to take really complex, tightly coupled organizations to begin the process of untangling them. About three or four years ago, we went down the path, Matt Van Vleet from previous and from Pillar Technology and from Accenture joined us and we started a studio. And the reason why we started a studio was because some of the challenges that we were facing in organizational design couldn’t really be solved unless we were able to do some of the technology decoupling work as well. So we went down this path of working with some of our clients in the areas of product extraction, service extraction, a little bit of custom development. But the main hypothesis behind that was this idea of basically taking big things and breaking them into small things.
And as we’ve been going down this path of transformation with our clients, one of the things we’re finding is that a lot of our clients are dealing with things in the space of tech uplift, tech modernization, cloud migration. And these initiatives are very closely coupled to the idea of organizational design and how we’re going to run the organization on the backside.
Meet Philippe Bonneton
Mike Cottmeyer
So, Philippe joins us with a lot of big consulting background, a lot of background in the area of digital transformation, cloud migration, a lot of the things, data ai, a lot of the things that we’re talking about. And so, what Philippe’s going to do with us as our COO is help us safely navigate into this new space and build on the great work guys like Matt Van Vleet and Darryl Kulak and Kevin Smith have been doing and really help us expand our practices in that area. So without further ado, again, everybody say hey to Philippe and Philippe, why don’t you take a moment and tell us a little bit about you and what your background is.
Philippe Bonneton
Yeah, thank you Mike. Hi everybody. So very excited to be joining Leading Agile here. A little bit about my background. Agile is a term I learned. I’m going to dig myself to be here, but it was about 12 years ago. I was at Viacom at the time, hired as a mobile product lead for all of the Nickelodeon brands and joining an organization, a game production and software engineering organization that was very waterfall. And I joined it right at the time when the team started to move into Agile and it was done through blood, sweat and tears at the time, but we were building our sort of makeshift agile process and governance model as we did that. So very interesting to join leading Agile today and go back to some of these concepts I learned earlier in my career. As you mentioned, I spent a good amount of time in big consulting.
I worked at Accenture for about eight years at Accenture. What was very interesting and where I see a lot of similarities with what we’re trying to do here is that I joined at the time when digital transformation was in its infancy for those big consulting firms and the realization that you need to go further than just giving advice. You’re not just a strategy firm. You need to start having the software engineers that can code the data scientists that can analyze. And you need to have that in-house as a big consulting firm to be able to be relevant to your clients in this new digital transformation world. And so I see a lot of similarities with what you just described here with leading agile and understanding that beyond the organizational and operational transformation that you bring to clients, you want to start looking at the tech that they talk about, what’s keeping them up at night around data and AI around cloud security. So lots of similarities here. I did a lot of that when I was at Accenture. I spent a little bit of time at Amazon after that working in the devices organization and helping figure out what it meant to do cloud gaming and to scale cloud gaming for an organization like Amazon and its partners. And recently joined leading Agile here and helping with the growth journey with what’s ahead here when we look at technology first undertakings and how we help our clients transform and become smarter as they do that.
Mike Cottmeyer
So, what I thought we could probably try to explore today is maybe a couple different things. So as we were prepping for this, there were several case studies that we walked through where you and I were exploring the idea around some of the failures around cloud migration, digital transformation, different aspects of being disconnected from the business or not getting return on investment. So what I thought we might do is try to explore a little bit in those case studies, talk about how leading Agile’s approach to transformation, how it can help lead and guide and inform tech uplift and digital transformation and cloud migration. And then if we can pull it off, I’d love at the end to explore a little bit about the relationship between technology transformation and business process transformation and how that really enables some of the really cool emerging AI technologies and some of the things that companies are trying to do with data.
Challenges of Monolithic Migration
Mike Cottmeyer
So with that, we’ll see how it goes, but that’s where we’re going to try to head today. So with that, so we talked about this one company that you work with that basically as I recall, the problem that they had is they went down this path of doing a gigantic monolithic cloud migration. I feel like I’m overusing that word, but they did this big monolithic cloud migration. Talk to me a little bit about some of the challenges that you saw in that and maybe some of the things that if we had to do it over would’ve gone differently.
Philippe Bonneton
So their mandate, the big strategic thing they were trying to do was to migrate to the cloud, but not just their operations. They were trying to migrate what they had been selling their clients for decades in terms of monitoring software. They were trying to migrate all of that to the cloud, build this whole value proposition for their long-term clients around the benefits of the cloud. And the way they went about it is they just hired a thousand software engineers and they said, now we’re a cloud company. We have all the infrastructure, all the technology, the skills, what they didn’t have and where it becomes so interesting to bring the leading agile angle, what they didn’t have is they didn’t have the organization and the processes to be able to operate and commercially drive this new cloud offering with their clients. And I think that when you think about cloud and cloud migration, the benefits of cloud, it’s easily scalable.
It’s very modular, it’s very dynamic as a technology. What it does is it puts a magnifying glass on all the ways you’re siloed and traditional as an organization and all the way you have rigidity and dependency as an organization because now you have this new tool that’s been designed from the ground up to be agile and really follow demand and supply and the ebbs and flows of your operations. But then you realize your operations were always built with rigidity, with structure, with a sort of traditional reliability and predictability that no longer works when you use a technology that’s so modular and so dynamic and so interconnected as well. So this particular client, they went in and they hired a bunch of engineers, big CEO press releases and things like that with billions of dollars invested. But what quickly appeared was they were not finding the value, they were not getting the ROI, they were not even sure how to measure the ROI on their clot investments, and I would say the chemistry was just not there.
All this big bang around, we’re going to be a cloud first company now and then very little software sales to show for very little spreading of those cloud skills internally just disjointed, siloed, all of the issues that all of the things that worked in the traditional model became barriers to this future that they were trying to build around the cloud. And so you can imagine that puts the whole company in some sort of existential crisis like what are we doing wrong? Things start to break at the seam and without a good strategy to actually transform the way you work, the way you deliver software, the way you operate the software, that’s what you’re going to face. And that’s where I see a real link between the technology and the leading agile core expertise.
Mike Cottmeyer
So, one of the things that’s really been a hallmark of the way that we’ve approached the market for the last 13 years is that we move organizations out of often functional silos or the way we like to describe it is a big part of our strategy is to organize systems and process and people around customers and markets. At the end of the day, what that means is that I’m really hunting for an intersection between business capability models, domain designs, organizational structures, product models. Because what we really want at the end of the day is an organization of people that are focused on a certain customer that have a certain autonomy over the technology. So let’s go into this idea of cloud migration and the idea bringing monoliths to the cloud. So what I want to explore Philippe a little bit is the idea that one of the things we see quite often is a failure mode is that we take a legacy monolith and we move that monolith to the cloud, and that introduces a couple problems because the cloud’s really designed for modularity, it’s designed for composability, it’s designed to be able to scale only the components that you want to use or that you need to scale.
So talk to me a little bit about some of the strategy that you saw employed around, I guess what we might call lift and shift or just taking the existing technology and moving to the cloud. Let’s just pull that thread for a minute and some of the challenges it created.
Philippe Bonneton
Yeah. Yeah. So in the case of that client I was referring to, they had a performance management software or software suite, let’s just call it that, and something that they had been selling to their clients for and implementing for many years. Early implementations dated back 20, 30 years ago. That software itself was one big business, one big p and l for the client. When they thought about becoming cloud first and they hired all these engineers, what they did is they embarked on this, I would say big waterfall program of let’s just take this thing replicated in the cloud, create the complete cloud version of it, and then start selling it to clients. The challenge there, and I’m sure you can already think where it breaks, right? It’s too big to fail. It takes way too long. You are a year and a half into this migration of a monolithic software into the cloud. You haven’t shown a single dollar of revenue yet for it. It’s just one big cost center.
Then what happens is retroactively, you think, oh, we should have broken it down into pieces. So then you start to have a staggered sort of release of this software and you go to your clients and you say, well, V, one of what I’m selling to you right now is not going to have all the functionality you used to have when you were using our legacy software, but it’s going to do X, Y, and Z features. It’s getting you there. Clients don’t want to hear that, right? Clients were happy with the legacy software and would say, why do I need to follow? Your vision is great, but what does it do for me? How does it help me in my day-to-day operations? And so the client was faced with that issue, monolithic software, two big to fail. Now we’re a year and a half into this re-engineering this migration of what’s bringing us money, but our clients are just not buying it.
They don’t understand why we’re selling them a half-baked functionality and why we keep pushing the deadlines and milestones further because our development is just delayed. And so those were the big challenges, and I think retroactively, they went in and started to break it down into batches, retroactively. They started to say, okay, well one piece of the functionality that we can sell today that brings value to clients today, we’re going to focus on that. But that was after the fact. What was missing was the initial strategy, the plan to go do that in small batches, to do that in a predictable way to start showing revenue or return on investment early on so that you can continue funding this migration and you can continue to learn as you go. They were just in too deep with one big effort, and as they were gathering the learnings from this migration, they were realizing we started it wrong. And so that was really the big challenge they faced among other things.
Mike Cottmeyer
Well, one of the threads I was exploring with Dennis Stevens a couple of videos ago was sometimes the early business cases for doing cloud migration is deprecating data centers, making efficient use of hardware, maybe repurposing or letting go of the staff that’s associated with those data centers. So there’s a lot of economic drivers early on to just move everything into the cloud. So we explored a little bit of that. So I guess maybe my question for you be is did those economic drivers play and if they did, was it ever considered a strategy for maybe getting it all up in the cloud early on and then progressively starting to decouple it over time so it could be more modular? Because again, I think what I’m hearing you say is that moving it piecemeal and trying to sell a less viable product wasn’t the right strategy. So what would we do to keep it whole and then improve it over time, realizing the economic realities of the situations we went?
Philippe Bonneton
Yeah, I think early on you have to ask yourself the question, which building blocks or which batches of this big monolith are going to be the ones that will drive value for my clients? Going back to what you were saying about customers and markets, what are things that are going to move the needle for clients if I move them early moved, that can be extracted, I guess from the monolith as more standalone building blocks that will generate economic value for clients, generate revenue and return for the company that’s moving to that SaaS model. So starting with that, understanding the why, the value of what you could migrate first and how is it actually something that we can migrate easily? Is it something that’s going to be operational quickly enough that we can start showing a business, we can start showing revenue and return for it?
The issue I think, and I see that in other organizations is that that thinking is maybe not done with enough diligence early on, and it tends to be treated as more of a IT or infrastructure effort, which then the questions you ask yourself is what’s the cheapest way to move the most of my infrastructure to the cloud possible? How much can I outsource? How much can I just get onto the cloud thinking about it much more in terms of cost and in terms of what’s going to give me the most, what can I call it, the most infrastructure or the most bandwidth move to the cloud, versus really thinking, what’s that small piece that I might move to date that will make a difference for my clients? And I will start educating my clients on, oh, there’s value in adopting this new version of the tool I’ve been using for 20 years that is now in the cloud because I can do things like over the air upgrades of the software because I have better reliability mechanisms tied to the product. So that’s how I would think about it.
What Do Technology and Organizational Transformation Have in Common?
Mike Cottmeyer
So when we do a core transformation, one of the things that we do is we tend to look at the organization through a business capability lens. So we look at the organization in terms of what it produces, what are the teams required to produce it, what are the technologies required to produce it? And we look for encapsulation opportunities. Basically it’s like where can we break dependencies, where dependencies are left, we put in mechanisms to manage ’em. So what I’m kind of trying to explore a little bit on this thread is he’s mentioned the idea of planning and maybe insufficient planning and awareness. Is there an opportunity to look at the technology infrastructure similarly to the organization? Because what we have to figure out how to do is because we never have the luxury of telling the company they can build less or they need to do less, or it’s like we have to figure out how to do the transformation in space. So we’ll look holistically at the whole organization and the whole solution and then try to figure out how strategically which pieces to start to pull apart over time so that we can realize that economic value for the customer. Is that kind of what you’re getting at? Is that how you’re thinking about it or something
Philippe Bonneton
Else? Yeah, a couple of thoughts come to mind around this. The first thing is I agree with you, it’s hard to tell a client or you should do less, but maybe you go back to that client or you start by thinking, do I need to go make a billion dollar investment into this project right now? Do I need to go hire a thousand engineers right now or should I take a slice of that first and say, how do I build it more organically with a smaller chunk of the business with not tackling right away the big money maker of the company? So I don’t know if it’s doing less, but I think it’s being a little bit more thoughtful and strategic about how do we start in a way where we can fail and learn without much risk? I go back to this idea of the two big to fail that quickly happened there de-risk this effort, how can you start a smaller team?
How can that team not cannibalize? That was the other issue we haven’t touched on yet, which is I’ve been very focused on the migration or the architecture itself. But the piece we haven’t talked about yet is that when you move this big monolith from traditional legacy systems to the cloud and you have a whole new economic model around it that’s tied to it, right? You start selling software licenses, you disrupt the whole way of selling or the whole value chain beyond just the engineering piece gets disrupted. And so it might not be telling the client to do less. It might be telling the client, how do you de-risk all that? How do you pilot? How do you start with a much smaller batch or slice of your business and build the muscle memory around it, build some of the best practices organizationally, the way you deliver that software, the way you sell that software, and then you expand from that.
And I think what I hear a number of clients talk to us about their cloud efforts, and it always starts with, oh, we are on a three year journey. We just committed $500 million to our big cloud migration effort. And you can sense when they talk about it, it’s already overwhelming. It’s already like many people’s jobs are tied to this commitment. And so how do you start it simply put in a more agile way? How do you start those efforts by saying, okay, let’s understand business outcomes we’re going after. Let’s see how we operate today, how we deliver and operate our software today, and what are those pieces that we can take and learn from at a smaller scale and build a little bit more predictability for the future and kind of ramp up our effort to migrate versus coming in as a big IT effort and saying, all right, our CIO just committed $300 million to this effort and now we’re tied to AWS or Azure and we don’t know how, if we ever need to get out of this, if we have cost overruns or anything like that, we don’t know how to do that.
Mike Cottmeyer
Okay. So kind of the two big takeaways I think from that particular exploration was the idea of, or maybe three being incredibly planful about how you’re doing it, the idea of taking the big batches, breaking them into small batches and doing them in a way that is risk mitigated and economically justified. And then maybe the third point might be is making sure that all the business processes that go along with that cloud migration are being migrated in parallel with the technology. So it’s not just an IT focused initiative, anything. I got it.
Philippe Bonneton
And I mentioned de-risking or lowering the risk, but I catch myself when I say that because when you start thinking about your cloud migration, when you start thinking about the promise of cloud, I don’t want to only talk about it as let’s make sure there’s less risk when we do it because there is a tremendous opportunity around it. There’s actually a tremendous opportunity to say, now we have a tool that the whole organization can use. We have a new way of building software, building product, delivering value to clients that again, is much more modular, much more scalable, should be the promise of cloud, is that it’s much more cost efficient. So its less, it’s about de-risking, but it’s also about how do we maximize that opportunity? How do we start reshaping our teams so that they make the best use of the cloud architecture that we’re building or that we bring or that we’re migrating to? And so I guess my point here is I mentioned big budget, three year migration programs, sounds scary, sounds overwhelming. People might lose their job over that if it doesn’t go well. But you can look at it completely differently as well. A glass half full, which is each of these businesses, is a tremendous opportunity to really transform into an agile, scalable, modular type of organization. And that can be overlooked. I guess the point is cloud investment is not just a tech investment that you need to a tremendous opportunity.
Mike Cottmeyer
So, I think like anything, we want to maximize the value, maximize the return on investment, minimize the risk, so that values received.
How to Get Early ROI on Cloud Migration
Mike Cottmeyer
Okay, cool. Well, so let’s pivot into the second case study that we talked about. There was this one organization that you worked with where they basically went down this cloud migration path and then had some calculations around return on investment, payback period, things like that, and then got deeply into it and started realizing that maybe the economics weren’t there or that the payback period is going to be a lot longer than they expected. Why don’t you set up that story for us a little bit and see what we can pull through on it?
Philippe Bonneton
Yeah, very interesting story, and we’re moving to a different space here where we’re talking about direct to consumer Netflix type model, the streaming of content to consumers and how the cloud can be used. We talk about cloud here a lot about as the architecture that powers your enterprise, but we need to remember the cloud market overall. The biggest chunk is just consumer market. It’s the consumer cloud. So this company, I was working at the time at Amazon working with a number of players in the video gaming space, and at the time it’s still pretty trendy, but at the time the big thing was cloud gaming. How do we break boundaries of your console, your pc, and just make high definition gaming available anywhere on any device, any screen with the power of the cloud? Again, very strong, tremendous opportunity, very strong value proposition behind it.
And without getting into too much details about which company specifically that was, there aren’t too many players in that space. What was very revealing to me at the time about the challenges of moving to this cloud, economic models, not just cloud architecture, but economic model was the disconnect that I found in a specific organization between the engineering side of things or the product and engineering side of things, the business development and commercial side of things. And then the financial side of things, and I’ll name this. So you have a team that goes and builds an amazing cloud streaming product for video gaming. They’re just the best at it in the world, and they’re going to build something with the latest technology. It looks amazing for a consumer. Then you have the commercial side. So they do that and there’s a cost associated to that. They think in terms of getting the best possible product, but there’s a cost associated to that.
Then you go and you have your biz dev team, your marketing team, they go out and they go and they try to lend partnerships with a bunch of other content providers, device makers, just let’s make this thing as big. The pie needs to be so big. Our product that we just built that’s amazing needs to be available on any device, any screen, anywhere. And so you have those well-oiled engines that are figuring that out now that marketing and commercial side, they think in terms of revenue, they think in terms of adoption rates. And so they’re really looking at that. Those two sides of the business are not fully aligned and fully connected. So you have a big cloud undertaking here, but there is a missing point, which is the perfect reconciliation of how much does it cost to sustain this, and then how much can we really drive with adoption rates, compatibility of devices and so on.
And to me, the most revealing part is you have this beautiful cloud vision and story and the person who cuts it, the person who comes in one day and says, pause, we’re not doing any more. We’re not writing a single line of code until we figure that out. Is the CFO of the company that comes in and says, show me the economic model that tells me that for every hour of game streamed or every new customer adopted, I’m making money. I’m generating a profit, and tell me how far, where is the breakeven point of this big cloud undertaking? And so that’s something that I think is very revealing because again, you can think about big cloud initiatives as it driven or tech driven. You can think about them as big commercial plays, new monetization. I’m releasing a new product, I’m turning my boxed software into a cloud available product, and it’s going to completely change the economics of my business. But then you come back to, okay, tie these things together. Show me the cost justified business aligned formula here. And if you don’t match, if your breakeven point is not clear, the whole thing falls apart, the whole thing gets put on hold and then you never see another press release for that beautiful cloud gaming vision that was exposed earlier on.
Mike Cottmeyer
Yeah, that’s fascinating. Just for everybody else, Felipe and I, we’ve known each other for maybe a year and a half now at this point, and we’ve been working together pretty closely for about the last six or eight weeks. And so I don’t know everything that’s going to come out of Philippe’s mouth as we’re sitting here talking, right? So there’s a little bit of exploration going on and it’s fun and it’s kind of neat. But one of the things that I think is super fascinating is that this is the problem that the software industry has had for 20 years, right? It’s like we believe that we can identify all the requirements up front. We believe that we can do the design. We believe that we can do the architecture, we can do the build, we can roll it out in a monolithic way, and that at the end of three to five years, somebody’s going to want to pay for it or it’s going to deliver the value.
And so the problem at the agile space has been trying to solve again, 22, 23 years now at this point, even before the signing of the manifesto. It’s like how do we structure and orchestrate the work in such a way that it’s potentially shippable, that it’s always valuable, that it’s always testable, that it’s always deployable. And that way at the CFO comes along and says, Hey, we’re done funding this. We have the highest value software product that we could possibly have. And what we’ve really learned viscerally in leading Agile’s core business over the last 13 years that organizations are the same way. We do a lot of work with product organizations and services organizations and technology enabled services organizations, and it’s all the same thing. Big things into small things getting value out in the market. And what I just heard you say on that front, Philippe, is that cloud migration tech uplift has to be looked at the same way. It has to be looked at as how do we do this in a way that is continuously economically justified, that is continuously valuable, that is profitable from day one, and so that the migration begins to fund the migration over time? It’s the exact same problem just applied into a different domain.
Philippe Bonneton
And I think an interesting aspect of the story I just shared here is whether you like it not this big cloud vision, this big move to the cloud, whether it’s motivated by some technology efficiency aspects or commercial aspects, it’s going to transform you whether you like it or not. Because going back to that example, the metrics I’m tracking as a business leader, when I’m selling boxed software, I’m selling video games, I’m distributing them or I’m selling the console itself. The metrics I care about is how much does it cost me to manufacture that and pay the licenses for the content? What’s my consumer price? And then once that’s done, I’m done. I don’t have to continue to worry about that customer. They bought my game, they bought my console. When I move to cloud gaming, it’s a completely different business. I have to care about customer adoption, usage, monetization over time.
I have to care about latency. I have to care about software reliability day to day, not just like is the software that I’m shipping in the box bug free, but is my system up? Do I have outages? How do I prevent them? How do I minimize the cost of outages or minimize the cost of outage prevention? It’s a whole new business, and so it will transform you, and so you will have to have new capabilities, new business functions, new ways of measuring the efficiency of your operations, new ways of hiring, and of building a culture around. So it’s fascinating about it and where I see the clear link with what leading Agile has been doing for years now, it’s when you start on your cloud journey or on your, we talked cloud here, but when you start to infuse more in your business, when you start to leverage AI and ml, it’ll transform you. It will force you whether you like it or not. You cannot continue to operate as you were with your legacy system once you move in the cloud. And I think that’s the challenge that a lot of companies see in hindsight, we needed to fix or to change the way we operate as we were starting this big technology undertaking.
Mike Cottmeyer
Yeah, that’s awesome. Really cool. It is just fascinating to me the amount of parallels between these two things and just human nature and the way we tend to think about change and migration and just building things and transforming things. Fascinating.
Cost Optimizing Cloud Migration
Mike Cottmeyer
So the last case study, we talked about people that get really deep into these cloud migrations, right? There’s, you have the development costs, you have the DevOps, you have the automation issues, things like that. And one of the things that we’re seeing is people just throwing bodies at it. So how does a company, when they get into a migration, do it in a way that maybe the word I’m looking for is cost optimized, intentional, making sure that we’re getting the right return on the investment so that we don’t find ourselves going down this path and things spinning out of control in ways that we didn’t anticipate.
Philippe Bonneton
So a couple of things there. The first one I like to bring up, we touched a little bit on it earlier with my first example, but when you migrate your applications to the cloud, if you were carrying tech debt in those applications, they just perpetuate the cloud. They didn’t just magically solve things and all of a sudden your applications run with very low maintenance required quite the opposite. I think if you migrate applications that are in an architecture that has some level of tech debt, some level of just unfinished work and optimized aspects to it, when you move to the cloud and now you can scale everything and now you have to think about how you provision your services and so on, and how you manage reliability of these applications. You’re now facing a set of interdependent issues and risks and threats, and I’m talking here, reliability, but same thing is true for security, just security compliance.
All these things are starting to become multi-layered challenges for your organization to manage. And to your point, we see clients throw bodies at the problem bodies and tools. I’ll say bodies meaning how do I staff my DevOps team and my reliability team to make sure I don’t run into, I don’t have any outages right now. We sold for the cheapest short-term solution and we’re going to go find engineers offshore. We can outsource that to a big consulting, and now you have 500 a thousand engineers that are going to be on call and that are going to do very, very repetitive tasks. Those engineers, they would be way too expensive to hire and they’re just too scarce onshore, and honestly, no cloud engineer wants to do those sorts of repetitive maintenance tasks. So that’s the first challenge you have is throwing bodies at the problem and then throwing tools.
Just last night I was talking to this company that is in the space of configuring virtual machines for the cloud, and they say, yeah, yeah, we’re solving the problem that AWS or Azure doesn’t solve because with us, you just press a button, and you get a machine that’s automatically configured in a data center and it’s easy. And I had the same example with another company saying, oh, we are going to automate away the resolution of your cloud issues. We’re just going to build algorithms and you press a button and it automates away things. So you see all these point solutions that to be fair, have value, they’re great, they can save a ton of money, they can drive a lot of efficiency, but they don’t fix your core issue. They don’t fix your, and being new to leading agile, they don’t fix your system of delivery.
They don’t fix the system that creates or that exposes those vulnerabilities in the first place. I think one of the things that we can help our clients do is how do you scale your cloud operations and your cloud infrastructure? How do you start building more sophisticated? How do you really take advantage of the cloud in terms of scale, in terms of sophistication, which you can do with those applications, with the customer experience you can build, do that without scaling your costs, without scaling the number of people that are going to be opening and closing tickets just for maintenance. How do you scale your cloud business without putting all your best engineers on, fixing stuff on maintenance task, and you keep them doing the strategic work? So how do you free up that time?
Automation is a part of it, but I think you want to build the right organization as well underneath it. You need to have, what we see today is at clients, I think we see fragmented organizations. Everybody has their own set of best practices of how they manage the cloud. You have different stacks, right, between the different organizations that a client, so how do you harmonize all of this? How do you create more of a central governance body within your company that will look at cloud DevOps? We see clients doing more and more of that, those central cloud DevOps teams, but also a central cloud efficiency team whose job it is to figure out where we can make better use of what’s offered by an AWS and Azure or A GCP, how to automate the provisioning of applications, how to drive a culture of accountability and cost efficiency across the layers of the organization as well.
So one example I always love to talk about that is engineers today who are building the apps that run on the cloud don’t have necessarily the incentive to think about the cost of it. They think about building them, right? They don’t think about building them in a way that’s going to lower your AWS bill or your GCP or Azure bill. So this is the sort of culture or the sort of way of working that you want to infuse across your engineering organization as you move to the cloud is this is a very powerful tool, very scalable, very efficient if we do it, and if we all have those same sort of metrics that we track from the engineer writing the code to the closing a ticket to the DevOps leaders all the way to, again, it goes back to the CFO and so on, it goes back to the second example I was sharing earlier. So those are some of the things I think are important. The key takeaway for me in my rambling answer here is the natural instinct is to throw bodies at the problem or to go adopt the next tool that’s going to give you better observability, better automation, but those things require the right system underneath to be truly efficient and to really deliver what you’re looking for.
Mike Cottmeyer
Yeah, it’s just, again, it’s just fascinating listening to you talk about this because one of the things about LeadingAgile over the last 13 years is we take a very systems thinking approach to this. What I’m hearing you say, just using that language is that so much of what we’re doing is local optimization. So much of it is only focusing on one part of the problem, not considering the whole. And to me, gosh, just at the end of the day, it all comes down to encapsulation, it all comes down to orchestration. It’s like minimizing dependencies. It’s all the same fundamental underlying thinking and underlying science.
In Search of the Composable Enterprise
Mike Cottmeyer
So as we wrap this up, Philippe, I think the vision, and there’s a word that I picked up in industry, it gets written about. I think Gartner talks about a little bit the idea of the composable enterprise, right?
At the end of the day, what we’re really hunting for, whether it be through the language of business capability modeling or the language of domain-driven design, the idea of a product-driven organization, the idea of moving from projects to products, a lot of these buzzwords, I think what’s up underneath all of ’em is this notional idea of a composable enterprise. Basically an enterprise composed around objects, an enterprise composed around composable subunits of the company, alignment between people, process and technology. That’s the holy grail.
So let’s assume we could get to that. What kind of possibilities open up in the area of data optimization ai? I just got to figure if we had a really well-formed technology organization, and for the geeks out there just like with defined inputs, defined outputs, defined performance characteristics, service levels of that composable enterprise, what do you think is possible from a data perspective, an analytics perspective, an AI perspective? What does it open up for us?
Philippe Bonneton
Yeah, so it’s interesting to hear your talk about composable enterprise, and it’s one of those terms, and I’m new to leading Agile, and I listen to that term, but what it brings me back to is many years ago when we started this journey of digital transformation with Accenture, when it became the thing that we talked about and it was to the cloud already at the time, the technology, the way we talked about the technology was modular architecture, microservices, all these things. Essentially the concept of now you can break things down into small pieces, you remove the dependencies in the technology, and you can do so much more with your software. And I think what we’ve been hunting for here is great. Your technology and your architecture can do that, but the organization that’s wrapped around it, can it do that? Or is it still a bunch of silos and a bunch of metrics is and if so, it doesn’t matter how modular and agile and composable your technology is if you are not operating as such. So it’s clearly to me where we’re going, what we’ve been fishing for, what we’ve been fishing for in the last easily 10 years around digital transformation. Now what happens if you can do this right? If you can build that composable enterprise and you have the right technology, scalable, agile modular underneath, to me, it opens up some very interesting things. Another buzzword, since we’re throwing a few buzzwords here, is the idea of self-healing networks, self-healing architecture. Love it.
Working with this company, I mentioned kind of like a reliability automation company. The value proposition behind it is your engineer, instead of having to go into the system and fix things and then commit the code and say, I fixed the problem, we are going to start to automate it by saying, okay, problem identified, press a button, script deployed, no longer need to code or access a system. That’s the first layer of automating things. Ultimately, the vision is the system understands the anomaly before the outage happens and the system fixes itself. That’s where you become very, very composable, very modular and not reactive, actually. You become very proactive at it. So it’s such an interesting concept because it’s true for cloud reliability, but it’s true in so many other industries or at so many other levels. I’ll finish with this one example. I worked for a big one of the leading home builders here in the us.
They asked for our help to figure out the future of home building. What did that mean to be in that business in the future? And obviously that was maybe six, seven years ago. Obviously, we gravitated very quickly towards data, ai, ml, and those sorts of things like the connected home and all the data points that you get out of your home and what you can do with it. And we all have heard of the use cases of, oh, your fridge is going to tell you when you need to go buy more food or your fridge order food for you. If it says that it’s empty, we were pushing the envelope further and saying, in the future, you could have a self-healing, self-maintaining home. You live in there and your home knows how to maintain itself. The appliances, just even the structure knows when to call the right services to come in to fix something before it’s broken, just based on data. That’s possible, and I know I’m just sharing some anecdotal examples here, but it’s to open up our minds to what it means when you start to operate as a composable enterprise and you make that use of data and of modular cloud-based technology. That’s what it opens up for you, and that’s what I find fascinating about it.
Mike Cottmeyer
Yeah. Cool. So Philippe, thank you so much. I think we’re on the cusp. A lot of what we’re doing with, again, business architecture, domain design, organizational transformation, we do outcomes-based plans, what we’re moving towards as a company is a way of looking at the entire system from technology to people moving towards this composable enterprise. I love the introduction of the idea of a self-healing network. I just think it opens up a lot of possibilities in the future, and so it’s pretty exciting where we’re headed. If anybody is interested, if this has been an interesting conversation, anybody’s interested in having us pull on a different thread and a subsequent video, happy to do that. Would love your feedback, would love your comments, and give us some guidance on what you’d like to talk about us to talk about more. We’ve got a lot to say on the subject. We’ve been dancing around the periphery of this for several years and we’re on the verge going all in on it, so it’s a pretty exciting time. So again, Philipp, thanks. Welcome to the team and looking forward to working with you for years to come in. Talk to you soon.
Philippe Bonneton
Thank you, Mike. Thanks everybody.