SAIP: The Architecture Business Cycle

The next reading assignments come from the book Software Architecture in Practice (SAIP). Whenever future posts are based on this book, I shall prepend the acronym SAIP to the title.

The Swedish Ship Vasa (p. 4 of SAIP):

Faced with an impossible task, Hybertsson had the good sense to die about a year before the ship was finished.

One interesting (maybe even fairly obvious) point is that project requirements alone do not determine the architecture of the system. Think of it. Given the same set of requirements, no two developers would go out and develop with the same architecture in mind. And yet many software projects fail simply because all focus has been placed solely on the requirements. By placing all faith on the requirements alone, all other aspects tend to be neglected.

Instead, this book proposes that a software architecture is the result of technical, business and social influences. Moreover, just as these three factors influence the software architecture, the software architecture also affects the technical, business and social environments. This chapter of the book has not yet defined architecture, but we may just use the definitions that we have covered in my previous posts.

For instance, the architect has to take into consideration the resources that his organization can provide. The organization might have a limited pool of programmers to spare for the project. Therefore, the architect might have to choose a particular tool, programming language and architecture that the programmers are familiar with.

Moreover, the experience of the architect himself also plays a great role in determining the architecture of the system. If the architect suffered from a bad experience with some particular approach, he would be wary of using that approach on a future project.

As aforementioned, not only does the technical, business and social influences affect the decisions of the architect but the architect will also affect those factors. An example of this would be when the architect produces a prototype for evaluation. With a prototype, the customer would be able to evaluate the feasibility of this piece of software. The customer might then decide to add or remove features to suit their own needs. Adding or removing features has an effect on how the architect should proceed for the next stage.

The book itself has a lot more examples of the interaction between the stakeholders and the architect. Most of these might seem like common sense but the authors have done a good job by actually expressing the more general cases on paper.

Toward the end of the chapter, the book provides some rules of thumbs on what is a good architecturea. A more mature methodology for evaluation would be based on the Tradeoff Analysis Method that is presented in chapter 12 of the book.

One would think that the interaction between software architects and the stakeholders is something that people in the software business should know about. And yet, most software projects do not go as plan simply because the customers throws down a set of requirements for the developers, with some budget and a timeline and expects the developers to produce something by the deadline. Great architecture seldom (if ever) come out as a sequential series of steps. Instead it requires iterative steps that refine trouble spots in the software architecture as both the requirements, stakeholders and architect themselves mature in the life of the software.

Hopefully, with more agile development methods such as XP, there is a trend toward making software development more iterative.