How'd you like to listen to dot net Rocks with no ads? Easy? Become a patron for just five dollars a month. You get access to a private RSS feed where all the shows have no ads. Twenty dollars a month, we'll get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot net rocks dot com. Hey Carlin Richard here. As you may have heard, NDC is back offering their incredible in person conferences around the world, and we'd like to tell you about them. NDC
Copenhagen is happening August twenty seventh through the thirty first. Go to NDC Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the twentieth. Go to Eddcporto dot com to register and check out the full lineup of conferences at NDC conferences dot com. Hey there, this is Jeff Fritz, the purple blazer guy from Microsoft, letting you in on a little secret about my friend Carl Frank. You know, the guy who started dot net Rocks,
the first podcast about dot net in two thousand and two. The guy who's been teaching Blazer on YouTube since twenty twenty. Yeah that Carl Franklin. Well, Carl's joined up with the folks from Code in a Castle to teach a week long hands on Blazer class at Are you ready to get this? At a castle slash villa in Tuscany. It's sort of a luxury vacation with
Blazer learning built in. Carl's calling it the Blazer master Class. You'll learn Blazer from the ground up, finishing the week with the ability to build and deploy Blazer applications. Since the training happens for only four hours in the morning over six days, you can bring your significant other, your partner with you and you should right This part of Italy is absolutely beautiful. There's so much to see and do and and Larry and Marco from Code into Castle are organizing
daily activities both at the castle and in the area. The castle is in the Marema, a less touristed region of Tuscany, offering both classic Tuscan hill country as well as easy access to the Etruscan Riviera, with sublime local food, wine and olive oil around every corner. Breakfast is included every day. There will be two communal dinners at the Castle book ending the experience and most other meals and all activities are included. And did I mention you'll learn Blazer
in person from Carl Franklin. Listen, space is limited and for very good reason. This is quality training in a beautiful setting. Go to code in Acastle dot com slash Blazer twenty twenty three that's bla z R two zero two three to take advantage of this amazing opportunity to join Carl in Tuscany for an unforgettable week of led dulce vita while advancing your programming skills in this important new technology. Hey, guess what's dot net and rocks. I'm Carl Franklin and
I'm Richard Campbell, and we're bad. We're doing the thing, doing the thing. The arts off the walls. Oh, I was gonna ask, you know, in the in the long running, you know, slowly packing up the house, all the arts off the walls except the two really big pieces, do you I don't even remember the totem Oh yeah, yeah, yeah, photographed Rodney Rodney Lowe eight foot by four and a half feet. Ask me how I know? Well, and who's got a wall big enough
for it? Right? So we're really concerned. I don't want to put it into storage. But our friend ken All's dad has a place some big high wall, So I said, would you take care of this for me? And he's like, yeah, Now I have to pay a team to build a scaffold to take it down and then take it up there, build another scaffold and put it back up. But you know, at least it's going to a good place. I mean, maybe someday we'll build another house
that has a wall big enough for this thing. We do love the piece. Yeah, it's enormous. You don't want it in storage though, right. I don't want to put it in storage. And it's enough. I mean just cleaning up all the art or and the rest of the walls. It's like a lot of this is going to get stored away, but stored away under the stairs kind of thing, not something so gigantic that it's going to crush under its own weight. Right. Well, that's great news.
I have some news for better No frameworks for all the crazy music got well last night. Okay, so this is the twenty eighth, right, so last night, this is the twenty eighth. So last night I was in New Hampshire with our friends Patrick Hines and Duane Laflotte. Oh I know those guys. Yeah. So we do this little show called Security this Week. Nice and it is our one hundredth show. Who congratulations. Yeah, I
know I've done this hundred thing a couple of times once or twice. Yeah, it's a great milestone, right, I mean, it's just there's not that many podcasts you get to one hundred episodes. Yeah. So the thing I want to tell everybody if you haven't heard Security this Week is be prepared to laugh. We make tragedy fun. We talk about all the hacks and you know, ransomware and all the attacks that have happened over the week,
and often there is a chance to laugh at something. So and it's necessary for that for that kind of content, Oh for sure, because it's so dry it can be without a doubt, And certainly when I do security related shows on run As. I think one of my top ten shows of all time is a show with Dana Ebb walking through what it took to recover from a ransomware attack with a company. Yeah, like it's like six months, Like that's reality. Yeah. One of the stories that we talked about this
week. Is Microsoft putting anti ransomware stuff in Windows eleven. Yeah, Yeah, they're trying to stem that tide, just make it that much harder. Well, in the end, it's always privilege escalation, right, Yeah, so another not to plug run as left, right, and center. But I just did a show with Sammy Laho where we talked about the fact that multi factor authentications work so well that the number one exploit for ransomware is no
longer fishing, it's on patched servers. Yeah, and so now we're having this conversation about you can't afford the time to test the patches before you deploy him. The risk is higher. So it's better to just deploy the patch and deal with the occasional failure from that than it is to be exposed to ransomware because you haven't patched immediately. Oh my god, I gotta I gotta mention this one and we'll get We'll get to Thomas in a minute. I
know he's chopped at the bit. But one of the things that came out this week was an absolutely undetectable vulnerability in AMD raise on whatever. There's z rising AMD rising chips CPUs where you can take over without any privilege escalation. You can take over every application or access every application that is running, even in a cloud scenario, which is scary. Yeah, I think you're talking about zen bleed. Zen bleed. Yeah, and zenbilied is basically the same
exploit as meltdown in specter on the Intel side. I mean, they're not in the wild. It's a theoretical exploit. Yeah, it's you know, based on on CPU cashing, so it's kind of random. But there is a firmware update, so they've gotta they gotta fix it. And the and the trade, of course is costume performance. They're gonna slow down, that's right, They're gonna because they're managing scity cat. And this is the same
problem that we had with you know, specter and meltdown. And I reminded that AMD made fun of Intel at the time, oh yeah, and said, you know, this would never happen to our CPUs, just like Apple made fun of Windows in the day. You know, we never get hacked. That would never happen. That would never happen. You know, do not do not throw rocks. It is all glasshouses. The gods of vengeance and irony are hitting you with some SmackDown. Yeah, they will. They
are upon you anyway. I wish them well. Get your microcode patched up, you'll be okay. And listen to Security this Week and it's episode one hundred this week Security this Week dot Com and congrats to you guys. That's awesome. Yeah, so who's talking to us today? Richard Campbell grabbed a comment top A show is eighteen forty six. Boy, that's a big number. This is the show we do with Michael Perry when we're talking about immutable
architecture. You know, we're going to be upping our architecture game today. So I figured I would make I would refer to a previous architecture show because Michael Smail this is only a couple of months ago wrote this comment. He said, Hey, great show, guys. Especially loved the bit about the partial refunds, which caused all sorts of fun in my workplace. You know this idea, you know, transactions are immutable kind of thing, and it's
like, okay, but see this invoice. We're going to give back some of the money for that. Like you've got to plan that in just like back orders, all of that stuff. It's these are business cases to have to show up in your architecture fantastic two to hear about operational transformation, which has eluded my memory since I first heard about it, and a Mobile develop
our conference in New Zealand. I will be listening to this one over again, and that I find really interesting, right, Like there's and certainly Michael Perry, you know, that was some dense material we got from him. Probably takes a few listens to really pick up all the detail everything that Michael said. You can listen to that while you're driving your X Wing Fighter around the death Star. There you go, yeah, because I know he does.
Michael, thank you so much for you're commenting. A copy of music Cobi is on its way to you. And if you'd like a copy of Music Cobi, write a comment on the website at dot net rocks dot com or on the facebooks to publish every show there. And if you comment there and we read on the show, we'll say Jay, copy of Music Cobi. And it occurs to me that I can't say you can follow us on Twitter anymore because it's not called Twitter. Yeah, the social media service formula
known as Twitter. It's at Twitter dot com. So go to Twitter dot com so you can follow us on X. All right, I just have three words for you. W t F Yeah no, has this guy completely lost his mind? I think I've said this before. It's like I missed the Elon that sent his sports card into space, Like, yeah, yeah, this Elon is nutty. He's just nuts. But every time we can be reminded that just because you've made a lot of money doesn't mean you're necessarily
smart. Is not a bad thing either, That's true. It's a cautionary tale. All right, Well, you can follow us on X I suppose. But the fund is happening over on Mastodon, so join us there. I'm Carl Franklin at tech Hub dot social, and I'm Rich Campbell at mastodon doot social, and you know, go on there and send us to let us know you're listening. Yeah, yeah, yeah. And I'm also hanging out on the Blue Skies and the threads. You know, I haven't gotten
to Blue Sky yet and threads. We talked about that a little bit. I don't really have a big Instagram presence, but I guess I'm going to build it up. Yeah, if you put it a little time into Instagram and then activated threads yeah, you get some useful results, but yeah, yeah, it is interesting to see the market fragmenting. We've had a few folks plugging us about to doing more stuff on LinkedIn too, because that seems to be kind of a sensible place. Okay, all right, let's bring
on Thomas. Thomas Betts is the lead editor for Architecture and Design info Q, a co host of the info Que podcast, and a laureate software architect at Blackbaud that's blac k bau d. That is not an accent black blood. It sounds a little Boston. That's like Patrick hind same blackbird, black blood. For over two decades, his focus has always been on providing software solutions that delight his customers. He's worked in a variety of industries including social
good, retail, finance, healthcare, defense, and travel. Thomas lives in Denver with his wife and son. They love exploring beautiful Colorado. His collection of dot net Rocks coffee mugs he has a collection allows him to use a different one each day of the work week. Welcome back, Thomas, thank you, Yes, and I do actually change them out every day. So that's so cool for sustainability, right right where evenly. I think you
are a number one commenter at one point. Yeah, pretty pretty probably pretty confident in saying that, Yeah, this is you're one of the reasons that on run As I made different colored mugs. I know I don't have a run As mugs one thing I don't have. What. Well, there's a simple solution to this, Thomas, like, it's not that complicated. Really, Well, then I have to get all the colors of run As mugs. And there are eleven of them, and if you can get them all,
I'll make you a gold one. So there's twelve. You haven't even done, and don't ever stop drinking coffee otherwise we're screwed. So what are you thinking about these days? Thomas? Thinking more about architecture. So, like in my bio mentioned, I'm also I work at blackbod, which is a software provider for social good and in my spare time I worked for InfoQ do some writing and editing. Which was interesting because they're talking about me commenting
on the show. I actually looked it up last night. My first comment back from when it was an emails a comment, not write a comment on the website was on episode two twenty seven or I think it was right on two twenty seven, and it actually ties into the theme of infol Q and q con, which is information Robin hoods. We want to take information and spread it out there. So for people that don't know, infol Q is a website and a platform for news and articles and podcasts for mostly on software
early adopters and innovator trends, but really it covers the whole gamut. So I cover architecture design over there and a little bit of everything else because architecture design is a big umbrella for what is in software. Did you listen to that show with Michael Perry by any chance the I listened to all the shows. Of course you needible architecture one. Yeah, yeah, yeah, there's some good tips, a lot of things. If you don't have to change
stuff, you know, it makes makes life easier. But everything in architecture is trade offs, right, so you have to think about what are your business consequences. You can't just go and implements. I'm in the architecture. I think it's going to make better performance. Well what does that mean on the other side? Yeah, yeah, he was. It was a really impressive, uh talk. I thought absolutely, I was impressed with the guy with Michael. I mean I had, you know, met him in social
situations and stuff, known him a long time forever. Yeah, but that that one really was. Like, so, in terms of shoring up your architecture, are we going to start with the over architecture problem or do you want to start with the under architecture problem? Well, I think we want to start with what is architecture? Because that's good too. People don't know. I mean, imagine walking down the street and I live in Denver, there's a lot of high rises. Ask anyone on the street, like,
give me an example of architecture. They point to the buildings, right, and then you ask them for an example of software architecture and they probably run away, honestly. Yeah. But in the community, you ask someone and the best they can do is maybe point to a diagram and it's like here the blue drawing, isn't it. It's the UML drawings. It's what the boxes and arrows. But by the way, you am, nobody knows that
that is anymore CSML. Is that the new one? But you know, we don't have the physical thing to look at, like software is just it's electrons, not molecules. You can't go up and touch the software. You can touch the hardware, but people don't know what software architecture is. And I think the same problem is also about if you ask someone what is a software architect? Like imagine introducing yourself at a party and you say I'm an
architect. They're like, oh, you design buildings. That's really cool. You ever introduced yourself as a software architect? You get the bobble head effect to someone that looks like you're like, uh huh, that sounds impressive. They have no idea what that means. But that's true within the community, like even within software development, we have all these definitions of what is architecture,
what is the role of a software architect? Yeah, I'm tending to call myself a software development and they asked me to fix their printer and then I get angry and leave. Right, That's why my mom still says that he does something with computers, and that's that's valid. Yeah, it's not inaccurate. It's not inaccurate, but we you know, say you say you're a software architect, once in a while, you're gonna get some decisis.
So what does that mean? Yeah, well, I think if you look at what I think of architects need to do, there's like some common responsibilities that every architect has to have, whether you're an enterprise architect or a solution architect or a software architect, like just generic terms. It's and this goes back to the common a little bit. You need to understand both the technical
and the business requirements. You can't just do one or the other. And then the architecture part of it is you have to make those architecture decisions. You have to design systems, and then once you've made those design decisions, you have to explain them to stakeholders. Right now, The thing about all of those like do this and do that, understanding the technical and business responsibilities, Like none of that says you have to have a title that says architect.
Like I was doing architecture long before someone said, okay, you're now an architect. Yeah right, And so I mean we make the point that software architecture is more about an activity than a title, right right, And any developer that doesn't use an architect is the architect, right yeah, the accidental architect. And that goes to if anyone has to be an architect, especially if you're the only person on the team, anyone can practice architecture.
So if we don't really know what the term means and we're not sure what we're trying to do, I'm saying, well, we can level up and get better at it. Well, how do we get better at it? And I think if you don't focus so much on what you're trying to deliver, don't focus on the UML diagrams or whatever you're producing, go to the core skills, the underlying behaviors you have to have to be an architect. And the four that I came up with, and it's kind of like a
pyramid, they build upon each other. First one of the baseline is good communication, and then second to that is decision making. Now when I tell people that but the architect is responsible for the decisions, why isn't that the first primary responsibility? And I'll get back to that, But just to finish out the list above, that is adaptability, being able to respond to change.
And then leadership. And I said, all of those are important and any given day, what you have to do and what you have to focus on might change based on your day to day tasks. But as I've been observing this for years. This is kind of the base rank of how they fallen into play. And I think I need to say, going back to when I talked about with in foc, most of what I'm I'm talking about today is not just my own observations. One of the nice things I get
to do with in foqu is I work with experts. There are a lot smarter than me, solving much harder challenges, and I tend to reference, you know, this person taught me this thing, and make sure I give credit where credit is due. If you go back, I listen to it last that first comment that I gave to dot net Rocks, I actually said, I'm like, I stopped listening to the show and send a link to my coworkers because I thought it was my responsibility to share information with others.
So this kind of goes to that whole whole theory of why I like working with infoqu is because we are trying to you know, share the share the knowledge with everyone. Yeah, going back to the whole you know, people that understand what a software architect is. I find that using the analogy of building a house or building a building is great because people can say, oh,
well, you don't just like start slapping down bricks. No you you don't just start you know, hammering, you know, nailing boards together. No, no, no, no, no. You have to have a plan. And how do you have a plan? You make a blueprint? Well, who designs that? And it's the architect, right And the architect has to know the laws of physics, and they have to know the art
of the tools that they're using to make blueprints or whatever. And then they also, like you said, the stakeholders, they have to satisfy the homeowner who is hiring them to design the house. And you know, they say, oh, we want the patio here, and we want the garden here, and we want a sunken living room and how does that work? And so the architect figures out how to make that work within the laws of physics.
And they may come back and say, you know, you're going to need a great big beam across this open ceiling because it's not going to support blah blah blah, And then okay, the stakeholder says, yeah, all right, we can live with that, but we have to paint it green. I think that's a good analogy. I love having analogies and metaphors because it helps explain things in different terms than again, that's software you can't see. And the house is a great one because yes, you're clearly working with
different stakeholders. They say I want my bedroom this big, and I want
the bathroom to have this kind of stuff. And then the architect has to know things like and the plumbing has to do these things so we don't fill the house up with sewer gas right, and make sure the electrical system doesn't shorts right, and the homeowner assumes this I would point out as someone who has built a couple of houses like there are actually specialists in each of those skills that the architect wrangles, right, goes to a structural engineer and says,
what do you think and takes us put that pushback, and goes to the plumber. It's going to lay this stuff out, and who's going to say, oh, I need a stack here and a stack there, and so you know, some walls are going to have to be a bit bigger because we've got to fit a three inch pipe through it. Like it is, it is all dialogue. Yes, it's a group of experts collaborates sort of like the general contractor. But before anything gets built. They're the general
contractor of all the other architects or designers of different systems. Yeah, but I would argue that GC's another role because they're the implementer, Like they're the folks that are supervising the implementation. Yes, but that doesn't start happening until after the architecture. Yeah. Certainly in house building, the architect and the engineer are working to get to They won't get permits until he submit a plan that's going to work. That's true. Yeah, we don't have that formality
in software. You know, lawful people just go off and start writing code. And I think that's where the software architect like tends to wear all those different hats. You have to be able to communicate with all those people in those different rules, and then sometimes step in and do the work. Like the general contractor can pick up a hammer and do some of the work. They can do the plumbing. They might not be a plumber, but they
know some of the skills. That's why I think that architects should still write code. Like some people think architects are just doing the design, coming up with the pictures. I think you have that responsibility to still write code. It helps you relate to the developers, especially in we've gone hybrid and remote, and you don't sit there and you don't get to hear like the people around you and what they're suffering with, Like write the code, see that
that design that you came up with. You're like, this is the way it's going to work, and then you try and implement it and it doesn't you get to share that pain of oh, we need to change the design because I see it that does work. It's harder to hear fourheads hitting keyboards these days, although I mean I've I've gotten really good over the years when I've been responsible for teams is watching check ins because there's just you know,
I learned the shape of each of my developers check ins. There's folks at check in almost every hour, like they're always pushing code onto their branch, like that's how they like to work. Ones that typically do it before the
lunch break and before they leave at the end of the day. And as soon as you see a change in the pattern to check in, it's a good chance to go and look for keyboard in prints on the forehead like that's usually There's another key rule, which is like if you haven't a check in from that developer in three days, do you really think on the fourth day you're gonna get the trade greatest check in known to man. I'm thinking no, I'm still waiting for it. I keep waiting for that to happen.
And I've seen that behavior too many times. But yeah, you know, I'm also big on trying not to interrupt them when they're when they're working. But if there's two days have gone by and I haven't seen a check in and I'm used to them checking in twice a day, you can kind of swing, you know, give them a pain or something and say, hey, how's it going. I want to die? I'm like, okay, yeah, let's talk. I think that that's all gets back to that idea
that my first skill that every architect needs to have is good communication. Because every my statement is every software problem is fundamentally a communication problem, right everyone. I look at you send, and that's that's true, no matter who
are what's communicating. Like, we can have problems between two servers, two systems that are trying to talk to each other, you nevin, communication problems between the developer trying to write the code, and that's what you're describing is the people, the people interacting with each other about the software, Like maybe you didn't understand requirements, or maybe you thought you understand the requirements and you go and implement it and doesn't do what you want to? Did you write
a bug? The bug is just you told the computer to do something and it's not what you wanted it to do. Like, whose fault is that? It's like that? And then you look at our error. Look at an HDP four hundred response, like it's the first of the four hundred clientaries, and all it says is bad request, which is I don't understand what you wanted me to do. Right. That's like we understand communication problems are our problems? Yeah, that's the that's the web server's way of saying,
now, see what we have here is a failure to communicate. I mean, I'm also concerned that often people are looking at the architectural role as somewhat dictatorial. It's like, you will build it this way. I think you know, when I'm working in that group, it's like, what does it take to persuade the architect that we maybe need to shift the design? Because
Richard and I know some very opinionated architects, do we not? I think it was a Scott Hanselman quote that he likes opinions that are strong, opinions that are weakly held, right, like go out there and say here's what you're gonna do. But once someone convinces you through data, through analysis, like I know you said this was a good plan, but I thought about these other things, and you're like, yep, you've convinced me. We're going to change the plan. Be willing to you know, don't die on
every sword, like not all of them are good decisions. You're not right every time. Well, and in the end, you were all working on the same problem. You're trying to deliver results for customers. So it's not your wrong, I'm right either. It's that we're helping to mature the plan.
It's a good idea to adopt the phrase, I think and in check that into your sentences when you're talking to people, and the and the presumption as an architect, and I mean, I've been through this where I'm in a house that we built, right, and I remember the builder who was
a the general contractor who happened to be the carpenter. Realizing that both the architect, the structural engineer and the city had missed a design flaw in the blueprint and that there was like a missing beam and nobody had caught it until the guy building it said, hey, what's holding this up? Right?
Ecuse me, excuse me, I just got one question. And that is often when the developers realize, I know, you said that this server can talk to that server, but something's missing or this code doesn't work, and it's a glaring hole that once you see it, how would you have missed that? But everyone can miss it. Yeah, it absolutely happens, and it needs to be a pathic communication to feed that back that bring resume.
You know, you also can't presume you're right either. Right, It's like, hey, I cannot make these two I have not been successful made these two machines communicate. I don't know if it's me or it's them, but this is what's happened. Yeah. So going back to the idea that if every software problem is a communication problem, right, The other slip side of that is that as an architect, the biggest impact that you can have to make a project successful is to find ways to improve communication. Right. We
can improve how our services talk to each other. Are we using synchronous or acing as communication we can improve? This is what you where UML comes in because UML is a great way to communicate, right right right. UML is just a very structured version of the ad hoc boxes and arrows. That's my oversimplification. Yeah, cocktail napkin with circles and arrows on it. Yeah,
boxes and arrows are fine. I like Simon Brown's C four model, the C four models, the four seas are I'm going to test myself context something something code anyway, It's four different layers of the architecture, and the differences each one of those layers you draw different diagrams because they are intended for a different audience, which goes to my thing. I said, this is the last round on my show. The number one advice for how to improve communication
is know your audience. Who are you talking to, what are you trying to explain to them, and what's the most expective way to communicate? Context containers components in code. Thank you, I knew I should have had it in my fingertips. You can google faster. I can from the context is I want to build a house, and then the code is I want to install this wall or this electricity, right, those are the different things. And just like your general contractor analogy and your architect to the I'm going to
give sign to my subs to do the work. You have to provide different diagrams. So UML might be useful in one of those situations, but it's not the right tool for everybody. And sometimes the diagram isn't the right way to presentage field. Maybe you have to give a PowerPoint presentation and you want the really simplified view of the world with maybe some boxes and arrows, but
it's just what that audience needs to hear. So I took a systems analysis class in college, and I remember the professor saying on day one, he says, the most important thing you can do as an analyst is get an org chart. Get an organization chart. You should know who you're talking to before you say one word. And that's I don't I've never seen anybody offer an org chart, And I don't know. Richard probably does that when he goes into you know, because he needs to know who's your boss, who's
your boss's boss. I want to talk to your boss's boss's boss. We really how our decisions ultimately made right. Because often you know, as the external guy, as the consultant, you are less susceptible to siloing yourself. You tend to go between these layers, and often you're turning up communication failures
that are already happening. I mean, let's face it, you didn't call me because things were going well, right, So you know I've said this before, Like pretty quickly you figure out in this role you're a marriage counselor Yeah, it's not a it is all. It is not that the technology
can't do it is that this team is struggling to do it. And why persone complains about person B, person B complains about PERSONNE and they complain to you, and you're like, well, yeah, well, and also just expectations aren't aligned all the way up, so it's always good to press against all that. But you don't do in the disguise of this is a dysfunctional
team. You do this in disguise of hey, I'm the new guy, I'm only here for a week and you're paying me a lot of money, so ask some questions and just the process of them explaining it to you. I mean, so I swear it's very rubber doc. How that first day where we're just going to use whiteboards and draw the problem out, the number of times we turn up the actual problem in the process. Thomas just held
up a rubber rubber everyone right right in the hand. That the point that art chart goes to an idea that Gregor Hope describes as writing the architect Elevator that you need to be able to go from the IT engine room down in the basement all the way up to the CEO penthouse and be able to communicate to all those different stakeholders at all those different levels to be effective. And again, once before you open the doors to get off the floor, think
about who's the audience that's receiving that. What do they need to hear? And sometimes what do they not need to hear? Like you're not going to get an hour sit down with the CEO. Well maybe Richard does, but I'm not going to. If I can get five minutes, I have to
give a really really concise five minute pitch. Maybe it's thirty seconds. And so what is the important thing you need to communicate to help them make the decision that you're there to provide advice on gentlemen I get interrupted from one moment for this very important message, and we're back. It's Don at Rocks, I'm Richard Campbell, that's Carl Franklin. Hey, hey, talking to our friend Thomas Betts about this art of architecture as much as this, you know,
doing it better. And you hit on a really key point before the break there, which is part of an architect's skills, not just communication, but communication in multiple languages, effectively the language of the developer, the language of the business stakehold, the language of the system reliability engineer, stite reliability, the engineer, you know, the guys who are going to operate this stuff, Like if you're doing your job well, you are making sure all
those stakeholders have a seat, are being heard and that their concerns are manifesting your diagrams and documents. Yea, I think that moves us into the second point level of my skills. You need to know is decision making, because it's that first step is understanding the decision to be made. You have to gather information from all those stakeholders. What do you want in your house?
And you know, I've basically distilled decision making down to almost a simplified scientific method that you have that first step of understanding the decision and then take the time to produce some options, evaluate those options, and then decide on something. And then the last step, just like the scientific method, is to communicate your decision. Now that first and last step, say hey, look how important communication is. If you don't take the time to talk to the
right people and understand what they need. And again, those different viewpoints are going to have different impacts on how you design something. Then you might design the wrong system. You might have missed that beam that you needed to put up. And many times you're the people that you're interviewing and asking their opinion. Sometimes they'll say I have no idea, what do you think? And sometimes they'll be very opinionated, Oh, we want to use the lamp stack
with you know, Kubernetes and all this stuff. And you have to ask them why you know, without coming across like you don't know anything. And then they're going to throw you under the bus in the next meeting because you're an idiot. You know, like there's a dance to be done there, right, you need to okay, you want to do this? Tell me why what are the benefits. What are the drawbacks? Yep, I think there goes. Do any you know, ask any architect any question their default
responses. It depends because it always depends on what was decision criteria and that example, I want to use lamp stack, Well why well we use the lamp stack? Well why do we use the lamp stack? It's like, well, it's in our architectural diagrams, and can you tell me, well, why was the decision made? Well, it's on the diagrams. The diagram only it's like watching the Olympics. Imagine they only covered the metal ceremony and they only showed the gold medalists. You don't get to see anybody else.
You don't get to see any of the events, like something's missing. The diagram just captures the winner. But there was a lot of thought process, that whole scientific method of here are the options we chose. And that's why instead of just having the diagrams as useful as they can be, I like to use Architecture Decision Records ADRs because they capture that why behind the decision? Why do we use the lamp stack? Here was what we considered.
Here are the trade offs that we looked at and then this one. Because of all these decisions. A good technique that I like to use is, Okay, pretend I don't know anything about whatever it is you're suggesting the lamp stack Kubernetti. Pretend I don't know anything, convince me go ahead, and
I'm gonna just make some notes here. You know. So it because if you're an architect, right, you'll probably know these things and somebody's gonna just look at you and say, like you said, well, because that's the best thing, right, because you know, why should I explain it to you? So you have to say, look, pretend I'm your mother. Explain you know, explain yourself. Grandma Franklin needs to know why the lamp stack. Absolutely. I grabbed the link to adr gethub dot io, which
is a pretty good summary of the architectural decision records. This is really about documenting these decisions, to capture why it's documented decisions. The term I think was coined as far as I can tell, by Michael Nygard, like, yeah, those things come down to thought works, don't they. And the other one that you might want to look up is mad m adr the markdown,
well, it was marked down architecture decision records. They changed the name to mark Down Any Decision Records because what we're talking about this decision making, it doesn't have to be just software architecture. Those were just the first people that needed to find a way to communicate their decisions, right. I would love to see more businesses using this for the business decisions. Why did we
decide to do this project and not that project? Why did we fund this, Why are we you know, hiring these people, why are we doing whatever? You can capture those decisions as opposed to oh it was decided from Yeah, and nobody's ever going to read these except a large language model. It's operating your business, which should be enough, right, Like then you can ask it questions and it should have pretty good answers based on the ADR
data. Yeah, there's been a discussion about that, like can we plug it in and say, can it analyze what the next decision? What is right and what's wrong. I have to admit when chat GPT first came out and I was working on this presentation, like I wonder what it would do, and so I asked it questions and I found it's it's good in that rubber duck scenario, give me the options, what are the trade offs? And if you are really, really lazy, you can ask it to write
an a DR for you. Now check it because what it decides might not be the right thing for you, but it might give you that starting point. Right. Yeah, in the end, all the text is right. Is no different than a deep fake made on buy an image generator. It's sometimes those images aren't half bad, and sometimes that and sometimes the text isn't half bad, but it is. And it's nice to work from something already written. It's easier to edit than to write from scratch, but you do
have to edit it. Yeah, it's and I like a DRS because they get you out of that blank whiteboard scenario. Yeah, when you go in and ask amy, draw your system and show me where your pain points are. That that's good. But when you get down to how are we going to solve the problem? I have sat there and stared at the blank whiteboard
or the pen in hand, like I don't know. The answer is not coming to me, And you're just trying to think through and get to that, like you want to get to the end of the race without running it. Yeah, the a DR if you start with the markdown one. It's a template, and it's like, what's the name of the decision? What are you trying to decide? What are you considering? And just the act of having to fill out the template and write it out, it's the rubber
duck. Again. You are explaining to yourself because you're going to have to explain it assuming someone else will read this document. Well, sometimes the decision is a bad not a bad decision, but it's unnecessary because of somewhere lower down in the stack, a decision was made that is focusing you on the wrong problem. And so that's where an architect can come in and say, you know, I understand why you're not coming up with a solution to this
is it's because it's architected wrong. It's designed wrong, and you know, here's some suggestions of how to avoid this pitfall. Yeah, that gets to the third points, a good segue to adaptability because everything constantly changes, right, like no architecture plans survives first contact with the engineers. They are going to break they are not going to follow it, or they're going to implement it exactly the way you told them to, even the wrong things that you
didn't realize and you have to change that. We have to have agile architecture. We have to have an architecture that can continually evolve. And if you make your decisions assuming this is the one only way to do this and they will never change now, the only way you're going to fix that is to
replace the system down the line. It's better to say, here are the decisions we're making, and we assume that they're going to change over time, and if we document them when we say this isn't working anymore, we need to change it, instead of well, here's the diagram and try and redraw
the diagram. If you look at the ad R, it's got a date on it, and it's got a decider like you have someone's name, like who to blame, and go ask the question like you chose this based on these criteria, But now we have a million users sitting on our website. Maybe our decision criteria was wrong. It was right at the time, but it no longer fits. You can just revisit that decision and you have that as a starting point, as opposed to throw it all over and start starting
at you get those names and dates. It's kind of like a walk in and a restaurant, right, you know, you have to date things and you have to name them. What is this? Is it meet? Is it cake? We'll call it meat? Yeah, But you also make a point here. You're implying a point here, which is the architect's kept to stay engaged. Yea, because you know I have run into organizations where they're working from an architectural template and that person isn't at the company anymore, right,
And so it's like this idea of architecture is gospel is disturbing. Yeah, And maybe if you have at least their name and not just a department or the architecture team, what does that mean? Like, I want to know Thomas made this decision? You know? Can I go ask him? And if you ask me about something I decided six months ago, I'm going
to scratch my head and wonder. I'm like, yeah, it seemed like a good idea at the time, but I hadn't remember that if I wrote it down, I can point to it and we can have a discussion over that and say, is that's still valid? And oh we assume that is this still correct? Or what has changed? How many problems arise or can arise from people being afraid of looking bad. I'm sure you've seen that as
much as I have. There is sometimes the I want to push forward because this is what we're doing, and I don't want to be the person to hit the brakes. My hardest decision. I'm not going to go into the details, but people know about this. You know. A year ago was I think we're going in the wrong direction, and it was my decision to go down that path. And then four or five six months later, it's
like, this is really not the right way to go. And having gone through the whole process and document it the whole way, it's like, hey, this was a great idea, but our business requirements changed and we want to do a slightly different path or significantly different path. We shouldn't just keep going blindly down that direction. And so yeah, we're gonna lose a few months worth of effort, but in the long run, and that was part of the ad R was let me show you what this looks like on a
timeline, because again, explain to the right people. The business owner needs to know, not just oh, well the technical solution isn't going to work or it's gonna be hard. What does that mean? It means that a year and a half from now, we're not going to hit our goal. Yeah, and that's the money you're going to save. And a year and a half from now, we're going to deliver something instead. Oh I like
that. Yeah, I'm gonna I can quickly deliver you the wrong thing, oh yeah, or we can spend a little more time to deliver the right thing. Which would you prefer. Actually, we were going to spend a long time delivering the wrong thing too, so yeah, we's been a long time delivering the wrong thing. If you want the worst of all worlds, yeah, yeah, I guess the real question is, you know how much
of a refactor of architecture takes place? Like there's lots of incremental twitches you can do, but that whole hey, we kind of have to relay this whole thing out again. Yeah yeah, I like. I like when you can go into a new project and you say we're going to have an evolution architecture or a continuous architecture. There's two different terms. There's different people. And the guys that I worked with for an article series on info Queue,
Peer Puer and Curb Bittner, they talked about a minimum viable architecture. And I love this idea of the MVA, which is the architecture that supports your MVP, your minimum viable product. Again, business stakeholders understand the MVP right, Well, I'm going to give you just enough architecture to support that because we're going to put this out in the wild, let customers use it, and then wait for feedback to find out what's our next step. What are
we going to build on top of it? And as we change which direction the product heads, we have to make changes to our architecture as well. And the fact that you've designed your architecture to be adaptable and change because it's based on those decisions that can change it kind of builds in that agility from the get go. Yeah, it sounds if you're comfortable with the idea that you're going to revise the architecture, it is going to be revisited, then
you do a lot. You don't have to overplan, you can just bring in that minimal viable with this acceptive of being refactored and infecting this software below it. I think that being agile it applies to both the architecturally build and how we as architects practice our jobs. I mentioned earlier, you're not sitting in a desk in a cubicle farm next to everyone. Everyone's remote. How
do you get the pulse of everything? Well, that switch, that abrupt shift from in person to everyone's hybrid, brought about a bunch of communication challenges, but people also saw communication opportunities. We went to more people are doing asynchronous communication, like I don't need to have that face to face meeting and that those are those distractions you talked about. I don't want to bother the developer and interrupt their day because this five minute call is going to actually take
them out of their headspace for an hour. So asynchronous communication is good. ADRs support asynchro communication. Instead of only the people who can go into the room with the whiteboard and draw on the conference room whiteboard, get to be in the decision. Now everybody can see your decision. I like sticking them in source control, put them in get it's a text file. Anybody can
see them. They're highly adaptable, and I think we've even seen, you know, kind of the fallout of the companies that did adapted well to being remote, like the ones who are able to just like keep doing business and didn't have this abrupt like stop in their business process. Like some of that is the team and some of it is the architecture. And you know, you guys have talked about Conway's law a few times that your architecture looks like
your teams your team architecture. Yet Yeah, and I have the COVID corollary to Conway's law that highly effective distributed teams are able to build highly effective distributed systems. And contrary to that, if your teams struggle with that highly distributed communication, you are not going to be successful building a distributed system. If you're like, we're gonna do micro services, but our teams have to be in the office together, Like your team structure is a monolith, you have
to build a monolith. Yeah, you're well more relevantly, you're gonna build a modelith you can call it whatever you want, but this is what's going to come out of the other side. It's interesting to point your point. Then it's like, because the team is distributed, we've kind of have an opportunity here to make it easier to build more distributed systems because they're already working like that. Yeah, yeah, and we find where are the teams struggling
to communicate. How do we fix that's that marriage counselor role. How do we fix the communication between teams? If they have to talk to each other every day, then there's not really two teams. You have one big team. First thing is to not use teams. We have a combination with Slack and teams. And you can tell guess who uses slack, A big Slack fan, not a big the engineers use Slack. Everyone else in the business
uses teams. Yeah, so it but yeah, interesting, you were talking about this idea of if you're municating with a group every day, they're actually on the same team, right, And that's that you want loose coupling in your architecture. You want loose coupling and your teams. And so if those teams want to be able to work independently, you want to reduce how many communication points they have that will be in their software as well, that their
software will communicate on the same boundaries. But if you have that we've got to talk every day, then yeah, you've got two services that are highly coupled, and they're gonna have to be deployed in law study as well be the same service. Yeah, now you have the distributed monolith, which is the worst of all worlds. That I mean. At the same time, I'm always loath to block communication in any way, right, but I would I would think in an architecture role, you're like, Okay, these teams
are need to communicate routinely. You want useful communication, right, You shouldn't have to talk all the time to figure out, Hey, how do I call your service? And that should be documented, make a swagger end point and just generate a client off of that. And if it doesn't work and it doesn't do what you need and say, hey, I need a new endpoint, how do you submit a poor request to them? How do you use those techniques and have a little bit of discussion over here's what I need
from you. Not let's sit down together and now I've pulled you off your task so you can work on my task with me. You know, this is a good opportunity to ask you, Thomas, what you thought of the modular monoliths show we do with Leila, because we're talking about that now. Yeah, I'm actually halfway through that episode. But no, the modular monolith
is a topic that's on the INFOCU Trends report. So every year INFOCU does several different trends reports, and I'm responsible for the architecture one, and we've had some variation of modular monolith moving across that the graph for a while. And it's the idea that you don't like. It's not monolith versus micro services.
It's well architected systems and what are the modules that you need to build and recognizing Yeah, you can separate concerns without going full on micro service, right, And so if your code sciences is as simple as how do you organize your code? I can't remember who talked about the good architecture. There's some discussion about how to stu up your project and it was like very structure and you had to follow the rules. It's like, this is so much
structure. I'm like, I think what he was getting at is if I have a directory structure and I'm going to change. You know, we do financial stuff invoices, and here's the invoices controller and then here's the Invoices business layer, and here's the invoices data layer. And I'm any one change to
invoices is touching code in three different places. Like if you just modify the folder structure and say it's invoices, and then underneath that is all the stuff when you make a change to that module, Like, all of your change are under one directory structure. And mentally you're like, oh, this is not a big cross cutting concern. It's that vertical slice and all those vertical slices stay together. And so when I see modular monoliths, I think that's
good because you're focusing on the modularity aspect. The modelis is just the delivery technique. Yeah, A good way to find out what's going to get touched is just change the interface. Let the compiler tell you. Yeah, I think it was. You've all lower you talked about the things you break off into monoliths or into micro services. It's not necessarily for the performance gains. But what is likely to change a lot, And you want the thing that
you change a lot to be as small as possible. And the stuff you don't change a lot is very stable. Like the food in my fridge gets changed all the time, but my refrigerator doesn't get changed. Let's be honest. You don't do this for performance. In fact, it will often degrade
performance. You do this for Yeah, you want to be agile. It depends what you mean by performance, yeah, because I had to throw out it depends there because if you're you have a service that needs to do a million requests, then you need to be able to scale that to handle a million requests and the other service doesn't need to have that much load. Does it need to be as BIG's And that's not so much a performance conversation, is a scaling conversation. Yeah, and yeah, you need to find the
appropriate level of granularity for all of these things. Yeah, but I do agree with that. You've all's positioned on where where are your points of resonance? Like where where? And how big you want the smallest pieces of your code vibrating. So it's like, oh, you know, this constant change happening in this service, but it's tied to these other four and so now they're all constantly being redeployed. It's like peeling that one off and paying a
bit of overhead to it so that the impact of update is lower. Ye, you know, we're willing to pay that overhead, only you know those often those overheads are milliseconds, so it's not that big of a deal, but it is a security boundary. It's a transactional boundary. Like nothing is free. Yeah, if you've got something that has to be really secure, you've got PII data whatever, and you PCI data whatever. It is, like I want nobody to see that except this little thing over here. That's
easy. It's the convenience factor where oh, I'll just put this code here that tends to get to Like the monolith isn't bad. It's the big ball of mud that's bad. The code that we can't understand, that's bad. So the monolith is fine if it's the right thing. And for most cases, don't start with microservices. That's usually your first step. Like if I had one problem and then we came with microservices, now we have ninety nine, I have a microservices a problem factory. Right, yeah, I think.
I think in that same show with Leyla, and admittedly it came out yesterday, so I don't blame you for not having finishal listening to it. Yet we're recording it the day after it was published. There's another Conway's law element there where you know, I think lately did a good job of describing where is the case where you start with microservice. It's a very large project.
You know it's a large project and you have a large distributed team working on it, where now the microservices boundary is actually simple afy working in parallel with such a big team. Yeah, but if you don't, if you don't have all of those things, like you're just creating ceremony you don't need. Yeah, I think I think that's Martin Fowler has a post of you must be this tall to ride micro services, love it and and if you only have ten people, you should not do it. Yeah. Right,
you need someone to work on your platform. How do you make it easy to spin up new services and tear them down? Like I don't want to have to be going into the Azure portal every time I need a new service I have, I have almost command line tools. I want to create something, I spend something up and that that that platform that we need for the development to be efficient. You need people that are just dedicated on that problem and be able to make that scale and efficient to your team. Yeah,
very fair done. Coming into the end here, how do we want to wrap this up and leaders anything to call back on? Yeah? The last thing we didn't get to his leadership, and I think that this back to the point that every architect still needs to write some code, and on the flip side, all developers can do architecture. I talked to Andrew harm Law, who I just saw today. The first two chapters of his new book
are coming out. They're available on O'Riley or somewhere. But he talked about the architecture advice process, and it gets to the idea that anyone can make architecture decisions. There's only two caveats. You have to talk to all the people who are going to be impacted by the decision, and talk to the people who have knowledge about and the relevant experience to make the decision. So this is one of those things like be the servant leader and help mentor the
next generation of architects. Again, you don't have to be an architect, but I want to help you make good decisions. Maybe it's not even architecture decision. Maybe it's should I use this library or that library. Let's think about it. Maybe we should write an ADR for that. To just go through the process and if they see I've had engineers I work with say I appreciate that we use a DRS because it tells me how to make a decision,
like they're seeing why was a decision made? But also, oh, I can use that as a template when I need to make a heart decision. So right, if I can complete this ADR document in a sensible way, I have a better chance of getting that decision done. Yep. Yeah. So architecture is a team sport, you know. We got to find
the ways to work with everybody, encourage them to get better. I think the last little shout out I have to get it is read Domain Dier from Design by Eric Evans, because when I talk about communication and I said that communication is between computers, between people and computers, and between two people, DDD really gets to the heart of that. I mean, the subtitle of
book is tackling complexity at the heart of software. If you use a ubiquitous language within a bounded context, and you take that language of the business, use it for your requirements, use it for your code, it's going to solve a lot of problems because you don't have those extra translation steps. You just simplify the communication. And so that's one of the things that I always go back to. It's like, how do we define our domain and recognize
what the language is within my domain? Isn't the same outside the domain. Like if I say cookies, am I going to go and give you a cookie to eat? Or you accepting the cookies on the website? Right, words don't always mean the same, and so make that boundary context, make the boundary and say, right now, for our problem, here's what we're talking about. Yeah, good stuff, Thomas. What's next for you? What's in your inn? So my bio mentioned that I'm living with my wife
and son here in Denver. My son starts college in two weeks. Not not at all nervous or excited about that. Okay, no, no, one state over. He's going on in Nebraska. So yeah, so close enough he could come over for the weekend, but far enough away that he probably won't. So Denver has like the third busiest airport in the world. Omaha does not. And I have to say, having flown in there, it's amazing. It's so great, isn't it. So I love getting in
out of smaller reports. And then the other thing on my to do list coming up, I'll be speaking at my company's annual conference, Bbcon in October, which is back in person for the first time. Pandemic and it's in Denver. It moves around the country, and so I'm like I will, I'm in Denver, so you get to go home at net. So anyone listening to the show who is a black Bug customer and wants to hear about the architecture we're doing within our systems, that's all. I'll be speaking about
a couple of my coworkers. All right, Thomas, this has been great. It's always good to talk to you, and it's been a long time. And come back soon, will you? Of course? Have you do help anytime? All right, We'll see you next time on dot net rocks. Dot net Rocks is brought to you by Frankland's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at pwop dot
com. Visit our website at dt n et r o c ks dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two thousand and two. And make sure you check out our sponsors. They keep us in business. Now go write some code, see you next time. We got Van