7.3 Teamwork

One frustrating aspect of becoming a system architect is realizing that one individual probably could not build a large software system alone in a reasonable time frame. And even if it could be done, the software architect probably could never convince an organization that allowing him/her to do so would be in the best interests of the organization. Therefore, architects inevitably must interact with a team of individuals in order to design and develop software.

It is difficult to create a well-designed system without an understanding of the domain model that the system supports. The key elements of a well-described domain model follow.

Domain Model Requirements A discussion of the domain business problem the domain model supports and the context in which it provides meaningful solutions. The domain business problem should not refer to software constructs but to the objectives of the business and various users of the system. For example, in banking, a business problem would state that a customer uses a bank to save money, write checks against funds in the accounts, borrow funds at an agreed-upon interest rate, and transfer funds between accounts. A discussion of the domain business objects that comprise the model and the relationships between them. For example, a banking system would define the types of accounts supported, the relationships among the accounts, the business rules governing account ownership, and how funds may be transferred between accounts. The business processes that the system either automates or facilitates. The business process definitions must include the purpose of the process, the specific inputs and outputs of the business process, and any records or side effects produced. For example, it may not be possible for the system to perform a higher level task such as analysis. However, it may facilitate analysis by executing algorithms, which are a single step in the analysis, and presenting the intermediate results to the analyst. Defining the concrete steps and decision points by which an analyst performs the business function of analysis allows a design to accommodate automation without depriving the user of the control and configuration needed to achieve the desired results. A discussion of the various roles that the system supports and how the roles are acquired and released in various scenarios. Each role should be clearly defined with a concrete and limited set of responsibilities. For example, a bank may define the roles of teller, office manager, loan officer, and customer. Even if the customer may want the appearance of creating a new account, the domain model may require the system to play the role of a teller or office manager in order to complete the transaction rather than have the customer assume a new role. A discussion of the various ways information is organized in a domain. For example, in banking there may be an employee organization starting with the board of trustees and bank president and ending with the security guards. Another organization may be the staffing arrangement on a typical day with M number of tellers, N number of guards, X number of account managers, and so on. Yet another way to classify the organization may be with respect to signature authority. Having information about the various classification schemes used in the domain provides a basis for later abstractions. Frequently, the abstractions are frozen prematurely, and the precise domain classifications, which justify the design abstractions and modularization of functionality, are lost.

An important role of software architects on a team is to ensure that the highest quality software can be delivered within a certain set of constraints. Even in the face of intense time constraints, the role of an architect includes an awareness that compromising too much on software quality will eventually extend the time to delivery rather than shorten it. It is essential that software architects know what the development team expects of them in order to maintain personal focus, establish team confidence, and demand essential concessions (time, tools, and expertise) from other stakeholders who may possess different agendas (e.g., marketing departments and human resources).

Unfortunately, the word quality has become greatly abused throughout corporate America, especially in the software development industry. For an emerging architect, leading a team in developing software, quality involves adhering to basic principles. A key principle is to avoid reworking existing code. This standard is most effective when a second principle is followed: strive to reduce the amount of code required overall to accomplish the system objectives. For any two designs that accomplish identical functionality, the design that leads to the simplest implementation is preferable. This benchmark does not mean that the simplest design is always preferable because frequently a small design means the problem has been overabstracted and a large number of significant implementation details are undocumented. Obtaining a feel for the complexity of the implementation is crucial to really understanding the true simplicity of a proposed solution.

Just as the software architect has a well-defined role on a development team, a few other roles must be satisfied by individuals other than the software architect. A project manager is necessary to fulfill the vital and time-consuming tasks of tracking the progress of the development effort and providing updates, both to the higher level stakeholders and to the development team so that they can evaluate progress against their predetermined goals. As new information that affects the schedule arrives, the project manager solicits information for replanning and updates the involved parties. Additionally, there will be team members who will be responsible for executing one or more individual software processes. For example, there may be a build manager who ensures that configuration management is actively used and that the software can be built regularly. Someone else may be responsible for code versions or bringing new team members up to speed and arranging mentors. A requirements analyst may be tasked with ensuring that design and implementation tasks and deliverables are traceable back to stated or derived requirements.

