The Art of Being an Architect - Micheal Carducci

In this talk, Michael Carducci focuses on the art and craft of software architecture, emphasizing the importance of understanding the holistic context in which architecture operates. He reflects on his extensive experience as a software architect and how he has discovered that many architectural challenges stem from organizational processes rather than technical designs. The talk introduces a framework for software architecture, highlighting key concepts such as the prioritization of non-functional requirements, or 'illities,' including scalability, adaptability, and evolvability. He discusses the need for strong communication skills, the ability to translate business needs into technical strategies, and the organizational change required to successfully implement new architectures like microservices. Carducci also presents tools for navigating these challenges and stresses the importance of understanding the people-related aspects of architectural decisions.

Now, we're going to dive into a topic that is very near and dear to my heart. And as I was preparing for this year, I did something foolish. I submitted all of these ambitious new talks that I wanted to create. And so, it was eight new talks that I was bringing to you. And in fact, a lot of you were the very first to see some of

these talks. And I couldn't have asked for a a better audience, a better community to be part of. Now, this week in some of the sessions that I've been talking about, I've been reintroducing ideas that have been largely forgotten, but have become more valuable than ever. I gave a talk 2 days ago uh entitled data architecture for AI. And that was introducing an entirely new paradigm for

thinking about data and epistemology and AI and the intersection of all these things. Trying to introduce entirely new models to think about agentic interaction. But I don't think any of those talks have been as ambitious as this one. Because what I am trying to introduce to you in this talk is the art of being a software architect. The truly hard part, not the technical challenge, but all

of the other challenges that we have to solve. Now, I'm going to spoil the ending for You will not walk away at the end of this session having learned everything there is to know. But what I can do is I can give you a road map. I can give you a framework. I can introduce some new tools. Because these are the real challenges, and these are what

separate pattern pickers from the genuine architects. And this is not something that I've just been doing this year. It's something that I've been working on now for years and years and years to make the process and make the journey easier. So, it's my hope today I can give you some ideas. I can point you in some directions. I can give you and leave you with a few

gifts to help you on your journey. So, that's what we're going to do today. If we have not had the opportunity to meet yet, my name is Michael Carducci. I'm a software architect. I like to call myself a holistic software architect. And in the beginning, the reason I sort started to adopt that title was because I spent a lot of the last 15 years working as an

independent hands-on software architect. I come to organizations and I try to help them with the various challenges that they face. Now, at one point in the last 15 years I made a little observation, and it was it was slightly troubling this observation. Basically, I would come in as an and they would say, "We need help with our architecture." And I said, "I'm your guy. I can help

with this." And then I would come in and I would look at their architecture. And their architecture was fine. Their architecture was actually quite reasonable. It was well thought through. It was well designed. But, it wasn't living up to the potential. It wasn't delivering on the promises that that architecture should do. And then I would look around the organization and I would start to realize that the

problem wasn't the architecture. The problem was the people and the process and the practices that they were or weren't adopting. And so a lot of my effort wasn't to design architecture, to build My job was to enable the architecture. And at some point I thought it was really weird that I just spent the last week building pipelines for IAC, for DB ops, ML ops. And most of

that doesn't fall under the purview of architect. And I thought, am I really an architect or is this just kind of how I'm billing myself and I'm doing all these other things? And then one day I had an epiphany. It's all connected. All of it is And I ended up taking that realization and distilling that down into the model that I introduced into my book. And by

the way, if you contact me on LinkedIn, I think my publisher was here, we had a conversation. They said, we have discount codes. And so if you're interested in getting that, reach out to me on LinkedIn or my email, [email protected] and I will send you those discount cards codes. I think I get 100. So the first 100 uses of that code will So definitely first come, first

served. But that was where I started to realize that software architecture is so much bigger than the design. That's why I adopted this idea and this label that I applied to myself as a holistic software architect looking at everything, not just one narrow dimension of all of it. And that, the everything else, that's the art. That is the art of being a software architect, the ineffable, the

stuff that's difficult to define, difficult to articulate, difficult to learn, difficult to articulate. But before we talk about the art, I think we should talk about the craft. I'm going to talk about a project, a hypothetical project, and it's important that I point out it's hypothetical. Any similarity between this and a real project that have has ever existed in any organization, particularly one that I might have

been involved with, is purely coincidental. I even asked my attorney, in other words, I asked ChatGPT, if the things I'm talking about are legally distinct from anything that has ever existed before. And in fact, it is. So, for all intents and purposes, this project is entirely hypothetical and not real at all. So, what is the craft? Well, the craft is about taking the requirements and designing a

way to assemble all the pieces of the system in such a way that the desirable properties in the system emerge. What are these desirable properties? They're the illities. Scalability, adaptability, evolvability, modifiability, elasticity. There's a whole bunch of these. There are an enormous number of these. And you can never have them all at once. So, we have to figure out the right set of illities with the right

