How DevOps Enables Business Architecture Alignment

In this video, we explore our iterative and incremental Agile Transformation framework and discuss why this approach is valuable to large organizations attempting to adopt sustainable Agile practices.

Additionally, we’ll discuss the common failure modes we often see in our clients’ business architecture.

Then, we’ll identify opportunities where you can implement DevOps practices alongside Agile methodology to improve your Agile metrics, accelerate business alignment, and achieve your desired business goals.

Lastly, we’ll cover how our all-new Studios offering is helping our clients implement all this and more.

Website: https://go.leadingagile.com/jvc

Agile Transformation white paper: https://go.leadingagile.com/0i0

Also, check out our newly redesigned resource center. We collected all our articles, white papers, webinars, and more into one easily searchable location: https://go.leadingagile.com/bks

Contents of this Video:

0:00 Our Agile Transformation Framework

2:21 Business Alignment Failure Modes

5:12 DevOps & Agile

8:27 All-New Studios Offering

 

Transcript

All right. Today I want to talk about product extraction and how we can use that to reach higher base camps.
First, when we’re tallking about product extraction, let’s talk about what hasn’t changed from what Leading Agile traditionally does. So if you know Leading Agile, we have an approach and an opinion on how you take slices of an organization through a transformation. And we have not changed that. We still have base camps and treks and expeditions and outcomes based plans. So what we’re talking about here when we’re talking about product extraction and technical dependencies is more of a yes and. Yes, we need to do what we’ve traditionally done, and we need to do these things in order to be sure we’re successful at reaching the higher base camps. This is just another view of the same thing. We’re going to very much be focused in on the slice of the pie here around technology and architecture, but all of the other types of dependencies and external orchestration need to be dealt with. And we still care about all of those things, we’re just focused in on the technology and architecture slides too.

So when we’re looking at moving from base camp one to two to three, what we tend to find is as you’re moving between base camp two and three, there’s a set of technical dependencies and impediments that really make that trip harder. When you’re looking at a base camp three or four team, our goal is to break the dependencies and increase local autonomy, where different teams or different products can work at different paces and be enhanced independently, built independently, deployed independently, and tested independently. And in order to do that, these technical impediments need to be dealt with.

So that’s the framing of the problem we’re going to talk about today. So let’s talk about what is product extraction and why would I need to do it? When we plan an expedition or plan a transformation, we help you identify products that align to your customers and markets. And as you do that, we look for products that we can put one to two pizza teams around so people… The idea of the pizza analogy is that you could feed the team with two pizzas for lunch. So it’s not a huge team. But we want those teams to be able to enhance, build, test and deploy their product with minimal orchestration, right? So we want that team to be able to be laser-focused on their customer, internal or external, in solving that problem and not being overly dependent on all the other teams. The challenge is, in big enterprises, the system architecture could look like this, and if you overlay the product architecture, the two don’t align. There’s… They weren’t designed with each other in mind.

So if you simplify the problem and you look at it and say, “We have… If we just had two products, we would want to have each system that supports that product have clear APIs, contract tests and mocks, so that each can be worked independently, and again, that they could be enhanced, built tested and deployed independently.” Sometimes that’s not possible and we have one big system that we need the two products to co-exist within. But then we need to be able to have two teams working within that code base and they need to have componentized build and test protection so that they can each make changes without being overly dependent on the other.

As you get to more complex environments with mainframes or packages, you’re going to have a combination of the two models, where you’ll have… Like in this diagram, product one, two, three, and four… Let’s say they could be mobile apps or websites that have their own system that can be built in a way that it’s independent, and we have other product teams that might all be part of the same ERP. And they need to be able to do things in a componentized way. Ultimately, the acceptance criteria are the same, but the strategy is going to be a combination of clear, separated APIs where possible, and componentized builds where necessary. So that’s the goal, right? We want our systems, architecture, and our product architecture to align. If I use another analogy here, if you had an architecture and you wanted to take one component out of the architecture, it would be like picking up one chocolate chip or one M&M, and many times the design of the architecture isn’t the problem, it’s what happens to the implementation over time.
So as heat gets applied, right? The architecture loses some of its encapsulation. So heat in this analogy could be deadlines, could be changing requirements, could be new market forces… But what we often find when get to a client is something that looks like this, where there was a good architecture design, but as things changed, it’s a bit of a mess to try to figure out “How do I separate things? How do I divide and conquer?” Right? It’s not a soft gooey center when it’s heated up, but still well encapsulated with good protection around it. So there’s two approaches to deal with this. If you’re… In most cases, what we can do is we can extract a product from this architecture and get it into an encapsulated product.

So we did decouple the code, we refactor to have clear APIs, we create contract tasks or mocks. And in the process of doing that, there’s other practices like continuous integration and test data management that will also be improved. Sometimes if things are so bad that really there’s not much of the initial architecture left, we may be doing component rewrite where the market’s changed so much or the APIs are so unclear that we need to basically write some decoupled code and do it more or less from scratch. So that wouldn’t happen for an entire application usually, that might be certain components within it. So you may do a mix of product extraction and component rewrite or reimplementation in order to get to the model that you want, where your product architecture and your systems architectures are aligned. And ultimately, that’s what’s going to help you reach that base camp three and four goal, by continuing to do the things that you do at your expedition and transformation level around the people and the process and so forth. But starting to look at some of those technology dependencies that provide a lot of drag in the process.

In the end, if you can align your systems architecture with your product architecture, you’ll be able to move faster and respond to the market more quickly. And that’s essential for base camp three and above teams. We believe that product extraction is something that every organization needs to do. We have a few ways that our studios and our technical coaching can come alongside and help you get there. The reason you need help in getting there in many cases is because teams that are just forming and just getting used to some of these agile practices are not experts in refactoring and product extraction. And long-term, they don’t need to be. Because once you have the product extraction done and things are working in an independent way, you don’t need to bring in a separate… You don’t need that additional skillset. So oftentimes we find, either for speed or for capacity reasons, clients are looking for someone to help them with their product extraction.

We do this from two different stances, from a studio stance where you can put a team in that can do the product extraction or the refactoring or the reimplementation of the components to get your software into that modular state. We also, from a coaching standpoint, have a scaled technical uplift model where we can help your teams improve their skills. Often the best way to do this is a one-two punch, where during your expeditions, you have a scaled technical coaching model implemented so your team’s technical skill is increasing. And then for those higher order skills that are a one-time need, or there’s not enough capacity to handle, you’ll bring in a studio’s team that can do the extraction, turn it over to your uplifted team throughout the journey of the expedition, and then eventually move on to solve other problems. Studios and technical coaching are two ways that we can help accelerate and improve your ability to get beyond base camp to base camps three, four, and five.