Kent Beck, First Class Software. Abstract ... talk usefully about systems without talking about their detail; a knowledge of them gives us design choices ... We take this simplicity to be an expression of a powerful architecture. But note that ... People regularly tell me anecdotes ... originated as a group of cathedral architects who.
Software Architecture:
The Next Step for Object Technology (PANEL)
Bruce Anderson, University of ESSPX (moderator) Mary Shaw, Carnegie-Mellon University Larry Best, American Management Systems Kent Beck, First Class Software
Abstract Architectures are the structuring paradigms, styles and patterns that make up our software systems. They are important in many ways: they allow us to talk usefully about systems without talking about their detail; a knowledge of them gives us design choices; attention to this level can make systems and families of systems have the non-functional properties we want, especially changeability. Each panelist will address the following issues: What is architecture? What is the value you have had so far from this concept? What is the next step for you? What is the next step for the community? l
l
l
What is the next step for you? Progress comes from taking aware steps, but what steps are those? They could be in attempting to discover and catalogue architectures; creating awareness of this level of product envisioning; doing design more consciously; finding ways of describing systems; consolidating legacy code; abandoning legacy code; making new software lifecycles. What is the next step for the community? Are there ways to work that go beyond projects and companies? Will there be focus on the community, which suggests cooperation, learning, divergence and empowerment; or on the marketplace, which suggests competition, confidentiality, convergence and dependence?
l
2 Mary Shaw
1 Background What is architecture? We all have experience of systems of great conceptual clarity and integrity. Such systems are, relative to their functionality, more easily understood and modified than others. We take this simplicity to be an expression of a powerful architecture. But note that we do not have to have a definition of architecture. Like health or quality, we can reach a productive shared understanding for the purpose at hand without making an allencompassing definition. What such understandings have been useful? What is the value you have had so for from this concept? Any value ought to include the more costeffective creation of software-based artefacts, but what are the cost drivers? Is the value in having more design choices? greater valuing of knowledge? longer-term design processes? faster learning? better communication between projects? reusable components? constraint and configuration languages? more predictable development paths? something else.7 ail of the above?
356
Software architecture is concerned with the organization of software systems: the selection of components from which they are composed, the interactions among these components, the composition of interacting components into progressively larger subsystems, and the overall patterns that guide these compositions. It is concerned not only with the system structure, but also with functionality, performance, design, selection among alternatives, and comprehensibility. The word “architecture” is used in a number of different ways. For example, we may speak of the architecture of a particular system, by which we mean the details of the design of that particular system. We may speak of an architecture, or an architectural style, by which we mean the pattern that guides the selection and composition of components and interactions for a class of similar systems, such as pipe-and-filter systems or object-oriented systems. Or we may speak simply of architecture, by
which we mean the systematic study of system-level software design. The concept of software architecture, or rather its detailed elaboration, is allowing us to move from folklore toward organized models and theories for system organization. Software designers have used box-and-line diagrams for many years to describe the overall organization of their systems. These diagrams evidently communicate useful information, because they are commonly used. However, their notation and labeling are idiosyncratic, informal, and imprecise. People regularly tell me anecdotes about how our explicit (but still informal) description of common architectural patterns help them understand past events that were previously mysterious. For about five years I have been concentrating on identifying, classifying, and interpreting the range of architectural patterns in common use. The theme of this work has been diversity: widespread claims to the contrary, no single architecture serves all needs; conversely, different applications are best served by different architectures. The development of a good theory of software architecture will: - provide software developers with the intellectual building blocks for designing new systems in principled ways using well-understood architectural paradigms. - show how formal notations and models can be used to characterize and reason about a system design. - familiarize software developers with concrete examples of actual system architectures that can serve as models for new designs. My immediate plans include developing a taxonomy of architectural styles, devising a model to explain the abstractions that govern inter-module interactions, designing and constructing a notation and tool that will support software designed in different architectural styles, and codifying design strategies for selecting appropriate architectures.
The community needs most to become more ecumenical - to acknowledge that different architectures match different problems. This will allow codification of existing folklore about architectural design strategies. It will also provide a way to understand, perhaps even to define, the domain-specific architectures that are the subject of considerable current attention.
3 Larry
Best
Architecture has multiple aspects, including: - Components and frameworks. Things that are architected (buildings and networks, for example) seem to consist of component alternatives with standard interactions that are defined within conceptual frameworks. - Focus on product versus process. Architects seem to spend much more time understanding product possibilities than the actual process of creation. This is in contrast to the traditional focus of software developers on tools, language, and methodology - process rather than product issues. - Systematic accumulation of product experience. Brownowski describes how the Masons originated as a group of cathedral architects who pooled their hard-won expertise on what designs worked. This pooling eventually evolved into the extremely systematic body of product knowledge we see today. Perhaps a mechanism for accumulating and organizing software product experience is similarly important, especially as software applications become larger, more complex, and technologically diverse. - Architectural methodology. Assembling applications from established components as opposed to crafting unique applications from scratch has some profound methodological implications extending to the most basic paradigms for software development. I have both experienced and witnessed profound benefits to an architectural approach to application software development, primarily the benefits one would expect from large-scale architectural (as
357
opposed to archaeological) reuse. Architectural understanding gives developers a common terminology when discussing their product, enables the distillation of generic design issues from application specifics, and eventually leads to availability of reusable components to support generic application requirements. The bottom-line benefits I have personally seen include greatly reduced cycle times and user problems and greatly increased productivity and user satisfaction. As Director of the Application Architecture Lab for the AMS Center for Advanced Technologies, I am participating in a significant extension of our fifteen years background with architectural approaches to application development. My part of this effort is prototyping how to present to users the interactions among a number of key generic software components, components that include managers for workflow, data interchange, consultation, search, representation, etc., as well as various generic business domain objects. I am also exploring the importance of conceptual frameworks and systematically accumulated software product knowledge to architectural reuse. The 00 community is starting to recognize mat objects and components are not the same thing. This is an essential step towards widespread recognition of the importance of architectural approaches to application software development under the object paradigm.
4 Kent Beck
\
I can’t any more think of a single definition for architecture. How about: - Post hoc; how you explain a working system - Academic; a characteristic relationship between entities in a system. - Cynical; a word coopted by programmers to justify outrageous salaries by putting it on their business cards. - Reductionist; what remains when you can’t take away any more objects and still understand the system.
- Circular; what architects do. That last one has a ring of truth in it for me. Give a problem to a programmer and they will solve it, and should be able to explain the benefits of their solution. Give the same problem to an architect, and you will receive not just a solution and its benefits, but the costs as well - it’s impact on the rest of the system, resource availability, and the schedule. Given this, I can define architecture as a fit of problem to resources satisfying functional, financial, and aesthetic constraints. I passionately believe in the micro-architectures called patterns and their ability to evolve what I am calling architectures from problems in a multitude of small steps. The one place I consistently use architecture is in my consulting practice. The first test I apply is whether the staff can explain me system to me in 3-5 objects, If they can’t, there is no explicit architecture. More often than not these projects are in trouble. When I facilitate group designs, I look for the emergence of an architecture as an important step in the maturation of the design. Before the architecture appears, everyone is edgy, trying to hold too many details in their minds at one time. At some point, someone says, “Oh, I see! The whole system boils down to one of these talking to any one of those, using any one of these things over here for storage or communication.” At that moment, the tension goes out of the room. Everyone has been able to discard a host of details elaborating the workings of the subsystems. They can afford to only understand the details of the parts they will be responsible for, I need to get better at writing patterns, making them wider and more active, and I need to articulate the relationship I see between patterns and architectures. I also need to explain why architecture can safely be allowed to grow from a design, rather than being forced on it in the beginning. We need to understand patterns better. It is only when a pattern comes alive, becomes generative, when it both describes a valuable situation and
358
Researchers can never produce the required results while their work is separated from practice. Practitioners can never reap the full potential of change if they leave things to researchers. In a design-based domain like software engineering there is a large quantity of experiential knowledge, of which artistry is part, and this is itself subject to research, to development and to increased understanding. The key activity here is to reflect on practice as it is going on, to “do” and to “look at the doing” and to “see the done”. This requires awareness and maturity on the part of practitioners and researchers, and cooperation between them.
creates it in context, that it is a compelling shared “word” in the “vocabulary” of designers. We need to catalog and communicate architectures. If the emergence of an architecture is as important as I have stated, recognizing them or recognizing when there isn’t one is a critical part of design.
5 Arthur
N. Other
Architecture is to be understood in terms of the experience of being an architect, because making architectures is a uniquely human activity. Greater technical understanding of paradigms, increased knowledge of components and computational mechanisms, improved design processes - all these provide a sounder platform for the exercise of creative artistry, not a replacement for it. “Architecture” is a word mat legitimises a certain kind of talk in the software system business: “wasting extra time on design” moves to “clarifying the architecture”; “boondoggling with that young guy from the other division” becomes “mentoring an apprentice architect”; “fooling about with PageMaker” is now seen as “augmenting our divisional Architecture Notebook”. The value (and the danger) is in the emphasis on this more powerful level of thinking, working and discussing. A handbook is an expression of the knowledge, understanding and agreement of a professional community. There is currently no handbook of software architecture available, because at the moment there is no universal, or even large, community of software architects. By attempting to write a handbook before it is time we can experiment with both exploring technical ideas, and with community-building. The Architecture Handbook project does just this. Our community is still split: practitioners often think mat researchers have all the answers, and become angry and disappointed when ideas don’t work out quickly; but also practitioners often think that researchers have no answers at all, and become angry and disappointed when me research community cannot help them with, or even appreciate, their very real concerns.
359
Despite me sober language, these are revolutionary ideas. We are proposing to conflate training, researching and doing; to move from “technology transfer” to “research integration” and to talking not about “harnessing” but “making”.
6 Biographies Bruce Anderson, University of Essex. Bruce is a researcher, teacher and consultant. He led the Architecture Handbook workshops at OOPSLA in 1991 and 1992, and has worked in industry on the role of architecture in me software process. Mary Shaw is a professor at Carnegie-Mellon University. Mary is well-known in the academic community, and more widely via her involvement at the SEI, for her work on software engineering education, and on software architecture. Larry Best is director of American Management Systems’ Application Architecture Lab. Larry has been involved in large-scale information processing for more than 15 years, and is the author of “Application Architecture” (Wiley 1990). Kent Beck, First-Class Software. Kent is a happy hacker, promoter of design excellence, and innocent-looking killer of naive ideas about software systems, architecture and patterns. Arthur N. Other, Alternative Ideas Inc Arthur is a placeholder for the as-yet unknown fourth member of me panel. Arthur may or may not present the views given above.
