The Role of the Software Architect

 The Role of the Software Architect

 If you gathered a group of software architects in a room and asked them to describe the jobs they do, you would probably end up with at least a dozen different definitions. More tellingly, if you asked the people with whom the architects work how their colleagues fill their working hours, you would probably get still more definitions. Our own practical experience supports this. On some projects, the person with the title of architect has a very hands-on, directional involvement in the nuts and bolts of designing, coding, and testing. Alternatively, architecture may be viewed as an ivory tower from which pronouncements are handed down at intervals to the build and implementation teams. Architect is also often used as a generic title to denote a senior technical member of staff (such as the Java architect that a number of organizations have). Architects may specialize in one area, such as networking, middleware, or database design, to the exclusion of others; occasionally, the architect may not even have a system development background at all, having entered through another route such as business analysis. The title may also be further qualified in various ways such as application architect, data architect, or even enterprise architect, without being clear what these roles involve. So before we consider how you perform your job as an architect, we need to understand exactly what that job is—what your responsibilities are, where your boundaries are, what areas you should delegate to others, and how you work alongside the other members of the team to ensure a successful software delivery. In this chapter, we establish a definition of the software architect’s role, including what you are and are not expected to do to fulfill this role and what qualities you need to possess in order to be a successful architect. We also explore how this role relates to others involved in the product or system development process. 

The Architecture Definition Process

The last concept in our model of software architecture captures the process used to design an architecture and create an AD for it. We call such a process architecture definition.

This process is often called architectural design, and we say this informally ourselves. However, in the book we tend to avoid this term because of the potential confusion between its usage as a process and as an artifact. The goal of an architecture definition process is to design an architecture that meets the needs of its stakeholders. 

There are a number of aspects to this:

• Capturing stakeholder needs, that is, understanding what is important to stakeholders (possibly helping them reconcile conflicts such as functionality versus cost), and recording and agreeing on these needs 

• Making a series of architectural design decisions that result in a candidate architecture 

• Assessing the candidate architecture to determine how well it meets the stakeholder needs 

• Refining the architecture until it is adequate 

• Capturing the architectural design decisions made and the resulting architectural structures of the system in some form of AD appropriate to the environment in which you are working These activities form the core of the architecture definition process and are normally performed iteratively. We talk more about this in Part II, in particular how stakeholder needs and concerns relate to functional and architectural requirements. For now, we’ll leave you with another principle.

Architecture Definition Isn’t Just Design

 A common question that arises is whether architecture definition is “just” part of design or whether there is something more to it. It’s true that architecture definition incorporates elements of design and also of requirements analysis, but as we shall see in this book, it is a separate activity from each of these.

 • Design is an activity focused on the solution space and targeted primarily at one group of people —the developers. It works within a clearly defined set of constraints (the system’s requirements) and is essentially a process of translating these into the specifications for a conformant system. Historically, design has tended not to focus as much on the needs of other groups such as operations or support, assuming that their needs have been captured in the requirements specifications (or often ignoring them altogether).

 • Requirements analysis, on the other hand, is an activity focused on the problem space that (in its purest forms) ignores the needs and constraints of groups like developers and systems administrators because it defines what is desired rather than what is possible. It also works within a clearly defined set of constraints (the system’s required scope), although within these constraints it tends to have much more freedom than the design process does. Architecture definition resolves this tension by bridging the gap between the problem and solution spaces. Its focus is to understand the needs of everyone who has an interest in the architecture, to balance these needs, and to identify an acceptable set of tradeoffs between these where necessary. The tradeoffs take into account the constraints that exist (e.g., technical feasibility, timescales, resources, deployment environment, costs, and so on). 

Although your role as a software architect incorporates elements of design and of requirements capture, there are some key differences between it and the other two roles, the most significant of which revolve around its scope. 

• You have to take input from a much wider range of people than just the user community (as we have seen in our discussion of stakeholders). 

• You have to consider a much wider range of concerns than just functionality (as we have seen in our discussion of views and perspectives). 

• You have to consider the big picture as well as the details. Architecture definition is often more a process of discovery than of just capture. At the early stages when—with luck—you start to be involved, the stakeholders may have only hazy ideas of their expectations of the system. Furthermore, there may be a number of conflicting ideas about how the system should be built, and there are likely to be big gaps in technical knowledge and developer experience in the proposed solution elements. Although theory says that you should not start to think about the solution until you understand the problem—and we like this approach, as a theory—in practice, stakeholders start to think about technology solutions from day one. You can’t avoid this; you just have to manage it

The Boundary between Requirements Analysis and Architecture Definition 

Part of your role as an architect is to be involved in the process of analyzing, understanding, and prioritizing the system’s requirements. This also allows you to start assessing the difficulty involved in implementing each requirement. Strictly speaking, your role does not include requirements gathering, and ideally you will be presented with a complete, consistent, prioritized list of the key goals and requirements for the system. However, such a list often doesn’t exist, and even when it does, requirements analysts often struggle to trade off requirements against each other; while part of this process involves understanding the relative business value of requirements, it must also take into account the associated costs and risks. Some of the requirements specified initially are likely to be difficult to implement because the requirements analysts have little or no insight into the implementation options. As an architect, you are ideally placed to provide this insight so that the importance of each requirement can be considered in the context of the likely cost of providing it

The Boundary between Architecture Definition and Design 

One of the most important decisions you will have to make as an architect is whether something is important enough for you to worry about or whether it can safely and more appropriately be left until the detailed design phase—in other words, whether it is architecturally significant. Philippe Kruchten neatly captured the essence of architectural significance in his definition, which we paraphrase here.