9.2 Architectural Iteration

Architectural iteration relies upon intelligence gathering during a project. Whether, how, and when to change an architecture are some of the most important decisions for a software architect. An architecture is a plan, and it is said that no plan survives first contact with the enemy. The enemies in this case are change and ignorance. Software architects want their decisions to be flexible enough to survive changes. But according to Alistair Cockburn, "We don't know what we don't know" [Cockburn 1998]. Ignorance is the more dangerous enemy. What an architect doesn't know can change his or her architectural assumptions to the breaking point. This intelligence operation is intended to defeat these enemies through the preplanned strategy of architectural iteration.

Architects can be very insulated from the realities of software development. The most active time for any architect is at the start of a project. During this time, the architect is free to envision the system without much concern for downstream constraints. Early in the project, an enticing vision is often preferable, both to impress the funding sources (e.g., with apparent progress) and to attract potential staff to the project.

The software architect should practice restraint at this stage for several reasons. First, on average, software projects are over budget by 184% by the time of delivery [Johnson 1995], and the systems seldom deliver what was expected. Overestimation of what is feasible is one of the most common failings of up-front estimators, among which architects are key participants. Second, it's more important for projects to prove credibility through demonstrated results, rather than paper plans, known in a derogatory sense as "slideware" or "viewgraph engineering" [Brown 1998]. It is important to help projects identify what is feasible for early demonstration and delivery. Rather than to define "the big vision" for what the system could potentially become in an unconstrained-budget environment, it is important to architect for reasonable implementation costs and long life-cycle maintenance.

Software Process Background

The two traditional types of software processes are waterfall and iterative. Waterfall process is a sequence of steps, such as "analyze requirements," "design," "code," and "test," which are of long duration and are scheduled only once during the software project. It is widely accepted that the waterfall process does not work for software development in most organizations.

Waterfall fails because of change and the nature of software development. A waterfall process is unable to effectively respond to changes because changes often require rework in earlier parts of the process. Rework would require violation of process and scheduling constraints. So the project continues ever onward in denial of changes that may cause it to deliver the wrong system. The nature of software development is chaotic. Software projects are products of one or more minds. Communication and miscommunication between people have chaotic effects upon the ability to assess progress and quality. As more unknowns are discovered, responsiveness, rework, and redirection are often required.

The iterative process reuses the waterfall sequence but makes each step much shorter and the whole sequence repetitive. The steps are shortened because the scope of the problem addressed in each step is greatly reduced. The sequence is repeated so that the efforts can be redirected in response to changes and discoveries. Iterative process is sometimes called risk-driven development because in each iteration of analyze-design-code-test there is a feedback assessment (perhaps with user input), and a new plan can be formulated for the next iteration in response to what is learned. Each iteration is an opportunity to rework elements of each process step in accordance with lessons learned.

A key variation of the iterative process model is the iterative-incremental process. Incremental processes focus on specific functions of a system, one at a time, not all system functions at once, as may be the case in waterfall and pure iterative processes. For example, an increment may focus on prototyping selected screens. This would be called an external increment because it is focused on the externally observable behavior of the system. In another example, an increment might focus on building a data access layer, an API for transparent retrieval, and an update of multiple databases. This would be called an internal increment because it is focused on internal functionality that is not directly observable to end-users.

In an iterative-incremental process, particular functions are selected in sequence for incremental development. Each increment becomes an iteration of the process. The goal of the iterative-incremental process is to complete an entire function in an increment so that it will not require rework downstream in the process. In other words, the analysis, design, coding, and testing of that one function must be exhaustive enough to reduce or eliminate the need for later rework.

The iterative-incremental process is a widely accepted approach to software development. Some authorities have called it a "spiral" process because each iteration increases the scope of developed software and builds upon the results of previous iterations. Planning a spiral process is one of the most important functions of project management. The balance and sequence of project iterations are critical to project survival, balancing factors such as progress, risk reduction, and upper management support.

