Software architecture (panel): the next step for object technology

Moderator's note: this is a lightly-edited set of extracts from the answers given to audience questions during the panel session, together with a brief excerpt from the following BOF discussion. It is not a comprehensive or balanced treatment of either the panel session or of the panelists' views. The position papers printed in the OOPSLA Proceedings contain further powerful statements by the panelists. I have a very broad definition of architecture and I would define it as really understanding software as a product, and the recurring things you see in software as a product. This can go to the very early stages of development where we are talking about recurring requirements. What are the recurring things that people use applications for, and what are the recurring ways that applications support business processes for instance? You can use architecture as a tool for analysis all the way down to actually assembling predefined facilities or software components, both big ones and small ones. So I would certainly not limit the idea of architecture to logical or physical. I think if you look at other uses of the term outside our particular discipline, then they also adopt a very broad definition of what it is. In software, although there is less consensus and we are less explicit about it, you can still recognize distinct levels of design. The differences have to deal with the issues that you are resolving when you are working at that level of design. So we have an executable level of design, we have a programming level, then we have what I think of as the architecture level where we think about the way that components (which more or less correspond to the compilation units but not quite) are put together to realize the gross function of the system. Here is where we worry about how the overall functionality is decomposed, about how the overall performance budget is partitioned out. We worry about bottlenecks and global throughputs and gross aggregate properties of the system here, and I think if we move up from there you may be above to identify a specification or requirement level where the issue is, what is to be computed, in terms recognized by software people or by users. So when I say software architecture I am meaning the design that resolves the issues at the software system level of the design, excluding the algorithm …