set of priorities. We have to think the right way about the tradeoffs that are involved in all of And so, I came up with a definition of architecture because it's always been a hard thing to define. I think in one of the sessions in this room this week, somebody said, "Well, Martin Fowler said architecture is the stuff that's hard to change." If you believe that, I would

encourage you to go to to developersummit.com and find one of the on-demand sessions entitled Agile Architecture. It's a very different way of looking at software architecture. That's one aspect of the model that I put together by synthesizing all of these different ideas that were out there that were connected, but nobody had taken the final step to connect them. And so to come up with a true definition,

stop the stuff that's hard Uh I think another definition I heard, and it might have been Martin Fowler as well, he said, "It's the important stuff." Whatever that is. That's not a very useful answer either. The answer that I came up with, the definition that I came up with was this. Architecture is the essence of the software. Everything the system can do beyond the features and functions.

So, I want you to imagine for a moment that you have a very lofty title. You are the chief at a big enterprise AI project in an organization that is relatively new to the space. You've got solid data science teams. You've got solid engineering teams. But this is kind of a moonshot project for the organization. It's the most ambitious thing perhaps that they have ever done. And

you start with something vague and exciting. A big vision document full of buzzwords. Enterprise knowledge graphs, algorithmic outputs, human feedback, data intelligence, knowledge collection, knowledge interconnects, knowledge tapestry, unprecedented innovation. This is the kind of usual buzzword-driven drivel that you'll get from the business. Some grand vision that somebody somewhere cooked up who had no idea how hard it would be. And now, it's your job to make this

a reality. It's exciting. It's terrifying. But you like a good challenge. So you read this document. You don't just read the document. You read between the lines. You try to figure out all the things that they didn't say cuz they certainly say a lot. There's a lot of words in that vision. But there's nothing in there that informs the architecture. So the first part of the art

of software architecture is to be able to take something like this in the language of the business and translate it into the language of the architect. Another part of that art is being able to do that translation over and over again to different divisions. One of the art part of the art of software architecture is being able to talk business to the business people, talk finance to

the finance people, talk talk technology to the technologists. A friend of mine, a guy named Nate Schutta, who's been here before. He's not here this year, but I hope he comes back. He likes to say that architects are the organizational Rosetta Stone. We are, as Neil Ford would put it, the nexus point in the organization. We are where all these things connect. This is where part of

the art of being a is translating something like this into a technology strategy that the organization can execute on. So the first art is just that, the requirements analysis phase. So given something like this, I would read it and I would start to form a hypothesis. Not a guess, not a hunch, not a theory, a hypothesis, a testable hypothesis. And then I have meetings with various stakeholders

in the organization. I introduce myself. I let everybody introduce their sell themselves. I like to hear what they worry about. I like to hear what keeps them up at night. I like to hear what they're excited about. I ask questions. I don't make statements. I ask questions. And the goal of that question those questions are to test my hypotheses. if architecture is everything else the software is

going to do and the first law of software is that everything is a trade-off every every time we make one of those things stronger, we make something else weaker. That's challenging to navigate. But we're not talking about the art, we're talking about the craft right now. So we've got a set of requirements and from that set of requirements we come up with a prioritized list of illities,

the architectural characteristics, the non-functional requirements, what I like to call capabilities. And another part of that communication is why I call them capabilities and not non-functional requirements. I can say non-functional to everybody in this room and you know what I'm talking about. sometimes in the organization as an architect, I'm not just talking to you. I'm talking to the business and the when they hear non-functional they switch

off. Well, I don't care what it doesn't do, Michael. I care about what it does do. We got all these features here that we want to deliver. It's like, okay. That's great. We know what the features are. We know what the functionality is. What are the capabilities? And in that process of this hypothetical example project this is our prioritized of illities. Number one, it has to be

evolvable. Because it's an emerging space. We're going to be learning new things. We're going to be changing the way it behaves. We can't bake this into concrete. We need to be able to pivot and adjust and evolve and go different directions if we need to. The second one, if you read that document, if you read that integration forms a key role because we're essentially integrating with every

data source in that organization. Integration is very high. It's only second to evolvability because we don't know what the customer's going to want to do once we've integrated all their data. And as they come up with new ideas, the system needs to evolve. It needs to gracefully adopt, adapt, and absorb adopt and absorb both both business and technical change. Interoperability is a strong third. Agility is a

strong force. And as we're doing this to enable that agility, we need that testability. We realize that this is going to be quite bursty so that elasticity matters. There's a heavy workflow component so we need to think about that. It needs to be easy to deploy because without that deployability or falls through the floor. We know that we are essentially integrating the entirety of an organizational knowledge

base from all of their different systems. That's a lot of data. We need to be able to scale to all that data. But scalability is not number one. It's the most exciting. It's the one that we can brag about. Who doesn't love talking about a billion users? But in the reality of things, scalability is important, but these other things are more important. Performance matters, but not as

much as scalability. Configurability matters, but not as much as performance. Simplicity matters some, but not as much as the other things, which means that to get these other things, we might make the whole thing more complex. And cost is the very last con- consideration on this list. It needs to be within the budget, but we've got a pretty big budget. So, where do we go from here?