External iterations are critical to demonstrating progress (for management support) and usability risk reduction (i.e., making sure that the correct system is being built). However, external increments usually require throw-away coding because certain internal functions that have not been implemented must be simulated. In contrast, the objective of internal increments is finished code that can be used throughout development and the system life cycle. In general, the most cost-effective way to build a system starts with internal increments. There are often stronger motivations to perform external increments early in the project.

The Role of the Architecture Process

Software architecture helps the project manager in planning increments because the architect breaks up the system into well-thought-out functions (e.g., subsystems and system use cases). The process for software architecture is only one of the tasks in the overall software development process. Much of the software architecture activity takes place early in the project; thus, building software architecture comprises early project iterations.

Spiral processes are intended to be quite flexible when applied. How much depth and how often each step is applied can vary from iteration to iteration. Also the length of iterations can and should vary. Software architecture requires this flexibility to be applied sensibly. Ideally, iterations are longer at the beginning of a project. These initial iterations can be called architectural iterations because the principal deliverables are architectural artifacts (e.g., higher level systemwide technical plans).

Generally, the first two iterations are the longest and are applied to architectural planning. A total of three to six months for these iterations is not unreasonable, although as little as two to four weeks is commonplace.

Explicit architectural planning has some distinct benefits in software process. First, the architectural iterations do not require an entire project team. Hordes of programmers are unnecessary during the architectural iterations. In fact, adding programmers too early in the project can lead to much dissension and wasted labor expenditures. Many programmers resent having to participate in lengthy requirements analyses and architectural processes. As might be expected, many programmers would rather be designing and coding hands-on. Also, it is difficult to design creatively in groups larger than five people. So, ideal architecture teams are kept small, as are ideal programming teams, with four people for three months being the most effective size and task duration for development.

A key benefit of architecture is planning the partition of large systems developments into smaller subprojects. As might be expected, the ideal goal would be to form subprojects for about four people working for three months. Architecture can plan the partitions and define the boundaries between these subprojects. The most detailed partitioning of boundaries is in the form of software interface definitions (i.e., computational architectures). As such, architectural planning makes the whole software process more efficient.

During the architectural phases, commitments can be minimized. For example, it is not necessary to purchase a lot of equipment or software licenses for a small, short-duration architecture team. Any expensive licenses that are required (e.g., for assessing software technologies) could be demonstrator or evaluation versions. The project can also save on labor costs by using a small team during these initial phases.

Architectural planning defers commitment of resources until they are needed. As soon as the development phase starts, it can be accelerated because the development effort and many crucial technical decisions are preplanned by the architecture team. A desirable partitioning ratio between architecture planning, development, and deployment is 2:1:1-in other words, half of the project for planning, one quarter for "doing" (i.e., software development and testing), and one quarter for training and deployment. This is a classic result from general project management, which has been applied successfully to software projects. This division should, however, be considered a "goal," not a hard and fast rule. In a sense, after development starts, it continues throughout the software system life cycle, with about 70% of the expenditures occurring after the completion of the formal development project, during operations and maintenance.

Development of a maintainable system is one of architecture's key benefits. Architectural planning is essential for achieving higher level qualities such as maintainability, reliability, and extensibility. Many of these qualities are directly or indirectly linked to system complexity. It may be simple common sense, but excess system complexity makes it difficult and expensive in virtually every respect. For example, complex systems are hard to document, develop, test, maintain, debug, and so forth. Architects understand that a system must be as simple as possible, but not too simple (i.e., simplistic). Most systems can be designed in a much simpler way than developers would normally assume.

In any problem there is an inherent complexity, but there is an even greater complexity in solutions (assuming that the solutions work). The necessary complexity in the solution is a result of the inherent complexity in the problem. The excess complexity in the solution (beyond the inherent complexity) varies greatly. From experience, most excess complexity derives from a lack of design coordination. Excess complexity can be a natural result of uncoordinated designs, particularly at the system level of software scale. Knowing this, architects can manage and minimize the excess complexity.

