Architecture as a Service

Welcome to Definitely May Be Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale.

Hi, and welcome back to Definitely Maybe Agile. I'm sitting here as usual, uh opposite Peter. Uh Peter, our topic today is architecture. Architecture as a service, actually. Do you want to kick us off?

Sure. I love this topic. It's um it's one of my favorites when I think about uh the complexities that come into play. Um and I because I've seen this happen in a number of ways from uh a new CTO coming in and saying, uh, well, we don't need uh we're gonna go back, but we don't need architecture and firing all the architects.

And that you've really seen that. That doesn't sound like a success recipe.

It it wasn't. It it uh it caused some severe problems, to say the least. Um over time. I mean it it became apparent that uh well architects do actually play a very, very critical role in the development of software. Um however, it sometimes doesn't really necessarily appear that way. And in large organizations, they they sometimes are seen as this ivory tower creating uh diagrams and complex categorizations of things that uh really not very useful or not really intelligible to the rest of the organization and not really um representative of what's actually happening. So uh with the I mean with that in mind, how do you see architecture?

Well, I just wanted to follow up on what you said there, because I I think um architecture is a specialist skill. So should you understand everything that an architect is working on?

I don't think you necessarily need to understand everything an architecture is working on, but you but you need to understand the first part of that, that architecture is a specialist skill, that there is this place where having an understanding of what are the principles we're following, what are the standard elements we're going to be drawing from, what are the patterns we're gonna be following uh so that we don't all wind up running off in a million different directions and then finding that none of the things we built can actually talk to each other. Uh, that's kind of where you end up if you don't have any form of architectural guidance. And so there's this this juxtapose between the best architectures come from the team and the this need for some sort of architectural oversight. And these two seem to clash in the middle and not necessarily agree with each other. Uh, how how do you see it?

I think you've you've uncovered there this sort of uh the gray area, let me put it that way, that we often see. So when we're when we're trying to introduce agility into an organization, we're no longer sequencing all of the work we do, therefore there's no longer this nice lengthy period in which an architecture team can consider what the problems are and bring some of those to the table, for sure. But what that means, of course, is they need to uh interface much more uh um closely to the teams delivering the work. And I would say that there are kind of two things that I've seen happen there. Number one is how do you engage with the team? Because you can't you can't sit on the team in sprint and design architecture. Architecture is a much longer cycle problem to solve. You can't solve the problem in a in a handful of days, typically the most significant architectural uh problem. But then the second thing is is teams respond really badly to this is the architectural solution, just go and build it or only use this. So I mean, we'll talk about the first problem that I described, I'm sure, in more detail. But the second one, when I've been working directly with architecture teams, I like this idea of thinking of architecture as a service. It's not a template or uh you know a cookie-cutter thing that is forced onto the teams, but much more architecture is uh understanding what the problems are the teams are trying to solve and solving those problems through the service of architecture through to them trying to help there is exactly yeah, guiding and putting structures in place and standards and different architectural constructs in place which allow those teams to flourish in terms of whatever it is they have to do, code quicker, more stable, solve security problems or performance problems, and in fact, preempt security problems and um performance problems and things like that.

Yeah, there we there was uh there was a quote from my deming bot today that uh around standardization that actually kind of triggered the thoughts in this direction for this today, and uh which was all around this idea that we we don't have standards of things, so we don't have standard sandwiches, he described it like standard sandwiches, standard houses, standard all these pieces. What we have are standard uh pipes and bricks and lumber pieces that fit together. We we have these standard components that we know that we can rely on, and in the software world we have these two. And sometimes one of the one of the I suppose anti-patterns might be a word for it that I've seen uh in the the agile space is where there's this kind of rejection of the standard patterns, even though they're very often heavily relied on. And so there's this sort of we don't we don't want to admit that we'll actually architecture built and made sure that all those pieces that you rely on to build the software product on top were actually in place. Uh and if we hadn't built all of those underlying pieces, then you wouldn't be able to build the thing that you're building. But uh so let's uh and and I'm thinking some really common fundamental underlying bricks that we need in order to be able to construct the the larger software systems that we build on top of them.

