It is a broad topic architecture. Yes, it is. Where do you wanna start? Technical sociotechnical?

Um, Kind of both. Well, one of, one of the questions that always comes up is how relevant is architecture mm-hmm. In today's world. Yeah.

I I, I think that's a good one to start. I mean, I think it is, it is pretty relevant and, uh, it affects a bunch of things. Not just, you know, the, the software, the process, the systems that you work on, but obviously how the people work and how the processes support them too. I think they're all, they're all coupled, um, hence kind of Conway's law, right.

If you don't get it right, you end up with, uh, organizational structures that reflect kinda the architecture of your software. Sometimes it can be good, sometimes that can be bad. Yeah, definitely. I was, uh, uh, pleased to see the emphasis in accelerate on loosely coupled architectures as a key enabler Yes.

Uh, For being able to adopt DevOps and, and move faster. Yep. Agreed. Um, The degree of coupling in the architecture, as you say, directly drives coupling in the teams.

Yep. Um, and of course, the more coupled the architecture, the more fragile, and then that sets up this feedback loop where breakages in production cause people to get farther and farther off, off of DevOps. Right? Yeah.

Like when you've had a big outage, it takes a lot of, um, institutional courage to stick with the, the DevOps approach rather than falling back to more familiar chapters. Yeah. So high coupling in the architecture leads to fragility and production, which triggers that social loop, uh, that pushes you away from DevOps. Interesting.

Yeah. The other thing I like to accelerate, you know, kind of related in the area is when they talked about transformational leadership, they really kind of highlighted that transformational leaders really help teams kind of rearchitect their systems. So it's not just, you know, it's not just kind of a, you know, a leader facade from the standpoint that, you know, you don't understand enough about the systems to really help, um, to help your people. It's really helping them, a architect build the processes.

All the other things around DevOps, like continuous delivery integration, and also the culture, uh, very important there too. Yeah. And I think the influence goes, uh, in two directions. So the leader has to make the space for that change to occur.

Um, uh, sometimes the information needs to come from below on, uh, what are the boundaries that aren't working today. Hmm. Uh, teams don't often like to point at something and say, you know what? I need to own that in order for us all to work together more effectively.

Yeah. Or I'm gonna give you this, and no, it doesn't come with headcount, doesn't come with budget, but this responsibility belongs in your area. Yeah. Uh, it's, it's pretty tough for, you know, managers to do that, or for architects embedded in the teams to do that, but maybe they surface that information and the leader can say, all right, we're gonna redraw some boundaries.

We're gonna renegotiate some contracts here. Yeah. Yeah. Understood.

So, back to the kind of coupling, I've kind of been noodling that that problem, and I actually talk about it in, in, uh, in my presentation, and I actually have some potentially surprising conclusions, but, um, I think the one thing that I, I've been thinking about lately is there are many types of coupling, and I think I talk, you talk about that in your, in your book and release it. Um, but I do think of kind of two broad areas. One is just technical coupling, like you kind of wired some things together, but another is like functional coupling in, in systems. Um, really as, as you try to kind of reach coherence and get an entire set of systems to work together, that functioning company functional coupling becomes a real issue because it usually requires people to rationalize the functional coupling.

Mm-hmm. And that's a very difficult thing to, you know, it's a much harder thing to do as opposed to, you know, a p i, um, you know, basically you can have a p i versioning that allows you to have decoupling between APIs at least for some period of time, but at some point you have to reach coherence, functional coherence, and that really requires people, and the core requires really heavy coordination to kind of get to get that done. So what are, what are your thoughts? Have you seen that problem?

I've seen manifestations of it in a couple of ways. Um, there's a talk I have called uncoupling where I present my current taxonomy of types of coupling. Uh, the one most people see most often is operational coupling. Right.

System A is down because system B is down. Okay. Um, there's also development time coupling, which is like, um, you changed your interface and so I have to change my interface. Right?

Yeah. And that's something we both do in our code bases and we have to coordinate. Um, there's another kind of functional coupling, which is like, we have all agreed that we're using Kafka to pass messages, and if one of us changes away from Kafka, we all have to change. And it's not that we're necessarily coupling our behavior, but we're using common components that have to be coherent.

Mm-hmm. Um, then there's also semantic coupling where we don't have any code level dependencies. We don't necessarily have any direct calling, but you have a notion of customer and, you know, one customer has many accounts, and I have a notion of customer, but one customer equals one account. Yeah, yeah, yeah.

You know, now we've got a problem if we try to work together. Right. So you bridge that by having the same concepts embedded in multiple systems, but now if we need to change it, we have to coordinate our changes on those semantics. Yeah.

There's an interesting, I, I think I was calling that semantic coupling more like functional coupling, but it, I think it's the, the same thing. And the thing that, the thing that I've been challenged with is when you have that, that functional coupling and folks are trying, or semantic coupling when people are trying to reach coherency, you, I've started to come to inclusion in many cases that that's a better place to use cohesion. In other words, like we, we've separated systems in some sort of way, and now I've got coupling or Samantha coupling and I have two entities or two versions of entities like customer or account, and you're now forever rationalizing the dependencies between those things. So kind of one of my thoughts was that are those areas where you almost need to hug the coupling and it's better to have cohesion because, and put those modules together because then you can use compilers and other tools to help resolve the, if I change an entity, then I might get a compile time error, as opposed to if I have those things distributed across teams, modules, and even like sometimes time zones like you may have mm-hmm.

You know, time zones 16 hours apart, where those teams now have to go figure out how do I resolve semantic coupling? Um, you know, one, one of the counter measures I've been kind of thinking through is that do you really bring those modules together? Is that better than having them separated? Um, it can be, so that coupling sort of acts like an attractive force, like a gravitational force that's trying to pull those things together.

Yep. Um, uh, if you go along, if you sort of go with that force and bring them together so that they're inside the same boundary, um, now you may have a problem when the next module also has that attractive of force and you end up, you know, getting an, uh, uh, unmanageable, uh, mount inside the boundary. So this is where, um, I do find domain driven design to be a useful technique, because the other answer you can say is actually if our semantics are different, that may indicate that there's something actually different or fundamentally different about what we're doing. And maybe it's only a coincidence that we're using the same noun, uh, to call it customer because you've got a totally different life cycle.

You know, maybe your system is in marketing where a customer is someone you sat next to on the plane. Yeah. And maybe my system is in support where a customer is someone who's actually signed a support contract and can open tickets. Okay.

Um, so the life of a customer in your arena and the life of a customer in my arena are, are different. Um, um, so in that case we would say, well, we're, we're kind of being fooled by the, the language Yeah. It has a paucity of nouns to describe these different things. Okay.

So in that case, you would say, we're gonna treat the cement coupling by actually pushing them farther apart. Yeah. And putting an explicit anti-corruption layer where we, we know we're transiting between domains, even if it's like customer to customer, uh, in the entities we're being deliberate about, meaning we're transitioning from a marketing customer to a support customer. Gotcha.

Okay. Alright. And I think that kind of brings up the whole, you know, how big is a monolith and you know, how many microservices do you make? Type of kind of debate.

Right. Yeah. 'cause there's probably a, a, a kind of right size in that area as opposed to, you know, unfortunately the last couple years folks have gone in kind of the microservices theater, you know, let's turn everything into a microservice. Yeah, yeah.

Scoring yourself by the number of services you've created. Yeah. Where that's probably not the right answer either. There's some something in the middle that's, you know, more like four or five kind of bounded contexts, you know, just to kind of give a number as opposed to 50 microservices, bounded contexts to, to right size kind of how big that, how big each of those domains are, and then how much coupling you're going to have versus how much distribution of the, the, all those, uh, domains are.

So that's a, a big trade off that I don't think many folks are getting right these days is to see kind of a lot of arbitrary microservices creation. I, I think that's probably true, um, because we sort of, uh, had had a bunch of promotion of the idea that if I tell you I've got a microservices architecture, I've actually said something about my architecture. Yeah. Um, all I've really said is how am I deploying things or, you know, how am I aligning the operational boundary with the development boundary?

Yeah. Um, but there, there's certainly a need for additional levels of structure in that. Mm-hmm. So, you know, if I have, uh, half a dozen services in my, uh, context, do I allow people outside the context to call all of those?

Uh, or do I create a gateway service or a proxy service or a, a boundary, uh, service? Yeah. Um, those are architectural decisions about, um, how much do I wanna spend on translation layers? Uh, how big do I allow, uh, context to get before I have to split it up?

Is it manageable? Um, do I have greater in internal cohesion than I have, uh, coupling across the boundary? Um, same architectural considerations you would have if you're talking about, you know, modules in your source code structure. Yeah.

Yeah. Got it. Yeah, that's a, it's an interesting problem space. Mm-hmm.

I think one that, uh, kind of needs, uh, needs more thought. 'cause I've seen the two extremes, you know, one huge monolith and then the other extreme, which is 50 microservices and neither seem to both produce suboptimal outcomes. Yeah, definitely. Definitely.

In, in terms of development effort, in terms of, um, uh, runtime cost or operational cost in terms of how much time you spend, uh, parsing curly braces and emitting curly braces. Well, cognitive load at some point, That too, Humans have to understand the domain. And if that domain is distributed in, in such a way, you know, across many code bases, many languages, many, you know, then the ability for, you know, a group of humans to understand it starts to diminish. Um, Yeah.

I think, um, we also saw a lot of adoption of microservices in companies that were in sort of a hypergrowth phase mm-hmm. Where you were hiring people, you know, off the street, put 'em straight in front of, you know, visual studio code or sublime text if you're going back far enough. Um, and the idea was we need these people to be cranking out code, uh, as soon after we hire them as possible because we may only have 'em for six months, um, or we may only have six months of funding left. Um, and in that environment, you want people's knowledge to be as local and independent as possible.

Right. Because they're not going to have time to acquire global context. Yeah. Yeah.

So microservices are kind of a organizational or a, an architectural solution to that organizational problem. How do I assimilate, you know, four x the number of developers in a short period of time mm-hmm. When that growth levels out as it always does, you know, do you really need so many small boundaries or would you be better served with, you know, agglomerating, some of them? Yeah.

Um, it, it, it's definitely, uh, a series of trade-off decisions and it's reasonable to say I have a different answer at different points in my company's lifecycle at different points in our growth cycle and at different points in our sort of technical maturity. Yeah. You also run a bit into the, what was it, the Gartner bimodal it fallacy, which is, Hey, I've got this old stuff, I've got some old monolith and it's crufty, so let's just leave that be and let's build a whole bunch of microservices around it that then end up being dependent on the monolith because the dependency. Yeah.

That's the funny thing about that is it's sort of like, you know, a giant galaxy with a halo of dwarf galaxies around it. Yeah. You know, the giant is still there devouring everything. Exactly.

And so then you end up with, you know, you start fast, you're like, great, I got some microservices to production and a new website, but then I'm can't change the, uh, I can't change the monolith quick enough because I don't have the CI practices, you know, fast deployments, which can be done on, on monolith to some amount. Absolutely. And, and, uh, and then you kind of, You end up With dragging the whole system down. You end up with the worst of both worlds, right?

Yeah. Because you've got the slowness of developing in the monolith and you've got the operational overhead of, of the microservices. Yeah. Yeah.

Yeah. That's neat stuff.