Architecture by Delegation The good old days of software promulgated a practice that continues today. Software architecture was and is often designed by delegation. To architect by delegation, a manager identifies candidate subsystems and then delegates the details of interface specification to individual developers. The number of subsystems selected is usually based upon the number of programmers. Six programmers equal six subsystems, four programmers equal four subsystems, and so forth. Having the preexisting structure of the software organization drive the technical solution is a dubious practice, but what happens next is even worse. In order to define subsystem interfaces, programmers engage in pairwise negotiations to define the software interfaces. Since all interface decisions are decentralized, the process inevitably leads to unique interfaces, also called an order N by N solution. The interfaces are unique to each implementation and to each system. The tragedy of architecture by delegation is that architectural qualities of design are seen as desirable by developers but virtually always are sacrificed to expedience. Commonality of interfaces is viewed as a desirable objective but is seldom pursued in practice. Management of complexity is not a significant issue if there is technical support from fellow programmers and the ability to change things whenever agreeable.

Architectural planning enables organizational decisions to be made after their consequences are clearly understood. A classic problem for software projects involves mismatches between the technical requirements of the solution and the preexisting structure of the human organization. After the human organization is established for a project, with ownership for specific architectural partitions, it is most difficult to change. It is even worse when the architecture is ill-defined because technical decisions are equivalent to political decisions. It is very undesirable when political compromises become the most important drivers in the design of the system. Doing architecture, up front, with a small team, allows management to establish the proper organizational structure, one that does not conflict with technical imperatives.

From a management perspective, architecture is a useful planning activity because it defines the solution in sufficient detail to provide a dramatically improved basis for project planning. While estimation methods (e.g., function points) are capable of forecasting project costs, these methods cannot define an architecture for the solution. Estimation methods cannot indicate how the system is configured, how to organize the project team, or how to decompose the project. Architectural planning can.

The Macro Process: Architectural Iteration

Architectural iteration is a process for quality improvement in project/system architecture. The process spans the entire system life cycle. In this description of architectural iteration, it is assumed that extensive review and feedback are applied at every step in which the project makes an important selection. As soon as the architects are willing to make a commitment, the information value is lost if it is not reviewed, validated, or confirmed through consensus of peers, developers, or other system stakeholders.

Typically, a software project begins with an informal vision, or an inspiration that may be the result of a creative discussion, or someone's bright idea. This occurs long before the project is a formal project. This could be called Architectural Iteration 0.1 (the version and iteration are referred to synonymously here). This vision is then documented in some form that sells the concept to the system stakeholders (Iteration 0.2). As a result, time or money becomes available to pursue the vision. In follow-on iterations, projects diverge greatly, depending upon industry, participants, and corporate culture. Assume, in this case, that an architectural planning activity occurs next.

After Iteration 0.2, the architectural planning proceeds through requirements analysis and architectural specification, followed by architectural prototyping. During the paper planning phase of architectural specification, any number of design alternatives can be considered. Ten iterations of paper design are not atypical. The architect (or architecture team) is seeking the best solution. And they cannot effectively evaluate solutions without committing them to paper or software for criticism.

Design concepts can (and should) vary widely. For example, designs that are highly vertical should be attempted, as should designs that are broadly horizontal and hybrids of the two extremes. At the paper stage of design, commitment to any specific design is inconsequential; therefore, bizarre ideas should be explored in order to discover their potential benefits, if any.

Having gathered the best ideas, from paper design studies, architectural mining, and other intelligence, the architects select the final design. Call this Iteration 0.9. In the architects' judgment, it represents the best design candidate for realization.

An architectural prototyping activity is appropriate at this point. Its purpose is to validate the key design decisions, in particular the dynamic behavior of the solution. The architectural prototype is a simulation of the system, with all architectural boundaries implemented, but with the internals of the subsystems stubbed out (e.g., throwaway code).

Lessons learned from the architectural prototype are incorporated into the final iteration of the architectural phase, which can be called Architectural Iteration 1.0. It produces a paper specification and architectural prototype representing the best design that the architects can produce (with respect to paper studies and simulation), without actually building the system.

