You learned in Build Amazing Software how software architecture improves our ability to ship awesome software. The architecture, not the architect, provides these benefits. It’s the architect’s job to guide the team to design an architecture so we can get these benefits. In What Software Architects Do you learned how software architects go about this task, and we’ve expanded on these ideas throughout the book.
Let’s revisit the architect’s key responsibilities from the perspective of our new knowledge:
Architects are responsible for defining the architecturally significant requirements, especially quality attributes. We prefer to use human-centered design methods to gather these requirements so we don’t lose touch with stakeholders’ true needs.
Architects guide the team to identify patterns that will promote desired quality attributes. We prefer to minimally design the architecture to ensure key quality attributes are achieved, leaving all other decisions to downstream designers.
Architects monitor the design as it emerges and shepherd the team as they implement the architecture. We strive to capture design decisions as accurate models using the lightest-weight documentation methods that work for the team and stakeholders. We use these models to reason about the system, evaluate our decisions, and identify risks in our ability to achieve business goals.
Architects help the team reconcile trade-offs as design decisions are made and as the architecture evolves over time. We use risk to determine how much design work is required and where to focus the team’s attention.
Architects deal with the reality of shipping software by identifying technical debt and devising strategies for paying it back. We recognize that technical debt is an unavoidable consequence of success and work to manage debt strategically over the life of the software system.
Architects empower their teams to take ownership of the system by ensuring the team has the knowledge and skills required to understand, explore, make, and evaluate an architecture. We prefer to design the architecture with our team instead of designing the architecture for our team.
For many teams programming is the easy part. Understanding what the problem is and deciding how the broader system comes together to solve that problem can be tough. The better everyone understands the architecture, the more prepared your team will be to tackle the challenges of software development. Designing the system together creates this deeper understanding.
3.143.241.133