In the military, jump school is used to prepare soldiers for landing in enemy-occupied
terrain. Without adequate intelligence, paratrooping soldiers can find themselves in the
middle of a village dung heap, a minefield, or a camouflaged enemy camp. Similarly in
software, when the architect joins an organization or project team without adequate
intelligence information, there is no telling what they are getting into. An architect can be
doomed from the start due to existing organizational or interpersonal problems among
team members. Conversely, you may discover a team that is already well organized,
where you have the luxury of devoting the majority of your time to technical rather than
process and team-building activities. This chapter is not about intelligence gathering;
rather, it is about making the best of whatever situation you encounter when assigned as
the architect of a software development team. The information on software process and
team building will provide the tools for building an environment where the architect can
successfully transfer architectural principles throughout a team and ensure that they are
realized in the software development process.
Process
A good software process will detail the steps necessary to repeatedly produce a software product which satisfies a set of requirements or a design objective. Unfortunately, many emerging architects lack the luxury of an existing, proven software process. In such cases, it is the responsibility of the software architect to work with the project manager in defining and executing the software processes necessary for success.
Upper Management to Software Architect: "Hey, these UML diagrams look different than the ones three months ago. Why do you keep changing your architecture?"
If you are doing your job as an architect well, eventually one or more of the stakeholders will confront you with the above statement. Keep calm; don't panic.
There are a few common misconceptions you need to quickly dispel in order to resolve this situation. First, there is an industry confusion about the difference
between software design and architecture. In order 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. 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, it is the presence of a good software architecture which 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 which allow the new requirements to be
introduced in the course of actual implementation or address how a particular
subsystem was designed, rather than architected."
Team Work
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.
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 bigpicture 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.
Quality
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 corporations, 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.