The publication of Architectural Iteration 1.0 is an important project milestone, and the most critical milestone for software architects. At this point, the architecture is transferred to the development teams for detailed design and construction (i.e., iterative incremental development). As the conceptual basis for the entire software project, the architecture should be stabilized or frozen, while this detailed work proceeds. The architecture represents the key assumptions of the project. Changes in key assumptions can have dire consequences. The architecture also represents the boundaries of the project, both internal and external. If these boundaries are unstable, much negotiation or worry mongering may result. The architects work with project management to reduce these negative consequences through architectural stabilization.

The keys to stabilization include (1) doing homework during the architecture iterations and (2) sticking together, including architects, management, and lead developers. The team is ill-prepared for Iteration 1.0 if its members can't defend their architecture when facing simple and complex questions.

During the development iterations, the architecture team is available to communicate the design. The architects can answer the developers' questions and interpret designs. The architects should not try to micromanage the internals of each subsystem's design but should simply reinforce the larger scale boundaries defined by the architecture through well-articulated explanations.

At the same time, the architects are beginning their intelligence collection for Architectural Iteration 2.0. As people ask questions and raise concerns, architects should take notes. Any immediate change to the architecture is unwarranted because the experiment is just beginning. It is important to respond with good judgment and not to react in a reflexive manner.

Developer Reaction to Architecture

As the developers near completion of their first prototype, the result of a major development iteration, the architecture team begins active intelligence collection, preparing for the next iteration of the architecture. What the architects observe can be categorized in terms of three developer reactions: (1) implementation as planned, (2) misunderstanding, and (3) defect workaround.

When the system is designed on paper, the architects envision various design benefits. These benefits are unproven until they provide advantages to developers in practice. When the architects inspect the implementation, and it appears to be implemented as planned, they have evidence that the design benefits have been realized. For this to happen, the architectural vision and design must be communicated and understood, then implemented, and the design must be technically sound. Evidence of implementation as planned is confirmation of adequate communications and design soundness.

What happens in practice is that some parts of the design are implemented as planned, whereas other parts are applied in unexpected ways. Each design element has an intended purpose that defines how it should be used by developers. However, architectural intentions do not always match implementation reality. The three developer reactions apply to each and every architectural decision that affects their work. The architect needs to inspect the designs carefully to discover the developer reactions. This check involves conversations with developers as well as inspection of software and subsidiary design documentation.

Note that it is not the architects' role to be judgmental. During this discovery phase, the architects should be neutral fact finders, using informal discussions and casual reviews to collect their information. This is not the time to enforce architectural decisions; rather, it is the time to rediscover the architectural reality, having been through the cycle of design and development.

When the design is not implemented as planned, there are two alternative reasons: there was a misunderstanding of the architecture, or there is a real design defect. The architect must decide which is which. In a misunderstanding, a sound design was implemented in a creative way by the developer. The developer could have done what was achieved by using the architecture as planned, but he or she didn't. The developer proceeded to implement the design in a discretionary way that exploited other elements of the design to achieve the same purpose.

As professionals, architects tend to assume everybody in their work environment is trustworthy and has good intentions with respect to architecture and implementation. If possible, they also make the competent engineer assumption, that all the developers are sufficiently educated and competent to understand and implement a properly articulated architecture. Alas, the competent engineer assumption does not always apply in many of today's programming shops, so architects must work with management to make necessary adjustments to project policies and procedures. Architecture is particularly valuable in that it provides technical guidance to the developers, thus eliminating much guesswork. We can supplement that architectural benefit with training and mentoring.

Using effective management practices, architects must never jump to the conclusion that developers have bad intentions. When there is a misunderstanding, they should always assume that further explanation is needed (perhaps in the form of additional education and training). In this sense, a misunderstanding is a failure of the management and architecture team to communicate the design effectively. Procedures for architectural release and rollout should be modified. For example, if there is a consistently misunderstood part of the design, spending more time communicating that part of the design is warranted in the next iteration.

The one-day architecture seminar can be effective as the primary architectural communication mechanism. This lecture-tutorial seminar is not a review. This fact should be emphasized to the audience because there is an implicit assumption in many development cultures that every meeting is some form of review. In this one-day seminar, the architects explain the architecture, section by section and level by level. In our experience, a written document, alone, cannot be an effective means of coordinating implementations without some form of face-to-face explanation. In other words, the stand-up tutorial imparts some missing element of communication that cannot be effectively replaced by architectural documentation.

At first impression, this missing communication factor appears mysterious. What the stand-up tutorial imparts, that no document can, is the architects' commitment to the system design, in every important detail. Through a stand-up tutorial, the architect can make the system vision understood and much more believable. In addition, the architect can quickly explain rationale for design details that no amount of documentation can replace. In a perverse sense, architectural rationale can be nearly unlimited. Design decisions can be based on long experience or on design insights gained through lengthy studies. While one can attempt to explain these experiences at length, real knowledge can be gained only by experiential learning.

It is possible, as a last resort, that the design has a flaw that must be changed. Flaws and defects can come in many forms and for many reasons. They can be mistakes, oversights, ignorance, and so forth. Many such defects are unpredictable and are discovered and remedied only through experience. As architects, it is our last resort to change the design. Design changes have consequences. A change may fix a certain problem locally, but it may cause many other problems and hardships for the project. For example, a significant change to a system-level API used by a dozen applications would involve substantial reprogramming. Sometimes such changes are necessary if there are great technical advantages to the new design.

After Intelligence, Iterate the Design

The architects have learned much during the initial paper design process. They have gained additional insights during architectural prototyping, but the real test of the architecture occurs during development and testing of engineering prototypes and production releases. At every step, the architects strive to improve the quality of the design; they use the lessons learned to make the design better and better. Since quality is the satisfaction of human needs, architects are continually working toward a design that will realize the most stable balance of design features supporting a quality solution addressing the stakeholders' needs.

In terms of our architectural iteration process, at the end of Architecture Iteration 1.0, the design of the architecture during Developmental Iteration 1.0 was frozen. Near the end of the developmental iteration, substantial intelligence was collected about how the architecture was implemented. Any changes to the architecture must be inserted during the transition from Developmental Iterations 1.0 to 2.0. The key idea of architectural iteration is to keep the architecture stable during development, changing it only at discrete times synchronized with work-stopping transitions in the development process.

The architectural activity is vigorous near the beginning and end of major development iterations, where most developers will work on finishing and stabilizing the current release before branching off and building the next major release of the code. It is the intention of architects to catch the train of the next major release, without derailing the project through ill-timed architectural fluctuations.

Changes are made to the architecture through a decision process called architectural concentration. Intelligence gathering provides information about design comments, criticisms, and actual usage. Each of these inputs to the process comprises an architectural design force. The architect balances the design forces through improved communications or design changes. Many forces are required before a design change is justified. If we are too responsive to forces, design changes will be frequent and violent. This is the opposite of the stable environment that architects are attempting to create. If the architect does not respond to emerging design forces, an equally indefensible situation is created. So the architects find balance between these extremes by using the architectural iteration process. In other words, there will be changes to the architecture, at discrete times, according to the project plan. Any inputs received are considered intelligence for the next architectural iteration.

In the architectural concentration process, many forces are resolved by each change. The appropriate analogy is "killing two birds with one stone." The influences of several design forces are combined to cause a single change to the design that addresses the needs. The architect must distinguish between what is needed and what is desired. The provision for "what is needed" must be satisfied, but the provision for "what is desired" should be considered with moderation. Also, it is important to realize that the explanation of the revised architecture can be as important as design changes. In other words, how the features of the architecture are explained is a way of resolving forces, which is often more effective than direct technical changes.

Architectural iteration works like a critical damping factor. If architects are too responsive, the architecture changes too rapidly and does not converge for a long time. If they are too stubborn to be responsive, the architecture also takes much longer to converge, perhaps after the stiff-necked architect is dismissed. Architects want to play their proper role in the project so that the architecture converges as rapidly as possible, but without much oscillation, which is overresponsiveness to change.

The mission of architects is to ensure that the system converges on a high-quality design, at least for design decisions that have a systemwide impact. And if software architects truly believe in the principle of encapsulation as promoted by OO and component paradigms, that's all they should really care about because any internal design defects (outside of the architect's control) are isolated within subsystems. Quality convergence is a goal unique to architects because developers (who are focused on coding issues) or management (who are focused on short-term results) seldom see it as a priority. However, we know that architecture quality will contribute significantly to the ease of coding and the delivery of short-term project results, as well as to the longer-term issues of usability, extensibility, and maintenance.

The Micro Process: Architecture with Subprojects

The core process of architectural iteration is called architecture with subprojects. Because architectural planning partitions the problem into subsystems with stable boundaries, it is possible to design and develop these subsystems as subprojects in relative isolation. "Relative isolation" suggests that the subprojects may be conducted concurrently or in a distributed organization, with relatively minimal need for inter-subsystem coordination (assuming that the architecture "does its job").

Architecture with subprojects can be described as a viewpoint on the overall process of system development as follows:

From-Scratch Designs Versus Smart Architectures The practice of architecture involves some engineering, some psychology, some art, and a great deal of intuitive judgment. That architecture is not, however, magic. When designing a new system, it is insufficient to "throw something together" and expect to generate good design. When starting on a new design, the worst approach is to give all the developers a blank sheet of paper (or analogous situation) and ask them to design from their own knowledge of the problem under a tight deadline. Almost as bad is an approach where the architecture team tries the same thing. This situation, called designing in a vacuum, occurs when there is no intelligence gathering. In contrast to other fields of endeavor, a software architect has no particular advantage over ordinary developers when designing in a vacuum. The limitations of designing in a vacuum can be overcome in several ways. One approach, described at length in this book, is architectural mining. Architectural mining gives the architect substantial, detailed information about how to design similar systems effectively. It also conveys a sense of perspective, beyond experience with a sole implementation. Another approach is domain analysis, where a set of requirements is iterated, with user involvement, from a disorganized jumble into distinct horizontal and vertical elements. In both cases, the experience of domain analysis is more valuable than the artifacts generated because it trains the architect to think about the problem and realize the advantages of increased intelligence and vicarious experience.

Architecture in Chaos

Architecture attempts to bring some additional technical order to the chaotic process of software development. Development can appear chaotic because of apparent changes in the environment of the project. It is the strong desire of software management to give their sponsors what they want-and what they want can change as frequently as the wind direction. In addition, a software project is a learning experience in which business requirements and real-world constraints are discovered during the project, not during initial requirements elaboration.

The technical environment is also changing; innovations that occur during a project can motivate changes in technical plans. As commercial technologies increasingly address the vertical needs of industry, it becomes easier for external marketers to have an impact on organizational decisions about software. For example, we have seen extremely well-planned projects completely change direction and technologies, almost overnight, because of vendor influence.

Software design models are inherently intolerant to change. Design models are crafted with respect to certain assumptions and an emphasis on what's important and what's not. When changes in fundamental assumptions occur, the models are invalidated because their hard-wired assumptions no longer hold true. Most projects find this acceptable. It is a very common failing to deny that invalid models are indeed invalidated. Instead, projects pretend to make progress with broken models, which become progressively more corrupted.

Another source of chaos is in the software process itself. It is devilishly hard to assess software progress, especially by word of mouth. A common joke in the software profession is that the software is always 85% done. Of course it is, and the last 15% can easily add another 90% to the development time and budget. As the truth emerges about software progress, there are many surprises, including many pitfalls and unknowns and necessary reworks that have an impact on the project's schedule and direction.

Architects are not the primary responsibility holders when it comes to controlling chaos; that is properly the role of management. However, architects are a de facto part of the management team and can influence management decision making. Architects are responsible for eliminating as much technology-driven chaos as possible and for mitigating chaotic conditions in other areas touched by architecture, such as enterprise architectural models. Architects should use their influence with management to make suggestions about how to handle important situations that they may have encountered on previous projects. In addition, architects work with management to affect decisions, solutions, and policies that moderate chaos.

Architectural iteration is a primary approach for dealing with chaos, from the software architect's perspective. Some additional strategies that should be used with architectural iteration for dealing with chaos include: