In this episode, Kenny and Andrea dive deep into some really interesting problems we're seeing in software architecture & design right now. You know, how some people are still working in those "ivory towers," or even the "hands-on" folks are running into issues? We're trying to figure out some different ways to build better systems.

Kenny (Baas) Schwegler: Hello Andrea.

2

Good evening to you.

3

Andrea Magnorsky: How are you?

4

Good morning for you.

5

Kenny (Baas) Schwegler: Yeah.

6

So why are we here?

7

Why are we doing this?

8

Andrea Magnorsky: We're trying to

learn about stories on facilitating

9

software architecture We keep seeing

this thing of people either on working

10

in ivory towers, having problems with.

11

Software architecture practices

and also people doing hands-on

12

work also having problems.

13

And we're trying to kind of talk about

some other options that, you know there,

14

if there's something else that we can do

that allows us to build parent systems.

15

So that's why we're here.

16

Kenny (Baas) Schwegler: Good.

17

Yeah.

18

And we're missing someone.

19

He's not here unfortunately, Andrew.

20

But hopefully he'll be here next time.

21

Andrea Magnorsky: We're missing Andrew a

lot, and hopefully this amazing video will

22

make Andrew realize and get some fomo.

23

Kenny (Baas) Schwegler: Yeah, and

hopefully we can invite some other friends

24

of ours that can join the stories because

there's a lot of stories to tell, let's

25

first go into what's the problem, right?

26

Why are we doing this?

27

Actually, the stories on facilitating

software architecture, there's the

28

great book about Andrew as well, right?

29

With is facilitating

software architecture.

30

I wrote a book with Evelyn and Gien,

about collaborative software design.

31

and there's the book by Diana,

of course on her system thinking.

32

So there's this shift from

architecture Andrew writes about it.

33

Of course, I put it a little bit of

a team topology model here where you

34

see, okay, we have these four teams.

35

We might have a platform team as well,

and these teams need to take, decisions,

36

architectural decisions, right?

37

So when we want to scale architecture when

you're just in one team, it's easy, right?

38

Still, there might be some problems there.

39

Some

40

Andrea Magnorsky: problems, yeah.

41

Yeah.

42

So in this architectural scale,

what things can go wrong?

43

In here this picture is saying we

have four stream aligned teams, I'm

44

describing what I'm seeing, right?

45

Some decisions that need to be made.

46

Then we have a platform team,

and there's inside that.

47

Two streamline teams that are doing

platforming stuff I dunno what kind

48

of ways you're doing this decision.

49

So I'm kind of wondering about,

are these decisions transparent?

50

What happens when, these different

teams needs some to do something?

51

that requires coordination.

52

How do they do that?

53

How does their organizational structure

enables or hampers them in making

54

these decisions that need to, that's

when I see this picture, that's

55

the first things I start seeing.

56

What do you see?

57

Kenny (Baas) Schwegler: Yeah, it's

the same what I see, , a lot of

58

organization do is moving with team

topologies to these kind of setups,

59

Where we have, where they say we have

streamlined teams and we have have these.

60

Teams in the platform team, right?

61

They bring, can be cloud teams,

so they can be any any teams that

62

helps the streamline team build

faster software because that's

63

what we're trying to do, right?

64

We're trying to unblock the teams

with so they can be more independent

65

and they can deliver more value.

66

The thing is what I see right?

67

Streamline teams and the platform teams

need to have architectural decisions,

68

significant architectural decisions.

69

So usually what I mean with

that, it's impacting other teams.

70

What might impact other teams.

71

Especially this one in the middle, right?

72

It's a bigger one between the two teams.

73

And classically how organizations are

doing that is a little bit, well, one

74

option, one mode is okay, then we're gonna

have some ivory tower architects, right?

75

So we've.

76

Create an architecture team.

77

Hint, nowadays they'll call that

an enablement team, but are they

78

actually enabling these I, I

put it in the gray area, right?

79

Which is not a official team

topology type, but when you look

80

at the team topology model they

have this to explain, this is not

81

an official team topology type.

82

And we were talking about

this earlier as well.

83

Team topology is just a model to help you.

84

Visualized flow of change within your

teams and see how can we change them.

85

In this case, you have architects

and they're helping the teams,

86

so they're in collaboration

mode, which is that purple thing.

87

But that's actually blocking and

maybe as if you're working inside a

88

team or if you're an architect like

myself or like you Andrea, right?

89

You have this feeling, right?