Under some rare circumstances, an architect may be given the opportunity to assemble a new development team from scratch. When this occurs, the fortunate software architect should recognize and appreciate what a rare opportunity he or she possesses and resolve to make the most of it. Although team formation is usually a management function, the architect often plays an influential role. The architect should obtain a big-picture view of what the project entails and identify the processes and skill sets required to be successful. The team must not become too unbalanced in a specific skill. For example, most software applications require fairly sophisticated interactive user interfaces, which may be difficult to achieve with a team of relational database experts. A good mix is desired not only for their ability to perform their specialty but more importantly to provide a unique viewpoint and to educate fellow team members about the benefits and limitations of their technical areas. In choosing the size for a team, keep it small. If the work requires a team of more than five people, it is reasonable to create subteams, with the understanding that the subteam structure exists primarily to make communication manageable. This structure can be enforced by ensuring that team leaders are selected on their ability to communicate effectively with team members and the architect, rather than purely on their technical skills or experience. Furthermore, the team leaders must be aware of the communication criteria to ensure that technical experts are not inadvertently slighted or feel that their technical abilities are not properly recognized.

Even in the case where the architect is assigned to a team, the same guidelines on team balance and team size apply. It does not matter how many people a team has if the right mix of skills and experience is not already present on the team. In the past, training and time allocated to get team members up to speed on a particular skill set were sufficient. However, with the radical decrease in development cycle times, many companies hire people who have the skills demanded by a particular project, either as new employees or consultants, rather than train existing staff. In such cases, failure to utilize the new employee or consultant as a mentor to existing employees with different skill sets is a common mistake.

As soon as the membership of a team is established and the development process begins, the architect must immediately decide and communicate how design and implementation tradeoffs will be made and what the intended quality level of the software is. This decision must be made carefully because it is difficult and expensive to change either of these after the project kickoff. Often, some architectural planning is useful, before team formation, to guide these decisions. If performance is a top priority, then the architect should make it clear that all design and code are expected to maximize performance over space, maintenance, and robustness. In effect, the architect should define the design force priorities for the team. Concepts such as design by contract and caching should be reviewed, and their existence should be validated in design and code reviews as well as reflected in the test plans. If quality is a high priority, then more time needs to be allocated to review and test processes. These tradeoffs must be documented explicitly for the team. Ideally the guidance would be broken down into specific design and implementation heuristics for individual developers to follow.

Starting from the project kickoff, the architect should maintain a continuous flow of information to team members. If design by contract is used, the architect should circulate articles about its effectiveness and how other people coped with its disadvantages. If developing a product, information about comparable products or off-the-shelf solutions that may help shorten development time should be provided. If the architect hears that someone is struggling with a particular design, he or she should stop by for a chat and offer to let the developer read Arthur Riel's design heuristics book, for example [Riel 1996]. The architect cannot be effective by walking around and talking all the time (i.e., hallway management) or by hiding in an office and waiting to be called upon. Rather, his or her role is to provide technical guidance, receive technical feedback (including project deliverables), and ensure that all team members have whatever information they need to be successful, from both internal and external information sources.

A key part of the architect's role is to maintain a continuous interest in all parts of the project. Early in a software project, everyone's interest is high, as there are many possibilities. If the process is successful, decisions will be made that constrain the possibilities, and as parts of the system begin to get implemented, real-world problems will be encountered that affect schedule, performance, and resource constraints. It is typical to see interest in any effort decrease after the project is actually under way. However, in the early stages, the architect is identified as the key person who understands and decides technical matters. At a high level, the actions of the architect and fellow team members are seen as potentially affecting all aspects of the system. As the system is further decomposed, some problems become more interesting than others to the architect, either because of their complexity or because they coincide with the technical areas of personal interest. If the architect constantly spends time on the areas of most personal interest, team members will feel their own areas are viewed as less important. If these feelings persist, team members in a particular subarea will tend to psychologically distance themselves from the team as a whole. They will begin to believe that the architect and other team members do not respect their work and will tend to focus solely on their tasks, independent of the concerns of the system as a whole. The architect can prevent this misunderstanding by making a constant effort to allocate time to all areas and to ask questions and probe into the technical challenges in all aspects of the system. In addition to maintaining the morale of all the subteams, frequently the knowledge gained provides a better holistic view of the system and opportunities for synergy that would not otherwise be apparent. Furthermore, the architect is setting an example of the kind of cross-fertilization high-performance teams demand. When possible, the architect should call regular meetings where all team leaders are allowed to voice concerns and get feedback on looming technical challenges. Ensure that everyone fully understands how each subgroup contributes to the overall project objectives. The software architect should be prepared to ask specific questions to draw out crucial status information, if subteam leaders are reluctant or decline to provide sufficiently detailed information.

