PERSPECTIVES
What's the Difference Between Architecture and Design?
The question of how architecture is different from design has nipped at the heels of the architecture community for years.
Fortunately, the answer is easy. Architecture is design, but not all design is architecture. That is, many design decisions are left unbound by the architecture and are happily left to the discretion and good judgment of downstream designers and implementers. The architecture establishes constraints on downstream activities, and those activities must produce artifactsfiner-grained designs and codethat are compliant with the architecture, but architecture does not define an implementation.
You may ask, "What decisions are nonarchitectural? That is, what decisions does the architecture leave unbound and at the discretion of others?" To answer this question, we return to our definition of software architecture, cited in the preface: ". . . the structure or structures of the system, each of which comprises elements, the externally visible properties of those elements, and the relationships among them."
Thus, if a property of an architectural element is not visible, or discernible, to any other architectural element, that element is not architectural. The selection of a data structure, along with the algorithms to manage and access that data structure, is a typical example. Suppose that the architectural prescription for the data structure is that it provides programs, invoked from other architectural elements, that store and retrieve data; whether we choose a linked list, an array, a stack, or any other solution is therefore immaterial to those other elements, as long as our choice lets us meet the developmental, behavioral, and quality requirements levied on us.
"But wait," you protest. "You used the term architectural element: What's that? Are there nonarchitectural elements? If so, what's the difference?"
There may be nonarchitectural elements; their existence is unknown except to those who are outside an architectural context. For instance, a module may correspond to a work assignment for a development team; a module created under the doctrine of information hiding encapsulates a changeable aspect about the system. Modules are hierarchical entities; that is, a complex module, such as a work assignment, can be decomposed into smaller modules: smaller work assignments. Each module has an interface and an implementation. The interface to the parent is a subset of the union of the interfaces of the children.
Suppose that you're in charge of implementing module M and that, as far as the architect has stipulated, M has no submodules. Perhaps you discover that M's interface routines could all be implemented quite straightforwardly if you also designed and implemented a common set of services that they could all use. You assign a small subteam to design and implement thisthisthis what? Well, it's a work assignment, and it encapsulates a changeable secretnamely, the algorithms and data structures used by the common servicesso that makes it a module, a submodule of M. Let's call it M2:
"I get it," you say. "Because its existence is not known outside of M, M2 is not an architectural module."
It's tempting to agree at this point and be done with this, but that's not quite the right way to look at things. In some layered architectures, the layers at the top are not allowed to use the layers at the bottom; in essence, the bottom layers' services are not known to the top layers. But we would never say that the bottom layers of an architecture are nonarchitectural. The argument about "unknown outside of" appeals to a relation different from the one present in a module structure. Modules are related to one another by the contains relation, or shares a secret with relation. Whether a module's services are known or unknown by another module is a property of the uses relation, which is a different kind of animal.
"OK," you say. "So is module M2 an architectural element or not?"
I would say not, but not because it's "invisible" to the other modules outside its parent. I'm afraid you're not going to like the reason. It's a nonarchitectural element because the architect said sothat is, he or she didn't make it part of the architecture.
"You're joking," you say. "That's a completely arbitrary definition!"
Not really. The reason the architect didn't make it part of the architecture is that its existence or nonexistence was not material to the overall goals of the architecture. The architect gave you the freedom to structure your teamimplementing Mas you saw fit.
The fact is, no scale or scope or measure or line divides what is architectural and what is not. One person's architecture may be another person's implementation and vice versa. Suppose that M2 turns out to be very complicated and that the subteam you assign to it begins by giving M2 an internal structure. To the coders of M2, that structure is an architecture. But to the architecture of the system that includes M, the very existence of M2, let alone its internal structure, is an implementation detail.
Modules and other hierarchical elements[1] are subject to confusion about where to draw the line between architecture and nonarchitectural design. If you want to be tediously precise about the matter, the coding of each subroutineor even the coding of a single line of codecould be considered a separate work assignment. Of course, we would not want to consider such minutiae to be architectural: The whole point of architecture is to let us reason about larger issues. So when should an architect stop decomposing modules into smaller and smaller work assignments? One heuristic comes from David Parnas [Parnas, 86, p. 363]. He says that a module is "small enough" when, in the face of a change, it would be just as easy to recode it as it would be to alter it. Technically speaking, you can't know a module's code size at design time, but if you can't make a good guess, you're probably not the right person to be the architect for the system you're working on.
Processes and other nonhierarchical elements can also be nonarchitectural. Suppose that the architect gave you a budget and the freedom to create up to 12 tasks and that these tasks do not synchronize or interact with any other tasks outside your work assignment. In that case, we could make the same argument: that these tasks, or elements, are nonarchitectural.
"All right," you sigh. "Once more, with clarity?"
Sure. Architecture is design, but not all design is architectural. The architect draws the boundary between architectural and nonarchitectural design by making those decisions that need to be bound in order for the system to meet its development, behavioral, and quality goals. (Decreeing what the modules are achieves modifiability, for example.) All other decisions can be left to downstream designers and implementers. Decisions are architectural or not, according to context. If structure is important to achieve your system's goals, that structure is architectural. But designers of elements, or subsystems, that you assign may have to introduce structure of their own to meet their goals, in which case such structures are architectural: to them but not to you.
Architecture is truly in the eye of the beholder. And what does all this have to do with documentation? If your goals are met by an architecture, document it as such, but expect the possibility that subsequent, finer-grained design may produce architectural documentationabout a small piece of your systemon its own.
P.C.C.
|