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