I'm just imagining Lego, yeah, right? The wonderfully diverse models and and so on that you can build with Lego, and yet the number of pieces of Lego is probably not even in the thousands, I would guess. So the underlying underlying components there are standard, very strongly standard, and yet at the same time there's plenty of room there for innovation.

Yeah. And uh and as we as we take and develop these pieces, we often then put them into the system so we can consume them, and that becomes then like the the platform. And but there's always as where we started here, that that kind of this ensuring that we we don't stifle innovation, we still allow sufficient development. And sometimes we may have to go back and say, well, actually, this is not serving us anymore. How do we have that conversation that this is not the architecture we need? We need to go back and start again and completely redo it. And that's where I think this architecture as a service idea is is critical. This we need to the architecture needs to have a strong enough understanding of the context the team is operating in to be able to come back and say, okay, well, this is how we can help you move forward and help work out what that new direction should be and how to determine what that is. Um without a greater understanding, the broader understanding that they they possibly have of the of what else they might need to integrate with in the environment. Like what are the pipes they need to fit into those kind of things.

And I I also think there's there's a tendency in a lot in a lot of sort of architectural minds, if you like, or enterprise architectural groups, to try and plan for everything and avoid emergent need. And I'm the reason I'm mentioning that is part of we were just chatting earlier on, but the uh the whole railway gauge issue. If you look into railway gauges, the the basically how wide apart are the railway lines.

Because this is something that people do, we do exactly.

Yeah, well, if it's not raining outside, what else have we got to talk about? Oh yes, but uh what I find interesting, if you look into Canada, for example, um Canada's gone through many different sort of iterations where they start off with lots of different various gauges, lots of innovation, no standard gauge going on, but of course that limits you as you keep going. And eventually what they find over a few decades, they start standardizing, and then even then they find even more need for standardization because in order to have trains cross the border into the US, of course, then what you find is the US and Canada have different gauges as they're coming together. So the interesting thing there is uh how do we look at this and go, hold on, why don't we sit down and plan this all out? Well, we don't know where it's going to go. And so to start with, there isn't a need for standardization because the first thing we need to do is innovate like crazy creator need to understand that, but then we sort of have to bring everything back to a standard and solidify that as we go forward. And I think that's that's something that we want our architecture groups to recognize is there are certain areas where standards facilitate speed and security and various things in terms of getting work done. But there are other areas where we need to help teams just experiment to find out what the way forward is so that we can then kind of see what the emergent need is, perhaps.

So this is that idea of the architect acting as that guide, acting as the bridge between the teams and building that community of learning, this this this idea that uh together we learn uh and bringing people together to have that idea. And I think uh we were talking around this this idea of like if you have this central architecture team, how they might behave differently from a distributed architecture team. Uh and so so if we if we look at these different these different models, uh I often associate that back to uh architecture essentially being a component of safety in an organization, a component of the safety culture, right alongside security and compliance in these other areas, where you have and the the closer you can put them to the context of the of the value streams they're working with, then the the greater the help they will be to those teams. Whereas if they're off in a like a central ivory tower writing generalized policies, those generalized policies are very hard for a team to apply to the immediate context that they're working in, because there's a disconnect between the two.

Now, what you're describing there, if I'm hearing you correctly, is an argument for um closer to the value stream, more distributed architects near where the work's being done. Uh, I've seen a different take on that, which is the need for centralization when you're looking for, for example, global platforms or global capabilities, technical digital capabilities that are being um and as they get more distributed, they tend to become a lot more uh localized, and very little in the way of reuse is happening, for example. So there's how would that context, that need for something central in terms of systems, platforms, capabilities sit with your so this is the push to get the architects distributed.