Well, now we have to think about, well, what exists, what existing work in can we learn from, can we bring into this project to make this work? Now, my friend Mark Neal Mark Richards and Neal Ford, they came up with a scoring system, what they call the qualitative scoring, the star rating system. If you've been to any of Neil's talks this week, you've probably seen their scorecard,

where five stars are the best, one star is the worst. Yeah, 2020, that was a one-star year. the thing is, they built these scores out of decades of experience doing this over and over again and learning the hard lessons. And they give us the score cards. Uh this is published in Fundamentals of Software Architecture, came out in 2020. Another edition, if it's not out, it's going to

be out very soon. Definitely worth checking out. And in fact, they give us a process. They say, "Pick the top few. Pick the top few illities, and we can use this as a rubric to figure out what the best architecture pattern that exists right now is, and we can use that as a place to start." That's not a bad approach. So, what is number one on our

list? is that evolvability. Now, I can immediately You and see which architectures are more evolvable, which architectures are less evolvable. And there's a pretty clear winner here. The second one is integration. Nothing is really particularly good at integration except for that old school uh orchestration driven enterprise service bus driven service oriented architecture, which nobody seriously builds anymore. They're just things that exist and we maintain. So, we

can rule that out and we have to go to a second choice here. The third one is that interoperability. Again, we're going to ignore that last column because that's certainly not we want not how we want to go about it because remember, what's number one in our ilities? Evolvability. And how evolvable is this? It's as bad as it gets. Then we look at our fourth one, agility.

Once again, one star over there. We've got some threes and some fives. We get some things to consider. And then number five, testability. We've got it's kind of all over the place, but by using this approach, we can figure out, okay, for number one, here's our winners. For number two, we've got a winner there, but we've already ruled that one out. So, we go to our second

choice. For number three, we got a winner there, but we can rule that one out. We're going to go to our second choice. For number four, microservices are the clear the strongest contender. And number five, oh yeah, that's our second choice. We're still looking at that one. We're considering that one. And for number five, the testability, it's five stars for microservices. Uh although, when we're looking at

this on that fifth category, there's also something to be said about this service based. But if we're looking at it through this lens, there's a pretty clear answer. Everything is pointing to microservices. Do we agree? Yeah? Hands up if you agree. My reasoning Okay, my reasoning sound. Fantastic. Now, I take a slightly different approach than Mark and Neal because I have the model that I use incorporates

a lot of elements from what they've contributed to the field, but it also incorporates elements from a lot of other people's contributions to the field. So, for me, it's less of this pattern or that pattern, and it's more about tuning. So, I'm taking these, and I'm quantifying these now, and I'm translating these prioritized capabilities into targets into this grid. Now, you can have as many as you

like. We're not limited to just top two or top three. The rules on this process and how I adopt it and integrate it into my model is you can have as many of these as you want, but the rule is no two targets can occupy the same space. So, let's see how microservices in in the general measures up to our capability needs. Here are our targets. And

again, no two are occupying the same spot. So, how do the microservices measure up based on the star ratings? Now that we're sort of quantifying okay? That's not too bad. Right? We're we're over we're above our targets in some, we're below our targets in others. Most notably, we're below our targets uh in the workflow. We're not doing very well at the workflow capability. And integration and interoperability

are not doing that well. But we don't we don't adopt patterns by themselves. Usually, when we start with a pattern, the first thing we do is we start tweaking it. We start adapting it to our requirements. So, that's really what we're going to do here. We're going to start adding additional architectural constraints. I mentioned the keynote this morning that architecture is Architecture, you fundamentally, your architecturally significant

decisions are decisions that constrain the degrees of freedom in the implementation process, whether that's implementation teams or your AI agents. And architectural constraints are the atomic primitives of architecture. They are like the periodic table of architecture. We can put one set of them together and we get one architectural style, we put a different set of them together, we get a different architectural style. And that's the key

thing. This is a composable framework for architecture. So, let's start adding constraints. Now, you remember that capability workflow? Do you remember what architecture pattern that we had in the grid that was very, very, very good at workflow? That's right, the event-driven. So, let's borrow some of the constraints from event-driven. And see, one of the cool things about the model that I created and I talk about this,

you can find me talking about the tailor-made architecture model or the model for holistic architecture and there's a bunch of other talks about this. You'll find those at developersummit.com in the on-demand sessions and those are free to everybody. But, uh, I'm going to take one of those constraints, borrow a constraint though a constraint that specifically is responsible for that workflow We're going to bring in the communication

constraint that we're using in addition to our API, we're bringing in a pub/sub. Now, you notice Some of them went up, some of them went down. This is how this works. We actually assign numeric weights to every single constraint. So, you get design-time feedback on the process. We can bring that in. And now, look, we're doing amazingly well in our workflow capability. We're getting closer. Now, integration,

interoperability, I talked about this on Wednesday. This is the stuff that I was talking about in the context of AI. This is my data architecture for AI. it actually shows up in a lot of different places. The model of JSON-LD isn't just about semantics for AI. It's also about integration and So, we can define those as new constraints to our periodic table, and we can adopt them.

So, that means we can bring in the resource abstraction, and we're using that semantic data. at our integration and interoperability. We lost a little bit on the workflow, but we're pretty close. I mean, we're not far off. The only thing is, our simplicity has kind of fallen through the floor. It's completely disappeared. But, that's okay. We have smart teams, they'll figure it out. And uh we're a

little bit lower than we want to be on testability, but we're not I think we can agree that we've gotten kind of close. And see, what's happened here is our platform democratized the enterprise knowledge graphs. And in fact, in this project, we're doing graph uh rag and graph rag before ChatGPT. And we could handle the scale. It's all there. This was ready to be as big as

our vision. So, as far as the craft goes, how did we do? Hands up if you think we did pretty well for the architecture. Yeah, anybody? Or would you go would you have gone a different direction on the architecture? Cuz that's the other thing. There's no best practices. There's no absolute right answers. That's one of the hard parts of the art Well, generally the consensus was in

the architecture team, in the leadership team, and everything else that this is the perfect architecture. You know, on paper or on the whiteboard. Do you think we're set up for success here as far as we can be as far as architecture goes? We're going to learn, we're going to adapt. But do you think this is a good starting point for that Okay, yeah. Get some nods. I'm

getting some nods. Get some nods. The project failed spectacularly. Even though it's a hypothetical project, it failed spectacularly. And in fact, the project consumed about $40 million over dollars over just two years. And when it was killed, when the project was finally canceled, hundreds of people lost their job. The organization, in fact, didn't just say, "Well, that didn't work out." They actually said, "We're not doing this

anymore." They divested the entire engineering division. And the thing that was sad is within 18 months of this hypothetical project, the rest of the industry was trying to build exactly what we had been building. We could have been first. Instead, we never even left the starting blocks. The reality is it didn't have to fail. And yours doesn't either. So, the craft of architecture is using technology to

solve the technical problems. But the art of architecture is solving every other problem. To put it differently, the craft is the architecture, the art The art is you. And the thing is at that time, despite over a decade in architecture roles, that was a failure that taught me the most. That's why I wrote my book to prevent other people from having to go through that pain. That's

why I wrote this talk and all the other talks that are around it. This is something I've been circling around for years. So, the first lesson we know is architecture is about constraints. We've talked about this now. You've got an You've got a glimmer of an idea of how And in fact, whether you look at the Agile Architecture talk or the Tailor Made Architecture model, or a

model for Holistic Software Architecture, it's pretty clear about architecture being constraints. I talk about the lineage of all that because it's not a new idea. So, we look at this. Let's talk about it what it means in practice. Because the architecture itself, the craft, might have been technically optimal. The problem is the organization wasn't ready for it. See, every constraint closed doors. I wasn't just prescribing an

architecture. I was asking the entire organization to change almost every aspect about how they work. Dramatically, radically. And I was closing doors to what they they comfortable with and what they were familiar with, and I was saying you have to learn entirely new skills. That it doesn't matter what has worked for you in the past. This is a different project and we're going to do it my

way. How do you think that went? It was challenging. But what does this actually look like? To prescribe something like microservices, I can talk about the architectural constraints that define the core of microservices. I call this the microservice abstract style because essentially that's the template that we start with that we derive our concrete architectures from using this model. But it's not just the technical Because what does

the rest of all this mean? Well, we look at this and Mark Richards defines microservices as a single-purpose components that do I'll describe it this way. I'll just describe it simply. I don't remember exactly what Neil said or Mark said. Highly decoupled, independently deployable, fine-grained components that each control their own independent database are grouped by domain and partitioned at the bounded context with communication facilitated facilitated by

some kind of API running in an environment with high operational automation. That's the technical answer. But what does this actually mean in practice? Let's take it apart. Well, if we're partitioning at the bounded context, we have to know where those things are. And if you're in a non-trivial domain, this isn't something that you can do by yourself. You can't just sit in the ivory tower and and

draw a context map and draw the layout of all the domains and subdomains and bounded contexts and everything else. They have to be discovered because that information exists, but it's in the mind of the domain experts, all the business people. And the best tool we currently have for identifying all of this stuff is domain-driven design, which requires a pretty significant investment. You've got to get all these

people together in the same room at the same time and have conversations that are not always fun. It takes days. It's long. It's expensive. It's hard. Because decomposing a system into microservices is more than just untangling code. It's figuring out the module boundaries at a granular level. And the thing is that requires not just an investment into DDD to uncover the natural seams in the business and

the logical modules in the software system, but there's more than that. Because that's only possible in an organization that has well-defined domains. And then Conway's law teaches us that, oh great, you figured all that stuff out, it doesn't matter. Organizations that produce systems are constrained to produce systems that are copies of the organizational the organization's communication structures. What does that mean? It means that the teams need

to be aligned to the domain so they can be value stream teams. So that means after we've done this big, complicated, heavy herding cats investment into DDD, the next step is an entire organizational redesign, breaking apart teams, restructuring teams, repurposing teams. Re- redesigning the entire communication flow in the org chart to enable that That's a big change. And we need sophisticated development teams. One of the things

about microservices that makes all of those five-star scores appear, or at least a lot of those five-star scores is a high degree of decoupling. Microservices takes an extreme approach to decoupling. And to do that, a lot of the decoupling has to be severed. And the thing is a lot of developers would say, "Oh, don't repeat yourself." That's the best practice. That's how we do things. We follow

DRY. Some developers follow DRY like it's a religion. And to tell them that they're actually wrong in the context of this application is kind of like telling a child that Santa Claus isn't real. You're going to get a lot of pushback. You're pushing against decades of best practices that have been beaten into their heads. So, you need very sophisticated development teams that understand that the rules are

contextual, and sometimes you break Sometimes you bend them. We need a very mature development Because to get the agility benefits of microservices, everybody needs to work in a highly independent way. We need a lot of very sophisticated technical practices. These were technical practices the organization wasn't doing. We need high automation in dev and in the environment. We need organizational commitment to devops. That is a non-negotiable. And

again, these are new skills for a lot of Teams didn't necessarily have this. The teams need to work independently. So, they needed to be able to build, test, and deploy without a single dependency on any other team. You add those dependencies back in, the five-star guarantees of microservices, some of them immediately start to go away. We're doing contract-first development. API first development. That's not how we tend

to approach this. The way we tend to approach APIs is we write the code and let the API And those APIs are usually quite a bit in flux. We need CICD pipeline pipelines without a central bottleneck. We need an environment that supports high And we still haven't touched on the disciplines and thinking of event-driven systems because remember we borrowed some aspects of event-driven systems. We didn't touch

on the complexity and the difficulty to start working and thinking about semantics and knowledge graphs and entirely new data models, let alone the complexity of a rag with early GPT with the developer edition of GPT-3 before ChatGPT came out because hypothetically we were using GPT before ChatGPT came out. And see, every constraint demanded something of the teams, the organization, and the environments. And that's our second lesson

of the art software architecture that every has consequences. It demands something of the team. So, part of the art is being aware of the non-technical tradeoffs. The craft is navigating the technical tradeoffs. We're going to move our elasticity up and yes, we know that's going to bring our That's going to That's going to reduce the quality of cost. And this is a big part of the core

thesis of my book, but you don't need the book. You just need to know that the art is thinking about the people, not just the computer. That may be one of the most important aspects of the art of software That the problem exists outside of the computer. The solution exists inside of the And there's more than one problem to We have to be cognizant of the holistic

cost-benefit analysis of each individual architecturally significant decision. The cost and the benefit and the trade-offs there for each constraint. The art is making the right trade-offs now that we know that trade-offs are not always technical. And the reality that we face is you can manage the organizational impact but you can't eliminate it. So, let's talk about some tools that we have to manage this, to evaluate this,

to navigate the art because that's what I want to give you is the foundation of a framework to operate in this space, especially as I mentioned this morning that we are all becoming architects. Now, the good news is the calculus of all of this is changing. If we were doing this now, the team say, "Oh, well, we don't have expertise with this particular flavor of YAML." You

know who does? Your LLM. That can unblock a lot of these. So, that's another aspect of this in the in the year 2026 is figuring out which of these can AI help us help us with. AI can help you as the architect to build the tooling to unblock the team. But, some of the tools to navigate the organizational change, to manage the organizational impact, to measure some

of the stuff, three things that I'm going to talk about, the four-way test, the assertiveness versus cooperativeness, and the weighted decision matrix. Useful tools to kind of evaluate and think about these things. The four-way test is a pretty simple rubric. For every discrete change or decision, these are a good starting point to decide whether this is worth pursuing. Four questions. Is it the truth? Is it a

preference? Is it a bias? Is it hope? You want it to be the truth. Is it going to be fair to everybody involved? Is it going to build goodwill? Is it going to be beneficial to The assertiveness versus cooperative matrix is a powerful tool to think about how to achieve agreement on both the problems and the solutions. So, the art of an architect is to work to

present the changes and the solutions in a way that we are as far as possible towards the upper right corner towards collaboration as we can get. Avoidance is bad. Competition, compromise, or or accommodation, they're a little bit better. But collaboration is the ultimate goal. Now, not every situation's going to get let you get all the way and all the other parties to the collaboration level, but you

want to at least do what you can to prevent avoidance for yourselves and the others. Now, weighted decision matrix is a way to challenge your biases. This is a tool that I use a lot. Essentially, we've got different competing approaches because there's always more than one way to do it, especially in architecture. I think in architecture and in Pearl, I guess. So, we start with solution alternative

one, solution alternative two, solution alternative three. And I like to work with other people when I do this. And then I've got my various criteria that I'm evaluating them from. These aren't These aren't things that I just make up. These are the weighted values that I have discovered in the requirements analysis process. And some of them are more important than other. That's why I assign weights. So,

