Architects exist to design, yes, but their eyes remain focused on a point on the horizon far beyond the architectural phases and the completion of the blueprint or model. Client, architect, and builder - all have the same destination in their sights: the successfully completed structure. The only point is to build something and move people in.

Overall Phases

It is noteworthy that the title refers to the phases of software construction - not the phases of software architecture. The point of the process is to build something, not just design it, but the process is architecture-driven because it begins with an architect and client, and follows according to the architectural plan.

All construction projects can be simply divided into two primary phases: the design (or architecture) phase and the construction phase. This classification can exist, however, on several levels depending on the size and complexity of a project.
For example, a large housing development would have a large-scale design of the layout of roads, subdivisions, utilities, and common amenities, such as tennis courts, pools, parks, and ballparks.
The construction phase would follow to complete the overall site. This would include building roads, installing utilities, cleaning the sites, and possibly building the common amenities.
In turn, each individual home would have its own design and construction phases - often with separate clients, architects, and builders. However, the site developer would have planned for each home by defining the legal boundaries of the lots and ensuring that each would be feasible for building. It would also be likely, in most areas, that design guidelines for the individual homes in terms of their size, quality, and style would be determined as a part of the overall development plan. So even before a lot is sold, the design phase for that home can be influenced largely by the context in which it will be built. The outcome will be quite predictable, even to the point where an architect has little to do. Sometimes an owner is given a choice of three model homes - and that, as they say, is that.

This is thoroughly analogous to software-based technology structures. A large bank, for example, may desire a total software redesign. The overall domain and scope would be defined before any work began on an individual structure, such as a loan application. The global design issues, such as risk management, are the covenants that each individual application design must heed.
The framework would be the same as for the housing development. The infrastructure would be laid out, the relationships between individual units would be mapped, the size and number of the individual structures would be planned, and the look and feel, quality, and "covenants" would be detailed - down to flower pots, if desired.
There is endless flexibility here. One Kirkland community is made up exclusively of Frank Lloyd Wright homes. Each may vary considerably but the desired overall style is the same. On the other hand, there is a planned community in Laval that forgot to specify the types of fencing homeowners could choose. The result is chain link - white picket - cedar rail terror.
The point is that each project, whether brick or computer code, has its own design and construction phase. And there are nested layers and meta-levels to design and construct, as dictated by the scope of the individual project.
The analogy holds in this case and tells us that when the larger context is not considered, fences make the best neighbors.

With these caveats in mind, and more to follow, the first four architectural phases are presented next. The list of phases is largely patterned after the phases of architecture and construction, outlined and practiced by the American Institutes of Architects.

Phase One: Pre-Design - Shared Vision

In this initial phase, the architect listens in order to understand the needs and expectations of the client, as well as the scope and scale of the project. The client's key design points, stated requirements, and preferences are assessed. The architect carefully studies the context of the project - the entire enterprise of which the project is a part. The needs and culture of inhabitants - their patterns of activity - come to be understood through listening, observing, reading, and asking questions. The client's resources are determined, including financial and intellectual capital available, as are the problems the client needs to overcome.
The architect begins to strategize - to identify possible solutions available through technology, as well as organizational management and process changes.
A design direction begins to take shape, with the architect and client collaborating, sketching, talking, and refining their understanding until a shared vision emerges.

Phase Two: Domain Analysis - Conceptual Definitions

The architect undertakes to understand and document the areas (domains) for which the system will be built and to learn client expectations and needs in as much details as necessary. The desired behavior of the system - what it needs to provide the inhabitants - are outlined. The architect assesses the client's business and technology environment and the interplay these factors have with the scope of the project. The domain terms and concepts are accurately defined.
An architect may specialize in a specific domain or call in a domain expert - for example, one or more domain users most proficient with the business process flow.

Phase Three: Schematic Design

In this phase, architectural-level designs depicting the domain characteristics and technology structure are prepared. The look-and-feel of the system - the user interface style - is designed. Prototypes are built. Lines between phases blur at this point. Migration and risk assessment are performed.

Phase Four: Design Development

Now the architect continues the expansion of detail and design refinement to converge on a final design. All the domain and technology design drawings, that is, what the client needs to validate that the expectations are met - are finalized.

CAUTION: These Design Phases are Not Linear

The Phases outlined above are not linear. They are not even a road map. In fact, the list of design phases exists as much to tell the client what to expect as to direct the activities of the architect. Owners need to know what their active role will be in the design stages; the description of the phases provides a logical, cognitive framework.
Design is a collaborative, iterative, even mysterious process. It is filled with wayward epiphanies, setbacks, and insights.
The first thing a client may say to an architect is "I want a flag-stone floor patio like we had growing up on the East Coast." It would be absurd, of course, for an architect to tell the client to wait for the next phase before delving into this level of detail. Rather, the architect takes this information as grist for the mill, because it says a great deal about the client's expectations and tastes. Then the architect can take those ideas and preferences beyond the client's horizon and present design concepts. There is sketching going on at this point, representing feedback loop between the client and architect.
So in the circular way, with the architect understanding the domain, listening to the client's needs and expectations, completing necessary invention and engineering, and working together with continuous feedback, a shared vision emerges and is agreed upon.

Phase Five: Project Documents

The architect focuses on the need of those who will actually construct the system. The construction process, roles of team members, and construction sequences are documented. The construction guide, user interface style guide, and test guide are written. The architect specifies tools and methods to be used, as needed. All the details needed by those who will build the system are completed in this phase.
The level of detail documented by the architect is variable depending on the needs of the project and the builders in question. In individual situations, it is the architect's responsibility to decide how much documentation is needed and when.

Phase Six: Staffing and Contracting

The architect assists in identifying the actual builders of the system. For outsourced projects, bids are submitted to outside contractors and potential participants are evaluated. The architect assists with contract details and in assigning cost. Sequences are arranged, and contracts signed.
This marks the end of the strictly architectural phases, but typically the architect remains involved with the project during the following construction phases when the structure becomes a reality.

Phase Seven: Construction

The architect's supervisory role during construction ensures that the original vision is understood and executed. The architect reviews construction-level designs to the degree dictated by the complexity of the construction process. The architect conducts design reviews and analyzes problems and change requests. The architect also designs the accepted changes, assesses the impact on overall design and cost, and sequences the changes. The architect participates in testing and acceptance reviews to the extent needed or desired by the client.

Phase Eight: Post-Construction

The architect assists the client with the project rollout and the migration to the new system. The architect can be involved with the training of system operators and inhabitants, as needed. The architect assists in warranty issues and ongoing maintenance procedures, as necessary.

Conclusion: The Party Phase

The architect and the client meet when construction is all over, and reminisce about trials and triumphs (even the best of projects are fraught with difficulty). They hold a big party at an Italian restaurant, complete with itinerant street band, for the builders, employees, and customers involved with the project. Those naysayers who whined incessantly and said it couldn't be done now stand mute, sipping their margaritas.

---