8.2. Architecture Iteration

Architecture 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. As software architects, we want our decisions to be flexible enough to survive changes. But according to Alistair Cockburn, we don't know what we don't know [Cockburn 98]. Ignorance is the more dangerous enemy. What we don't know can change our architectural assumptions to the breaking point. This intelligence operation is intended to defeat these enemies through the preplanned strategy of architecture 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.

We would urge restraint at this stage for several reasons. First, on average, software projects are over budget by 184% by the time of delivery [Johnson 95], 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 98]. It is important to help projects to 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 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 our ability to assess progress and quality. As these things we don't know are discovered, responsiveness, rework, and redirection are often required.

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 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 iterative-incremental process is to complete an entire function in an increment, so that it will not require rework downstream in the process. This means that the analysis, design, coding, and testing of that one function must be exhaustive enough to reduce or eliminate the need for later rework.

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 we are building the right system). However, external increments usually require throw-away coding, since 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 Architecture Process

Software architecture helps the project manager in planning increments, because the architect breaks up the system into well-thought-out functions—for example, 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, software architecting 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 "architecture iterations" because the principal deliverables are architecture 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 architecture planning has some distinct benefits in software process. First, the architecture iterations do not require an entire project team. Hordes of programmers are unnecessary during the architecture 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 architecture processes. As might be expected, many programmers would rather be designing and coding hands-on. Also, it is difficult to creatively design in groups larger than 5 people. So, ideal architecture teams are kept small, as are ideal programming teams, with 4 people for 3 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 you might expect, our ideal goal would be to form subprojects for about 4 people working for 3 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, architecture planning makes the whole software process more efficient.

During the architecture 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.

Architecture planning defers commitment of resources until they are needed. Once 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. We would consider this as a "goal," not a hard and fast rule. In a sense, once 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. In our opinion, architecture planning is essential for achieving higher-level qualities such as maintainability, reliability, extensibility, and others. 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 architected 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 due to 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 equals six subsystems, four programmers equals 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 the 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 unique to each system. The tragedy of architecture by delegation is that architecture 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 you have face-to-face technical support from fellow programmers, and the ability to change things whenever agreeable.

Architecture 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. Once 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. Architecture planning can.

The Macro Process: Architecture Iteration

Architecture iteration is a process for quality improvement in project/system architecture. The process spans the entire system life cycle. In this description of architecture iteration, we will assume that extensive review and feedback are applied at every step in which the project makes an important selection. Once 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. We could call this Architecture Iteration 0.1 (we will refer to the version and iteration 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. In this case, we assume that an architecture planning activity occurs next.

After Iteration 0.2, the architecture planning proceeds through requirements analysis and architecture specification, followed by architecture prototyping. During the paper planning phase of architecture specification, any number of design alternatives can be considered. Ten iterations of paper design is 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 well as 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, architecture mining, and other intelligence, the architects select the final design. We can call this Iteration 0.9. In the architects' judgment, it represents the best design candidate for realization.

An architecture 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 architecture 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 architecture prototype are incorporated into the final iteration of the architecture phase, which we can call Iteration 1.0. It produces a paper specification and architecture 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 Architecture 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 architecture stabilization.

The keys to stabilization include (1) doing your 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 developer questions and interpret designs. The architects should not try to micromanage the internals of each subsystem's design, but 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 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. We can categorize what the architects observe 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, that is evidence that the design benefits have been realized. In order for this to happen, the architecture 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, and other parts 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 in order to discover the developer reactions. This involves conversations with developers as well as inspection of software and subsidiary design documentation.

We emphasize 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 development. The developer could have done what was achieved by using the architecture as planned, but 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, we make the assumption that everybody in our work environment is trustworthy and has good intentions with respect to architecture and implementation. If possible, we also make the competent engineer assumption, that all of the developers are sufficiently educated and competent to understand and implement a properly articulated architecture. We know that the competent engineer assumption does not always apply in many of today's programming shops, so we can work with management to make necessary adjustments to project policies and procedures. Architecture is particularly valuable in this respect, in that it provides technical guidance to the developers that eliminates much guesswork. We can supplement that architectural benefit with training and mentoring.

Using effective management practices, we never jump to the conclusion that developers have bad intentions. When there is a misunderstanding, we 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.

As our primary architectural communication mechanism, we favor the one-day architecture seminar. This is a lecture-tutorial format which is not a review. This 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 architecture is explained by the architects, 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. You can attempt to explain these experiences at length, but the real knowledge can be gained only by experiential learning.

It is possible, as a last resort, that the design has a flaw which 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 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, we froze the architecture design during development iteration 1.0. Near the end of the development iteration we collected substantial intelligence about how the architecture was implemented. Any changes to the architecture must be inserted during the transition from development iterations 1.0 to 2.0. The key idea of architecture 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 architecture 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 architecture fluctuations.

Changes are made to the architecture through a decision process called architecture concentration. Through our intelligence gathering we know about design comments, criticisms, and actual usage. Each of these inputs to the process comprises an architectural design force. The design forces are balanced by the architect 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, it creates an equally indefensible situation. So the architects find balance between these extremes by using the architecture 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 architecture 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.

Architecture iteration works like a critical damping factor. If we are too responsive, the architecture changes too rapidly and does not converge for a long time. If we are too stubborn to be responsive, the architecture also takes much longer to converge, perhaps after our dismissal. We want to play our role in the project so that the architecture converges as rapidly as possible, but without much oscillation, which is over-responsiveness to change.

As architects it is our mission to ensure that the system converges on a high-quality design, at least for design decisions having systemwide impact. And if we truly believe in the principle of encapsulation as promoted by OO and component paradigms, that's all we 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 it is seldom seen as a priority by developers (who are focused on coding issues) or management (who are focused on short-term results). 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 the longer-term issues of usability, extensibility, and maintenance.

The Micro Process: Architecture with Subprojects

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

We can describe architecture with subprojects as a viewpoint on the overall process of system development as follows:

From-Scratch Designs versus Smart Architecting The practice of architecture involves some engineering, some psychology, some art, and a great deal of intuitive judgment. However, we believe that architecture is not 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. We call this situation designing in a vacuum, because 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. We can overcome the limitations of designing in a vacuum in several ways. One approach that we described at length is architecture mining. Architecture 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.

Architecting 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 marketeers to impact 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 impact 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 architecture 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.

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