WEBVTT 1 00:00:01.000 --> 00:00:04.759 How'd you like to listen to dot net Rocks with no ads? Easy? 2 00:00:05.320 --> 00:00:09.400 Become a patron for just five dollars a month. You get access to a 3 00:00:09.480 --> 00:00:14.240 private RSS feed where all the shows have no ads. Twenty dollars a month, 4 00:00:14.240 --> 00:00:18.399 we'll get you that and a special dot net Rocks patron mug. Sign 5 00:00:18.440 --> 00:00:23.679 up now at Patreon dot dot net rocks dot com. Hey Carlin Richard here. 6 00:00:24.039 --> 00:00:28.480 As you may have heard, NDC is back offering their incredible in person 7 00:00:28.559 --> 00:00:32.840 conferences around the world, and we'd like to tell you about them. NDC 8 00:00:32.960 --> 00:00:38.840 Copenhagen is happening August twenty seventh through the thirty first. Go to NDC Copenhagen 9 00:00:38.960 --> 00:00:44.679 dot com for more information. NDC Porto is happening October sixteenth through the twentieth. 10 00:00:44.960 --> 00:00:49.039 Go to Eddcporto dot com to register and check out the full lineup of 11 00:00:49.079 --> 00:00:54.200 conferences at NDC conferences dot com. Hey there, this is Jeff Fritz, 12 00:00:54.399 --> 00:00:58.759 the purple blazer guy from Microsoft, letting you in on a little secret about 13 00:00:58.799 --> 00:01:03.479 my friend Carl Frank. You know, the guy who started dot net Rocks, 14 00:01:03.520 --> 00:01:07.000 the first podcast about dot net in two thousand and two. The guy 15 00:01:07.040 --> 00:01:12.400 who's been teaching Blazer on YouTube since twenty twenty. Yeah that Carl Franklin. 16 00:01:14.280 --> 00:01:18.200 Well, Carl's joined up with the folks from Code in a Castle to teach 17 00:01:18.280 --> 00:01:22.239 a week long hands on Blazer class at Are you ready to get this? 18 00:01:22.840 --> 00:01:29.239 At a castle slash villa in Tuscany. It's sort of a luxury vacation with 19 00:01:29.319 --> 00:01:36.680 Blazer learning built in. Carl's calling it the Blazer master Class. You'll learn 20 00:01:36.719 --> 00:01:40.680 Blazer from the ground up, finishing the week with the ability to build and 21 00:01:40.719 --> 00:01:46.439 deploy Blazer applications. Since the training happens for only four hours in the morning 22 00:01:46.560 --> 00:01:49.439 over six days, you can bring your significant other, your partner with you 23 00:01:49.920 --> 00:01:56.799 and you should right This part of Italy is absolutely beautiful. There's so much 24 00:01:56.840 --> 00:02:01.040 to see and do and and Larry and Marco from Code into Castle are organizing 25 00:02:01.159 --> 00:02:06.760 daily activities both at the castle and in the area. The castle is in 26 00:02:06.799 --> 00:02:12.400 the Marema, a less touristed region of Tuscany, offering both classic Tuscan hill 27 00:02:12.520 --> 00:02:16.960 country as well as easy access to the Etruscan Riviera, with sublime local food, 28 00:02:17.400 --> 00:02:23.719 wine and olive oil around every corner. Breakfast is included every day. 29 00:02:23.840 --> 00:02:28.199 There will be two communal dinners at the Castle book ending the experience and most 30 00:02:28.280 --> 00:02:32.439 other meals and all activities are included. And did I mention you'll learn Blazer 31 00:02:32.800 --> 00:02:38.840 in person from Carl Franklin. Listen, space is limited and for very good 32 00:02:38.840 --> 00:02:43.960 reason. This is quality training in a beautiful setting. Go to code in 33 00:02:44.080 --> 00:02:52.199 Acastle dot com slash Blazer twenty twenty three that's bla z R two zero two 34 00:02:52.400 --> 00:02:57.759 three to take advantage of this amazing opportunity to join Carl in Tuscany for an 35 00:02:57.840 --> 00:03:04.039 unforgettable week of led dulce vita while advancing your programming skills in this important new 36 00:03:04.159 --> 00:03:21.479 technology. Hey, guess what's dot net and rocks. I'm Carl Franklin and 37 00:03:21.560 --> 00:03:25.560 I'm Richard Campbell, and we're bad. We're doing the thing, doing the 38 00:03:25.560 --> 00:03:30.680 thing. The arts off the walls. Oh, I was gonna ask, 39 00:03:30.759 --> 00:03:34.280 you know, in the in the long running, you know, slowly packing 40 00:03:34.360 --> 00:03:38.560 up the house, all the arts off the walls except the two really big 41 00:03:38.599 --> 00:03:42.439 pieces, do you I don't even remember the totem Oh yeah, yeah, 42 00:03:42.479 --> 00:03:46.039 yeah, photographed Rodney Rodney Lowe eight foot by four and a half feet. 43 00:03:46.080 --> 00:03:53.120 Ask me how I know? Well, and who's got a wall big enough 44 00:03:53.159 --> 00:03:54.360 for it? Right? So we're really concerned. I don't want to put 45 00:03:54.360 --> 00:04:00.039 it into storage. But our friend ken All's dad has a place some big 46 00:04:00.120 --> 00:04:02.599 high wall, So I said, would you take care of this for me? 47 00:04:02.639 --> 00:04:05.840 And he's like, yeah, Now I have to pay a team to 48 00:04:05.879 --> 00:04:12.520 build a scaffold to take it down and then take it up there, build 49 00:04:12.520 --> 00:04:15.919 another scaffold and put it back up. But you know, at least it's 50 00:04:15.960 --> 00:04:18.560 going to a good place. I mean, maybe someday we'll build another house 51 00:04:18.600 --> 00:04:21.480 that has a wall big enough for this thing. We do love the piece. 52 00:04:23.040 --> 00:04:26.279 Yeah, it's enormous. You don't want it in storage though, right. 53 00:04:26.519 --> 00:04:28.519 I don't want to put it in storage. And it's enough. I 54 00:04:28.560 --> 00:04:30.120 mean just cleaning up all the art or and the rest of the walls. 55 00:04:30.160 --> 00:04:33.120 It's like a lot of this is going to get stored away, but stored 56 00:04:33.160 --> 00:04:38.800 away under the stairs kind of thing, not something so gigantic that it's going 57 00:04:38.839 --> 00:04:43.439 to crush under its own weight. Right. Well, that's great news. 58 00:04:44.360 --> 00:04:57.800 I have some news for better No frameworks for all the crazy music got well 59 00:04:57.879 --> 00:05:02.319 last night. Okay, so this is the twenty eighth, right, so 60 00:05:02.439 --> 00:05:05.279 last night, this is the twenty eighth. So last night I was in 61 00:05:05.360 --> 00:05:11.480 New Hampshire with our friends Patrick Hines and Duane Laflotte. Oh I know those 62 00:05:11.519 --> 00:05:14.959 guys. Yeah. So we do this little show called Security this Week. 63 00:05:15.199 --> 00:05:20.920 Nice and it is our one hundredth show. Who congratulations. Yeah, I 64 00:05:21.000 --> 00:05:25.480 know I've done this hundred thing a couple of times once or twice. Yeah, 65 00:05:25.519 --> 00:05:27.839 it's a great milestone, right, I mean, it's just there's not 66 00:05:27.879 --> 00:05:30.600 that many podcasts you get to one hundred episodes. Yeah. So the thing 67 00:05:30.680 --> 00:05:34.279 I want to tell everybody if you haven't heard Security this Week is be prepared 68 00:05:34.319 --> 00:05:44.120 to laugh. We make tragedy fun. We talk about all the hacks and 69 00:05:44.519 --> 00:05:48.600 you know, ransomware and all the attacks that have happened over the week, 70 00:05:49.399 --> 00:05:57.680 and often there is a chance to laugh at something. So and it's necessary 71 00:05:57.759 --> 00:06:00.680 for that for that kind of content, Oh for sure, because it's so 72 00:06:00.800 --> 00:06:05.920 dry it can be without a doubt, And certainly when I do security related 73 00:06:05.959 --> 00:06:09.680 shows on run As. I think one of my top ten shows of all 74 00:06:09.759 --> 00:06:15.759 time is a show with Dana Ebb walking through what it took to recover from 75 00:06:15.759 --> 00:06:18.600 a ransomware attack with a company. Yeah, like it's like six months, 76 00:06:18.600 --> 00:06:23.879 Like that's reality. Yeah. One of the stories that we talked about this 77 00:06:23.920 --> 00:06:30.079 week. Is Microsoft putting anti ransomware stuff in Windows eleven. Yeah, Yeah, 78 00:06:30.240 --> 00:06:32.079 they're trying to stem that tide, just make it that much harder. 79 00:06:32.199 --> 00:06:35.480 Well, in the end, it's always privilege escalation, right, Yeah, 80 00:06:35.519 --> 00:06:40.240 so another not to plug run as left, right, and center. But 81 00:06:40.240 --> 00:06:43.600 I just did a show with Sammy Laho where we talked about the fact that 82 00:06:43.720 --> 00:06:48.560 multi factor authentications work so well that the number one exploit for ransomware is no 83 00:06:48.639 --> 00:06:54.920 longer fishing, it's on patched servers. Yeah, and so now we're having 84 00:06:54.959 --> 00:07:00.040 this conversation about you can't afford the time to test the patches before you deploy 85 00:07:00.120 --> 00:07:04.199 him. The risk is higher. So it's better to just deploy the patch 86 00:07:04.279 --> 00:07:09.000 and deal with the occasional failure from that than it is to be exposed to 87 00:07:09.040 --> 00:07:12.199 ransomware because you haven't patched immediately. Oh my god, I gotta I gotta 88 00:07:12.240 --> 00:07:15.439 mention this one and we'll get We'll get to Thomas in a minute. I 89 00:07:15.439 --> 00:07:18.639 know he's chopped at the bit. But one of the things that came out 90 00:07:18.680 --> 00:07:30.240 this week was an absolutely undetectable vulnerability in AMD raise on whatever. There's z 91 00:07:30.879 --> 00:07:42.000 rising AMD rising chips CPUs where you can take over without any privilege escalation. 92 00:07:42.639 --> 00:07:47.519 You can take over every application or access every application that is running, even 93 00:07:47.560 --> 00:07:51.399 in a cloud scenario, which is scary. Yeah, I think you're talking 94 00:07:51.439 --> 00:07:56.279 about zen bleed. Zen bleed. Yeah, and zenbilied is basically the same 95 00:07:56.319 --> 00:08:01.040 exploit as meltdown in specter on the Intel side. I mean, they're not 96 00:08:01.199 --> 00:08:05.959 in the wild. It's a theoretical exploit. Yeah, it's you know, 97 00:08:05.000 --> 00:08:09.759 based on on CPU cashing, so it's kind of random. But there is 98 00:08:09.800 --> 00:08:13.120 a firmware update, so they've gotta they gotta fix it. And the and 99 00:08:13.120 --> 00:08:16.319 the trade, of course is costume performance. They're gonna slow down, that's 100 00:08:16.399 --> 00:08:18.600 right, They're gonna because they're managing scity cat. And this is the same 101 00:08:18.600 --> 00:08:22.319 problem that we had with you know, specter and meltdown. And I reminded 102 00:08:22.360 --> 00:08:26.800 that AMD made fun of Intel at the time, oh yeah, and said, 103 00:08:26.839 --> 00:08:28.959 you know, this would never happen to our CPUs, just like Apple 104 00:08:30.079 --> 00:08:33.720 made fun of Windows in the day. You know, we never get hacked. 105 00:08:33.919 --> 00:08:35.480 That would never happen. That would never happen. You know, do 106 00:08:35.519 --> 00:08:41.039 not do not throw rocks. It is all glasshouses. The gods of vengeance 107 00:08:41.080 --> 00:08:45.600 and irony are hitting you with some SmackDown. Yeah, they will. They 108 00:08:45.679 --> 00:08:52.159 are upon you anyway. I wish them well. Get your microcode patched up, 109 00:08:52.200 --> 00:08:54.720 you'll be okay. And listen to Security this Week and it's episode one 110 00:08:54.759 --> 00:08:58.679 hundred this week Security this Week dot Com and congrats to you guys. That's 111 00:08:58.679 --> 00:09:03.360 awesome. Yeah, so who's talking to us today? Richard Campbell grabbed a 112 00:09:03.360 --> 00:09:07.039 comment top A show is eighteen forty six. Boy, that's a big number. 113 00:09:07.399 --> 00:09:09.120 This is the show we do with Michael Perry when we're talking about immutable 114 00:09:09.200 --> 00:09:13.519 architecture. You know, we're going to be upping our architecture game today. 115 00:09:13.639 --> 00:09:18.120 So I figured I would make I would refer to a previous architecture show because 116 00:09:18.399 --> 00:09:20.519 Michael Smail this is only a couple of months ago wrote this comment. He 117 00:09:20.559 --> 00:09:24.200 said, Hey, great show, guys. Especially loved the bit about the 118 00:09:24.320 --> 00:09:30.279 partial refunds, which caused all sorts of fun in my workplace. You know 119 00:09:30.360 --> 00:09:33.200 this idea, you know, transactions are immutable kind of thing, and it's 120 00:09:33.240 --> 00:09:35.440 like, okay, but see this invoice. We're going to give back some 121 00:09:35.440 --> 00:09:37.759 of the money for that. Like you've got to plan that in just like 122 00:09:37.840 --> 00:09:41.240 back orders, all of that stuff. It's these are business cases to have 123 00:09:41.279 --> 00:09:46.360 to show up in your architecture fantastic two to hear about operational transformation, which 124 00:09:46.360 --> 00:09:50.600 has eluded my memory since I first heard about it, and a Mobile develop 125 00:09:50.600 --> 00:09:54.200 our conference in New Zealand. I will be listening to this one over again, 126 00:09:54.720 --> 00:09:58.399 and that I find really interesting, right, Like there's and certainly Michael 127 00:09:58.440 --> 00:10:03.120 Perry, you know, that was some dense material we got from him. 128 00:10:03.279 --> 00:10:07.799 Probably takes a few listens to really pick up all the detail everything that Michael 129 00:10:07.799 --> 00:10:11.240 said. You can listen to that while you're driving your X Wing Fighter around 130 00:10:11.279 --> 00:10:13.399 the death Star. There you go, yeah, because I know he does. 131 00:10:16.480 --> 00:10:18.600 Michael, thank you so much for you're commenting. A copy of music 132 00:10:18.720 --> 00:10:20.639 Cobi is on its way to you. And if you'd like a copy of 133 00:10:20.720 --> 00:10:24.159 Music Cobi, write a comment on the website at dot net rocks dot com 134 00:10:24.240 --> 00:10:26.159 or on the facebooks to publish every show there. And if you comment there 135 00:10:26.200 --> 00:10:28.600 and we read on the show, we'll say Jay, copy of Music Cobi. 136 00:10:28.879 --> 00:10:31.919 And it occurs to me that I can't say you can follow us on 137 00:10:31.960 --> 00:10:35.639 Twitter anymore because it's not called Twitter. Yeah, the social media service formula 138 00:10:35.679 --> 00:10:39.279 known as Twitter. It's at Twitter dot com. So go to Twitter dot 139 00:10:39.279 --> 00:10:43.639 com so you can follow us on X. All right, I just have 140 00:10:43.799 --> 00:10:48.000 three words for you. W t F Yeah no, has this guy completely 141 00:10:48.080 --> 00:10:52.039 lost his mind? I think I've said this before. It's like I missed 142 00:10:52.080 --> 00:10:56.600 the Elon that sent his sports card into space, Like, yeah, yeah, 143 00:10:56.639 --> 00:11:01.440 this Elon is nutty. He's just nuts. But every time we can 144 00:11:01.480 --> 00:11:03.879 be reminded that just because you've made a lot of money doesn't mean you're necessarily 145 00:11:03.919 --> 00:11:07.960 smart. Is not a bad thing either, That's true. It's a cautionary 146 00:11:09.000 --> 00:11:13.120 tale. All right, Well, you can follow us on X I suppose. 147 00:11:13.279 --> 00:11:16.879 But the fund is happening over on Mastodon, so join us there. 148 00:11:18.000 --> 00:11:22.600 I'm Carl Franklin at tech Hub dot social, and I'm Rich Campbell at mastodon 149 00:11:22.679 --> 00:11:26.159 doot social, and you know, go on there and send us to let 150 00:11:26.240 --> 00:11:28.679 us know you're listening. Yeah, yeah, yeah. And I'm also hanging 151 00:11:28.679 --> 00:11:31.279 out on the Blue Skies and the threads. You know, I haven't gotten 152 00:11:31.279 --> 00:11:35.279 to Blue Sky yet and threads. We talked about that a little bit. 153 00:11:35.360 --> 00:11:37.639 I don't really have a big Instagram presence, but I guess I'm going to 154 00:11:37.679 --> 00:11:39.919 build it up. Yeah, if you put it a little time into Instagram 155 00:11:39.960 --> 00:11:43.840 and then activated threads yeah, you get some useful results, but yeah, 156 00:11:43.879 --> 00:11:46.840 yeah, it is interesting to see the market fragmenting. We've had a few 157 00:11:46.799 --> 00:11:50.240 folks plugging us about to doing more stuff on LinkedIn too, because that seems 158 00:11:50.240 --> 00:11:54.440 to be kind of a sensible place. Okay, all right, let's bring 159 00:11:54.480 --> 00:12:00.879 on Thomas. Thomas Betts is the lead editor for Architecture and Design info Q, 160 00:12:01.840 --> 00:12:05.639 a co host of the info Que podcast, and a laureate software architect 161 00:12:05.759 --> 00:12:13.039 at Blackbaud that's blac k bau d. That is not an accent black blood. 162 00:12:13.679 --> 00:12:16.919 It sounds a little Boston. That's like Patrick hind same blackbird, black 163 00:12:16.960 --> 00:12:22.399 blood. For over two decades, his focus has always been on providing software 164 00:12:22.399 --> 00:12:28.039 solutions that delight his customers. He's worked in a variety of industries including social 165 00:12:28.120 --> 00:12:33.440 good, retail, finance, healthcare, defense, and travel. Thomas lives 166 00:12:33.480 --> 00:12:37.039 in Denver with his wife and son. They love exploring beautiful Colorado. His 167 00:12:37.120 --> 00:12:43.559 collection of dot net Rocks coffee mugs he has a collection allows him to use 168 00:12:43.600 --> 00:12:46.120 a different one each day of the work week. Welcome back, Thomas, 169 00:12:46.320 --> 00:12:48.840 thank you, Yes, and I do actually change them out every day. 170 00:12:50.000 --> 00:12:54.240 So that's so cool for sustainability, right right where evenly. I think you 171 00:12:54.279 --> 00:13:00.399 are a number one commenter at one point. Yeah, pretty pretty probably pretty 172 00:13:00.399 --> 00:13:03.320 confident in saying that, Yeah, this is you're one of the reasons that 173 00:13:03.519 --> 00:13:07.039 on run As I made different colored mugs. I know I don't have a 174 00:13:07.120 --> 00:13:09.639 run As mugs one thing I don't have. What. Well, there's a 175 00:13:09.639 --> 00:13:11.440 simple solution to this, Thomas, like, it's not that complicated. Really, 176 00:13:13.600 --> 00:13:15.960 Well, then I have to get all the colors of run As mugs. 177 00:13:15.960 --> 00:13:18.759 And there are eleven of them, and if you can get them all, 178 00:13:18.799 --> 00:13:22.240 I'll make you a gold one. So there's twelve. You haven't even 179 00:13:22.279 --> 00:13:28.159 done, and don't ever stop drinking coffee otherwise we're screwed. So what are 180 00:13:28.159 --> 00:13:31.960 you thinking about these days? Thomas? Thinking more about architecture. So, 181 00:13:31.000 --> 00:13:35.440 like in my bio mentioned, I'm also I work at blackbod, which is 182 00:13:35.480 --> 00:13:41.840 a software provider for social good and in my spare time I worked for InfoQ 183 00:13:43.159 --> 00:13:46.919 do some writing and editing. Which was interesting because they're talking about me commenting 184 00:13:46.960 --> 00:13:50.360 on the show. I actually looked it up last night. My first comment 185 00:13:50.519 --> 00:13:54.039 back from when it was an emails a comment, not write a comment on 186 00:13:54.080 --> 00:13:58.200 the website was on episode two twenty seven or I think it was right on 187 00:13:58.240 --> 00:14:03.840 two twenty seven, and it actually ties into the theme of infol Q and 188 00:14:03.960 --> 00:14:07.679 q con, which is information Robin hoods. We want to take information and 189 00:14:07.720 --> 00:14:09.639 spread it out there. So for people that don't know, infol Q is 190 00:14:11.159 --> 00:14:18.399 a website and a platform for news and articles and podcasts for mostly on software 191 00:14:18.799 --> 00:14:22.240 early adopters and innovator trends, but really it covers the whole gamut. So 192 00:14:22.279 --> 00:14:26.840 I cover architecture design over there and a little bit of everything else because architecture 193 00:14:26.879 --> 00:14:31.080 design is a big umbrella for what is in software. Did you listen to 194 00:14:31.080 --> 00:14:35.879 that show with Michael Perry by any chance the I listened to all the shows. 195 00:14:35.519 --> 00:14:39.279 Of course you needible architecture one. Yeah, yeah, yeah, there's 196 00:14:39.320 --> 00:14:41.440 some good tips, a lot of things. If you don't have to change 197 00:14:41.440 --> 00:14:46.360 stuff, you know, it makes makes life easier. But everything in architecture 198 00:14:46.399 --> 00:14:48.879 is trade offs, right, so you have to think about what are your 199 00:14:48.919 --> 00:14:52.559 business consequences. You can't just go and implements. I'm in the architecture. 200 00:14:52.519 --> 00:14:56.519 I think it's going to make better performance. Well what does that mean on 201 00:14:56.559 --> 00:14:58.320 the other side? Yeah, yeah, he was. It was a really 202 00:14:58.399 --> 00:15:03.559 impressive, uh talk. I thought absolutely, I was impressed with the guy 203 00:15:03.799 --> 00:15:05.639 with Michael. I mean I had, you know, met him in social 204 00:15:05.679 --> 00:15:11.919 situations and stuff, known him a long time forever. Yeah, but that 205 00:15:11.919 --> 00:15:16.120 that one really was. Like, so, in terms of shoring up your 206 00:15:16.240 --> 00:15:22.879 architecture, are we going to start with the over architecture problem or do you 207 00:15:22.879 --> 00:15:26.480 want to start with the under architecture problem? Well, I think we want 208 00:15:26.480 --> 00:15:30.519 to start with what is architecture? Because that's good too. People don't know. 209 00:15:31.080 --> 00:15:33.600 I mean, imagine walking down the street and I live in Denver, 210 00:15:33.720 --> 00:15:35.799 there's a lot of high rises. Ask anyone on the street, like, 211 00:15:37.240 --> 00:15:39.080 give me an example of architecture. They point to the buildings, right, 212 00:15:39.519 --> 00:15:43.559 and then you ask them for an example of software architecture and they probably run 213 00:15:43.600 --> 00:15:48.200 away, honestly. Yeah. But in the community, you ask someone and 214 00:15:48.399 --> 00:15:52.600 the best they can do is maybe point to a diagram and it's like here 215 00:15:52.679 --> 00:15:56.360 the blue drawing, isn't it. It's the UML drawings. It's what the 216 00:15:56.399 --> 00:16:00.679 boxes and arrows. But by the way, you am, nobody knows that 217 00:16:00.759 --> 00:16:04.360 that is anymore CSML. Is that the new one? But you know, 218 00:16:04.440 --> 00:16:08.720 we don't have the physical thing to look at, like software is just it's 219 00:16:08.840 --> 00:16:12.120 electrons, not molecules. You can't go up and touch the software. You 220 00:16:12.159 --> 00:16:18.960 can touch the hardware, but people don't know what software architecture is. And 221 00:16:18.039 --> 00:16:22.120 I think the same problem is also about if you ask someone what is a 222 00:16:22.120 --> 00:16:26.879 software architect? Like imagine introducing yourself at a party and you say I'm an 223 00:16:26.960 --> 00:16:29.279 architect. They're like, oh, you design buildings. That's really cool. 224 00:16:29.799 --> 00:16:33.799 You ever introduced yourself as a software architect? You get the bobble head effect 225 00:16:33.799 --> 00:16:37.000 to someone that looks like you're like, uh huh, that sounds impressive. 226 00:16:37.039 --> 00:16:44.000 They have no idea what that means. But that's true within the community, 227 00:16:44.080 --> 00:16:48.279 like even within software development, we have all these definitions of what is architecture, 228 00:16:48.360 --> 00:16:52.120 what is the role of a software architect? Yeah, I'm tending to 229 00:16:52.159 --> 00:16:55.000 call myself a software development and they asked me to fix their printer and then 230 00:16:55.000 --> 00:16:57.279 I get angry and leave. Right, That's why my mom still says that 231 00:16:57.360 --> 00:17:02.240 he does something with computers, and that's that's valid. Yeah, it's not 232 00:17:02.320 --> 00:17:06.680 inaccurate. It's not inaccurate, but we you know, say you say you're 233 00:17:06.680 --> 00:17:08.039 a software architect, once in a while, you're gonna get some decisis. 234 00:17:08.119 --> 00:17:12.400 So what does that mean? Yeah, well, I think if you look 235 00:17:12.440 --> 00:17:18.799 at what I think of architects need to do, there's like some common responsibilities 236 00:17:18.839 --> 00:17:22.119 that every architect has to have, whether you're an enterprise architect or a solution 237 00:17:22.240 --> 00:17:27.240 architect or a software architect, like just generic terms. It's and this goes 238 00:17:27.279 --> 00:17:30.079 back to the common a little bit. You need to understand both the technical 239 00:17:30.240 --> 00:17:34.799 and the business requirements. You can't just do one or the other. And 240 00:17:34.839 --> 00:17:40.359 then the architecture part of it is you have to make those architecture decisions. 241 00:17:40.400 --> 00:17:45.319 You have to design systems, and then once you've made those design decisions, 242 00:17:45.559 --> 00:17:48.599 you have to explain them to stakeholders. Right now, The thing about all 243 00:17:48.640 --> 00:17:53.960 of those like do this and do that, understanding the technical and business responsibilities, 244 00:17:55.240 --> 00:17:59.960 Like none of that says you have to have a title that says architect. 245 00:18:00.480 --> 00:18:03.559 Like I was doing architecture long before someone said, okay, you're now 246 00:18:03.559 --> 00:18:07.480 an architect. Yeah right, And so I mean we make the point that 247 00:18:07.640 --> 00:18:11.559 software architecture is more about an activity than a title, right right, And 248 00:18:11.720 --> 00:18:15.400 any developer that doesn't use an architect is the architect, right yeah, the 249 00:18:15.400 --> 00:18:21.240 accidental architect. And that goes to if anyone has to be an architect, 250 00:18:21.319 --> 00:18:26.000 especially if you're the only person on the team, anyone can practice architecture. 251 00:18:26.400 --> 00:18:30.440 So if we don't really know what the term means and we're not sure what 252 00:18:30.440 --> 00:18:33.480 we're trying to do, I'm saying, well, we can level up and 253 00:18:33.519 --> 00:18:36.680 get better at it. Well, how do we get better at it? 254 00:18:37.240 --> 00:18:40.759 And I think if you don't focus so much on what you're trying to deliver, 255 00:18:40.839 --> 00:18:45.079 don't focus on the UML diagrams or whatever you're producing, go to the 256 00:18:45.480 --> 00:18:49.880 core skills, the underlying behaviors you have to have to be an architect. 257 00:18:51.400 --> 00:18:53.680 And the four that I came up with, and it's kind of like a 258 00:18:53.759 --> 00:18:57.920 pyramid, they build upon each other. First one of the baseline is good 259 00:18:57.960 --> 00:19:03.119 communication, and then second to that is decision making. Now when I tell 260 00:19:03.160 --> 00:19:07.759 people that but the architect is responsible for the decisions, why isn't that the 261 00:19:07.839 --> 00:19:12.519 first primary responsibility? And I'll get back to that, But just to finish 262 00:19:12.519 --> 00:19:17.400 out the list above, that is adaptability, being able to respond to change. 263 00:19:17.440 --> 00:19:21.000 And then leadership. And I said, all of those are important and 264 00:19:21.119 --> 00:19:23.720 any given day, what you have to do and what you have to focus 265 00:19:23.759 --> 00:19:29.599 on might change based on your day to day tasks. But as I've been 266 00:19:29.599 --> 00:19:33.119 observing this for years. This is kind of the base rank of how they 267 00:19:33.160 --> 00:19:37.880 fallen into play. And I think I need to say, going back to 268 00:19:37.880 --> 00:19:41.680 when I talked about with in foc, most of what I'm I'm talking about 269 00:19:41.680 --> 00:19:45.000 today is not just my own observations. One of the nice things I get 270 00:19:45.000 --> 00:19:48.640 to do with in foqu is I work with experts. There are a lot 271 00:19:48.720 --> 00:19:53.160 smarter than me, solving much harder challenges, and I tend to reference, 272 00:19:53.319 --> 00:19:56.880 you know, this person taught me this thing, and make sure I give 273 00:19:56.920 --> 00:19:59.599 credit where credit is due. If you go back, I listen to it 274 00:19:59.680 --> 00:20:03.839 last that first comment that I gave to dot net Rocks, I actually said, 275 00:20:03.039 --> 00:20:06.799 I'm like, I stopped listening to the show and send a link to 276 00:20:06.839 --> 00:20:11.759 my coworkers because I thought it was my responsibility to share information with others. 277 00:20:11.240 --> 00:20:15.440 So this kind of goes to that whole whole theory of why I like working 278 00:20:15.440 --> 00:20:18.119 with infoqu is because we are trying to you know, share the share the 279 00:20:18.200 --> 00:20:22.119 knowledge with everyone. Yeah, going back to the whole you know, people 280 00:20:22.160 --> 00:20:26.440 that understand what a software architect is. I find that using the analogy of 281 00:20:26.480 --> 00:20:30.759 building a house or building a building is great because people can say, oh, 282 00:20:30.839 --> 00:20:33.680 well, you don't just like start slapping down bricks. No you you 283 00:20:33.680 --> 00:20:38.640 don't just start you know, hammering, you know, nailing boards together. 284 00:20:38.720 --> 00:20:41.680 No, no, no, no, no. You have to have a 285 00:20:41.720 --> 00:20:44.160 plan. And how do you have a plan? You make a blueprint? 286 00:20:44.240 --> 00:20:48.640 Well, who designs that? And it's the architect, right And the architect 287 00:20:48.640 --> 00:20:52.400 has to know the laws of physics, and they have to know the art 288 00:20:52.559 --> 00:20:56.720 of the tools that they're using to make blueprints or whatever. And then they 289 00:20:56.759 --> 00:21:00.200 also, like you said, the stakeholders, they have to satisfy the homeowner 290 00:21:00.920 --> 00:21:04.920 who is hiring them to design the house. And you know, they say, 291 00:21:04.960 --> 00:21:08.200 oh, we want the patio here, and we want the garden here, 292 00:21:08.759 --> 00:21:11.559 and we want a sunken living room and how does that work? And 293 00:21:11.599 --> 00:21:15.799 so the architect figures out how to make that work within the laws of physics. 294 00:21:17.200 --> 00:21:18.960 And they may come back and say, you know, you're going to 295 00:21:19.039 --> 00:21:25.319 need a great big beam across this open ceiling because it's not going to support 296 00:21:25.440 --> 00:21:29.680 blah blah blah, And then okay, the stakeholder says, yeah, all 297 00:21:29.759 --> 00:21:30.960 right, we can live with that, but we have to paint it green. 298 00:21:33.920 --> 00:21:37.720 I think that's a good analogy. I love having analogies and metaphors because 299 00:21:37.720 --> 00:21:41.440 it helps explain things in different terms than again, that's software you can't see. 300 00:21:42.400 --> 00:21:45.279 And the house is a great one because yes, you're clearly working with 301 00:21:45.400 --> 00:21:48.480 different stakeholders. They say I want my bedroom this big, and I want 302 00:21:48.480 --> 00:21:52.440 the bathroom to have this kind of stuff. And then the architect has to 303 00:21:52.480 --> 00:21:55.920 know things like and the plumbing has to do these things so we don't fill 304 00:21:55.960 --> 00:21:59.480 the house up with sewer gas right, and make sure the electrical system doesn't 305 00:21:59.559 --> 00:22:03.200 shorts right, and the homeowner assumes this I would point out as someone who 306 00:22:03.279 --> 00:22:08.039 has built a couple of houses like there are actually specialists in each of those 307 00:22:08.039 --> 00:22:12.480 skills that the architect wrangles, right, goes to a structural engineer and says, 308 00:22:12.480 --> 00:22:17.079 what do you think and takes us put that pushback, and goes to 309 00:22:17.119 --> 00:22:19.440 the plumber. It's going to lay this stuff out, and who's going to 310 00:22:19.519 --> 00:22:22.759 say, oh, I need a stack here and a stack there, and 311 00:22:22.799 --> 00:22:25.079 so you know, some walls are going to have to be a bit bigger 312 00:22:25.079 --> 00:22:27.079 because we've got to fit a three inch pipe through it. Like it is, 313 00:22:27.359 --> 00:22:32.759 it is all dialogue. Yes, it's a group of experts collaborates sort 314 00:22:32.759 --> 00:22:37.920 of like the general contractor. But before anything gets built. They're the general 315 00:22:37.000 --> 00:22:42.079 contractor of all the other architects or designers of different systems. Yeah, but 316 00:22:42.200 --> 00:22:47.279 I would argue that GC's another role because they're the implementer, Like they're the 317 00:22:47.319 --> 00:22:51.920 folks that are supervising the implementation. Yes, but that doesn't start happening until 318 00:22:52.119 --> 00:22:56.559 after the architecture. Yeah. Certainly in house building, the architect and the 319 00:22:56.559 --> 00:23:00.319 engineer are working to get to They won't get permits until he submit a plan 320 00:23:00.359 --> 00:23:03.119 that's going to work. That's true. Yeah, we don't have that formality 321 00:23:03.119 --> 00:23:07.319 in software. You know, lawful people just go off and start writing code. 322 00:23:07.480 --> 00:23:11.119 And I think that's where the software architect like tends to wear all those 323 00:23:11.119 --> 00:23:14.119 different hats. You have to be able to communicate with all those people in 324 00:23:14.160 --> 00:23:18.000 those different rules, and then sometimes step in and do the work. Like 325 00:23:18.079 --> 00:23:19.759 the general contractor can pick up a hammer and do some of the work. 326 00:23:19.960 --> 00:23:23.279 They can do the plumbing. They might not be a plumber, but they 327 00:23:23.279 --> 00:23:27.160 know some of the skills. That's why I think that architects should still write 328 00:23:27.200 --> 00:23:32.079 code. Like some people think architects are just doing the design, coming up 329 00:23:32.119 --> 00:23:36.279 with the pictures. I think you have that responsibility to still write code. 330 00:23:36.279 --> 00:23:41.839 It helps you relate to the developers, especially in we've gone hybrid and remote, 331 00:23:41.960 --> 00:23:45.160 and you don't sit there and you don't get to hear like the people 332 00:23:45.200 --> 00:23:48.559 around you and what they're suffering with, Like write the code, see that 333 00:23:48.559 --> 00:23:51.559 that design that you came up with. You're like, this is the way 334 00:23:51.559 --> 00:23:55.079 it's going to work, and then you try and implement it and it doesn't 335 00:23:56.079 --> 00:23:57.920 you get to share that pain of oh, we need to change the design 336 00:23:59.000 --> 00:24:02.720 because I see it that does work. It's harder to hear fourheads hitting keyboards 337 00:24:02.759 --> 00:24:07.680 these days, although I mean I've I've gotten really good over the years when 338 00:24:07.680 --> 00:24:11.960 I've been responsible for teams is watching check ins because there's just you know, 339 00:24:12.000 --> 00:24:15.839 I learned the shape of each of my developers check ins. There's folks at 340 00:24:15.880 --> 00:24:19.200 check in almost every hour, like they're always pushing code onto their branch, 341 00:24:19.359 --> 00:24:22.759 like that's how they like to work. Ones that typically do it before the 342 00:24:22.839 --> 00:24:26.319 lunch break and before they leave at the end of the day. And as 343 00:24:26.359 --> 00:24:29.880 soon as you see a change in the pattern to check in, it's a 344 00:24:29.920 --> 00:24:32.880 good chance to go and look for keyboard in prints on the forehead like that's 345 00:24:32.960 --> 00:24:36.079 usually There's another key rule, which is like if you haven't a check in 346 00:24:36.119 --> 00:24:38.079 from that developer in three days, do you really think on the fourth day 347 00:24:38.079 --> 00:24:41.200 you're gonna get the trade greatest check in known to man. I'm thinking no, 348 00:24:41.759 --> 00:24:44.960 I'm still waiting for it. I keep waiting for that to happen. 349 00:24:45.039 --> 00:24:48.240 And I've seen that behavior too many times. But yeah, you know, 350 00:24:48.279 --> 00:24:51.720 I'm also big on trying not to interrupt them when they're when they're working. 351 00:24:52.039 --> 00:24:53.759 But if there's two days have gone by and I haven't seen a check in 352 00:24:55.039 --> 00:24:57.039 and I'm used to them checking in twice a day, you can kind of 353 00:24:57.079 --> 00:25:00.240 swing, you know, give them a pain or something and say, hey, 354 00:25:00.720 --> 00:25:04.519 how's it going. I want to die? I'm like, okay, 355 00:25:04.599 --> 00:25:08.279 yeah, let's talk. I think that that's all gets back to that idea 356 00:25:08.359 --> 00:25:14.759 that my first skill that every architect needs to have is good communication. Because 357 00:25:15.599 --> 00:25:22.839 every my statement is every software problem is fundamentally a communication problem, right everyone. 358 00:25:23.200 --> 00:25:26.480 I look at you send, and that's that's true, no matter who 359 00:25:26.480 --> 00:25:32.000 are what's communicating. Like, we can have problems between two servers, two 360 00:25:32.000 --> 00:25:34.759 systems that are trying to talk to each other, you nevin, communication problems 361 00:25:34.799 --> 00:25:40.119 between the developer trying to write the code, and that's what you're describing is 362 00:25:40.279 --> 00:25:44.680 the people, the people interacting with each other about the software, Like maybe 363 00:25:44.680 --> 00:25:48.079 you didn't understand requirements, or maybe you thought you understand the requirements and you 364 00:25:48.119 --> 00:25:51.039 go and implement it and doesn't do what you want to? Did you write 365 00:25:51.039 --> 00:25:55.000 a bug? The bug is just you told the computer to do something and 366 00:25:55.039 --> 00:25:57.000 it's not what you wanted it to do. Like, whose fault is that? 367 00:25:57.079 --> 00:26:00.559 It's like that? And then you look at our error. Look at 368 00:26:00.559 --> 00:26:04.119 an HDP four hundred response, like it's the first of the four hundred clientaries, 369 00:26:04.119 --> 00:26:08.039 and all it says is bad request, which is I don't understand what 370 00:26:08.079 --> 00:26:11.640 you wanted me to do. Right. That's like we understand communication problems are 371 00:26:11.640 --> 00:26:15.039 our problems? Yeah, that's the that's the web server's way of saying, 372 00:26:15.559 --> 00:26:22.920 now, see what we have here is a failure to communicate. I mean, 373 00:26:22.960 --> 00:26:27.519 I'm also concerned that often people are looking at the architectural role as somewhat 374 00:26:27.519 --> 00:26:32.119 dictatorial. It's like, you will build it this way. I think you 375 00:26:32.160 --> 00:26:33.200 know, when I'm working in that group, it's like, what does it 376 00:26:33.240 --> 00:26:38.720 take to persuade the architect that we maybe need to shift the design? Because 377 00:26:38.839 --> 00:26:45.519 Richard and I know some very opinionated architects, do we not? I think 378 00:26:45.680 --> 00:26:49.119 it was a Scott Hanselman quote that he likes opinions that are strong, opinions 379 00:26:49.119 --> 00:26:52.799 that are weakly held, right, like go out there and say here's what 380 00:26:52.799 --> 00:26:56.079 you're gonna do. But once someone convinces you through data, through analysis, 381 00:26:56.160 --> 00:27:00.960 like I know you said this was a good plan, but I thought about 382 00:27:00.960 --> 00:27:03.759 these other things, and you're like, yep, you've convinced me. We're 383 00:27:03.759 --> 00:27:07.000 going to change the plan. Be willing to you know, don't die on 384 00:27:07.039 --> 00:27:08.480 every sword, like not all of them are good decisions. You're not right 385 00:27:08.519 --> 00:27:11.759 every time. Well, and in the end, you were all working on 386 00:27:11.799 --> 00:27:15.920 the same problem. You're trying to deliver results for customers. So it's not 387 00:27:15.039 --> 00:27:19.279 your wrong, I'm right either. It's that we're helping to mature the plan. 388 00:27:19.640 --> 00:27:25.319 It's a good idea to adopt the phrase, I think and in check 389 00:27:25.440 --> 00:27:29.200 that into your sentences when you're talking to people, and the and the presumption 390 00:27:29.279 --> 00:27:30.759 as an architect, and I mean, I've been through this where I'm in 391 00:27:30.799 --> 00:27:37.599 a house that we built, right, and I remember the builder who was 392 00:27:37.599 --> 00:27:41.759 a the general contractor who happened to be the carpenter. Realizing that both the 393 00:27:41.839 --> 00:27:48.640 architect, the structural engineer and the city had missed a design flaw in the 394 00:27:48.680 --> 00:27:52.880 blueprint and that there was like a missing beam and nobody had caught it until 395 00:27:52.960 --> 00:27:56.720 the guy building it said, hey, what's holding this up? Right? 396 00:28:00.000 --> 00:28:04.960 Ecuse me, excuse me, I just got one question. And that is 397 00:28:06.000 --> 00:28:08.160 often when the developers realize, I know, you said that this server can 398 00:28:08.160 --> 00:28:11.759 talk to that server, but something's missing or this code doesn't work, and 399 00:28:11.799 --> 00:28:15.720 it's a glaring hole that once you see it, how would you have missed 400 00:28:15.759 --> 00:28:19.400 that? But everyone can miss it. Yeah, it absolutely happens, and 401 00:28:19.440 --> 00:28:23.119 it needs to be a pathic communication to feed that back that bring resume. 402 00:28:23.880 --> 00:28:27.440 You know, you also can't presume you're right either. Right, It's like, 403 00:28:27.480 --> 00:28:30.240 hey, I cannot make these two I have not been successful made these 404 00:28:30.240 --> 00:28:33.960 two machines communicate. I don't know if it's me or it's them, but 405 00:28:34.200 --> 00:28:40.200 this is what's happened. Yeah. So going back to the idea that if 406 00:28:40.240 --> 00:28:45.799 every software problem is a communication problem, right, The other slip side of 407 00:28:45.839 --> 00:28:49.559 that is that as an architect, the biggest impact that you can have to 408 00:28:49.599 --> 00:28:55.039 make a project successful is to find ways to improve communication. Right. We 409 00:28:55.079 --> 00:28:57.920 can improve how our services talk to each other. Are we using synchronous or 410 00:28:57.920 --> 00:29:02.680 acing as communication we can improve? This is what you where UML comes in 411 00:29:02.720 --> 00:29:10.119 because UML is a great way to communicate, right right right. UML is 412 00:29:10.160 --> 00:29:14.200 just a very structured version of the ad hoc boxes and arrows. That's my 413 00:29:14.319 --> 00:29:18.160 oversimplification. Yeah, cocktail napkin with circles and arrows on it. Yeah, 414 00:29:18.240 --> 00:29:22.799 boxes and arrows are fine. I like Simon Brown's C four model, the 415 00:29:22.839 --> 00:29:30.400 C four models, the four seas are I'm going to test myself context something 416 00:29:30.559 --> 00:29:36.000 something code anyway, It's four different layers of the architecture, and the differences 417 00:29:36.119 --> 00:29:40.680 each one of those layers you draw different diagrams because they are intended for a 418 00:29:40.720 --> 00:29:42.680 different audience, which goes to my thing. I said, this is the 419 00:29:42.720 --> 00:29:47.079 last round on my show. The number one advice for how to improve communication 420 00:29:47.200 --> 00:29:49.720 is know your audience. Who are you talking to, what are you trying 421 00:29:49.759 --> 00:29:53.039 to explain to them, and what's the most expective way to communicate? Context 422 00:29:53.119 --> 00:29:57.160 containers components in code. Thank you, I knew I should have had it 423 00:29:57.200 --> 00:30:03.200 in my fingertips. You can google faster. I can from the context is 424 00:30:03.720 --> 00:30:06.680 I want to build a house, and then the code is I want to 425 00:30:07.240 --> 00:30:11.279 install this wall or this electricity, right, those are the different things. 426 00:30:11.319 --> 00:30:15.880 And just like your general contractor analogy and your architect to the I'm going to 427 00:30:15.960 --> 00:30:18.480 give sign to my subs to do the work. You have to provide different 428 00:30:18.519 --> 00:30:23.960 diagrams. So UML might be useful in one of those situations, but it's 429 00:30:25.000 --> 00:30:30.359 not the right tool for everybody. And sometimes the diagram isn't the right way 430 00:30:30.400 --> 00:30:33.799 to presentage field. Maybe you have to give a PowerPoint presentation and you want 431 00:30:33.799 --> 00:30:37.759 the really simplified view of the world with maybe some boxes and arrows, but 432 00:30:37.799 --> 00:30:42.359 it's just what that audience needs to hear. So I took a systems analysis 433 00:30:42.359 --> 00:30:47.559 class in college, and I remember the professor saying on day one, he 434 00:30:47.599 --> 00:30:49.920 says, the most important thing you can do as an analyst is get an 435 00:30:51.079 --> 00:30:56.000 org chart. Get an organization chart. You should know who you're talking to 436 00:30:56.160 --> 00:31:02.240 before you say one word. And that's I don't I've never seen anybody offer 437 00:31:02.279 --> 00:31:06.079 an org chart, And I don't know. Richard probably does that when he 438 00:31:06.119 --> 00:31:10.839 goes into you know, because he needs to know who's your boss, who's 439 00:31:10.839 --> 00:31:15.519 your boss's boss. I want to talk to your boss's boss's boss. We 440 00:31:15.599 --> 00:31:19.640 really how our decisions ultimately made right. Because often you know, as the 441 00:31:19.759 --> 00:31:27.920 external guy, as the consultant, you are less susceptible to siloing yourself. 442 00:31:27.960 --> 00:31:33.880 You tend to go between these layers, and often you're turning up communication failures 443 00:31:33.960 --> 00:31:36.680 that are already happening. I mean, let's face it, you didn't call 444 00:31:36.720 --> 00:31:41.960 me because things were going well, right, So you know I've said this 445 00:31:41.000 --> 00:31:45.920 before, Like pretty quickly you figure out in this role you're a marriage counselor 446 00:31:45.440 --> 00:31:49.880 Yeah, it's not a it is all. It is not that the technology 447 00:31:49.920 --> 00:31:52.480 can't do it is that this team is struggling to do it. And why 448 00:31:52.720 --> 00:31:57.079 persone complains about person B, person B complains about PERSONNE and they complain to 449 00:31:57.119 --> 00:32:00.960 you, and you're like, well, yeah, well, and also just 450 00:32:01.160 --> 00:32:06.160 expectations aren't aligned all the way up, so it's always good to press against 451 00:32:06.200 --> 00:32:09.680 all that. But you don't do in the disguise of this is a dysfunctional 452 00:32:09.720 --> 00:32:13.319 team. You do this in disguise of hey, I'm the new guy, 453 00:32:13.400 --> 00:32:15.200 I'm only here for a week and you're paying me a lot of money, 454 00:32:15.759 --> 00:32:23.160 so ask some questions and just the process of them explaining it to you. 455 00:32:23.359 --> 00:32:28.519 I mean, so I swear it's very rubber doc. How that first day 456 00:32:28.720 --> 00:32:31.920 where we're just going to use whiteboards and draw the problem out, the number 457 00:32:31.960 --> 00:32:36.440 of times we turn up the actual problem in the process. Thomas just held 458 00:32:36.519 --> 00:32:42.640 up a rubber rubber everyone right right in the hand. That the point that 459 00:32:42.759 --> 00:32:46.160 art chart goes to an idea that Gregor Hope describes as writing the architect Elevator 460 00:32:46.640 --> 00:32:51.160 that you need to be able to go from the IT engine room down in 461 00:32:51.200 --> 00:32:55.599 the basement all the way up to the CEO penthouse and be able to communicate 462 00:32:55.640 --> 00:33:00.920 to all those different stakeholders at all those different levels to be effective. And 463 00:33:00.400 --> 00:33:05.000 again, once before you open the doors to get off the floor, think 464 00:33:05.039 --> 00:33:07.279 about who's the audience that's receiving that. What do they need to hear? 465 00:33:07.759 --> 00:33:10.720 And sometimes what do they not need to hear? Like you're not going to 466 00:33:10.799 --> 00:33:15.240 get an hour sit down with the CEO. Well maybe Richard does, but 467 00:33:15.359 --> 00:33:19.359 I'm not going to. If I can get five minutes, I have to 468 00:33:19.400 --> 00:33:22.720 give a really really concise five minute pitch. Maybe it's thirty seconds. And 469 00:33:22.759 --> 00:33:27.720 so what is the important thing you need to communicate to help them make the 470 00:33:27.759 --> 00:33:30.720 decision that you're there to provide advice on gentlemen I get interrupted from one moment 471 00:33:30.759 --> 00:33:37.559 for this very important message, and we're back. It's Don at Rocks, 472 00:33:37.599 --> 00:33:40.759 I'm Richard Campbell, that's Carl Franklin. Hey, hey, talking to our 473 00:33:40.799 --> 00:33:45.160 friend Thomas Betts about this art of architecture as much as this, you know, 474 00:33:45.279 --> 00:33:49.119 doing it better. And you hit on a really key point before the 475 00:33:49.160 --> 00:33:52.920 break there, which is part of an architect's skills, not just communication, 476 00:33:52.960 --> 00:33:58.680 but communication in multiple languages, effectively the language of the developer, the language 477 00:33:58.720 --> 00:34:04.519 of the business stakehold, the language of the system reliability engineer, stite reliability, 478 00:34:04.519 --> 00:34:06.920 the engineer, you know, the guys who are going to operate this 479 00:34:06.920 --> 00:34:10.679 stuff, Like if you're doing your job well, you are making sure all 480 00:34:10.760 --> 00:34:16.559 those stakeholders have a seat, are being heard and that their concerns are manifesting 481 00:34:16.639 --> 00:34:22.559 your diagrams and documents. Yea, I think that moves us into the second 482 00:34:22.599 --> 00:34:25.239 point level of my skills. You need to know is decision making, because 483 00:34:25.239 --> 00:34:30.239 it's that first step is understanding the decision to be made. You have to 484 00:34:30.840 --> 00:34:34.679 gather information from all those stakeholders. What do you want in your house? 485 00:34:35.920 --> 00:34:42.000 And you know, I've basically distilled decision making down to almost a simplified scientific 486 00:34:42.039 --> 00:34:45.920 method that you have that first step of understanding the decision and then take the 487 00:34:45.960 --> 00:34:52.079 time to produce some options, evaluate those options, and then decide on something. 488 00:34:52.800 --> 00:34:54.239 And then the last step, just like the scientific method, is to 489 00:34:54.360 --> 00:35:00.239 communicate your decision. Now that first and last step, say hey, look 490 00:35:00.239 --> 00:35:02.599 how important communication is. If you don't take the time to talk to the 491 00:35:02.679 --> 00:35:07.920 right people and understand what they need. And again, those different viewpoints are 492 00:35:07.920 --> 00:35:10.440 going to have different impacts on how you design something. Then you might design 493 00:35:10.440 --> 00:35:14.559 the wrong system. You might have missed that beam that you needed to put 494 00:35:14.639 --> 00:35:21.000 up. And many times you're the people that you're interviewing and asking their opinion. 495 00:35:21.119 --> 00:35:22.760 Sometimes they'll say I have no idea, what do you think? And 496 00:35:22.840 --> 00:35:27.559 sometimes they'll be very opinionated, Oh, we want to use the lamp stack 497 00:35:27.719 --> 00:35:32.800 with you know, Kubernetes and all this stuff. And you have to ask 498 00:35:32.880 --> 00:35:37.880 them why you know, without coming across like you don't know anything. And 499 00:35:37.920 --> 00:35:40.719 then they're going to throw you under the bus in the next meeting because you're 500 00:35:40.719 --> 00:35:45.199 an idiot. You know, like there's a dance to be done there, 501 00:35:45.320 --> 00:35:47.760 right, you need to okay, you want to do this? Tell me 502 00:35:47.800 --> 00:35:51.719 why what are the benefits. What are the drawbacks? Yep, I think 503 00:35:51.800 --> 00:35:54.400 there goes. Do any you know, ask any architect any question their default 504 00:35:54.440 --> 00:36:00.400 responses. It depends because it always depends on what was decision criteria and that 505 00:36:00.440 --> 00:36:04.960 example, I want to use lamp stack, Well why well we use the 506 00:36:05.039 --> 00:36:07.280 lamp stack? Well why do we use the lamp stack? It's like, 507 00:36:07.320 --> 00:36:10.639 well, it's in our architectural diagrams, and can you tell me, well, 508 00:36:10.639 --> 00:36:14.440 why was the decision made? Well, it's on the diagrams. The 509 00:36:14.440 --> 00:36:19.800 diagram only it's like watching the Olympics. Imagine they only covered the metal ceremony 510 00:36:19.840 --> 00:36:22.159 and they only showed the gold medalists. You don't get to see anybody else. 511 00:36:22.400 --> 00:36:25.440 You don't get to see any of the events, like something's missing. 512 00:36:25.599 --> 00:36:30.320 The diagram just captures the winner. But there was a lot of thought process, 513 00:36:30.360 --> 00:36:35.800 that whole scientific method of here are the options we chose. And that's 514 00:36:35.800 --> 00:36:38.119 why instead of just having the diagrams as useful as they can be, I 515 00:36:38.199 --> 00:36:45.960 like to use Architecture Decision Records ADRs because they capture that why behind the decision? 516 00:36:45.119 --> 00:36:47.760 Why do we use the lamp stack? Here was what we considered. 517 00:36:49.480 --> 00:36:52.440 Here are the trade offs that we looked at and then this one. Because 518 00:36:52.440 --> 00:36:54.480 of all these decisions. A good technique that I like to use is, 519 00:36:54.599 --> 00:37:00.280 Okay, pretend I don't know anything about whatever it is you're suggesting the lamp 520 00:37:00.360 --> 00:37:06.519 stack Kubernetti. Pretend I don't know anything, convince me go ahead, and 521 00:37:06.800 --> 00:37:10.280 I'm gonna just make some notes here. You know. So it because if 522 00:37:10.280 --> 00:37:15.119 you're an architect, right, you'll probably know these things and somebody's gonna just 523 00:37:15.199 --> 00:37:17.920 look at you and say, like you said, well, because that's the 524 00:37:17.960 --> 00:37:21.599 best thing, right, because you know, why should I explain it to 525 00:37:21.599 --> 00:37:23.440 you? So you have to say, look, pretend I'm your mother. 526 00:37:24.840 --> 00:37:30.679 Explain you know, explain yourself. Grandma Franklin needs to know why the lamp 527 00:37:30.719 --> 00:37:37.000 stack. Absolutely. I grabbed the link to adr gethub dot io, which 528 00:37:37.079 --> 00:37:40.760 is a pretty good summary of the architectural decision records. This is really about 529 00:37:40.920 --> 00:37:46.159 documenting these decisions, to capture why it's documented decisions. The term I think 530 00:37:46.239 --> 00:37:49.480 was coined as far as I can tell, by Michael Nygard, like, 531 00:37:51.559 --> 00:37:54.039 yeah, those things come down to thought works, don't they. And the 532 00:37:54.079 --> 00:37:58.519 other one that you might want to look up is mad m adr the markdown, 533 00:38:00.159 --> 00:38:02.119 well, it was marked down architecture decision records. They changed the name 534 00:38:02.199 --> 00:38:07.039 to mark Down Any Decision Records because what we're talking about this decision making, 535 00:38:07.119 --> 00:38:10.880 it doesn't have to be just software architecture. Those were just the first people 536 00:38:10.960 --> 00:38:15.880 that needed to find a way to communicate their decisions, right. I would 537 00:38:15.920 --> 00:38:20.039 love to see more businesses using this for the business decisions. Why did we 538 00:38:20.079 --> 00:38:22.920 decide to do this project and not that project? Why did we fund this, 539 00:38:22.440 --> 00:38:25.199 Why are we you know, hiring these people, why are we doing 540 00:38:25.199 --> 00:38:30.519 whatever? You can capture those decisions as opposed to oh it was decided from 541 00:38:30.559 --> 00:38:35.000 Yeah, and nobody's ever going to read these except a large language model. 542 00:38:35.000 --> 00:38:37.519 It's operating your business, which should be enough, right, Like then you 543 00:38:37.599 --> 00:38:42.280 can ask it questions and it should have pretty good answers based on the ADR 544 00:38:42.400 --> 00:38:45.320 data. Yeah, there's been a discussion about that, like can we plug 545 00:38:45.360 --> 00:38:49.719 it in and say, can it analyze what the next decision? What is 546 00:38:49.800 --> 00:38:53.079 right and what's wrong. I have to admit when chat GPT first came out 547 00:38:53.119 --> 00:38:57.280 and I was working on this presentation, like I wonder what it would do, 548 00:38:57.400 --> 00:39:00.920 and so I asked it questions and I found it's it's good in that 549 00:39:00.000 --> 00:39:04.199 rubber duck scenario, give me the options, what are the trade offs? 550 00:39:04.400 --> 00:39:07.519 And if you are really, really lazy, you can ask it to write 551 00:39:07.519 --> 00:39:12.119 an a DR for you. Now check it because what it decides might not 552 00:39:12.199 --> 00:39:15.079 be the right thing for you, but it might give you that starting point. 553 00:39:15.199 --> 00:39:16.199 Right. Yeah, in the end, all the text is right. 554 00:39:16.320 --> 00:39:20.920 Is no different than a deep fake made on buy an image generator. It's 555 00:39:20.960 --> 00:39:23.800 sometimes those images aren't half bad, and sometimes that and sometimes the text isn't 556 00:39:23.800 --> 00:39:28.280 half bad, but it is. And it's nice to work from something already 557 00:39:28.280 --> 00:39:30.599 written. It's easier to edit than to write from scratch, but you do 558 00:39:30.719 --> 00:39:35.800 have to edit it. Yeah, it's and I like a DRS because they 559 00:39:35.800 --> 00:39:37.960 get you out of that blank whiteboard scenario. Yeah, when you go in 560 00:39:38.000 --> 00:39:40.800 and ask amy, draw your system and show me where your pain points are. 561 00:39:40.920 --> 00:39:45.639 That that's good. But when you get down to how are we going 562 00:39:45.679 --> 00:39:49.119 to solve the problem? I have sat there and stared at the blank whiteboard 563 00:39:49.159 --> 00:39:51.320 or the pen in hand, like I don't know. The answer is not 564 00:39:51.360 --> 00:39:53.719 coming to me, And you're just trying to think through and get to that, 565 00:39:54.039 --> 00:39:57.519 like you want to get to the end of the race without running it. 566 00:39:57.800 --> 00:40:00.079 Yeah, the a DR if you start with the markdown one. It's 567 00:40:00.079 --> 00:40:02.920 a template, and it's like, what's the name of the decision? What 568 00:40:04.000 --> 00:40:07.039 are you trying to decide? What are you considering? And just the act 569 00:40:07.119 --> 00:40:10.280 of having to fill out the template and write it out, it's the rubber 570 00:40:10.320 --> 00:40:14.840 duck. Again. You are explaining to yourself because you're going to have to 571 00:40:14.840 --> 00:40:19.239 explain it assuming someone else will read this document. Well, sometimes the decision 572 00:40:19.760 --> 00:40:27.039 is a bad not a bad decision, but it's unnecessary because of somewhere lower 573 00:40:27.159 --> 00:40:31.760 down in the stack, a decision was made that is focusing you on the 574 00:40:31.760 --> 00:40:36.960 wrong problem. And so that's where an architect can come in and say, 575 00:40:37.000 --> 00:40:39.719 you know, I understand why you're not coming up with a solution to this 576 00:40:39.840 --> 00:40:45.000 is it's because it's architected wrong. It's designed wrong, and you know, 577 00:40:45.079 --> 00:40:49.239 here's some suggestions of how to avoid this pitfall. Yeah, that gets to 578 00:40:49.280 --> 00:40:53.920 the third points, a good segue to adaptability because everything constantly changes, right, 579 00:40:53.960 --> 00:40:59.440 like no architecture plans survives first contact with the engineers. They are going 580 00:40:59.480 --> 00:41:01.840 to break they are not going to follow it, or they're going to implement 581 00:41:01.840 --> 00:41:05.880 it exactly the way you told them to, even the wrong things that you 582 00:41:05.960 --> 00:41:09.840 didn't realize and you have to change that. We have to have agile architecture. 583 00:41:09.920 --> 00:41:15.519 We have to have an architecture that can continually evolve. And if you 584 00:41:15.559 --> 00:41:20.199 make your decisions assuming this is the one only way to do this and they 585 00:41:20.199 --> 00:41:22.840 will never change now, the only way you're going to fix that is to 586 00:41:22.920 --> 00:41:27.239 replace the system down the line. It's better to say, here are the 587 00:41:27.280 --> 00:41:30.800 decisions we're making, and we assume that they're going to change over time, 588 00:41:30.320 --> 00:41:35.519 and if we document them when we say this isn't working anymore, we need 589 00:41:35.559 --> 00:41:38.239 to change it, instead of well, here's the diagram and try and redraw 590 00:41:38.320 --> 00:41:42.119 the diagram. If you look at the ad R, it's got a date 591 00:41:42.159 --> 00:41:44.920 on it, and it's got a decider like you have someone's name, like 592 00:41:44.920 --> 00:41:49.000 who to blame, and go ask the question like you chose this based on 593 00:41:49.000 --> 00:41:52.800 these criteria, But now we have a million users sitting on our website. 594 00:41:52.880 --> 00:41:57.840 Maybe our decision criteria was wrong. It was right at the time, but 595 00:41:57.880 --> 00:42:00.840 it no longer fits. You can just revisit that decision and you have that 596 00:42:00.920 --> 00:42:05.360 as a starting point, as opposed to throw it all over and start starting 597 00:42:05.360 --> 00:42:07.840 at you get those names and dates. It's kind of like a walk in 598 00:42:07.960 --> 00:42:12.639 and a restaurant, right, you know, you have to date things and 599 00:42:12.719 --> 00:42:15.960 you have to name them. What is this? Is it meet? Is 600 00:42:15.960 --> 00:42:20.679 it cake? We'll call it meat? Yeah, But you also make a 601 00:42:20.719 --> 00:42:22.760 point here. You're implying a point here, which is the architect's kept to 602 00:42:22.800 --> 00:42:28.159 stay engaged. Yea, because you know I have run into organizations where they're 603 00:42:28.159 --> 00:42:32.440 working from an architectural template and that person isn't at the company anymore, right, 604 00:42:32.599 --> 00:42:37.599 And so it's like this idea of architecture is gospel is disturbing. Yeah, 605 00:42:37.800 --> 00:42:40.960 And maybe if you have at least their name and not just a department 606 00:42:42.039 --> 00:42:45.039 or the architecture team, what does that mean? Like, I want to 607 00:42:45.079 --> 00:42:49.840 know Thomas made this decision? You know? Can I go ask him? 608 00:42:49.880 --> 00:42:53.039 And if you ask me about something I decided six months ago, I'm going 609 00:42:53.079 --> 00:42:55.440 to scratch my head and wonder. I'm like, yeah, it seemed like 610 00:42:55.519 --> 00:42:59.239 a good idea at the time, but I hadn't remember that if I wrote 611 00:42:59.280 --> 00:43:01.960 it down, I can point to it and we can have a discussion over 612 00:43:02.039 --> 00:43:07.199 that and say, is that's still valid? And oh we assume that is 613 00:43:07.199 --> 00:43:10.320 this still correct? Or what has changed? How many problems arise or can 614 00:43:10.360 --> 00:43:15.880 arise from people being afraid of looking bad. I'm sure you've seen that as 615 00:43:15.960 --> 00:43:21.039 much as I have. There is sometimes the I want to push forward because 616 00:43:21.039 --> 00:43:22.599 this is what we're doing, and I don't want to be the person to 617 00:43:23.039 --> 00:43:25.960 hit the brakes. My hardest decision. I'm not going to go into the 618 00:43:27.000 --> 00:43:30.039 details, but people know about this. You know. A year ago was 619 00:43:30.800 --> 00:43:34.480 I think we're going in the wrong direction, and it was my decision to 620 00:43:34.519 --> 00:43:37.239 go down that path. And then four or five six months later, it's 621 00:43:37.280 --> 00:43:42.800 like, this is really not the right way to go. And having gone 622 00:43:42.800 --> 00:43:45.639 through the whole process and document it the whole way, it's like, hey, 623 00:43:45.840 --> 00:43:50.840 this was a great idea, but our business requirements changed and we want 624 00:43:50.880 --> 00:43:54.519 to do a slightly different path or significantly different path. We shouldn't just keep 625 00:43:54.559 --> 00:43:59.960 going blindly down that direction. And so yeah, we're gonna lose a few 626 00:44:00.039 --> 00:44:02.559 months worth of effort, but in the long run, and that was part 627 00:44:02.599 --> 00:44:06.599 of the ad R was let me show you what this looks like on a 628 00:44:06.679 --> 00:44:09.960 timeline, because again, explain to the right people. The business owner needs 629 00:44:09.960 --> 00:44:13.800 to know, not just oh, well the technical solution isn't going to work 630 00:44:13.840 --> 00:44:15.599 or it's gonna be hard. What does that mean? It means that a 631 00:44:15.679 --> 00:44:17.719 year and a half from now, we're not going to hit our goal. 632 00:44:19.039 --> 00:44:21.719 Yeah, and that's the money you're going to save. And a year and 633 00:44:21.719 --> 00:44:23.400 a half from now, we're going to deliver something instead. Oh I like 634 00:44:23.519 --> 00:44:27.639 that. Yeah, I'm gonna I can quickly deliver you the wrong thing, 635 00:44:27.960 --> 00:44:30.360 oh yeah, or we can spend a little more time to deliver the right 636 00:44:30.400 --> 00:44:31.639 thing. Which would you prefer. Actually, we were going to spend a 637 00:44:31.639 --> 00:44:35.639 long time delivering the wrong thing too, so yeah, we's been a long 638 00:44:35.679 --> 00:44:39.559 time delivering the wrong thing. If you want the worst of all worlds, 639 00:44:40.239 --> 00:44:44.800 yeah, yeah, I guess the real question is, you know how much 640 00:44:44.840 --> 00:44:49.320 of a refactor of architecture takes place? Like there's lots of incremental twitches you 641 00:44:49.360 --> 00:44:52.679 can do, but that whole hey, we kind of have to relay this 642 00:44:52.719 --> 00:44:55.320 whole thing out again. Yeah yeah, I like. I like when you 643 00:44:55.559 --> 00:45:00.000 can go into a new project and you say we're going to have an evolution 644 00:45:00.239 --> 00:45:04.000 architecture or a continuous architecture. There's two different terms. There's different people. 645 00:45:05.000 --> 00:45:07.880 And the guys that I worked with for an article series on info Queue, 646 00:45:08.679 --> 00:45:14.840 Peer Puer and Curb Bittner, they talked about a minimum viable architecture. And 647 00:45:14.880 --> 00:45:19.119 I love this idea of the MVA, which is the architecture that supports your 648 00:45:19.239 --> 00:45:24.079 MVP, your minimum viable product. Again, business stakeholders understand the MVP right, 649 00:45:24.199 --> 00:45:29.760 Well, I'm going to give you just enough architecture to support that because 650 00:45:29.800 --> 00:45:31.480 we're going to put this out in the wild, let customers use it, 651 00:45:31.559 --> 00:45:35.599 and then wait for feedback to find out what's our next step. What are 652 00:45:35.639 --> 00:45:38.000 we going to build on top of it? And as we change which direction 653 00:45:38.039 --> 00:45:42.679 the product heads, we have to make changes to our architecture as well. 654 00:45:43.280 --> 00:45:46.760 And the fact that you've designed your architecture to be adaptable and change because it's 655 00:45:46.800 --> 00:45:52.199 based on those decisions that can change it kind of builds in that agility from 656 00:45:52.199 --> 00:45:54.440 the get go. Yeah, it sounds if you're comfortable with the idea that 657 00:45:54.480 --> 00:45:58.719 you're going to revise the architecture, it is going to be revisited, then 658 00:45:58.800 --> 00:46:01.840 you do a lot. You don't have to overplan, you can just bring 659 00:46:01.880 --> 00:46:08.000 in that minimal viable with this acceptive of being refactored and infecting this software below 660 00:46:08.000 --> 00:46:14.320 it. I think that being agile it applies to both the architecturally build and 661 00:46:14.719 --> 00:46:19.679 how we as architects practice our jobs. I mentioned earlier, you're not sitting 662 00:46:19.760 --> 00:46:22.960 in a desk in a cubicle farm next to everyone. Everyone's remote. How 663 00:46:23.000 --> 00:46:28.559 do you get the pulse of everything? Well, that switch, that abrupt 664 00:46:28.320 --> 00:46:35.920 shift from in person to everyone's hybrid, brought about a bunch of communication challenges, 665 00:46:35.960 --> 00:46:40.079 but people also saw communication opportunities. We went to more people are doing 666 00:46:40.119 --> 00:46:45.719 asynchronous communication, like I don't need to have that face to face meeting and 667 00:46:45.119 --> 00:46:47.639 that those are those distractions you talked about. I don't want to bother the 668 00:46:47.679 --> 00:46:52.840 developer and interrupt their day because this five minute call is going to actually take 669 00:46:52.880 --> 00:46:57.559 them out of their headspace for an hour. So asynchronous communication is good. 670 00:46:57.679 --> 00:47:02.119 ADRs support asynchro communication. Instead of only the people who can go into the 671 00:47:02.159 --> 00:47:06.239 room with the whiteboard and draw on the conference room whiteboard, get to be 672 00:47:06.280 --> 00:47:07.920 in the decision. Now everybody can see your decision. I like sticking them 673 00:47:07.920 --> 00:47:12.039 in source control, put them in get it's a text file. Anybody can 674 00:47:12.039 --> 00:47:16.920 see them. They're highly adaptable, and I think we've even seen, you 675 00:47:16.960 --> 00:47:22.920 know, kind of the fallout of the companies that did adapted well to being 676 00:47:22.000 --> 00:47:24.880 remote, like the ones who are able to just like keep doing business and 677 00:47:24.920 --> 00:47:30.320 didn't have this abrupt like stop in their business process. Like some of that 678 00:47:30.440 --> 00:47:34.079 is the team and some of it is the architecture. And you know, 679 00:47:34.119 --> 00:47:37.079 you guys have talked about Conway's law a few times that your architecture looks like 680 00:47:37.360 --> 00:47:42.599 your teams your team architecture. Yet Yeah, and I have the COVID corollary 681 00:47:42.639 --> 00:47:47.840 to Conway's law that highly effective distributed teams are able to build highly effective distributed 682 00:47:47.840 --> 00:47:54.599 systems. And contrary to that, if your teams struggle with that highly distributed 683 00:47:54.599 --> 00:48:00.239 communication, you are not going to be successful building a distributed system. If 684 00:48:00.239 --> 00:48:02.239 you're like, we're gonna do micro services, but our teams have to be 685 00:48:02.280 --> 00:48:06.559 in the office together, Like your team structure is a monolith, you have 686 00:48:06.559 --> 00:48:09.480 to build a monolith. Yeah, you're well more relevantly, you're gonna build 687 00:48:09.480 --> 00:48:14.000 a modelith you can call it whatever you want, but this is what's going 688 00:48:14.039 --> 00:48:16.679 to come out of the other side. It's interesting to point your point. 689 00:48:16.679 --> 00:48:21.360 Then it's like, because the team is distributed, we've kind of have an 690 00:48:21.400 --> 00:48:24.679 opportunity here to make it easier to build more distributed systems because they're already working 691 00:48:24.719 --> 00:48:29.159 like that. Yeah, yeah, and we find where are the teams struggling 692 00:48:29.159 --> 00:48:32.360 to communicate. How do we fix that's that marriage counselor role. How do 693 00:48:32.400 --> 00:48:36.760 we fix the communication between teams? If they have to talk to each other 694 00:48:37.199 --> 00:48:39.760 every day, then there's not really two teams. You have one big team. 695 00:48:39.840 --> 00:48:45.320 First thing is to not use teams. We have a combination with Slack 696 00:48:45.360 --> 00:48:49.440 and teams. And you can tell guess who uses slack, A big Slack 697 00:48:49.480 --> 00:48:52.360 fan, not a big the engineers use Slack. Everyone else in the business 698 00:48:52.440 --> 00:48:58.920 uses teams. Yeah, so it but yeah, interesting, you were talking 699 00:48:58.920 --> 00:49:00.840 about this idea of if you're municating with a group every day, they're actually 700 00:49:00.840 --> 00:49:06.320 on the same team, right, And that's that you want loose coupling in 701 00:49:06.360 --> 00:49:09.280 your architecture. You want loose coupling and your teams. And so if those 702 00:49:09.559 --> 00:49:14.320 teams want to be able to work independently, you want to reduce how many 703 00:49:14.360 --> 00:49:16.960 communication points they have that will be in their software as well, that their 704 00:49:17.159 --> 00:49:21.920 software will communicate on the same boundaries. But if you have that we've got 705 00:49:22.000 --> 00:49:24.679 to talk every day, then yeah, you've got two services that are highly 706 00:49:24.679 --> 00:49:28.159 coupled, and they're gonna have to be deployed in law study as well be 707 00:49:28.199 --> 00:49:30.639 the same service. Yeah, now you have the distributed monolith, which is 708 00:49:30.639 --> 00:49:35.599 the worst of all worlds. That I mean. At the same time, 709 00:49:35.639 --> 00:49:38.679 I'm always loath to block communication in any way, right, but I would 710 00:49:38.800 --> 00:49:42.719 I would think in an architecture role, you're like, Okay, these teams 711 00:49:42.760 --> 00:49:49.000 are need to communicate routinely. You want useful communication, right, You shouldn't 712 00:49:49.079 --> 00:49:51.679 have to talk all the time to figure out, Hey, how do I 713 00:49:51.719 --> 00:49:55.079 call your service? And that should be documented, make a swagger end point 714 00:49:55.079 --> 00:49:59.480 and just generate a client off of that. And if it doesn't work and 715 00:49:59.519 --> 00:50:00.320 it doesn't do what you need and say, hey, I need a new 716 00:50:00.400 --> 00:50:04.119 endpoint, how do you submit a poor request to them? How do you 717 00:50:04.679 --> 00:50:07.800 use those techniques and have a little bit of discussion over here's what I need 718 00:50:07.840 --> 00:50:12.679 from you. Not let's sit down together and now I've pulled you off your 719 00:50:12.719 --> 00:50:15.159 task so you can work on my task with me. You know, this 720 00:50:15.199 --> 00:50:20.239 is a good opportunity to ask you, Thomas, what you thought of the 721 00:50:20.280 --> 00:50:24.559 modular monoliths show we do with Leila, because we're talking about that now. 722 00:50:25.760 --> 00:50:31.679 Yeah, I'm actually halfway through that episode. But no, the modular monolith 723 00:50:31.760 --> 00:50:37.639 is a topic that's on the INFOCU Trends report. So every year INFOCU does 724 00:50:37.719 --> 00:50:40.719 several different trends reports, and I'm responsible for the architecture one, and we've 725 00:50:40.760 --> 00:50:46.840 had some variation of modular monolith moving across that the graph for a while. 726 00:50:47.400 --> 00:50:52.000 And it's the idea that you don't like. It's not monolith versus micro services. 727 00:50:52.159 --> 00:50:57.840 It's well architected systems and what are the modules that you need to build 728 00:50:58.079 --> 00:51:01.760 and recognizing Yeah, you can separate concerns without going full on micro service, 729 00:51:02.119 --> 00:51:06.760 right, And so if your code sciences is as simple as how do you 730 00:51:06.880 --> 00:51:13.039 organize your code? I can't remember who talked about the good architecture. There's 731 00:51:13.079 --> 00:51:15.760 some discussion about how to stu up your project and it was like very structure 732 00:51:15.800 --> 00:51:17.559 and you had to follow the rules. It's like, this is so much 733 00:51:17.559 --> 00:51:21.920 structure. I'm like, I think what he was getting at is if I 734 00:51:21.960 --> 00:51:25.000 have a directory structure and I'm going to change. You know, we do 735 00:51:25.119 --> 00:51:30.559 financial stuff invoices, and here's the invoices controller and then here's the Invoices business 736 00:51:30.639 --> 00:51:35.559 layer, and here's the invoices data layer. And I'm any one change to 737 00:51:35.679 --> 00:51:39.239 invoices is touching code in three different places. Like if you just modify the 738 00:51:39.239 --> 00:51:44.159 folder structure and say it's invoices, and then underneath that is all the stuff 739 00:51:44.280 --> 00:51:47.119 when you make a change to that module, Like, all of your change 740 00:51:47.159 --> 00:51:51.119 are under one directory structure. And mentally you're like, oh, this is 741 00:51:51.159 --> 00:51:55.840 not a big cross cutting concern. It's that vertical slice and all those vertical 742 00:51:55.840 --> 00:52:00.760 slices stay together. And so when I see modular monoliths, I think that's 743 00:52:00.800 --> 00:52:05.679 good because you're focusing on the modularity aspect. The modelis is just the delivery 744 00:52:05.719 --> 00:52:09.119 technique. Yeah, A good way to find out what's going to get touched 745 00:52:09.239 --> 00:52:15.039 is just change the interface. Let the compiler tell you. Yeah, I 746 00:52:15.079 --> 00:52:17.679 think it was. You've all lower you talked about the things you break off 747 00:52:17.719 --> 00:52:22.079 into monoliths or into micro services. It's not necessarily for the performance gains. 748 00:52:22.159 --> 00:52:25.880 But what is likely to change a lot, And you want the thing that 749 00:52:25.880 --> 00:52:29.800 you change a lot to be as small as possible. And the stuff you 750 00:52:29.840 --> 00:52:32.400 don't change a lot is very stable. Like the food in my fridge gets 751 00:52:32.480 --> 00:52:36.599 changed all the time, but my refrigerator doesn't get changed. Let's be honest. 752 00:52:36.599 --> 00:52:38.599 You don't do this for performance. In fact, it will often degrade 753 00:52:38.679 --> 00:52:44.840 performance. You do this for Yeah, you want to be agile. It 754 00:52:45.400 --> 00:52:46.960 depends what you mean by performance, yeah, because I had to throw out 755 00:52:46.960 --> 00:52:52.360 it depends there because if you're you have a service that needs to do a 756 00:52:52.360 --> 00:52:55.880 million requests, then you need to be able to scale that to handle a 757 00:52:55.880 --> 00:53:01.039 million requests and the other service doesn't need to have that much load. Does 758 00:53:01.039 --> 00:53:05.480 it need to be as BIG's And that's not so much a performance conversation, 759 00:53:05.639 --> 00:53:07.280 is a scaling conversation. Yeah, and yeah, you need to find the 760 00:53:07.320 --> 00:53:14.559 appropriate level of granularity for all of these things. Yeah, but I do 761 00:53:14.960 --> 00:53:20.360 agree with that. You've all's positioned on where where are your points of resonance? 762 00:53:20.559 --> 00:53:24.360 Like where where? And how big you want the smallest pieces of your 763 00:53:24.360 --> 00:53:28.920 code vibrating. So it's like, oh, you know, this constant change 764 00:53:28.960 --> 00:53:30.960 happening in this service, but it's tied to these other four and so now 765 00:53:30.960 --> 00:53:37.000 they're all constantly being redeployed. It's like peeling that one off and paying a 766 00:53:37.000 --> 00:53:39.880 bit of overhead to it so that the impact of update is lower. Ye, 767 00:53:40.639 --> 00:53:44.559 you know, we're willing to pay that overhead, only you know those 768 00:53:45.079 --> 00:53:47.440 often those overheads are milliseconds, so it's not that big of a deal, 769 00:53:47.519 --> 00:53:52.840 but it is a security boundary. It's a transactional boundary. Like nothing is 770 00:53:52.840 --> 00:53:54.800 free. Yeah, if you've got something that has to be really secure, 771 00:53:54.880 --> 00:53:59.639 you've got PII data whatever, and you PCI data whatever. It is, 772 00:53:59.679 --> 00:54:01.960 like I want nobody to see that except this little thing over here. That's 773 00:54:01.960 --> 00:54:07.880 easy. It's the convenience factor where oh, I'll just put this code here 774 00:54:07.639 --> 00:54:12.119 that tends to get to Like the monolith isn't bad. It's the big ball 775 00:54:12.159 --> 00:54:15.119 of mud that's bad. The code that we can't understand, that's bad. 776 00:54:15.559 --> 00:54:20.480 So the monolith is fine if it's the right thing. And for most cases, 777 00:54:20.719 --> 00:54:24.119 don't start with microservices. That's usually your first step. Like if I 778 00:54:24.159 --> 00:54:27.840 had one problem and then we came with microservices, now we have ninety nine, 779 00:54:28.079 --> 00:54:34.159 I have a microservices a problem factory. Right, yeah, I think. 780 00:54:34.360 --> 00:54:36.840 I think in that same show with Leyla, and admittedly it came out 781 00:54:36.960 --> 00:54:39.239 yesterday, so I don't blame you for not having finishal listening to it. 782 00:54:39.320 --> 00:54:45.239 Yet we're recording it the day after it was published. There's another Conway's law 783 00:54:45.280 --> 00:54:47.880 element there where you know, I think lately did a good job of describing 784 00:54:47.920 --> 00:54:52.559 where is the case where you start with microservice. It's a very large project. 785 00:54:52.679 --> 00:54:55.400 You know it's a large project and you have a large distributed team working 786 00:54:55.440 --> 00:55:01.400 on it, where now the microservices boundary is actually simple afy working in parallel 787 00:55:01.440 --> 00:55:05.719 with such a big team. Yeah, but if you don't, if you 788 00:55:05.760 --> 00:55:08.000 don't have all of those things, like you're just creating ceremony you don't need. 789 00:55:08.320 --> 00:55:10.840 Yeah, I think I think that's Martin Fowler has a post of you 790 00:55:10.920 --> 00:55:16.119 must be this tall to ride micro services, love it and and if you 791 00:55:16.159 --> 00:55:20.079 only have ten people, you should not do it. Yeah. Right, 792 00:55:20.320 --> 00:55:22.960 you need someone to work on your platform. How do you make it easy 793 00:55:23.039 --> 00:55:27.079 to spin up new services and tear them down? Like I don't want to 794 00:55:27.119 --> 00:55:30.719 have to be going into the Azure portal every time I need a new service 795 00:55:30.880 --> 00:55:32.800 I have, I have almost command line tools. I want to create something, 796 00:55:34.400 --> 00:55:39.199 I spend something up and that that that platform that we need for the 797 00:55:39.360 --> 00:55:45.119 development to be efficient. You need people that are just dedicated on that problem 798 00:55:45.159 --> 00:55:49.280 and be able to make that scale and efficient to your team. Yeah, 799 00:55:49.559 --> 00:55:52.679 very fair done. Coming into the end here, how do we want to 800 00:55:52.679 --> 00:55:55.840 wrap this up and leaders anything to call back on? Yeah? The last 801 00:55:55.840 --> 00:56:00.320 thing we didn't get to his leadership, and I think that this back to 802 00:56:00.320 --> 00:56:02.599 the point that every architect still needs to write some code, and on the 803 00:56:02.599 --> 00:56:07.760 flip side, all developers can do architecture. I talked to Andrew harm Law, 804 00:56:07.800 --> 00:56:10.960 who I just saw today. The first two chapters of his new book 805 00:56:10.960 --> 00:56:15.719 are coming out. They're available on O'Riley or somewhere. But he talked about 806 00:56:15.760 --> 00:56:20.599 the architecture advice process, and it gets to the idea that anyone can make 807 00:56:20.679 --> 00:56:23.159 architecture decisions. There's only two caveats. You have to talk to all the 808 00:56:23.159 --> 00:56:27.800 people who are going to be impacted by the decision, and talk to the 809 00:56:27.800 --> 00:56:31.559 people who have knowledge about and the relevant experience to make the decision. So 810 00:56:31.840 --> 00:56:36.320 this is one of those things like be the servant leader and help mentor the 811 00:56:36.360 --> 00:56:38.360 next generation of architects. Again, you don't have to be an architect, 812 00:56:38.400 --> 00:56:42.920 but I want to help you make good decisions. Maybe it's not even architecture 813 00:56:42.920 --> 00:56:45.280 decision. Maybe it's should I use this library or that library. Let's think 814 00:56:45.280 --> 00:56:47.960 about it. Maybe we should write an ADR for that. To just go 815 00:56:49.039 --> 00:56:53.039 through the process and if they see I've had engineers I work with say I 816 00:56:53.079 --> 00:56:57.880 appreciate that we use a DRS because it tells me how to make a decision, 817 00:56:57.960 --> 00:57:00.440 like they're seeing why was a decision made? But also, oh, 818 00:57:00.599 --> 00:57:04.280 I can use that as a template when I need to make a heart decision. 819 00:57:04.480 --> 00:57:07.679 So right, if I can complete this ADR document in a sensible way, 820 00:57:07.679 --> 00:57:10.320 I have a better chance of getting that decision done. Yep. Yeah. 821 00:57:10.360 --> 00:57:14.760 So architecture is a team sport, you know. We got to find 822 00:57:14.760 --> 00:57:19.719 the ways to work with everybody, encourage them to get better. I think 823 00:57:19.760 --> 00:57:22.480 the last little shout out I have to get it is read Domain Dier from 824 00:57:22.559 --> 00:57:27.800 Design by Eric Evans, because when I talk about communication and I said that 825 00:57:27.880 --> 00:57:31.440 communication is between computers, between people and computers, and between two people, 826 00:57:34.239 --> 00:57:37.400 DDD really gets to the heart of that. I mean, the subtitle of 827 00:57:37.440 --> 00:57:42.000 book is tackling complexity at the heart of software. If you use a ubiquitous 828 00:57:42.079 --> 00:57:45.800 language within a bounded context, and you take that language of the business, 829 00:57:45.400 --> 00:57:50.039 use it for your requirements, use it for your code, it's going to 830 00:57:50.119 --> 00:57:52.320 solve a lot of problems because you don't have those extra translation steps. You 831 00:57:52.360 --> 00:57:55.480 just simplify the communication. And so that's one of the things that I always 832 00:57:55.519 --> 00:58:00.000 go back to. It's like, how do we define our domain and recognize 833 00:58:00.360 --> 00:58:04.360 what the language is within my domain? Isn't the same outside the domain. 834 00:58:04.480 --> 00:58:07.880 Like if I say cookies, am I going to go and give you a 835 00:58:07.880 --> 00:58:09.880 cookie to eat? Or you accepting the cookies on the website? Right, 836 00:58:10.239 --> 00:58:14.920 words don't always mean the same, and so make that boundary context, make 837 00:58:14.960 --> 00:58:17.280 the boundary and say, right now, for our problem, here's what we're 838 00:58:17.280 --> 00:58:21.239 talking about. Yeah, good stuff, Thomas. What's next for you? 839 00:58:21.559 --> 00:58:24.400 What's in your inn? So my bio mentioned that I'm living with my wife 840 00:58:24.400 --> 00:58:30.880 and son here in Denver. My son starts college in two weeks. Not 841 00:58:30.880 --> 00:58:35.760 not at all nervous or excited about that. Okay, no, no, 842 00:58:35.920 --> 00:58:40.159 one state over. He's going on in Nebraska. So yeah, so close 843 00:58:40.239 --> 00:58:44.039 enough he could come over for the weekend, but far enough away that he 844 00:58:44.079 --> 00:58:46.719 probably won't. So Denver has like the third busiest airport in the world. 845 00:58:47.039 --> 00:58:50.920 Omaha does not. And I have to say, having flown in there, 846 00:58:50.960 --> 00:58:53.360 it's amazing. It's so great, isn't it. So I love getting in 847 00:58:53.400 --> 00:58:57.559 out of smaller reports. And then the other thing on my to do list 848 00:58:57.559 --> 00:59:02.559 coming up, I'll be speaking at my company's annual conference, Bbcon in October, 849 00:59:02.760 --> 00:59:07.880 which is back in person for the first time. Pandemic and it's in 850 00:59:07.920 --> 00:59:12.000 Denver. It moves around the country, and so I'm like I will, 851 00:59:12.280 --> 00:59:15.079 I'm in Denver, so you get to go home at net. So anyone 852 00:59:15.119 --> 00:59:19.119 listening to the show who is a black Bug customer and wants to hear about 853 00:59:19.159 --> 00:59:22.599 the architecture we're doing within our systems, that's all. I'll be speaking about 854 00:59:22.679 --> 00:59:25.239 a couple of my coworkers. All right, Thomas, this has been great. 855 00:59:25.480 --> 00:59:28.800 It's always good to talk to you, and it's been a long time. 856 00:59:28.840 --> 00:59:31.000 And come back soon, will you? Of course? Have you do 857 00:59:31.079 --> 00:59:35.800 help anytime? All right, We'll see you next time on dot net rocks. 858 00:59:58.159 --> 01:00:01.159 Dot net Rocks is brought to you by Frankland's Net and produced by Pop 859 01:00:01.239 --> 01:00:07.880 Studios, a full service audio, video and post production facility located physically in 860 01:00:07.960 --> 01:00:13.280 New London, Connecticut, and of course in the cloud online at pwop dot 861 01:00:13.320 --> 01:00:17.519 com. Visit our website at dt n et r o c ks dot com 862 01:00:17.559 --> 01:00:22.400 for RSS feeds, downloads, mobile apps, comments, and access to the 863 01:00:22.440 --> 01:00:28.039 full archives going back to show number one, recorded in September two thousand and 864 01:00:28.119 --> 01:00:30.480 two. And make sure you check out our sponsors. They keep us in 865 01:00:30.599 --> 01:00:37.119 business. Now go write some code, see you next time. We got Van