90

Oh, I'm helping the team,

but they're also waiting.

91

On me with my, maybe with my expertise

of the company or of the organization, or

92

Andrea Magnorsky: maybe

there is a coordination.

93

'cause there's collaboration

and also coordination's

94

well, we're waiting for you.

95

And also we're waiting maybe for a

third party, maybe for another team

96

that needs to respond about something

that they might not know yet.

97

And maybe as someone needs to go and

unblock them, and it could be you, me,

98

or someone else that they depend on.

99

So there's all this.

100

Waiting times, which are obviously

the opposite of what we want.

101

Right?

102

Kenny (Baas) Schwegler:

And they never wait.

103

I mean, a team cannot wait.

104

They won't do nothing.

105

So either they'll build

something themselves and work

106

around you as an architect.

107

So they say, and that's what I saw

happening in the agile world, right?

108

Teams are starting working more agile.

109

And then, oh, but we have this

architect what you need to wait on?

110

Well, we cannot wait.

111

Then you have a po.

112

Well, we cannot wait.

113

We need to deliver this.

114

So they're gonna do stuff anyway.

115

And it's still architecture.

116

Because there is either two modes.

117

It's either good architecture or bad

architecture, or somewhere in between.

118

You cannot do, you cannot not do no

119

Andrea Magnorsky: architecture.

120

Kenny (Baas) Schwegler: Yeah.

121

So the teams will do architecture without

them knowing they're doing architecture.

122

So either they're lucky and they're

doing it good, but most of the

123

time it's making things worse.

124

So this is one mode, of course, where

you have an ar ivory tower architect,

125

and then you have the mode, like more

of the hands-on architect, right?

126

Where you have.

127

Well, let's work within

the teams and with them.

128

But that's still blocking in a way,

because the architect is still the

129

one with the knowledge and they are

not passing this towards the team.

130

So still

131

Andrea Magnorsky: there's some,

and I'm gonna propose also

132

something so in here I, yeah.

133

What you're saying is there's this.

134

A hands-on architects would be some

like and again, this could be someone

135

that has a different role name but is

doing the architectural role, right?

136

And yeah, sometimes it goes

staff principles, sometimes

137

it's like a team lead.

138

Like, yeah, it doesn't really matter,

but it's someone that is doing the

139

architectural role and they supposedly

there's some bigger, more difficult, or

140

insert some way to make a decision about

why this person should focus on this.

141

Now they go and focus on this.

142

But the reality is that person will have

just so much context about the problem.

143

Yeah.

144

And they might be extremely capable.

145

Like this is not about how

capable that person is.

146

This is about, that is not possible

to know as much as the team that

147

consistently works on this on,

148

Kenny (Baas) Schwegler: yeah.

149

Yes.

150

And if this is the same, so in the

previous slide, we have one architecture

151

team that might be working like.

152

Here's something, pick it up, do it here.

153

It's more like the mode of an architect.

154

Go towards the team and work with them,

and then move to the other team and

155

work with them and then work with them.

156

So it's a different mode, but yeah,

that's this is also a blocker flow.

157

This is why we want to

and this is, I think.

158

Why Andrew and wrote the book

and why we of course, also move

159

towards more facilitating software

architecture instead of these modes.

160

Because what's happening here and this is

a great slide I always use by John Koler,

161

is what are the team boundaries, right?

162

What are these team boundaries and

what are, what I usually see happening

163

is actually all the team boundaries

are nowadays, mostly here, right?

164

Andrea Magnorsky: Can we describe this

you know, this is a, a super rich diagram.

165

Can we talk a little bit more about it?

166

Like what are we seeing here?

167

Kenny (Baas) Schwegler: Yeah.

168

What are we

169

Andrea Magnorsky: seeing here?

170

This picture what are we looking at?

171

So there is waterfall, agile.

172

Agile, able to release.

173

Can we other stuff that I can't,

174

Kenny (Baas) Schwegler: this is a

model and it's an overall model.

175

That's what John said.

176

He made this in 10 minutes.

177

He gave great talk with.

178

Zin at DDD Europe about modeling, right?

179

And here's just a model about

what are your team boundaries?

180

And he described these phases that a team

goes through, like opportunity selection,

181

requirements planning, design, and this.

182

This is very linear, while in reality

it might not be little, but these

183

are the phases that you might go

through, build, test, release, run.

184

So in the early days you have

waterfall, and for each of these

185

sections, you had a different team.