So this is this is this interesting uh juxtaposes, and this kind of ties into that platform piece as we start to move things into the platform, but we it this has been the case through in technology for the last few decades where we we centralized everything and we and we took it out of the delivery teams and handed it over to a group called infrastructure, and infrastructure then ran it. And so we we've but at times what we end up doing is we condense too much, we make we try to aim for too much reuse. And uh the the example of this um that I think was given uh in maybe the unicorn project, but I I've seen this example in real life where you have okay, we we currently have three switches in place at a a particular branch office, right? Because we've got three different vendors that need to come in. So they each need to be able to have separate control of those switches. But we decide that, well, from a reuse perspective, there's like 40 ports on each of these, 48 ports probably, and we but so we only actually need one switch, so let's get rid of the other two. But now the problem is you've got three conflicting users of that system all trying to use it at the same time, all trying to use it in a different way. And then one person says, Well, you're messing with my stuff, so I'm just gonna kick you other two people off, and everything falls apart. So the uh once you start to condense things in that manner and you've moved things into the platform, there's this um you get the benefits of the reuse in the sense you might have reduced the overall operational cost of the of maintaining the number of things you have, but the the cost of being able to take an action goes considerably up because I now got to, before I can take that action, ensure that I've got consensus with everybody else that's using that system to be able to take that action. And this is what causes a lot of the problems where we we move everything into a centralized platform, but no matter how hard we try, if you've just got one team building that centralized platform, they can't keep up with everything that's coming in. Because if they have to make one tiny change, and that change potentially impacts everybody else who's using that platform, even if it's something like, say, hey, let's take Kubernetes. Let's say Kubernetes, we run Kubernetes and they say no, we upgrade Docker to the next version, but some people's um some of the team's instrumentation isn't ready to take care of the new version of Docker. So we we might it might work for some teams and other teams fail as a consequence of that. We we break systems as a consequence of a more global change to the underlying platform.

But but is this not uh I mean it feels to me like there's never anything black and white in this. There's a there's a continuum, of course, and there are certain things which should be centrally managed. I'm thinking particularly around performance security, there are certain compliance issues that you you you know, the the headache of trying to manage distributed solutions in that space is the risk is too high. And then there are other things where you want to get the right level of central um direction and standard and agreement as to how far apart our versions are or whatever it might be, and then something distributed which really enables localized, you know, um innovative solutions, leveraging the capabilities around.

Yes, and uh and there's it's I think you brought up a very important word in there, um, and that word's risk. It's the it's all about uh how are we managing risk across the system? And this is understanding that as we look for this, are we making sure that we're providing the people who are going to be making the the decisions at the point that they're making the decisions? And if you consider every line of code that's written to be a decision, then that person needs to know the information they need to know at that moment they're writing that line of code. So how do we provide them with what they need to know in that context so they can make the right decisions and write the and do the right thing? Um, whether that be accessing the eternal data store, do I make need to make sure this is encrypted? What are the policies I need to ensure I've applied? Um, how do I make sure that we're we're using the the right language, the right integration so that for the system, the automation that may exist further in the system can properly uh manage that? Am I using the right versions of things, etc.? So that's a lot of information that if if you're the person who's sitting there writing that line of code, I can't possibly be expected to know all of this. I need to be able to have that exist somewhere in the real in the context I need to be able to actually at the moment I'm making that decision, I can actually execute it. Did that make sense?

Um let me try and summarize it back because it's Friday afternoon.

That'll probably help everybody listening to.

Um but so, in a sense, what I heard you saying is a little bit like that whole architecture as a service. We need the right the the inform, you know, that if I'm coding, if I'm changing the system, I need to know what I need to worry about there and then without having to worry about all of the information that you've just described. So I need to know the kind of the context within which I can make changes or can't. And it almost feels like going back to that idea of architecture as a service. What is the service I need to provide? What are the guardrails, the feedback mechanisms I need so that as a third-party vendor, developer, whatever it is, I'm able to innovate and work in my space and do what I need to do and get the feedback that says, yeah, you probably can't do this, or we're gonna have to talk about this, go look into what's involved there, or that needs to get bubbled up and talked about at a different level.

Yes, and I think that was a good summary of it.

So let me just come back to uh one of the first things I started with, which is um when should the architecture team involvement with a backlog of work begin? Because I said right at the beginning, it can't be when the team at sprint planning, whenever they pick up a piece of work, they go, hey, we're building this, that's way too late.

