THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the...

8
T 5 THE ROLE OF THE SOFTWARE ARCHITECT I f 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 prob- ably 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 of- ten used as a generic title to denote a senior technical member of staff (such as the Java architect that a number of organizations now 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 soft- ware 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 will also

Transcript of THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the...

Page 1: THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle. PRINCIPLE The architect is responsible for

T

5 THE ROLE OF THE SOFTWARE ARCHITECT

I f 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 prob-ably 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 of-ten used as a generic title to denote a senior technical member of staff (such as the Java architect that a number of organizations now 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 soft-ware 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 will also

Page 2: THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle. PRINCIPLE The architect is responsible for

57 r

56 PART I • ARCHITECTURE FUNDAMENTALS

explore how this role relates to others involved in the product or system de-velopment 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 difinition.

DEFINITION Architecture definition is a process by which stakeholder needs and concerns are captured, an architecture to meet these needs is de-signed, and the architecture is clearly and unambiguously described via an architectural description.

This process is often called architectural design, and we say this infor-mally 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 three aspects to this, as shown in Figure 5-1 .

• Captun'ng stakeholder needs, that is, understanding what is important to stakeholders (possibly helping them reconcile conflicts such as function-ality versus cost) and recording and agreeing on these needs

Capture Stakeholder

Capture Decisions

Made

Make Architectural

Decisions

Needs

FIGURE 5-1 ARCHITECTURE DEFINITION

CHAPTER 5 THE ROLE OF THE SOFTWARE ARCHITECT

• Making a sen'es ifarchitectural design decisions that result in a solution that meets these needs, assessing it against the stakeholder needs, and refining this solution until it is adequate

• Captun'ng the architectural design decisions made, in an AD

These activities form the core of the architecture definition process and are normally performed iteratively, We talk more about this in Part II, in par-ticular how stakeholder needs and concerns relate to functional and architec-tural requirements. For now, we'll leave you with another principle,

[§ PRINCIPLE A good architecture definition process is one that leads to a good architecture, documented by an effective architectural description, which can be realized in a time-efficient and cost-effective manner.

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 pro-cess 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 specification,

• Requirements analysis, on the other hand, is an actiVity focused on the problem space that (in its purest forms) ignores the needs and con-straints of groups like developers and systems administrators because it focuses on 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 it tends to have much more freedom than the de-sign process does.

Architecture definition resolves this tension by bridging the gap between the problem and solution spaces, as shown in Figure 5-2. Its focus is to un-derstand the needs of everyone who has an interest in the architecture, to bal-ance these needs, and to identify an acceptable set of tradeoffs between these where necessary. The tradeoffs take into account the constraints that exist

Page 3: THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle. PRINCIPLE The architect is responsible for

58 r--

PART I ' ARCHITECTURE FUNDAMENTALS

\

Architecture '\ Software SOLUTION) Design SPACESPACE \. Analysis Definition /

FIGU RE 5-2 ARCHITECTURE DEFINITION, REOUIREMENTS ANALYSIS, AND SOFTWARE DESIGN

(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 function-ality (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 rather than 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 sys-tem. 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 knowl-edge and developer experience in the proposed solution elements.

Although theory says that you should not start to think about the solu-tion until you understand the problem-and we like this approach, as a the-ory-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, un-derstanding, and prioritizing the system's requirements. This also allows you to start assessing the difficulty involved in implementing each requirement.

Your role does not include requirements gathering, and ideally you will be presented with a complete, consistent, prioritized list of the requirements for the system. However, requirements analysts often struggle to trade off re-

CHAPTER 5 THE ROLE OF THE SOFTWARE ARCHITECT 59

quirements against each other; while part of this process involves under-standing the relative business value of requirements, it must also take into account the associated costs and risks.

Many of the requirements specified initially are likely to be difficult to im-plement 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.

STRATEGY Work with the requirements analysts to understand the system's requirements and their relative importance. For each important requirement, consider the likely difficulty of implementing it and feed this back to the re-quirements analysts to help them understand what can and cannot be achieved.

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 signj/i'cant. Phillipe Kruchten neatly captured the essence of architectural significance in his definition, which we paraphrase here.

PRINCIPLE A concern, problem, or system element is architecturally signif- icant if it has a wide impact on the structure of the system or on its important quality properties such as performance, scalability, security, reliability, or evolvability.

Of course, whether something is architecturally significant or not is a largely subjective decision driven by your judgment, skill, and expertise (and that of your stakeholders) and by the circumstances of individual projects. For example, where a new technology is involved. questions around reliabil-ity and performance may be very significant, whereas they may be far less so in a system where the technologies are established and well understood by the developers.

Your job as an architect is to get the right balance between maintaining a high-level view and exploring the detail-something that will become easier with practice. Beware. however, of assuming that all architectural concerns are found at the abstract level; often, the devil is in the details. You need to consider aspects of your architecture at all levels. from the strategy to the

Page 4: THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle. PRINCIPLE The architect is responsible for

61

l 60 PART I • ARCHITECTURE FUNDAMENTALS

code. It is also important to keep considering whether your judgment is cor-rect and to make sure that as your AD develops, you continue to review whether your scope is appropriate.

STRATEGY As you are designing the architecture, review the areas you have determined as being architecturally significant or not, and revise these as nec-[jJ essary in the light of your deeper understanding of your stakeholders' con-cerns and of the architecture itself.

THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle.

PRINCIPLE The architect is responsible for designing, documenting, and lead- ing the construction of a system that meets the needs of all its stakeholders.

We see four aspects to this role:

1. To identify and engage the stakeholders 2. To understand and capture the stakeholders' concerns 3. To create and take ownership of the definition of an architecture that ad-

dresses these concerns 4. To take a leading role in the realization of the architecture into a physical

product or system

A common theme in most descriptions of what the architect does is some-thing along the lines of "the architect owns the big picture." We certainly support this view. One of your responsibilities as an architect is to develop and maintain a high-level view of the main elements in the product or sys-tem, which is subsequently translated into a detailed design, coded, tested, and deployed.

But this isn't all. You need to ensure that the big picture you develop is right for your situation. As we have seen, every problem has a number of possible architectural solutions, and every architecture has a number of pos-sible representations. You must select an architecture that is fit for purpose and then document that architecture in an appropriate way.

CHAPTER 5 • THE ROLE OF THE SOFTWARE ARCHITECT

end there. In fact, we find in general that the architect's involvement during the software development lifecycle conforms to the pattern illustrated in Fig-ure 5-3.

This figure shows the architect's depth of involvement during each major development iteration of the system's delivery. During the initial phases, your involvement is intense. You are fully occupied in defining and agreeing on scope, agreeing on and validating requirements, and providing the technical leadership to make the decisions that will shape the architecture.

Your involvement typically lessens during the derailed design and code phases, while the product or system is being built, tested, and integrated. In practice, you may take a different role during this period, such as design au-thority or designer. If so, you are likely to be involved in mentoring, reviews, problem resolution, and technical leadership. In any case, if the architecture needs any changes, you must lead the change process.

Your involvement peaks again prior to and during acceptance, as you pro-vide support and guidance to help resolve the last-minute problems that inev-itably occur and to ensure a smooth deployment.

[J STRATEGY Stay involved with the development process beyond the creation of the AD and through construction, acceptance, and handover (possibly at a reduced level of involvement).

1 .. c Q)

E Q) > '0 > ({J

E C Ql

E c ()OJ iil'0 o @.-§.c c Cl 0, Q. Qlc:r 'iii "C ()Q) '" QlOJ OJQ c:: Cl c3 E «()

Traditionally, the architect is viewed as making primarily an up-front contribution to system development-in other words, being heavily involved Time

in the inception stages of the project. However, your responsibility does not FIGURE 5-3 THE ARCHITECT'S INVOLVEMENT

Page 5: THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle. PRINCIPLE The architect is responsible for

r CHAPTER 5 ' THE ROLE OF THE SOFTWARE ARCHITECT 6362 PART I • ARCHITECTURE FUNDAMENTALS

relates Interelement 1..n I Relationship2..n

l..n compnses comprises

1.. n

gUidesArchitecture has antheDefinition System definition 1 n Process I

can be documented by addresses the needs of

•• of

follows designs O..n I .

creates I documents architecture for Stakeholder[_Oed and l I owns Description l..nj \ l..n

has

l..n

captures the concerns of -----------------

comprises

addressesI conforms to Viewpoint

l..n l..nO..n i 1\ 1..n I

l..n addresses

I I

FIGURE 5-4 ARCHITECTURE DEFINITION AND THE ARCHITECT IN CONTEXT

INTERRELATIONSHIPS BETWEEN THE CORE CONCEPTS We can now add two final pieces to our relationship diagram, namely, the process of architecture definition and the architect, as shown in Figure 5-4.

We have added the following relationships to augment the earlier ver-sions of the model shown in previous chapters (e.g., Figure 4-3).

• The architect captures and consolidates the concerns of the stakeholders. • The architect designs an architecture that meets these concerns.

• The architect creates and owns the AD. • An architecture definition process guides the definition of the

architecture. • The architect follows the architecture definition process to carry out all of

these tasks.

ARCHITECTURAL SPECIALIZATIONS So far, we have viewed the architect as a generalist who deals with all aspects of the system under development. This isn't always the case, especially on large projects where a team of architects may be working together. Everything we talk about in this book-stakeholders, views, principles, models-applies equally to such specialists, within their scope.

You are likely to see architects take on some of the following specializations.

• Product architect: The product architect is responsible for the delivery of one or more releases of a software product to external customers (and typically would stay associated with the product over a number of release cycles). The product architect is a key member of a product development team and oversees the technical integrity of the product. One specific challenge faced by the product architect is identifying user stakeholders, especially before the first release.

• Domain architect: Domain architecture is a specialization of the general architectural function, focusing on a particular domain of interest, such as the business architecture, data architecture, network architecture, and so on. Domain architects are particularly valuable for working on large, complex, or groundbreaking systems or for filling gaps in the knowledge of the software architect.

• Solution architect: In contrast with the domain architect, the solution architect specifically takes a broad, high-level view of the entire solution.

• Enterpn'se architect: Really good enterprise architects are among the most sought-after personnel in IT. Where the software architect concerns herself with a single (albeit probably complex and important) system, the enterprise architect has responsibility for the cross-system information systems architecture of the whole enterprise, including sales and market-ing, client-facing systems, products and services, purchasing and ac-counts, the supply chain, human resources, and so forth.

Page 6: THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle. PRINCIPLE The architect is responsible for

r 64 PART I ' ARCHITECTURE FUNDAMENTALS

THE ORGANIZATIONAL CONTEXT Let's look at how your role as a software architecT compares with those of the other key personnel on software development projects.

Business Analysts A business analyst is responsible for capturing and documenting detailed business requirements, typically focusing on stakeholders from the user com-munity, and ensuring that these are correct, complete, and consistent. You will often draw on the specialized knowledge of the business analyst, espe-cially when dealing with views of interest to acquirers, users, and assessors.

Project Managers A project manager is responsible for ensuring delivery of the product or system and meeting commercial priorities for resources, costs, and timescales. You will often help the project manager develop plans or assess them for reasonable-ness. You will also provide the project manager with technical information, feedback, advice, risk assessment, and so on throughout the project lifecycle.

Design Authorities A design authority (sometimes referred to as a technical design authority) takes overall responsibility for the quality of the internal element designs for the system. In our experience, the architect often fills this role as the project moves into the design phase. The design authority takes the architectural views as her input and acts as guide and leader to the software developers who design, build, test, and integrate the product or system.

We have found that design authority is often the role actually performed by people who have the job title of technical architect. These key people are often the primary technical points of contact for how the system is imple-mented and how the underlying technology platform works. This role on the project is crucial and must be filled by an extremely strong staff member. However, making tradeoffs between requirements and possibilities for the system's stakeholders is not an inherent part of being a technical design au-thority, although it is a key part of the architect's role. Therefore we argue that the technical design authority plays a design role rather than an architec-turalone.

The boundary between the design authority and the architect is probably the hardest one to define formally. One guideline we find useful when decid-ing whether an issue is architecturally significant is to consider its impact on

CHAPTER 5 THE ROLE OF THE SOFTWARE ARCHITECT 65

stakeholders. If the outcome of a decision is likely to have a significant im-pact on important stakeholders or requires tradeoffs between stakeholder needs, the architect should probably be responsible for the decision. If the decision is visible only within the development team, it is probably a design authority issue.

Of course, it is not always possible to make this assessment up front, and it is essential that the two roles cooperate fully. Let's consider a couple of ex-amples to see how this might work in practice.

EXAMPLE Architecture definition for a new system has identified the need for a relational database, from the industry-leading supplier, for persistent storage of transaction data. The imminent new release of the database server will provide some significant new technology features and potential improvements in performance.

Functionally, the system would look identical whether it were built on the current or new version of the relational database management sys-tem. However, taking on the new version presents some commercial risk related to availability of skills, confidence in the new platform, and the potential problems associated with any point-zero release.

Because of the possible commercial impact, we would tend to involve the architect in this decision.

EXAMPLE In integration tests, some end-user queries have been faIling [i] far short of their performance requirements, taking a minute or more to complete under peak load. Monitoring and analysis have suggested that some database tables need to be internally restructured, indexes modi-fied, and objects spread more evenly across physical disks. Access to data, which occurs via stored procedures, will not be affected (other than being much faster).

Because these changes have no visible stakeholder impact (other than to make the system compliant), it seems reasonable not to involve the architect in what are essentially internal systems decisions and to instead make this the responsibility of the design authority.

Technology Specialists A technology specialist provides detailed expertise in one specific area. Where the architect provides breadth, the technology specialist provides depth, and the combination of the two can be extremely powerful.

Page 7: THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle. PRINCIPLE The architect is responsible for

T 66 PART I • ARCHITECTURE FUNDAMENTALS

Broadly speaking, it is the technology specialist's responsibility to provide detailed facts, to assess the architecture for technical feasibility, and to spot pit-falls early. You should be able to take the information provided by the technology specialist and apply it to addressing the problems you need to solve.

You should always make the best use of the skills and knowledge of your colleagues in the organization. It's not possible to know everything about ev-erything, and as an architect you aren't expected to.

PRINCIPLE The architect provides and oversees the architectural breadth and works closely with both business-focused and technology-focused specialists who provide the specialist depth.

Developers The architect's involvement doesn't end with handing over the completed and accepted AD. Although your level of participation may decrease during the build and test phases, you will still maintain a technology leadership role to ensure that the team adheres to the spirit and the letter of the AD.

This may involve mentoring staff through the detailed design process, re-viewing designs as they are completed to ensure conformance to the system's architectural principles, arbitrating technology disputes, or even developing pieces of the implementation if required. You are likely to get involved in inte-gration and system testing to ensure that the tests exercise an appropriate se-lection of functional and operational characteristics.

You will also need to lead the change process if (as is likely) the AD re-quires any modifications during the development.

THE ARCHITECT'S SKILLS Although the job of the architect traditionally has a technology focus, and in nearly all cases the architect herself has a strong technology background, we have seen that the role is much broader than merely drawing up technical plans and designs.

You must have an across-the-board understanding of technology at a high level and of the real-world issues and problems the system is required to solve. You should have real experience with designing and building systems, although it may not always be possible to have direct, practical knowledge of the specific technologies you plan to use. (This is an example of when you must draw on the experience of technology specialists.)

Typically you will also have one or more areas of deeper technical exper-tise; this may not apply to your current project but will give you the ability to recognize a good design when you see one.

CHAPTER 5 • THE ROLE OF THE SOFTWARE ARCHITECT 67

People skills are also very important, such as the ability to build consen-sus, facilitate change, and rapidly learn about unfamiliar business areas and technologies. Above all, you must earn and maintain the confidence of all of your stakeholders, from senior management and users to developers, third parties, and operational staff.

THE ARCHITECT'S RESPONSIBILITIES A proJorma list of responsibilities for an architect would include the follOWing items.

• Ensure that the scope, context, and constraints are documented and accepted.

• Identify, engage, and enfranchise your stakeholders. • Facilitate the making of system-level decisions, ensuring that they are

made on the basis of the best information and are aligned with stake-holder needs.

• Capture and interpret input from technical and domain specialists (and represent this accurately to stakeholders as needed).

• Define and document the system structure and form. • Define and document strategies, standards, and guidelines to direct the

build and deployment of the system. • Ensure that the architecture meets the system quality attributes. • Develop and own the AD (Le., manage all changes to it). • Help ensure that agreed-upon architectural principles and standards are

applied to the finished system or product. • Provide technical leadership.

SUMMARY We have discussed two distinct concepts in this chapter, the final chapter of Part 1.

• Architecture df!finition is a process whereby stakeholder needs and con-cerns are captured, an architecture to meet these needs is designed, and the architecture is fully and unambiguously described via an AD.

• The architect is the person (or group) responsible for designing, docu-menting, and leading the construction of an architecture that meets the needs of all its stakeholders.

Page 8: THE ROLE OF THE SOFTWARE ARCHITECT · THE ROLE OF THE ARCHITECT We can now define the role of the architect in the following principle. PRINCIPLE The architect is responsible for

T 68 PART I • ARCHITECTURE FUNDAMENTALS

There is no single commonly accepted definition of the software architect's role. The role of the architect includes elements of requirements capture and high-level design but is more than either of these. In this chapter, we defined the four main responsibilities of the architect: to identify and engage the stake-holders, to understand and capture their concerns, to create and take ownership of the AD, and to take a leading role in the realization of the architecture.

We presented some architectural specializations that you may encounter (or even choose to take on) such as product architects, domain architects, so-lution architects, and enterprise architects. We also compared and contrasted the role of the architect with other key project roles such as business analysts, project managers, design authorities, technology specialists, and developers. We considered when the architect is important: primarily during the early stages of system development and during acceptance, with a lesser role dur-ing the build and test phases.

Finally, we itemized the skills that a good architect should possess and presented the architect's responsibilities.

FURTHER READING Most of the architecture books we mentioned earlier in Part I contain some dis-cussion of the architect's role. In addition, McGovern et al. [MCG004] contains a good discussion of roles related to software and enterprise architecture.

The definition of architecturally significant that we paraphrased earlier in this chapter can be found in Kruchten [KRUCOO].

PART II THE PROCESS OF SOFTWARE ARCHITECTURE