why not architecture

Browsing through the "Distributed Systems" book of Tanenbaum and Van Steen. In chapter 2, where they talk about software architectures, they talk about things much more level than whan reverse engineering calls architecture. They talk about object based, data-centererd, event-based, layered architectures. What in reverse engineering people call architecture, they would probably call components (at most).

From this point of view, the thesis should not be called anything architecture, but rather something like Understanding the macroscopic evolution of software. The title is cool because it easily accomodates the various levels of macro at which one can analyze the software. One macro-level is the project-level. The other level of macro is the super-project/super-repository/project-portfolio level.


In fact, it is in the context of software super-repositories that the architecture makes more sense. If I am a consultant, I don't need to reverse-engineer a system to find out its architecture. Probably people can tell me that it is a layered and an event-based system. On the other hand, if I am looking at Sourceforge, it becomes very interesting to have the possibility of detecting the projects that have an event-based architecture.

In this context, also the cool table makes sense. The granularity levels are the macroscopic levels of software. The time dimension is the evolution. And then the thesis will be about understanding software evolution at all these levels: what are the types of analysis that work at the corresponding levels, who are the stakeholders that are interested at the various levels.

Investigate further:
- the analogy with the fashion and culture. Fashion changes very fast - it is not relevant at the macroscopic level. culture changes slow, and it is the things that matter.


Open questions:
Where do the requirements fit into the picture? How do the tests fit?