So the there I I see they need to be they need to be involved right up front, as so many to do with that design piece of it. If we if we have a set of architectural principles which are well known and have been discussed with the team, that they understand what that looks like, or we've got a we've got platforms we can rely on, components we know we can pull from. So we that we're ready to go, and we're we're comfortable that the yes, this is what I need to know. I have no questions. Uh at that point, I you're you've I've got a set of practices and policies and direction, and I know what composable ponents I'm going to need to pull from, I know what versions of things I need, I know what architectural, what architecture I'm looking to fit into, where I'm going to need to go. So I don't have any questions at that point. At the moment that I do, I need to be able to like uh pull my cord and say, hey, hey, can can you come talk to me about this and help me work out what the right direction to move forward here is? Uh and that that again is that architecture as a service right up front to help make those decisions understand and help the that discussion. Um and that but that needs to be done in such a way that we we don't end up with, as I've seen in some organizations, a multi-layer approval process going through multiple committees who you have to create 30, 40-page decks to every one of those committees to go through and to have somebody who's really and and the purpose of those decks is really that this person here who's sitting in their their in their centralized apartment doesn't have the context, so I've got to give them the context. To give them that context, we've got to go and explain everything, which there are some benefits to that, and it means that we've got to explain it. It means we have to be able to.

I notice in all of that conversation, you didn't at any point mention any time frame. Maybe just um just to wrap it up, I think there are two or three key points. And in that some summary that I'm just going to ask you to do, Peter, here, maybe just touch a little bit on some aspect of how far ahead in terms of and I don't it doesn't need to be days and weeks, I'm not thinking that way, but you know, you're working with organizations with agility built in, they're not planning things a year out. They're so where exactly, and they don't have necessarily a staged design step. So how does that happen?

I I think in a similar way that we'd look at it from um the the other elements of the the safety team, so your security and your compliance areas, architecture can engage in the same way for things that we know are critical or that are are gonna be new, that we're gonna be building out some new critical uh value stream, some new critical delivery of capability. Um we want architecture there really, really closely married to what it is that we're building out to make sure that we're building something out that's gonna integrate well with what else we're doing, and that we've we really well we've got a very strong understanding of it. For something that is, hey, we're building yet another microservice that already exists in our known architectural web of microservices that's gonna serve up the lunch menu. And then yeah, go have at it. I don't really need architecture to do that. And if you want to go write it in Rust or something else, then go ahead and write it in Rust, it's as long as we we understand that we've met the right other criteria to do so. Um that that there's less architectural oversight needed. So I from a cadence perspective. I see in that perspective. So how far ahead is that at the moment that I'm doing something that I can see is gonna be that complex, I should be looking right up front and like where it's something longer. It's like, let me check in with you um like a quarter from now, like uh in a few weeks and see if you've got any questions.

I was I was gonna say just to summarize that, the word that's pinning a spinning around in my head is it's risk driven again. Yes, exactly.

Yeah, well, it's uh it's something I keep coming back to. So so to so to sum it so to sum it up, to sum it up, so the there's this balance, right? This balance between the the platform system, ensuring that it doesn't become so rigid, and that you're stifling innovation, that we're not forcing people into something that cannot change, that we're allowing people to be able to take uh pieces and then build things. And that takes you to the second point, which is around composability, that we're we're architecting composable components, that we they're like the gauge of railway. We want to make sure these things fit together so that that's why we need that architectural oversight, otherwise we'll end up with uh a million different things that can't talk to each other, uh, which depending on what we're doing, maybe that's what we're aiming for. And the probably not though. And then there's this idea of the central versus distributed, and we we talked quite a bit about the the benefits, and I guess we didn't really talk so much about that there is a there is a need for commonality of understanding across the architects themselves, so centrally in that manner, but a distributed model allows them to be closer to the context of the teams, and so yeah, that's pretty much I think where we landed with that one. Um, and that's it. I think uh architecture is a service. I really quite enjoyed this conversation. So uh well, what did you think, uh Dave?

Um thank you very much. I always learn so much when we chat. So again, thank you very much. I think there's some great points there, and uh look forward to the next time we get together.

Awesome, and uh me too. And uh yeah, if anybody wants to send us any feedback, it's at uh feedback at uh uh definitely maybe agile.com. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale.