The Process of Software Architecting

http://www.artima.com/forums/flat.jsp?forum=270&thread=156705

Peter Eeles has published a series of articles on IBM DeveloperWorks on software architecture. In his most recent installment, he discusses the tasks and processes a software architect is involved in during a project's lifecycle.

The article provides a helpful diagram of architecting-related terms, and concludes that architecting is a multidisciplinary activity that spans a project's entire lifecycle. While architecting is often associated with design, an architect is involved in processes such as:

• Requirements: the architect ensures that requirements of interest are captured, and the prioritization of requirements.
• Implementation: Define the implementation structures that will be used to organize the source code and executable work products.
• Testing: Ensure that the architecture is both testable and tested.
• Development environment: Set up guidelines, ensure that tools are available and are used.
• Configuration management: Define strategy, including version control, since configuration strategy often reflects the architecture.
• Project management: Provide input to the project planning activities.

He also shows that architecting is an activity that spans the entire project lifecycle:

Early on in the project, the architect is focused very much on discovery. The emphasis is on understanding the scope of the system and identifying the critical features and any associated risks -- all elements that clearly have an impact on the architecture. The emphasis then changes to one of invention, where the primary concern is to develop a stable architecture that can provide the foundation for the full-scale implementation effort. Finally, the emphasis changes to implementation, when the majority of discovery and invention has taken place.

While discovery, invention, and implementation often proceed in that order, Eeles points out that architecting is both top-down and bottom-up:

[...] It is rare for an architecture to be driven totally from the top down[...] It is also common for an architecture to be driven from the bottom up, as a result of lessons being learned from any executable software that has been created, such as an architectural proof-of-concept. To some extent, the architecture is also driven bottom-up as a result of design or implementation constraints that have been specified, in which cases these elements are "givens" that the architecture must accommodate. For example, a constraint might be that the design will use a relational database or interface to an existing system.

Eeles has much to say about design and architecting, and whether architecting is more an art than a science:

One way of advancing this maturity [of the discipline of architecting] is to draw upon an existing body of knowledge. In general terms, architects look for proven solutions when developing an architecture, rather than reinventing the wheel[...]

Although architecting can be seen as a science, there are times when it is necessary to provide some level of creativity. This is particularly true when dealing with novel and unprecedented systems. In such cases, there may be no codified experience to draw upon. Just as a painter looks for inspiration when faced with a blank canvas, architects may also, on occasion, see their work more like an art than a science. For the most part, however, the artistic side of architecting is minimal. Even in the most novel of systems, it is normally possible to copy solutions from elsewhere and then adapt them to the system under consideration.

As the process of software architecting becomes more mainstream, it is likely that it will no longer be seen as some mysterious set of practices that only the "chosen few" are able to comprehend, but rather as a broadly accessible set of well-defined and proven practices that have some scientific basis.

What do you think of Eeles' remarks on software architecting?