Lesson 225 - Architecture Narrative Act 1 Transcript, AI Summary & Key Points

00:00 Hello everyone and welcome to software architecture Monday. My name is Mark Richards and in this lesson number 225, we'll take a deeper look at act one, the setup as part of developing an architectural narrative for your architecture solution. In the last episode number 224, I gave an overview of developing an architecture narrative to be able to describe your architectural solution in its complete form.

00:29 If you haven't watched that lesson, I would highly recommend pausing this lesson and going and watching that one first. This one will make a lot more sense. All right. Well, in the prior lesson, we talked about creating an architecture narrative and overlaying that with something called the threeact structure. Act one being the setup, act two being confrontation, and act three being the resolution.

00:59 In this lesson, we'll focus and take a deep dive in act one, the setup. When we build an architecture narrative, a story telling about our architectural solution, we start with the introduction and exposition. So I want to talk about what goes into that primarily those aspects of the business problem including the vision uh the purpose and justifications.

01:26 And so uh let's see what um what goes into this. So part of the problem we have when we develop an architectural solution is not providing enough context. Act one, the setup is about the context. In other words, providing stakeholders with a better understanding of the overall picture of what we're building. For example, if we're building a new trouble ticket system for the SISOP squad, this was our famous SISOP squad from or well known.

01:57 It's not really famous but well known from our book software architecture the hard parts where we used it as a exposition. Uh this is essentially a trouble ticket system where customers enter uh trouble tickets and our customerf facing experts go out in the field and fix the problem. In the setup of our architecture solution we can provide very simple contextual diagrams.

02:22 uh if we're doing C4 for example, this would be the first kind of of view that we would show. In other words, here we create tickets, assign experts, notify, complete tickets, and send the surveys. That the system is a lot more complex than this, but this provides a nice overview about what do you mean by a trouble ticket system really. And so, so this is one of the first things that goes into uh this act one.

02:51 But one of the other key pieces to provide a context is addressing the business andor technical justifications because a lot of stakeholders may not see a need for this new system or a need for this particular migration. Listen, if I'm about to present or describe an architectural solution to replace the existing order entry system and half the stakeholders don't see a need to do so, they're likely not going to listen to my architectural solution.

03:29 So, here comes that second law of software architecture where the why is more important than how. Essentially, what we're doing here is describing really the justification. Now, I like to use the Zachman Enterprise framework for this. And that might sound a little surprising because this is a huge framework. And we're talking about act one, the setup.

03:53 I don't use the whole framework. I use one of my favorite pieces from Zachman, which is the Y model. And here across the different perspectives going all the way from the technical perspective all the way up to the executive provides justifications for why we're about to undergo a certain migration or new system. Let me show you an example. So let's start down at the technical perspective.

04:22 We're told move operations to the cloud. Uh that's would be all of the Zachman pieces involved with that. But the why piece is really about the justifications for moving operations to the cloud. So the developers and or the operations ask the developers in the engineering perspective and they say oh because we're developing new cloudnative applications.

04:45 Oh that makes sense. Cloud native belong in the cloud and they're happy. But then the developers aren't because that engineering perspective needs justification as well. Wait a minute. Why are we developing new cloudnative applications? And it's the responsibility of the development teams to ask that question. So they go to the architects and the architects say because we're moving all of our customer-f facing applications to microservices.

05:16 Ah you know this makes sense. There's a good justification for cloudnative applications and why we're developing those. But then the architect perspective also needs a justification. Wait, why are we moving our customer-f facing apps to microservices and they ask the business the business perspective and their justification is because we need to add new products and features quickly.

05:41 Ah well that makes sense because it justifies microervices given the five-star ratings for agility in that. But then the business still wonders why do we need to add new products and features quickly? They need a justification as well. And it goes all the way up to the top of the chain, the executive perspective, which gives the business justification to become the number one online insurance provider in the country.

06:13 And now everyone has the proper perspective. I love the Zachman framework as it moves almost like the architect elevator uh from Gregor Hope where we have justifications for our particular domain or what we're doing but we really don't know the true why question and it's up to every one of us to seek that executive perspective. This is what we can do as architects and provide this in our architecture narrative.

06:47 So every stakeholder regardless of their level knows the business justifications of why we're doing what we're doing and it gives people a renewed perspective and also a renewed motivation. There are so many other kinds of reasons the business has for undergoing some sort of effort. For example, maybe it's just to compete in a very tough market which we need better time to market, need more agile systems.

07:19 This is what we try to seek out to provide that context of the why question. The next thing that we do is who are the characters in the story? Don't forget this is the introduction and exposition. Who are the major players? Um there's two kinds. There's kinds in the system. For example, in our sysop squad, um the players or actors are the customer and the sysops expert.

07:44 Those are characters in our story. But the characters transcend these when we talk about developing and maintaining that system. For example, who are the development teams and how many development teams will we need? Who are the project sponsors or even the business stakeholders? um those that own or have concerns about the system itself. Um who's the product owner?

08:09 Um do we have any sort of internal users? Um who's going to support the system? And who are we going to collaborate with during the development and maintenance of the system? And um do we have to be involved with an architecture review board? Who are they? When do they meet? The these are the kind of things that we add to act one to define the characters in our story, the introduction and exposition of our architecture narrative.

08:40 If you'd like to see some great examples of act one, the setup given different contexts, you can go to the kata log. Um my friend Jackie Reid who wrote the communication patterns book took it upon herself to actually create a GitHub repo um providing or logging every one of the finalists and their architectural solutions. Um this was during the O'Reilly architecture katas that we've done for many many years and there's a great corpus of information here that you can look at from all the finalists in terms of act one

09:17 creating that architecture narrative. So this has been lesson 225 creating an architecture narrative specifically act one the setup. This is the introduction and exposition to launch our architectural solution. Next month we'll take a look at act two which is the confrontation the complications that occur in forming an architectural solution. This is a good one. So stay tuned next month for that particular episode. And in the meantime, thank you so much for listening.