The Customer is the Focus
Software architecture can conjure images of "geeky" activities like Extreme Programming, Scrum, Inversion of Control, etc. These images certainly are fostered by perusing the developer community, where the majority of blogs, forums, and websites are about development processes, tools, and technologies. Unfortunately, this results in a misrepresentation of software architecture. First and foremost, software architecture must take into account the needs of the customer.
Whether your project is an in-house development in which you or another department are "the customer," or whether you are developing a commercial product for an "anonymous customer," software architecture involves several steps before any design, and certainly any implementation, is laid to paper. Furthermore, these steps tend to be iterative. For example, while a user interface can be prototyped, the usability of the interface isn't really known until the user interface is backed by real data and real work environments.
Understanding the Domain
Of foremost importance is understanding the customer's business domain. This is easier said than done, as sometimes the customer doesn't fully understand their own domain, or more frequently, one encounters conflicting information about the domain, depending on to whom one talks.
It is also unrealistic to try to capture every nuance of the domain immediately. Important information will be omitted, additional requirements will be discovered, the requirements may change during development due to external market forces, etc. It is also unrealistic to hold off, until the domain is fully understood, on design and implementation prototypes, proof-of-concepts, and/or production rollouts of subsets of the application. Part of the process of coming to a complete understanding of the domain involves getting software into the customer's hands sooner rather than later.
Architecture Supports The Customer
The software architecture must take into consideration the most appropriate way to support the customer's needs, not just in terms of requirements, but also in terms of work processes. How involved will the customer be with the design and development process? Is the customer discovering requirements as prototypes are being developed, or does the customer have a well defined statement of the requirements? These questions, and more, drive architectural decisions.
Almost all software development has some iterative aspect to it. An application may be developed to an "alpha" or "preview" state and then handed to a select group of users for feedback. An application may be developed more iteratively with different levels of customer involvement. Furthermore, the level of customer involvement varies through the development process. The customer might have considerable involvement in the knowledge acquisition and prototyping stages, little involvement during actual development, and then considerable involvement again during testing.
Architecture Supports The Application Lifecycle
The development process does not end when the application "ships." Instead, it enters a maintenance phase, in which bugs are corrected, new features may be added, or work on the next major release is begun. Sometimes the delineation of production rollout and development is vague--pieces of the application are continually being developed and released even as new components are being designed for eventual inclusion.
Discerning the application lifecycle, having a long term plan for the application, affects the architecture. For example, a "one shot" application such as a utility may not require a sophisticated component-based architecture. Conversely, an application that is intended to support the computational needs of an engineering firm for the foreseeable future requires a careful consideration of the supporting architecture.
Architecture Supports Documentation
Documentation, especially with regards to application lifecycle, is often not considered when designing an application. Throughout the lifecycle of the application, users and developers alike will leave the company and new people will come in. The cost of training both users and developers is a consideration, but even more importantly, the less tangible value of an individual's knowledge must be considered. If a senior person leaves the company and with considerable knowledge "in their head," the company must recover this knowledge which can be a painful and costly process.
The application architecture can support the documentation process so that important knowledge does not walk out of the company. Through the use of a variety of available tools, the application can be "self-documenting," providing valuable information with regards to structure, workflow, user interactions, rules, states, and computations, all of which (and more) eases the transition when senior people are lost.
Architecture Supports The Developer
Lastly, a good architecture supports the developer, which ultimately supports the customer. An architecture that facilitates reporting, diagnosing, and correcting problems results in a faster turnaround, which is both more cost effective for the company and wins accolades from the customer. An architecture that is flexible throughout the application lifecycle eases the introduction of new requirements and the changing of existing requirements.
A good architecture does not get in the way of the developer, nor does it get in the way of the customer. Rather, a good architecture should facilitate application development, testing, debugging, and changing application requirements. Some up-front investment in architecture will have significant cost savings to the company when confronted with the realities of changing requirements and external market forces.