architectural drivers
There's a book I usually skim when starting a new project called Designing Software Architectures: A Practical Approach (a mouthful, I know). In that book, the authors explain the role of the architect, the design process, and many other concepts, but one I find particularly interesting is "architectural drivers".
When giving birth to a project, one might gravitate towards spending a lot of time defining functional requirements or even quality attributes. But most people forget about the REAL REASONS why things are the way they are: the business goals, the constraints, the design purpose behind every decision. For example, a customer might have free Azure credits, so they want to use that as their main infrastructure service. That's a good driver right there: the money, specifically, they spend less by using Azure.
As engineers, we need to understand, communicate with, and negotiate with our stakeholders about these drivers. They define the rails on which the project's train will run as a path to its final destination. And they give us a compass to bring things back on track when decisions start drifting away from those original motivations. For example, if someone is saving on infrastructure costs, that same instinct will probably surface in other areas of the project.
Understanding the driver behind the constraint helps us anticipate that and guide the project accordingly.
Link to the book:
Follow