186

So then of course the whole agile came

in and then the whole DevOps came in.

187

And what you're seeing with the

yellow one are the team boundaries.

188

So that part is owned by the team, but

you might still have internal handover.

189

So a story I was in a, in DevOps teams I

think eight years ago, and I was doing my

190

work as a Java engineer, and then I was

like, oh, this needs to go to production.

191

So I went to Jira, I filled in.

192

A ticket and I pressed send, and that

ticket went to the person sitting

193

next on the other side of the desk,

which was the person was in my team.

194

But the and that's what you see with this

handover, right from test to release.

195

So we actually did a handover.

196

The person was in the team, but I did

a gyro handover and I, and that was

197

the moment I was thinking, oh, this.

198

What's happening, I should actually go to

him and work with him, but I didn't have

199

the rights to do all the things he could.

200

But it was a first step.

201

So you see the first step, they're

in the team and then slow you.

202

You're also getting the rights to do that.

203

So those are internal

for external handoffs.

204

And when what John says handoff

is what I see in team topologies

205

called a blocker to flow, right?

206

I need to wait before that person

inside my teams does the release.

207

So, that's a little bit

of the team boundary.

208

And for me, what you want as a

stream aligned team is of course

209

the one at the bottom, because

then the whole team is able to do

210

everything without being unblocked.

211

So that's what we're seeing here.

212

Yeah.

213

Andrea Magnorsky: Yeah.

214

Yeah.

215

So I thought it was nice to explain

what we see when we see this.

216

And also I'd love to hear what you

were saying, which is like, when

217

we're talking with teams, we see.

218

That they are not really in the

all yellow, and most of them

219

are also not in the all gray.

220

Like are gray are they?

221

Kenny (Baas) Schwegler: Yeah, there

might be different modes as well.

222

I've seen teams mostly go from build,

test, release to run internally what

223

you see as design as a team member.

224

But usually DevOps might be that

they're building, testing, releasing,

225

running, but not actually designing yet.

226

So there might be different modes as well.

227

You build it in 50 minutes, but

it's a good conversation starter.

228

Yes.

229

To where, and I think this is

230

Andrea Magnorsky: a great way

to visualize this as a Yeah.

231

Like if you, so if you're

trying to do the centralization.

232

Like the first step is

understanding maybe where you

233

are, like where you are standing.

234

And also for that you need to understand

how does your team actually functions.

235

So perhaps looking at this and

seeing where are we within your

236

team is a good place to start.

237

Kenny (Baas) Schwegler: Yeah.

238

And that can give you already hints.

239

So I use this as a sense

making and go to with a team.

240

So where are you?

241

And that gives me a hint of where are

the blockers to flow in your team?

242

Especially on an architecture level,

I see a lot of teams on the left side,

243

and this is what John also says, the

left side, the opportunity selection,

244

requirements planning and design is

learning, and if a team is not part of

245

that, they will never be able to do the

full aspects of architecture because

246

they're removed from the learning part.

247

In order to build proper software,

you need to understand the

248

problem and the opportunities.

249

And usually architects sitting at

the left side and teams come from the

250

right side and team don't know that.

251

So there's a lot of blockers.

252

But if you then come in as an architect

and help the team, either as a hands-on

253

architect, like for like a few minutes,

or as an ivory tower architect, there's

254

no opportunity for the team to learn

actually, because you just come in.

255

You solve their problem and you just

give them the design, or they might

256

be part of the design, but they

were never part of the requirements

257

planning of the opportunity selection.

258

So you deny them to be able to learn

the craft of architecture themself.

259

Because in order to do proper

architecture, you need to

260

understand the opportunities and the

requirements and everything that's

261

happening at the learning phase.

262

So that's what also what's happening

from an Iry tower or a hands-on

263

architects, the status quo.

264

Keeps it alive, right?

265

You can never, you never allow the team

to go down because you are doing it.

266

So, and that,

267

Andrea Magnorsky: yeah.

268

And even if you want them to include

the team and saying, Hey, give some

269

feedback, depending on the organization

also, you, there is kind like how

270

actual how actually are the team to

give feedback and if they can just.

271

Inquire on, oh, I discovered

that this is the problem.

272

Here is some long document, and they read

it and make, you know, is that sufficient?

273

I mean, definitely better than nothing

but this is where it, the nuance on how

274

do we do the opportunity selection and the

requirements gathering and all of that.

275

Like how do you do that?

276

