A Change Model for Moving Legacy Systems Into the Cloud
Technical dependencies often get in the way of companies who are looking to Transform the way they do business. And even when they see an opportunity to modernize their legacy infrastructure, many find that the effort to move to the cloud either isn’t cost effective, or it’s more of a hinderance than it is a benefit. In this video, Mike Cottmeyer sits down with our Managing Director of Consulting to discuss some of the challenges associated with moving your applications to the cloud and what you can do about it.
Video Transcript
Mike Cottmeyer
Hey everybody, thanks for joining us today. Dennis and I are going to do something a little bit different than we might normally do. There’s kind of a class of problem in the industry that we are working with. It’s kind of agile transformation adjacent. It’s a little bit of maybe an impediment to agile transformation that we’re going to explore. And I’m going to talk a little bit about what leading Agile’s doing about it and what we’re doing in the market. And then we’re going to talk a little bit about some of the things we’re seeing with client challenges. So Dennis Stevens here with me who co-founded Leading Agile with me about 13 years ago now, and is our chief methodologist. Hey Dennis. How you doing, man?
Dennis Stevens
Good, Mike, how are you doing?
Mike Cottmeyer
I’m doing good.
Technical Dependencies That Prevent Transformation
Mike Cottmeyer
Okay, cool. So this is what we’re talking about. So one of the things that we know pretty well about this transformation space is that we’re to a point where it’s just so clear industry-wide, that this is not about agile practices, and we’re starting to see market shifts in such a way.
There’s a lot of coaches that are being let go. The market for training in a lot of ways is collapsing because I think what people are experiencing is that doing scrum daily standups reviews, retrospectives, burn on charts, right? It’s like it’s necessary but it’s not sufficient and it’s kind of been packaged as sufficient. So one of the things that we’ve been talking about for a long time is this idea of encapsulation versus orchestration, right? So leading Agile brings this idea of business capability, architecture, teaming strategies, flow-based governance, ultimately starting with business capabilities, but ultimately organizing around value streams, incremental and iterative transformation. And that’s really been the hallmark of what we’ve been doing for the last 10 years at least. And so what we find in that is when you start to think about the areas of what gets in the way of effective teaming strategies, effective agile governance, effective coordinating at scale, it’s always dependencies, right?
Dependencies are the things that are so expensive and there’s certain kinds of dependencies that are more straightforward to deal with. Orchestration dependencies, teaming strategies, how we think about products, how we think about funding. There’s a bunch of things you can do on the process side, but at the end of the day, if we don’t have appropriate encapsulation in the technology and appropriate alignment between the technology and the business, it’s really difficult to get the kinds of performance characteristics in organization that we’re all shooting for. And one place that we see a lot of different things in our clients, things that are adjacent to what has historically been leading Agile’s core business. So what we are encountering quite often is the industry is really calling tech uplift product modernization. There’s moving to the cloud, there’s the automation of infrastructure, DevOps, CICD pipelines, and what we believe is that the intersection of all of this is alignment of all those things.
And on the other side of alignment of all those things are the economic conditions that have to be created to be successful. It’s been on our website for at least 10 years. It’s never about going to agile, it’s never about adopting agile for Agile’s sake. So Dennis, one of the things that I was hoping we could start with, and we’re going to step into this, so let’s not try to answer it all at one time, but what do you see, see in terms of technical dependencies that are getting in the way of moving into a more agile delivery, agile product model? Talk to me a little bit about that and then we’ll move into cloud migration and some of the other tech uplift and financial stuff that we want to talk about.
Dennis Stevens
I think some of the initial things are just as a lot of people are operating in the enterprises that we’re in, they’re not working on very small, very autonomous like sections of products. They’re still working. It may be in the cloud, it may be outsourced, but there’s still giant monoliths that are very difficult to manage. So the teams still require tons and tons of orchestration and coordination between the teams to deliver anything. And I think it goes into the data and the integrations too. As people have tried to go into modern architectures, they’re actually simplifying things. They’re integrating more and more things together. So the ability to move fast in any area is really constrained by the network monoliths that are being created with these big integration nests.
Mike Cottmeyer
Interesting. Let’s pull that thread for just a second. Go a little bit deeper into this. So as they try to solve the problem of encapsulation as they try to solve the problem of modernization, you’re saying that they’re creating, there are other issues that they’re creating?
Dennis Stevens
Yeah. I’ll give you an example. We have a client that’s using a product called Pega, which in and of itself is a big mess of things, but Pega is through a bunch of connectors connected to 12 other backend systems through a bus, and any change made in Pega can show up and break something somewhere else. Any change made somewhere else can cause Pega not to work well. So they’re kind of going to solve it by building giant backend integration tests and slowing down delivery and having to do giant upfront designs because in their attempt to go to independent products, but in order to get where they’re getting data has to move between all these products. Integrations have to work. They’re actually, nobody’s paying attention to the gray area between the pieces and they’ve created a rat’s nest of implementation.
Mike Cottmeyer
So let’s go into that. So what is the gray area that nobody’s paying attention to?
Dennis Stevens
Who’s responsible for testing that the transaction that comes out of your service catalog into your bus and back up to Pega, like the service bus people’s piece work, the product catalog piece works, the Pega piece works, but the path of data through it is a mess. The transaction itself isn’t what was expected. And so even though every vendor’s piece is working, integrated whole is failing.
Why Companies are Moving to the Cloud and the Challenges
Mike Cottmeyer
So there’s tremendous amount of pressure maybe to move to the cloud to get on more modern technology architectures. So talk to me a little bit about why companies are making this decision and what they might do as an alternative if this isn’t working the way they expect.
Dennis Stevens
Yeah. The reason for moving to the cloud is because they believe that getting to these SaaS or infrastructure service, all these service-based platforms will increase their speed and performance. It will reduce their cost of maintenance and their need to keep things current and their staff and their data, disaster recovery and security. There’s a lot of things that they aren’t going to be experts at is focused on their business. So the cloud has a lot of benefits in that area. The challenge is the processes are not easy to set up and run end to end, and a lot of times those pieces are all outsourced to different vendors or different products. And so what’s making it difficult is you should be able just to enter something in your service catalog, have a pipe through and pump up and show up as an offer and another tool. You should be able to take a bill over here and have it show up in your CRM system over there. But the data has to be exactly right. The interface have to be exactly right and it doesn’t get tested until the end or until the day before you ship it. It’s very difficult for most organizations to manage at the edges.
Mike Cottmeyer
One of the things that I’m not usually a big fan of industry buzzwords, but one of the things that I’ve been reading about a little bit that I think is really at the heart of what we’ve attempted to do with leading Agile is the idea of the composable enterprise. So I think a lot about the intersection, maybe business architecture, organizational design, domain design, product type organizations, product driven organizations and such. So the holy grail in all this is much smaller applications, much smaller monoliths, monoliths with products extracted and services extracted and such like that, and then organizing around that value, creating complete cross-functional teams, optimizing for throughput, all those different things. So given what we’ve learned over the last 13 years, talk to me a little bit about how we might apply those things into these uplift and cloud migration problems that we’re seeing in our clients with our clients.
Dennis Stevens
The first one is just what must be true for that technology to actually be composable or maintainable by the delivery team? It’s got to actually be able to be built and tested and performed in a way that wasn’t previously expected when it was set up. It can’t be built on. It’s got to be built on a low trust, high assurance sort of model, but people aren’t building the technologies and the tests around the monoliths or around the modules or functionality to make sure that it follows all the rules that it’s necessary for the network to work. So they’re not really getting autonomous technologies and a lot of times it’s in the transaction and the data interaction, not just the code. And so things are not holding well together. You end up with a ton of tailoring and customization. We ran into this with one of our clients up in Indianapolis where they’d use salesforce.com and they’d built everything on salesforce.com and then they had tailor it and customized it for every individual region they had done it to get out of the habit of having lots of customized, difficult to manage. We’re trying to get the benefits of SaaS, the benefits of cloud, and ended up with the inability to change anything that everything else breaking.
Mike Cottmeyer
Interesting So basically in the attempt to move to the cloud, they in effect reestablish the monolith.
Dennis Stevens
They didn’t change their processes, their data expectations or the behaviors and the groups. They recreated the network of transactions that existed previously.
Mike Cottmeyer
So let’s pull that thread. That’s a really interesting thread. So what you’re basically saying is that they did the technology transformation, but they didn’t change anything else about how the business worked and ended up replicating the monolith on the backside. Talk to me more about that. Yeah,
Dennis Stevens
In a SaaS product, but everybody had their own tailored customized functions. Upgrades were impossible to do everything they were trying to solve for. They just recreated all because they didn’t go after or understand the implications of the variation in process. The org design that was still networked, not product oriented, and so they just recreated the same rat’s nest of transactions. Everything’s tied to be managed across everything.
Mike Cottmeyer
So is maybe a way of saying this that if you do the modernization and you do the cloud migration, you do the tech uplift, all these cool buzzwords, but you don’t actually do the refactoring, you don’t actually do the extraction work, you don’t align the business processes to the new technology models, you’re going to end up with the same problem.
Dennis Stevens
It’s absolutely what we’re seeing. Yeah.
The Implementation Patterns of Cloud Migration
Mike Cottmeyer
Okay, cool. Okay, so let’s shift gears for just a second. So one of the things I’ve been educating myself, maybe I’m a little late to the party, is with the idea of cloud migration because a lot of our clients are doing big cloud migration implementations. A couple years ago, Matt Van from Pillar joined us and we built a studio to do some of this extraction work. So it’s not my wheelhouse per se, but it’s something that leading agile as a company is playing into. Let’s talk generically a minute about the different patterns of cloud migration. Certain things I hear like lift and shift versus or maybe cloud ready versus cloud enabled versus cloud digital. Talk me through some of that and tell me how, maybe not just what the industry buzzwords are, but how are we seeing these ideas actually applied on client sites?
Dennis Stevens
Yeah, I’ll stay away from the cascade of S. There’s like a lot of people are talking about in different s, right? So one pattern is you’ve got something running in your data center and you want to take it out of your data center and put it in another data center, the lift and shift sort of model. You put the exact same thing that it’s in. You might do that because you’re trying to move rapidly out of an expensive infrastructure and physical asset people cost. It’s really expensive to have a data center. It’s really expensive to have disaster recovery for your data center. It’s really expensive to have all the people running it. The physical assets around it are super expensive, hard to maintain in many cases are data have not been well taken care of because they push things in the next year and the next year and now their data centers just are going to be very difficult to keep running, becoming more and more and more expensive.
Mike Cottmeyer
Before you go down that path. A little bit more, last little segment that we were doing, you were talking about how we’ll bring in vendors, we’ll move different parts of the app will get different parts of the app working, but there’s not ownership of the gray area. It was like the network effect between different components. So am I hearing you say that when we do a lift and shift and we have these gray areas, is that gray area keeping us connected to the data center and if so, what’s the impact of that?
Dennis Stevens
Yeah, so we’ve seen that in several cases where there’s, it’s still hardwired into the data center maybe for some access to a payment processor or some sort of other secure location, and they don’t actually have permission to connect their cloud instance to interface that they’re working through. So they end up having to leave the physical infrastructure in place until they sort that out or work that out vendor. It could be contractual, it could be compliance, it could be legal, but in a case of ours, it got overlooked and was very, very expensive. They just didn’t unwire the pieces. Another case, the disaster,
Mike Cottmeyer
We’ll talk about that. Very, very expensive. That’s really interesting. If we can figure out how to crack the code a little bit on where that cost is, it might be an interesting discussion to talk about how would we recoup that cost?
Dennis Stevens
They had to hold onto the physical data center for an extra two years.
Mike Cottmeyer
So the business case for the cloud migration and tech uplift was largely funded by the deprecation of the data center, but because we didn’t have all of the different impacts assessed, we couldn’t execute that move deprecate the data center, regain those costs. So therefore the RI on the transformation wasn’t realized. Is that what I’m hearing you say?
Dennis Stevens
That’s right. And it falls into that space of gray area. The application went up and worked fine. The data migration went up and worked fine. The interfaces and the backside of that and a service call they needed to make a network service call they needed to make, they couldn’t move the network piece, the pace they needed to and some of the data connections get data in and out of the back of the system moves. They missed dependencies, but the vendor wasn’t responsible. Those dependencies, the vendor was responsible for moving the product. So they moved it and it worked except they couldn’t run it and they couldn’t provision their customers with and had to leave everything in place in the data center until they resolve those
Mike Cottmeyer
Problems. So you might’ve answered it. So I grew up, I know you have a lot of background, PMI, project management, things like that. To me, that’s kind of like good project management in a way. I hate to say it, being a guy that runs an agile transformation company, so I know you made the case that people, how do you get ahead of that and make sure that that realization or that ROI realization can happen
Dennis Stevens
In this case from a feeds and speeds connectivity network standpoint, the dependencies just aren’t always clear. And so you’ve got to do a much better job of inventorying and having a strategy for all of those dependencies and some of those things it looks like, oh, that’ll be easy. We’ll figure it out once we get it moved. In some cases it just isn’t as easy as it looked, particularly if you’re moving multiple pieces and in this case there was a little bit of they were moving multiple things at the same time and got out of sync. So yeah, it is just project management, but the problem is because the components aren’t composable or movable or able to move around in the first place, it requires massive insight, massive understanding of all of your technology, and even though you think you’re moving like the whole monolith and your lift and shift, it has to be everything because even those monoliths aren’t autonomous or composable even in the big piece in lot cases.
A Change Model for Breaking Down Legacy Infrastructure
Mike Cottmeyer
Well, so we encounter this problem a lot with our clients. It’s not typically the space we play, although we do play in it some, right? We encounter these challenges with our clients. Talk to me a little bit about the things that we’ve learned over the last 13 years moving what I would call monolithic organizations into more composable organizations. What lessons from that transformation work might be applied and is it even reasonable to think that you could have a incremental iterative move to the cloud where we’re able to experiment and learn and try things, but yet realize the cost savings and the ri? And that’s a big question, but let’s peel into that a little bit.
Dennis Stevens
Yeah, I think it’s kind of straightforward. If you can’t encapsulate, you have to orchestrate it. We learn a lot in our organizations about dependencies and process and dependencies and requirements dependency and funding. When we try to make these teams autonomous and all of a sudden we find out that that planning process needs to be updated or we have to do something special there, that funding process is a problem. That resourcing of environments and things like that has to be updated because the team isn’t really very autonomous. There’s a ton of orchestration we have to do. So we spend time when we first get started and those dependencies are hidden by the chaos that the organization’s operating in. So if we can create a stable system and we can balance capacity, demand, we start to begin to see those dependencies. We can start to measure those out. So we don’t go straight to total autonomous independent teams operating without orchestration. We put a heavy amount of orchestration on top of anticipating. There are things that we might not know and we move a lot of planning up into the left. So
Mike Cottmeyer
One of the things that’s interesting, I’m going to kind of pull back to some of the really simple messages that we’ve been talking about for years. One of the things I’ve always struggled with when we kind of get into just the agile conversation is that there’s this idea that if we train the teams on Scrum and we empower them and then we let them make local decisions, that they’re going to kind of work things out. And I might make the assertion that within the confines of a well-formed scrum team with good boundaries and tests and very componentized architecture, that level of collaboration within the team is absolutely appropriate. Let’s pull in a little bit because some of these things you’re talking about, it sounds like what you’re saying is that we got legacy monoliths, unclear responsibilities, and we have a lot of chaos and confusion. Not a lot of people that deeply understand. If the answer isn’t hand it to the teams and let ’em figure it out. But the answer can’t be just command and control top down, just govern the heck out of the chaos. So talk to me a little bit about the middle ground and maybe from the angle of the middle ground from a process perspective, kind of a place that we’ll play a lot probably 80, 90% of the time, and then maybe we can explore the idea of how would we begin to bring order to the monoliths and shine light into the gray areas, something like that. That’s kind of where I want to go.
Dennis Stevens
When we set up a delivery team, we know that the delivery team lives in an ecosystem in the organization. That ecosystem includes how you do product strategy, how you understand your customers, how you decompose that into work the teams do. It has to do with how we do business strategy and how we set priorities and how we deal with economic trade-offs in the work those teams be focused on. It has to do with how we fund and budget teams and infrastructure and security in the million other things. We can walk around multiple aspects of the wheel, how we staff organizations, how we build teams, what leadership measures and rewards. So we have a number of those. We can look at a team and go, these are decisions we can move into the team right now. These are decisions that have to get orchestrated right above it because it can’t be collapsed into teams.
These are decisions that probably need to be orchestrated even higher, maybe at a portfolio or sometimes talk about an investment tier in a bigger organization, and we get kind of explicit about what the dependencies are, where they need to be orchestrated, and what the cost of having the inability to delegate them, what the cost is to the organization, start to measure and make it be really explicit and then get on the path of deprecating and removing those dependencies over time and removing the compensating controls to reduce cost and increase agility over time. So we have an idea of what all those pieces are around the teams. One of those things that we keep track of is the technology and infrastructure, the architectures and operating systems, operating operations and infrastructure that those teams exist within. And so we will do a lot of cleaning up of the teams within the constraints of the technologies and build into up into the left in our governance model. A lot of paying attention to those dependencies and what’s actually possible.
Mike Cottmeyer
When you say up into the left, right, we’re thinking for tiers, we’re thinking bound based flows. So what’s implied and up into the left is that the decisions are being made at the right level of authority and early enough in the process, so up and to the left early enough in the process to where they can actually inform the dollars and the costs and the budgets and all that kind of stuff. Is that what you’re
Dennis Stevens
Saying? That’s right. We just don’t want to put the delivery teams in a position of being responsible for delivering predictably when we haven’t created the conditions. We’ve left them with a bunch of dependencies and constraints and things that they can’t possibly orchestrate or resolve on their own, and they’re supposed to self-organize around it. That’s like the failure mode of most companies that we go into that have tried to do some agile or lean process.
Mike Cottmeyer
So the pressures of moving to the cloud. So we’re trying to deprecate the legacy infrastructure. We’re trying to reduce costs, we’re trying to optimize the performance characteristics of the business, and we have deadlines. I mean deadlines are real. We don’t, don’t have infinite time to rewrite everything in terms of services. We don’t have infinite time to be able to do all the necessary extraction work and business alignment work and everything or else it would take us a decade to move out of that data center. So what do you tend to recommend? Maybe see what do you tend to recommend for how can we get those costs realized quickly without leaving all the gray area stuff behind, all the reasons we can’t seem to get out, so how do we do it fast and then improved over time? Maybe something like that
Dennis Stevens
When we start to look at the pulls and pushes of doing a big move. So what must be true to do a lift and shift of an application and what are the things that will go wrong with the lift and shift? We’re going to have too much cost. We’re not going to be able to resource constraints, but we’re not going to have the organizational challenges that we had. We’re not going to have some of the cost of change. You balance those two things out, but then you have to dig into those different areas and see what’s really true on what’s not true. So we look at all the dependencies. There’s still some that are going to exist. We’re going to have to modify some of our behaviors around data security or other things that can’t connect to our system the way they used to. So there are going to be process flows.
You got to look at that and come up with the next option is let’s start to do some re architects. Let’s cut the boundaries off in relatively big chunks. Let’s build some stuff that we might throw away in two years, but it’s going to make it possible for us to move the big thing out, get the data center gone. We’re going to build some stuff that we’ve not be using in two years, or we might be doing some stuff that makes it okay to operate in a less than optimal fashion. It’s interesting when you look at the technology path, Mike, it’s the same conversation that we’ve been having around organizations. Some of the compensating controls that we put in place are actually not best practice where you might want to be in the future, but they’re absolutely necessary today. So they might have to build some stuff that bridges the gap for a while to get out of the data center.
Mike Cottmeyer
So what you’re saying is that, just let me pull on that just a minute. Right. So what Dennis is referring to is in our Basecamp one base camp two model, we actually have a fairly heavy governance framework because in the presence of a less than optimal organizational design constraints in the enterprise, dependency management always comes back to dependencies. We put in a fairly heavy orchestration model, but we get the agility by operating it in small batches and what we call it is a compensating control. And I think about it often is if I need to do a lot of heavy architectural work, let’s say I think about it in the context of restoring a legacy, like a classic piece of physical architecture like a building, maybe something like Notre Dame going through a wholesale rebuild in a lot of ways, you got to put a lot of scaffolding around the outside of it so that it’s safe to start reconstructing on the inside. And so with us, that’s planning and governance, but we do it in small batches, so we maintain agility. It doesn’t take the cost out, it doesn’t make it totally team driven, but it enables us to do some agile stuff very pragmatically before the organization’s been fully rebuilt using that building metaphor, the Notre Dame or anything like that, talk to me a little bit about what’s involved in creating some of that scaffolding, some of that non reusable stuff we might deprecate. What does that look like in real life?
Dennis Stevens
We might take sets of business logic that are really complicated, not well characterized that we can’t replicate or go rewrite in the near term, and we might take a big chunk of code, put in the container, write some interfaces to it and move it intact in a less than modernized way into the cloud as a big piece and then move pieces to interact with it. So we might have to build, might have to encapsulate that with some test scaffolding that’s really there just to make sure this thing doesn’t break in the meantime, but we actually don’t intend to continue to rely on that in the future. Pretty soon it would become a brittle difficult obstruction to the speed that we want to move at, but right now it’s probably necessary. There are cases of we might want to move a bunch of data that hasn’t. We might move the whole thing, lift and shift the whole thing if we can and just get the boundaries cleaned up. Just get the most critical things in the boundary, but lift and shift the whole thing knowing it’s going to be too expensive in the cloud and then start pulling pieces out of it incrementally and moving them up.
Mike Cottmeyer
Yeah, we were talking a lot internally about the analogs between our Basecamp structure and would it apply into some of the cloud migration work that we’re doing? And what we were kind of hypothesizing is that when we think about most organizations that we move, the rule of thumb I’ll use is 60, 70% need to go to Basecamp two, maybe another 20, 30% need to go to Basecamps three, maybe four, basically saying there’s a lot of legacy stuff that we’re not going to reinvent. We’re not going to get to the place where we totally untangle that org, but we’re going to get it stable and optimized and predictable and operating in smaller batches. Then maybe 20 or 30% of the org really needs true agility and maybe five or 10% needs lean startup like crazy, super fast stuff. What I’m hearing you say is that, and tell me if I’m interpreting this right, it’s like maybe we do a really safe lift and shift.
We make sure that all of the outside boundaries, you put the scaffolding around it, make sure it’s working, and we know that in doing so that we’re going to eat some costs, right? It’s not going to be the most efficient way of doing it. Then we’re going to start to think about, okay, what are the services that need to be extracted to drive those costs? And we’re going to do those first, or maybe we’re going to start to look at what products need to be extracted so that they can be more cloud native and more resilient over time. Am I thinking about that the right way?
Dennis Stevens
Yeah, absolutely. Absolutely. Okay, cool. One of the things that we’re seeing in the industry, Mike, is 40% of cloud migrations are reverting back because
Mike Cottmeyer
Interesting. What’s driving that? Is it the inability to get out of the data center, realize the costs? Is that what you’re getting at?
Dennis Stevens
Or There’s a big one, which is they didn’t realize they needed that data. As data becomes a more important play, they move the data into the cloud, but it’s still encapsulated. They need to bring that data back so they can pull it into their mesh and do more things with it. And there’s a thing called data gravity, which is a really interesting concept to start to think about when you move things into the cloud, which is the data starting to pull as data becomes more central, starting to pull more and more connections to it, more and more uses to it. So moving that monolith might be great for the process and the infrastructure, but I might need that data to be pulled separately and process in different way. I need to use it in 20 or 30 ways that I never thought about using in the past. So it becomes interesting how data starts to pull itself together in an organization.
Mike Cottmeyer
So maybe put a bow. It sounds like there’s a lot of really interesting things that we could maybe do some subsequent discussions around. It might be interesting to pull the thread around data analytics, maybe pull some threads around the application of artificial intelligence. It might have implications for security. Absolutely. And our kind of classic PDO composable enterprise, just agility at scale. There’s a lot of really cool topics that intertwined, but it sounds like though that if we can’t get some of this tech uplift stuff done well that that’s really going to put a barrier in front of some of the other business things that we’re looking to try to achieve.
Dennis Stevens
You can’t get there, so you might move everything up to the cloud to get your cost savings now or to get some benefit now, but it’s not your final move. There’s going to be three more moves after that. You’re going to pull your data back into a hybrid sort of data model. You’re going to deprecate and move some services out of the cloud that you’re not using anymore. You don’t want to pay for the storage now. It’s expensive. You might start consolidating things that you didn’t intend to originally. You start to look at the, so it’s an ongoing process. It’s not a, I’m going to do my cloud migration and I’m done. It’s I’m going to move into a new type of technology and infrastructure that creates a whole raft of options that I’ve never even considered before and explore those and enable those as we’re moving forward.
The Role of Business Architecture and Alignment
Mike Cottmeyer
Yeah, I think what we’re seeing is that there really is a lot of parallelism because one of the challenges that we have a lot of times with agile transformations because we clean up behind a lot of really poorly done agile transformations, and there’s a belief that agile works a certain way, and unless we go straight to that way, then we’re not doing agile. And it sounds like there’s a lot of people that are either just lifting and shifting and not doing that well, or they’re spending years trying to rewrite these apps in the cloud in a more services oriented way. And so what we’ve been hunting is how do we realize the economic benefits now and do that in a really responsible way, understanding all the costs, all the risks, all the trade-offs, understanding all of the compensating controls that have to be installed and then very systematically pull apart the architecture. So we’re optimizing that spend. We’re optimizing our financial stuff. But then I’m going to go back to something that you said earlier that if we don’t get the business aligned with it while we’re doing it, that we’re going to just end up recreating the same mess in the cloud that we created locally. Am I hearing that right?
Dennis Stevens
That’s correct. Yeah. So when we look at, there’s two sort of interesting threads here. One is, but it’s related. One is that business architecture lens that we want to look at our organizations around has always been a way to look at the technology and the business simultaneously. We tend to move on the business process product development side. More recently, we’ve been doing more and more of the technology move, but they’re not different lenses. It’s the same view though. Things that need to go get encapsulated, need to get encapsulated together, the business processes that need to get adjusted, need to get adjusted together. And it becomes really, really clear when you look at it holistically, how those two things fit together and then the patterns of failure are exactly the same. You move one and don’t manage the dependencies around it. You don’t pay attention to the business piece when you move the technology.
Mike Cottmeyer
What I think is fascinating is over the years is that we’ve expanded our aperture outside of just core transformation work. It seems like the business is using the language of business architecture. The technologists are using the language of domain-driven design. The product people are using the language of product-driven organization or projects to products. The agile community is insistent upon complete cross-functional teams. Some of the Gartner research is talking about the idea of composable organizations. It sounds like it’s interesting to me that all of these domains are talking about the same thing, but they’re not talking to each other. Do you have a point of view on that?
Dennis Stevens
Yeah, there’s not a unified way talk about it, and there’s all kinds of reasons for that. Vendors are selling tools in different areas. Consultants specialize different areas. It’s a risky proposition to sign up for fixing the technology and the organization and your product understanding. So people probably don’t want to walk into that game. It’s a lot easier as a manager and an organization to be responsible for your piece of it. So
Mike Cottmeyer
Maybe we should just create an organization that’s able to look at all that stuff holistically and then very safely move an organization incrementally and iteratively to where it wants to be. You want to build that organization, Dennis?
Dennis Stevens
Yeah. Yeah. I might start with understanding who my customers are and how we deliver value to ’em and then work backwards from the business capabilities, the organization, and then find the most important ones to move and start improving them from a systems wide holistic standpoint.
Mike Cottmeyer
Cool. Well, it sounds like there’s a lot of things for us to keep talking about. We thought this was kind of an important conversation because over the years leading Agile is we’re really growing and evolving. We’re getting ready to do some pretty interesting things in the marketplace. It started a couple years with our studios practice. That’s really starting to take off for us some of this product extraction work, some of this alignment of product strategy, technology, architecture, organizational design, integrating those into our change management business transformation offerings. It’s starting to be pretty powerful. So we’re going to try to figure out some ways to speak about that better in the marketplace. And so I’m excited to have in more of these. Any parting thoughts as we wrap this up? Dennis,
Dennis Stevens
Mike, I think it’s a really exciting, really exciting time and I think the industry is starting to see all the pieces. We were talking yesterday about five or six different movements that are sort of looking at it the same way, like you said, and not seeing each other. I think this the next generation technology, next generation organizational designs are the physics of it becoming evident in the market and we’re starting to figure out how to move people there.
Mike Cottmeyer
Well, thanks for your time, Dennis. I really appreciate it. Know you’re busy doing a lot of client work and helping me run a company and everything, so being able to pull out an hour to set up this conversation is meaningful. So we will get some time over the next couple of weeks and we’ll do a few more of these. I’m really excited to pull through some of the threads, especially around data. I think data is interesting. I think AI is interesting. AI readiness is interesting, and I really think it all kind of hinges on that same physics that you were just talking about. So it’ll be fun to continue the conversation. And everybody, thanks for listening. If you made it this far, we really appreciate you. Appreciate you guys tuning in. Hope this adds value. We’d really be interested if anybody has any points of view based on mine and Dennis’s conversation where you’d like to see us take this.
We’re doing some really interesting things and exploring some interesting things that are getting actually tough to write about because it’s like you’re almost in the land of writing books and you’re in the land of writing long form position papers and anything. We’re all pretty busy, so we’re just going to try to open up a conversation and just talk about some stuff. So if there’s any threads in this conversation you’d like us to pull, I’ve got Dennis on deck. I got a lot of smart people that work here in leading Agile, and we’ll get ’em on camera for you and we’ll start unpacking some of this and see if we can create some shared understanding. So anyway, until next time guys, thanks so much and we really appreciate as always tuning in. Have a great day. See ya’.