What Software Architects Do

Software architects are in a unique position on the team. They aren’t project managers, but architects decide when and how software is delivered. They aren’t product managers, but architects make sure the software meets its business goals. They write code, but architects design more than only algorithms and code. Software architects have a distinct set of responsibilities and are seemingly at the center of everything.

Most of us start our software careers focusing purely on technology. Knowing how to program, design efficient algorithms, test that everything works, and deploy software are all essential skills for software architects too. Growing from programmer to software architect requires you to accept some new responsibilities.

Define the Problem from an Engineering Perspective

Software architecture design is a human-centered design discipline. Everyone with a stake in the software can help you understand what is expected of it. Software architects work with product managers, project managers, and other stakeholders to define business goals and requirements for the software to be built.

On many teams, product managers define the features. Features are great, but there is another kind of requirement called a quality attribute that architects care the most about (see ​Reason about Quality Attributes (and Other System Properties)​). In addition to defining quality attributes for the system, architects keep an eye out for design constraints and features that might force the architecture down a specific path.

Defining the problem with the architecture in mind ensures you can build a system everyone wants. You’ll learn how architects approach requirements in Chapter 5, ​Dig for Architecturally Significant Requirements​.

Partition the System and Assign Responsibilities

Have you ever watched little kids play soccer? The only tyke to stay in position is the goalie, who remains glued to their team’s goal while the other children form a glob of kicking feet and chase the ball from one end of the field to the other. It’s adorable. Once the kids grow up a bit, they learn to play set positions. Playing positions is important since it lets the coach create a game strategy, which increases the team’s likelihood of scoring.

Some software systems are designed like a children’s soccer team: one great big clump of software chasing after a release. Software development, similar to soccer games, goes smoother when the software is divided into pieces and each piece is assigned a responsibility, a position to play.

Architects partition (a fancy word for divide into pieces) the software system so they can develop a strategy for achieving quality attributes and other system requirements. For example, you might assign functional responsibilities by designing one component to register users and another to identify pictures of cats. Or you could assign different teams to develop different modules. Or you might split things that read data from things that write data so the software system will be more reliable, available, and scalable.

Partitioning a system is important not just because it lets you develop a strategy for achieving quality attributes. Smaller things are easier to reason about, easier to test, and easier to design. Of course, since you broke the system into pieces, you’ll also have to make sure everything can come back together again.

Keep an Eye on the Bigger Picture

Every software system lives in the context of a bigger world. The world in which software lives includes the users who interact with it, the team who builds it, the hardware it runs on, and even the purpose for developing the software in the first place. Ideally, the architecture lives harmoniously within this broader context.

Thinking about the system as a whole means architects deal with more than just technology. People, processes, business needs, and many other technical and nontechnical factors play a part in the final software system. Even simple design decisions can have far-reaching consequences. Architects must look beyond a small neighborhood of design decisions and think about the system as a whole.

Software design is a constant struggle to find the right balance between the things you want and the reality you must accept. This means you must think about and make trade-offs.

Decide Trade-offs among Quality Attributes

Say high availability is an important quality attribute for your stakeholders and you need your software to respond to 99.9 percent of requests. One way to promote availability is to introduce redundant elements. Designing for this is simple, but there’s a catch. You now must purchase twice the hardware, which doubles your costs. In this case, you traded costs to get higher availability.

It is common in software development to give up something you want to get something you need. Architects identify the trade-offs and work with stakeholders to decide which compromises make the most sense.

Software systems are never partitioned perfectly. You’ll make compromises. You’ll make mistakes. As you build the system, you’ll introduce technical debt into the architecture.

Manage Technical Debt

Software architects know the details about how the system is partitioned. They keep an eye on the big picture and guide how everything comes together. They also connect technology decisions with business needs. Knowing all this puts architects in the perfect position to manage technical debt.

Technical debt is the gap between your software system’s current design and the design you need it to have so you can continue to deliver value. You can measure the amount of technical debt by estimating the effort required to close that gap. All software has technical debt. Technical debt is an inevitable byproduct of success. The best software development teams use technical debt strategically to ship faster and regularly pay debt down so they can continue shipping value over time.

Architects make technical debt visible and help stakeholders decide which actions to take to manage it.

Grow the Team’s Architecture Skills

Software architects are teachers and mentors for their teams. There is no use in designing an awesome architecture that nobody can understand. As the architecture expert on your team, it is your responsibility to share your knowledge with your team so they can successfully develop an amazing software system.

Architects teach design skills and architecture concepts just-in-time. To pass on your knowledge, you’ll pair design with teammates, create documents that educate and inform, and share constructive criticism. Perhaps the most important thing you can do to grow the team’s architecture skills is to include them in the design process. Architecture design is a social activity. Skills development is crucial to your team’s success.

Now you know what architects do, but we haven’t defined what we mean by software architecture yet. Let’s do something about that now.