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.