And how you can involve the team.

277

Because one thing that I can hear is like

complaints and it's like, oh, we can't

278

have teams doing all of this all the time.

279

And I don't think that's

what we're saying.

280

It's more about like someone will do some

bits that are more time consuming, but

281

the teams should be involved in a more

interactive, it's like, here is some

282

stuff I learned and you know, it's like,

here is some stuff I learned in a more.

283

They can inquire, they

can kind of try to poke.

284

It's oh, did you consider this?

285

What about this integration

with third party?

286

That is a nightmare to deal with.

287

It's oh, we never thought about that.

288

Like the, this thing of bringing

people co-creating the problem space.

289

Yeah.

290

That's a another point.

291

Kenny (Baas) Schwegler: Yeah.

292

So for me it's always about

and I had a conversation with

293

Trump about this a lot, right?

294

It's about accessibility, but also about.

295

If you talk about decisions,

it's about being able to consent.

296

It's about consent.

297

So what I usually do is, oh, yes, I

ask the team, I'm gonna work on this.

298

Who wants to join?

299

How do you want to work on this?

300

And I give them access.

301

And I think that's important.

302

And then some people were

like, no, not for me.

303

I have this big thing coming up.

304

But it's about the opportunity

that you can be involved.

305

So product teams doesn't mean

everyone does product opportunity

306

selection and requirements planning.

307

It's just everyone has

access to be able to do it.

308

And there at least are a few

people that can do it in the team.

309

I think that's you hit it very t

so yeah what happens there is what?

310

Andrew describes, right?

311

It's the Fifth revolution, which

is constantly designed our dev

312

orgs for flow and ownership, right?

313

And that requires a different way

of making architectural decisions.

314

So we're designing our organization

to enable that swift and continuous

315

delivery of customer value because,

you know, product thinking was

316

good and DevOps need was needed.

317

Agile manifesto was needed, but now we're

going to that more stream aligned teams.

318

What or.

319

What's been talked about in team topology,

and that's really about how can we

320

make sure teams can design themselves

because there's a great, there's a

321

great assumption, mis assumption about

team topology that managers should

322

do this or organization managers

should do this, but it actually, the

323

goal is to have teams do that and

try to design themselves for flow.

324

Andrea Magnorsky: Yeah.

325

Yeah, totally.

326

Something else.

327

It might be that someone is watching this

and going like, oh, so this means that if

328

I don't have all of these preconditions,

I probably can't do anything about it.

329

And I want to make sure that, to, to

tell you listener that is not correct,

330

as in you can make change towards

being more decentralized if you don't

331

like your no organization is Well.

332

It's the same really

than other organizations.

333

Very few organizations are similar,

and some of them will have all of this,

334

maybe some of them have just a couple

of this, and maybe, so for them, some,

335

this is just completely not suitable.

336

However the approach that this

proposes, I think is applicable.

337

Like you can apply some of these ideas.

338

Yeah.

339

And they can be useful even if you don't.

340

Kenny (Baas) Schwegler: And I think

that's why we want to do this, right?

341

To have these conversation to

say, well, this is my situation.

342

So as an example, I've, if we go back to

this slide, I had a team that, that was

343

in design as a team member, which is yeah,

we're not so much part of the design.

344

That's the product owner and that

person is handing it over to us.

345

But how can we do actually, and this

was about domain-driven design, which

346

domain-driven design you want to do?

347

Learning, learning, learning, right?

348

So I was doing example mapping

with them and they were like, yeah

349

but product owner isn't available

for this, doesn't want to join us.

350

So how can we actually start?

351

Well, I say, well, it's very simple.

352

You can still do example

mapping for yourself.

353

The product owner gives you the Jira

ticket with the requirements, right?

354

Yeah, yeah, yeah, yeah.

355

And that's horrible in a way, right?

356

That's not what Jira tickets are meant

for, but sure you'll get your requirements

357

and design in your Jira ticket.

358

So they say, yeah, yeah.

359

Okay.

360

So what I set then let's do

example mapping ourselves.

361

And what happens then is that you're

having a good acceptance criteria pop

362

up there and also a lot of questions.

363

And from there you can actually.

364

Make assumption of what you're gonna

do and that's, you're just gonna

365

push that back in the Jira ticket.

366

You're saying, okay, for next

sprint, we're gonna do it like this.

367

These are our assumptions, these were

our questions that we still have.

368

If you can answer them and work

with them before the next sprint

369

else, we're gonna do it this way.

370

So you're taking control of that

boundary and push that boundary.

371

Because at some point when you do this

a lot, the product owners will start to.

372

See Like but why do I

get so many questions?

373

It was obvious, right?

374

You just need to do this.

375

But then the team shows the example

map and shows the many questions.

376

Then they're like, oh, but

maybe we should do this earlier.

377

So I like to bring the pain forward,

as they say, in continuous delivery.

378

So you can, what you're saying,

Andrea, you can do a lot without

379

being in that fifth revolution, right?

380

Andrea Magnorsky: Mm-hmm.

381

Yes.

382

Absolutely

383

Kenny (Baas) Schwegler: so architecting

for flow, and you have Suzanne

384

Kai's book, she calls it architect

and by Flow, and she has this great

385

steps of how, where do we start?

386

And the first step, start assessing

the current flow of change.

387

Right?

388

That's what you can do as well already.

389

Now start assessing the blocks to flow.

390

I use event storming for that.

391

Paul Reiner created team

flow event storming well.

392

Events from Alberto and he did

it for team flow, great material.

393

And you just go in with the team and start

assessing, okay, what are the steps that

394

we take in our current flow of delivery?

395

Where are our blockers?

396

Where are enablers?

397

And then that's what you can already start

doing now and see where is the biggest

398

pain point and take it step by step.

399

Andrea Magnorsky: Yeah.

400

Also if you maybe are not practitioner

and you know, I met a lot of people that

401

are aware of event storming and also

kind of scared by actually practicing it.

402

It can be one of those practices that

because you are asking a bunch of people

403

to come together, feel really expensive.

404

And if you're not a practitioner,

then it's like this ever fulfilling

405

thing of like, well, I don't know how

to do it, so maybe I'll do it wrong.

406

And then it's, you know, it's got, so

there are other options, like for example

407

for me and sometimes I just literally

at people around, they go like, how

408

do we actually get something done?

409

And then you start talking about

it and just kind of trying to

410

provide alternatives on it.

411

Doesn't need to be.

412

Only this way, it's just that

we're used to these practices

413

and we find them very easy.

414

But also I understand why you might not.

415

Kenny (Baas) Schwegler: Yeah.

416

Alright.

417

I think that would be a, I just added

the material, the architecting for

418

flow and the team event storming.

419

So think that's a great book.

420

Yeah.

421

Yeah.

422

It's a great I still need to read it,

but I've seen a lot of her content.

423

Andrea Magnorsky: I've seen her

talk like a couple of times.

424

I grabbed, when you're like,

let's just open the book in

425

somewhere and see what Yeah.

426

And you're like, oh my

gosh, I really need to read.

427

But, there's so many books to

read and so many hours in the day.

428

Kenny (Baas) Schwegler: Yeah.

429

So I think this is the first

430

version of our stories for facilitating

software architecture as a first setup.

431

And one story we already gave.

432

We can start with the blockers to

flow or you can do stuff already,

433

but I think in the next talk or story

for architectural flow, we'll dive

434

into more of these contextual thing.

435

What can you actually start doing now?

436

I read.

437

I read, but how do I start in my context?

438

And maybe maybe we can invite, I noted.

439

Andrea Magnorsky: Yeah, I can add one.

440

I think we will be great if for

the next one we do have Andrew

441

here and we can start talking

about transparency by using adr.

442

And I have an example that I can

talk about and I'm sure a lot of

443

people, and it's so easy to see.

444

Like you, you start process

and you support the process

445

of actually writing adr.

446

And instead of just going, not

mating it, not saying write

447

ideas, that just doesn't work.

448

Saying we're gonna do it.

449

And this is what you explain

that you the need, you say, we

450

expect this to be the thing.

451

And it's a test like we're calling for

two months and actually do it like,

452

like a with observability type runs.

453

And then people want to keep doing it.

454

And then you start the on standard.

455

We dunno how to do, ah, that's a decision.

456

And people start seeing it and you

start seeing this nice signal itself.

457

Now we started getting transparency.

458

And this is a really rigid, like

this isn't a very rigid sport.

459

Imagine what would

happen in a product team.

460

Kenny (Baas) Schwegler: Yeah.

461

Yeah.

462

I think that's a good

story for the next time.

463

Going to what does

transparency actually do?

464

Thanks.

465

This was the first session.

466

Hopefully we can get more

stories facilitating stories

467

for software architecture.

468

See you next time.