Resources

• Slides

Transcript

[00:03] Over the next few videos, we’re going to talk about a few architectural concepts that are really important during this understanding phase and that they are also kind of related to one another. The first one is architectural drivers. These are the ones that we’re talking about in this video. And you can think of these as the influencers of your architecture. These are the various things that will influence your architecture in some capacity. Those architectural drivers will determine your architectural requirements. These are the success criteria of your architecture, All of the things that your architecture needs to do in order to be successful. And then finally, those requirements will drive your architectural decisions. Which we talk about briefly when we talk about the the spectrum between architecture and design. So these are the decisions that fall more into the architectural end of the spectrum. And we’ll talk more about them at the end of this module.

[00:59] Let’s now talk about architectural drivers. As I mentioned earlier, these are the different things that will influence your architecture to some degree. If you remember when we talk about frontend architecture, we saw how the same exact application could be built using two completely different architectures. And the reason those architectures look so different is that they had different drivers, different things influencing their architecture.

[01:25] So here are some of the most common architectural drivers that you may find. The first one is business goals. These are often overlooked because in a lot of cases they seem obvious. But these are the most important because they are the reason why the problem exists in the first place. These are the entire reason why we’re building an architecture to begin with. So these may include the goals of, you know, the CEO or a VP or a director of technology, that they want to increase revenue or reduce cost or improve velocity or reduce tech debt or whatever is the reason they may have to invest in this project. We have to keep those in mind because if we if we don’t meet those those goals, those requirements, then we can’t really say that architecture is successful.

[02:06] Then we have quality attributes. We mentioned this earlier. When we talk about architecture. And these are the things that these are things like performance, agility, scalability, maintainability, reliability, and so on. These are the “ilities” of your system if it ends in “ility”, then it’s is probably one of these. And we also know them as architectural characteristics. These are essentially the same thing. There’s always sort of like a baseline level for quality attributes. For example, you always want to have a base level of security and performance and maintainability and so on. So the point is not to list all of the quality attributes that we care about, but the most important ones, the ones that may influence the architecture, somehow we’ll see an example, an example of how these come into play in the next video when we see the requirements of our application.

[02:59] Another common influencer are constraints. These typically come in two forms. Technical constraints, which can be that you have to use our particular framework or our particular language or business constraints which are typically related to budget. We may have to stay below a given budget or time if you have to meet a deadline. This is probably the most common type of constraint. Then we have a time business constraint. Constraints are non-negotiable, which means that if it’s flexible somehow, then it’s not really a constraint. And they they are helpful in the way that they limit or the scope of a problem. These are decisions that are already made for us. So if we have a constraint about having to use Angular, for example, then we don’t have to go through the effort of figuring out which framework we have to use because that decision is already made for us.

[03:48] Next up, we have functional requirements. These are all of the things that your application can do, all of the features of your application. In the case of FullSnack, functional requirements may include being able to search for food items or browse restaurants or adding items to a shopping cart, checking out the shopping cart, logging in, create an account, and so on. Not all functional requirements are influential. So part of our job is to figure out which of those requirements are architecturally significant. So we’re going to do an exercise about that later in this module.

[04:22] Then we have the team’s experience and knowledge. This is something that will definitely influence the technology decisions that we make or when which patterns we decide to use for to build the architecture. The experience and knowledge of the architect also comes into play here because their breadth of knowledge, as we talk earlier about all of the different things that they know, all of the different tools that they are aware of will also influence how we build the architecture.

[04:49] And finally, we have technology trends, which will also influence your architecture to some degree. This doesn’t mean that you have to always follow the latest technology trends and in fact, you always better off choosing boring technology, boring, stable technology Instead for your structure, for your architecture. But being aware of what is the latest technology trends and being updated. That’s also part of your job as an architect. So evaluating the tradeoffs that come with newer technology with later development will also have a say in your architecture.

[05:19] As I mentioned earlier, all of these architectural drivers will determine our architectural requirements In the next video we will see how those apply to the FullSnack project.