 |
 |
|
 |
 Architects design structures to meet human needs. Structures can be assembled with sticks and stones or computer software and hardware, but the role of the architect remains the same. Architects spend the lion’s share of their time up front: listening to clients, understanding the totality of their needs and resources, scrutinizing feasibility, forming a practical vision of a structure, and creating a blueprint. As the structure is built, the architect intervenes in the client’s favor, ensuring compliance to the plan and guiding the vision through the tempest of design changes, crises and ambiguities. Client advocacy is the cornerstone of the architect’s role. To attain the role of true advocate, the architect needs an expansive repertoire - culling design elements from an unfettered spectrum of choice. An architect ceases to be an advocate if tethered to a prescribed set of technologies, tools, or methodologies, only narrowing the solutions available to the client. Individual architectural styles and preferences emerge and are imposed, as it were, upon the client, but these should be the refinements of a discerning mind, not choices forced by limited skill, education or experience. A lifelong mason, no matter how talented, cannot necessarily fill the role of an architect. If you have a chisel, everything tends to look like a rock. Words mean
things. An architect is an architect - not an engineer, a programmer, a scientist, a
webmaster, or a project manager. The word architect is distinct in the building
trades. In software construction, many borrow the gravitas of the title, but fail to
fulfill the role. At |
| Establishing the profession of software architecture will be a defining
activity, not a limiting one. Programmers, engineers, designers – all software
construction professionals – will have more distinct roles and their efforts greater
effect. And just as there are architect/builders in the construction trades, software
architects can fulfill a dual role - both with clear tasks and expectations. This clarity
will allow research, books, tools, and methodologies to be targeted to a recognized
architectural process. Our clients will understand software construction roles and
sequences. They will even have blueprints. Construction projects are always fraught with difficulty, even for homo constructivus, but buildings always get built. The blueprint becomes the reality, more or less, sooner or later. A profession of software architecture, with a defined role for software architects, will not eliminate the challenges inherent in software construction, but it will end the abandonment of uninhabitable information structures now strewn vacant and useless by the side of the road. The following phases define the role of the architect in the software construction process, conceptually following the phases of building construction and architectural services described by AIA Document B163, Article 2.2. These phases apply to all software construction projects, including those using iterative and incremental methods. Many software professionals are already drawing from the analogy with building construction to describe their processes, since it is a true analogy understandable to clients. This inchoate analogy holds the answer to the crisis in software construction and will shape our future. |
 |
|
|
 The architect listens to understand the scope of the project, the client's key design points, requirements, and expectations. The architect also studies the context of the project - the entire enterprise of which the project is a part. Client resources are assessed, such as the financial and intellectual capital available, and the problems the client needs to resolve. The architect identifies possible solutions available through technology, and organizational, management, and product changes. A design direction begins to take shape, with the architect and client collaborating and refining their understanding until a shared vision emerges. Broad budget and schedule objectives are set. |
|
|
 The architect undertakes to thoroughly understand and document the areas (domains) for which the system will be built and to learn the client requirements in detail. The desired behaviors of the system are outlined. The architect assesses the client's business and technology environment, and the interplay with scope. The domain terms and concepts are accurately defined. |
 Architectural-level designs depicting the domain characteristics and technology structure are prepared. The look and feel of the system - user interface style - is designed. Prototypes are built at this point, if they are needed. Migration and risk assessments are performed. |
|
|
 The architect continues the expansion of detail and design refinement to converge on the final design. All the domain and technology design drawings - that is, what the client needs to validate that the requirements are met - are finalized at this stage. |
 The architect focuses on the requirements of those who will construct the system. The construction process, the roles of the team members, and the construction sequences are documented. The construction guide, user interface style guide, and test guide are written. The architect specifies tools and methodologies, as needed. All the details needed by those who will build the system are completed. |
|
|
 The architect assists in identifying the actual builders of the system. For projects that are outsourced, bids are submitted to outside contractors and potential participants are evaluated. The architect assists with contract details and in assessing cost. Sequences are arranged and contracts signed. |
 The architect's supervisory role during construction ensures that the client's vision is understood and executed. The architect reviews construction-level designs to the degree dictated by the complexity and vicissitudes of the construction process.The architect conducts design reviews and analyzes problems and change requests. The architect 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 the client desires. |
|
|
 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 users, as needed. The architect assists in warranty issues and ongoing maintenance procedures. The architect and client meet when it is all over and reminisce about the trials and triumphs. They hold a big party at a Mexican restaurant, complete with Mariachi Band, for all the builders, employees, and customers involved with the project. Those nay-sayers who whined incessantly and said it couldn't be done now stand mute, sipping their margaritas. |
, we refer to software
construction not development. Buildings are not developed. To
develop is to grow, evolve, and unfold. Architects oversee construction, they do not
guide development. Theoretically, there is no end to development. And that is an object
lesson we should have learned by now. 