criteria one has a weight of 30, criteria three has a weight of 10, criteria five has a weight of 20. And then I score these to see which one is stronger, which one is weaker, and then we can just add them up. This is a way to turn a qualitative decision into a quantitative decision. This is something we can involve the business stakeholders in and get them

to agree on how important certain aspects are. Now, a lot of times the criteria that we're looking at, this is architecture-centric. So again, it goes back to being the organizational we are translating things into the value proposition to them. And so this helps evaluate ideas. This helps navigate this. This helps giving data to back up statements that you're making. Because ultimately, what you are doing as an

architect is not just designing the system, but you're driving change. And this is where everything gets shaky. So in terms of effecting architectural there's a five-step process. Identify the problems that require the change. Identify the potential changes. Identify the resources that you're going to need and the organization is going to need to make those changes. Then make a plan to orchestrate the change. And then execute plan.

Well, what are the variables here? I turned to the granddaddy of them all. This is Diffusion of Innovations by Everett Rogers. Everett Rogers is a man who spent his entire life studying how change happens. Whether it's social change, technical change, or anything else. And that's really what this book is about. And he gave us a lot of tools to think about this. And one of them was

the attributes of an innovation. He gave us five attributes. The relative advantage, how compatible it is with the way that people are already working, the complexity of the change that you're trying to drive. Can we do this as a trial or can we do this all at once? And the last one of this is observability. How easy is it to see the benefits? These are the variables.

These are the attributes of any kind of change that you want to drive. And every single one of these correlates positively or negatively towards the likelihood that the change that you're going to try to drive in the organization will be successful. So, let's look at microservices for a little bit through this lens. Do you want me to go back? You got it? Did you get it? All

right. So, let's look at case let's look at microservices as a case study. Now, back in 2016 2017, Gartner, you know, the hype cycle people, unironically embodying the Gartner hype cycle, by the way, were just a year or so earlier they predicted that everybody was going to be doing microservices. They followed that with "By 2019, 90% of organizations who try to adopt microservices will fail. They'll find

the paradigm too disruptive." And now, they weren't clear on what they meant by fail or what they meant by finding the paradigm to disruption not disruptive, but we can look at this through the lens of the model that Everett Rogers gave us. Now, we can compare two architectures using Mark and Neal's qualitative scoring. And you can see that executed well, microservices promise a great deal of relative

advantage. But, the thing is about relative advantage, feelings are facts. It's not about whether or not there's a there's a concrete advantage, it's whether or not people can see and understand and recognize that the advantage is there. So, relative advantage is all about the why. So, executing this architecture, as we've seen, requires major organization-wide changes, and some of them are incredibly disruptive. So, the why behind what

we're doing, the relative advantage, if that's not widely shared across the organization, it's going to be hard to overcome the other challenges that are going to come, that that that are going to follow executing on this architecture. Compatibility. Well, this is going to require some significant changes as we've seen as we went through all the consequences of those architectural constraints. Now, sometimes people say, "Well, this isn't

really new." So, the the fusion of innovations is about new things. But, the thing is, innovations, by definition, are always perceived as new, even if they're not objectively new. So, you're demanding changes from people who might be skeptical. They might not understand the benefits. And the thing is, innovations, the change that you're trying to drive, spreads as people are incrementally won over to the benefits or the

potential We talked about the challenges of Conway's law. What we're learning is that this architecture is probably not compatible with the organization as it stands. The art of being an architect is to decide, do we change the organization, which is hard, or do we change the architecture, which is hard? There's no right answers. There's no best practices. It's going to be different every time. We talked about

how we need the need to understand the trade-offs and why some of these architectural constraints exist. Normally, they will quietly do their own Kind of like how LLMs, when you tell them to do something, will often quietly do their own thing, regardless of what you asked. And then you go back to the chat box, you say, "Hey, um you didn't do what I asked you to do.

Can you Can you look at this and tell me what you did wrong? Oh, I see all the different things I did wrong. Well, if you knew, then why didn't you just do it? Cuz it's an LLM. The thing is, old ideas are the main mental tools that individuals utilize to assess new ideas and give them meaning. Individuals cannot deal with something new, the change, except on

the basis of what they already know. So, for the majority of organizations and developers adopting the strategy for the first time, there's going to be very little in here that's familiar. In addition to the low compatibility, this innovation, this change that we're trying to drive, is extraordinarily complex. Microservices is one of the most difficult architectures to execute well. Breaking apart teams is hard. Breaking apart data is

hard. Breaking apart systems is hard. All of the organizational practices that you have are hard. Uh and then there's the the phenomenon of innovation reinvention. Because people tend to gravitate to what's familiar. And they tend to reinvent your architecture once it's out there. Now, in terms of observability, how easy is it to see the benefits? It's going to take some time. Like a lot of the things

that we can observe about the benefits of they're not going to show up immediately. The metrics we're looking at are lagging, and that makes it really easy for people to abandon something like this. Now, the trialability. In this project, it was we're doing everything like this. There was no chance to do trials. There's no chance to learn from those trials. There were no chance to do that

as POCs. We had a limited runway and limited time. We just rolled with everything that we had. And that's very risky. So, that trialability though is another one of these things. Now, we can optimize because of our we can optimize these attributes. We can optimize the relative And that means being that Rosetta Stone again. What's in it for me? That's the most important question that you can

answer. That's the core of the art of being a A software architect. That's the core that's core of the art of software Is being able to communicate the value to the individual. What is the thing? What does it do? And why should I care? You have to be able to communicate in language that they can understand why they should care about what you're doing. So, I always

define this as what is the And what we really need to be thinking about to become that organizational Rosetta Stone, to develop your muscle in the art of software architecture, is being able to articulate on demand what's in it for the partners, the individuals, the managers, what's in it for you, what's in it for the team, what's in it for your boss, what's in it for the

executives, what's in it for the stakeholders, what's in it for the customer, what's in it for the developers. And this is not a comprehensive list. But you've got to be able to articulate That's the relative advantage. there are different kinds of decisions depending on who has authority. If you have an authority that can just dictate you're doing this or you're fired. This is what Amazon did. This

is how Amazon got to become what Amazon is. The Jeff Bezos in 2002 said, "Hey, we're doing all this service-oriented architecture stuff, and you're either going to do it or you're fired." And a lot of people were quietly thinking, "I don't understand why a bookstore needs to be an extensible programmable platform." But as far as Bezos was concerned, that's not your job. You're not paid to care,

you're paid to build what I tell you to build. And so, they might have had questions, but they kept them to themselves. Authority Authority-driven decisions mean the most important person that you need to communicate the relative advantage to is the authority who can issue the mandate from on high. Cuz I don't think it was Bezos ultimately came up with the idea. Somebody probably convinced Bezos that the

thing that he wanted to accomplish could be very ex- expeditiously accomplished through that mandate. So you just have to convince one thing one person. Collective decisions are the kind that are reached by team consensus. These are usually slower, but if you can overcome that hurdle, they're more sustainable. And so understand the solution, but focus on that broad accept- acceptance. Start by engaging others. Learn what their problems

are, and as soon as you learn what their problems are, now you can frame your arguments. This is why you ask more questions than you make statements. that's why I let other people do most of the talking. And then there are individual optional decisions. This is where people can opt in or opt out. This is definitely not the case with In fact, it wasn't any of these

in this hypothetical project. Because there was no authority, but there also was no choice. Now in terms of compatibility, we have to show that we have to be as compatible as possible with the existing tooling and mindset. And we have to be rigorous in how many changes we try to apply all at once. There's a a great quote from Nikola Tesla in the film The Prestige, where

he says, "Society only tolerates one change at a time." Now, there's another talk out there. I'm going to see if I can find it and put that online somewhere. But uh I came up with a talk called presentation patterns, or sorry, uh persuasion patterns for communicating these ideas. But, I think one of the most important realities of the art of being a software architect is the realization

that perfection is the enemy of progress. So, we have to figure out where we can flex, where we can defer, what we can defer to the last responsible moment. Now, in terms of complexity, new ideas that are easy to understand tend to get adopted more rapidly and more consistently. So, there are strategies that we can do. This is another tool in the toolbox of the art of

software architecture. Here they are. We can create learning guilds, book clubs, regular lunch and learns. Now that we've got GenAI, we can build very good, very polished proof of concepts, reference architectures, build tooling. This is so much easier now. Back in the duration of that project that doesn't really exist, I promise, we had a team that was supposed to be doing tooling, and then they got pulled

off to become a value stream team. And that was a real problem because that left all of the other developers high and dry. Reference implementations, training plans, all of these things. These are strategies you can use. In terms of trialability, change is always seen as risky. So, if you can do a trial, that's less risky. You're lowering the perceived scope and and and and scale of the

risk. In terms of of observability, you've got to figure what you can measure. You can't improve what you don't measure, and it's hard to make a case without So, what we're trying to show is the is the new thing is successful, the problem is tractable, the benefits are materializing, and this is better than the status quo. So, you have to think about what is it we can

measure. How can we visualize this? How can we make it real? To quote Peter Drucker, you can improve what you don't measure. So, what are the requirements for change? My friend and contributing author, Daniel Tippy, came up with a fabulous framework, and this framework is going to be my gift to you at the end of this session. He says there are five things that you need. You

need authority, accountability, responsibility, the knowledge to execute the change, and the will to do something different. Think about your organization right now. Raise your hand if you possess all five of those requirements, you personally. Yeah, my hands aren't up either. Oh, yeah, you. Okay, one one Okay. See, that's challenging. Almost nobody possesses all five. And so, this is the art of engineering change, since you will almost

never possess all five. Is it your company? I want to work where you work, cuz you seem like the that that's how you get stuff done. But, most people won't possess all five. So, it's important to figure out who has what you lack. This is a little form that I fill out. I start with a problem, and I do this at the problem level. Who has authority,

who has responsibility, who has accountability, who has the knowledge, who has the will? A lot of times, I was I was chief architect. It didn't matter. I didn't have any authority. I couldn't tell the teams what to do. In fact, there were three different people who had different authority over different slices of the organization, and none of them agreed on anything. So, what do we do? What

is the art? We borrow authority. We borrow it from those people who have it. That's another reason I have these meetings. So, I get everybody together, and I've already figured out who needs to be there by filling out those little sheets, those little worksheets that I We introduce each other. We I introduce myself. I let everybody else introduce themselves, and then I just listen to their pain

points. I understand the vision. I identify the candidates. I find the metrics that are germane. But the big one is I listen to the pain points. I listen to their pain points. Because later I can go back and say we're making this decision because it's going to make your pain point go away. That is powerful. Then they say, "Yes. Yes, we're doing that thing." And now when

I'm talking to the teams and I'm the architect and I'm saying, "Yeah, we're doing this other change now." And they say, "We don't want to do it that way." And I say, "Fine. Don't talk to me though. Talk to that man right there. Cuz he's got the authority. And then all of a sudden they're like, "Oh, oh, yeah, never mind. Never mind. We'll do that." I'm borrowing

your authority, sir. Thank you. Now, another thing we can do is diffuse the responsibility. We're tying the authority. We're tying it to the authority. We're defining what looks good for each team. We're giving things that the teams are responsible for. We're giving them some ownership. We're giving them they have a they they they have not just a role, but they feel like they've got some ownership. We're

always more invested in the things that we own than the things that we're just connected to. To scale the accountability, what we want to do is do work to align the incentive structures. Because if everything in the organization is incentivizing one outcome and that is at odds with the architecture, you either have to change the architecture or change the incentive structures. Again, of being an architect. In

terms of amplifying knowledge, this is where these strategies come in. My favorite one is the guild. I find the people on the development teams that aspire to be architects. And I say, "You know what? I'm starting an architecture guild. Would you like to participate in the architecture guild with me because I think you're special. And I think you'll get this in a way that other people can.

Doesn't that make you feel special? That's really powerful, too. So, now you're in the guild, and now you're learning more things. And now you are my eyes and ears in that team, and now I don't have to be everywhere all the time as an architect. This is scaling that. Diffusing that knowledge that's part of the art of being an architect. And the last one is building that

collective will for change. Triability matters here. Having platform or enabling teams or the reference architecture really matters here. Because if you just say go figure it you've done the craft and you forgot about the art, and it's going to fail nine times out of 10. But if you can get people on board and make it easy, make you want to make the easiest thing the right thing.

And everything follows the path of least resistance. You're starting to realize that the art is the hard part. Yeah. I've given you analytical frameworks and tools and perspectives and some tips, but there's no recipes. But the good news is this has been an area of deep study for me for many I'm going to show you something. is a chapter from my book. This is the last chapter.

We talk about all this stuff. But one of the most powerful things in here, yep, that looks familiar, doesn't That looks familiar, doesn't it? That That looks familiar. There's a lot of this in here, but it goes so much deeper. And one of the most important things is if I go down here, there's our responsibility, know-how, and will. We talk about these things, but we give you

two more things, the diagnostic And the diagnostic matrix looks like this. Different challenges that you might run into and where the weaknesses are. If you're not the authority, if you don't have if you don't have responsibility, how how do we diagnose what the problem is in the art of the architect? Now we're turning the art into a science. And the second thing that's in here is the

approach matrix. Now that you know what the problem is, And we've actually got concrete action items for every single one of these problems that we diagnose. So, that's the good news. The good news is there's a framework for this. Now, we're almost out of time. We have 45 seconds left. But if you want to go deeper, number one, that chapter I just showed you, that's my gift

to you. That's right here. Uh I gave a talk just about being more persuasive as an engineer, as a technologist, the influential engineer. It's a talk from a long time ago, my first ever talk at GIDS, right here. And then I have another talk recorded called the art of innovation that goes into all the Ever Rogers stuff. That's that QR code over there. I'll give you a

moment to go through those. And while you're scanning that, I'll deliver my closing lines. Ultimately, these are tools. These are frameworks. They're not the answer. They're a pathway to discover your answer. The reality is nobody can tell you what in your organization except maybe you. And it might be worth just taking a picture of this and then you can scan the QR codes later instead of trying

to scan them individually. You're going to get a PDF and you're going to say, "What am I going to do with that?" You're going to get a video. You're going to So, just take a picture of this and we are out of time, but it has been so wonderful to get to spend this week with you. So, I'll give that one more second while you're taking those

pictures. I will thank you for not only choosing to be in this session with me, but choosing to be at this event because this is a truly special event and I want you to understand that what makes this event so special isn't us up here. It's you out there. That's why we keep coming back and that's why I can't wait to see you next year. Thank you

so much. >> [music]