In most projects, there are a few critical dependencies whose prompt completion is essential for other tasks to proceed. For example, data access APIs must be defined prior to deciding on the data structures used to implement business objects. Frequently one or more of these tasks are either already on the architect's desk or well on its way there. It is vitally important that critical dependencies are recognized and that steps are taken to minimize the external factors that hinder their completion. Frequently, such tasks include senior developers who are also solicited to mentor other less-experienced developers. Working with the project manager, the architect must intervene to protect people working on critical tasks by temporarily suspending or reassigning routine responsibilities and to ensure that enough quality time is spent bringing critical tasks to completion. Few things are as detrimental to a schedule as having several teams unable to proceed because they need the results of a team that is behind schedule, especially when the slippage occurs from doing important work, but not work as important as removing the dependency.

Most software development teams work best with a flexible work environment. Most professionals in the industry are honest enough that, given a chance to arrive later at work by an hour or two when no morning meetings are scheduled, they will diligently work the same amount of time or more later to compensate. However, this is not always the case, and major team morale problems arise when benefits such as flexible work hours are abused. No leader, architect, or manager should tolerate repeated and blatant abuse of flexible work policies. If someone claims to work excessive time in the evenings, then it is reasonable to expect tangible results from the time spent, especially given the lower frequency of interruptions and office distractions. The team members should be judged on their results, and when the results do not measure up to the expectations of the team, either the project manager or the architect is responsible for finding out why and ensuring that a cooperative team environment is maintained.

Explaining Incremental Development to Upper Management Upper Management to Software Architect: "Hey, these UML diagrams look different than the ones three months ago. Why do you keep changing your architecture?" All software architects who do their job well are eventually confronted by one or more of the stakeholders with the preceding statement. They should keep calm and not panic. They simply need to quickly dispel a few common misconceptions in order to resolve this situation. First, there is an industry confusion about the difference between software design and architecture. To clarify the distinction in the minds of people having various, and frequently less-intensive, technical backgrounds, the following real-world analogy is recommended: "Say, do you know what Gothic architecture is? You know, with the medieval cathedrals and intricate designs and all. What about Ionic architecture, like the Romans used to build the Pantheon? You know, buildings with the rows of columns and fancy murals. What about modern architecture, with the rectangular shaped buildings and windowpanes and so on? Well, just because you have a building's architecture, it doesn't mean you have its blueprints. You still have to decide for each and every building how many rooms are needed, what their dimensions are, where the doors are, and a thousand other critical details. "The architecture may tell you that if you need to support a ceiling, you do it according to a particular set of guidelines. For example, the architecture will dictate whether the design should support the ceiling using a column versus an arch versus a slant versus a flat wall. It does not tell you the precise amount of support required or where to put the light switches. A building can be built an infinite number of ways using the same architecture. Similarly, software architecture does not provide a set of design blueprints. Working with a particular software architecture will still require incremental design and development. "As more is known about the problem space and as new functional or derived requirements are discovered, it is okay that designs evolve to handle new classes or problems. However, that does not mean that the architecture is changing. In fact, the presence of a good software architecture allows individual designs to change without causing cascading changes throughout the system. So rather than view the changes in individual designs as a weakness in the architecture, we either fix the processes that allow the new requirements to be introduced in the course of actual implementation or address how a particular subsystem was designed, rather than architected."