6.3. Teamwork
One frustrating aspect of becoming a system architect is realizing that you probably could not build a large software system entirely by yourself in a reasonable time frame. And even if you could, you probably could never convince an organization that allowing you to do so is in its best interest. Therefore, it is nearly inevitable that you will have to 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 which 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 which comprise the model and the relationships between them. For example, a banking system would define the types of accounts supported, the relationships between the accounts, the business rules governing account ownership, and how funds may be transferred between accounts.
The business processes which 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 which 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, etc. 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. Knowing your role on a development team is essential, both for maintaining personal focus, for team confidence, and for demanding essential concessions (time, tools, expertise) from other stakeholders who may possess different agendas, for example, marketing departments, human resources, etc.
Unfortunately, the word quality has become greatly abused throughout corporate America, and 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 rework of existing code. This 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 which accomplish identical functionality, the minimal design which leads to the simplest implementation is preferable. This does not mean the simplest design is always preferable, as frequently a small design means the problem has been overabstracted and a large amount 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, there are a few other roles which 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 who evaluate progress against their predetermined goals. As new information arrives which affects the schedule, 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 is given the opportunity to assemble a new development team from scratch. When this occurs, recognize and appreciate what a rare opportunity you possess and resolve to make the most of it. Although team formation is usually a management function, the architect often plays an influential role. Obtain a big-picture view of what the project entails and identify the processes and skill sets required to be successful. Don't allow the team to 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 5 people, create subteams, with the understanding that the subteam structure exists primarily to make communication manageable. Enforce this by ensuring that team leader selection is based on their ability to effectively communicate with team members and the architect, rather than on purely technical skills or experience.
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 was sufficient. However, with the radical decrease in development cycle times, many companies hire people having 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.
Once 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 is the intended quality level of the software. This must be decided carefully, as it is difficult and expensive to change either of these after the project kickoff. Often, some architectural planning is useful, before team formation, in order 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 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, circulate articles about its effectiveness and how other people coped with its disadvantages. If developing a product, provide information about comparable products or off-the-shelf solutions which may help shorten development time. If you hear that someone is struggling with a particular design, stop by for a chat and lend him Arthur Riel's design heuristics book, for example [Riel 96]. 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 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 a lot of possibilities. If the process is successful, decisions will be made which constrain the possibilities, and as parts of the system begin to get implemented, real-world problems are encountered affecting schedule, performance, and resource constraints. It is typical to see interest in any effort decrease once it 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 due to 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 feel 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 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 which would not otherwise be apparent. Furthermore, the architect is setting an example of the kind of cross fertilization high-performance teams demand. When possible, have 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. 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. As an architect, frequently one or more of these tasks are either already on your desk or well on their way to your desk. It is vitally important that critical dependencies are recognized and that steps are taken to minimize the external factors which 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.