Architecting and Designing


Roel Wieringa (

The GRAAL project (

University of Twente, the Netherlands

13 November 2004


This text in pdf format


Architecting is designing

Is architecting a system the same as designing it? Are all architects designers? Why do we distinguish architects and designers anyway? To answer these questions, we need to say what we mean by ``architecting'' and ``designing''. We define the architecture of a system as the structure of the system such that the system, due to this structure, has emergent properties. To architect a system is to design its structure such that the components form a coherent whole with emergent properties. And so architecting a system is designing it.

Not all designing is architecting, more or less

But is all designing architecting? Webster's defines designing as specifying an outline for action. To design is to preparation for action: by making a plan; it is to think before you act. The outcome of design is a specification what to do. You can design a chair, a house, a business process, a business structure, a software system and a holiday. In all cases, during design you analyze the problem to be solved and the goals to be reached, consider possible actions to be taken, analyze their consequences, and choose an action. Software engineers have a restricted view of design and see it as the definition of the internal structure of a program. As the above list of examples of design shows, this is just one of the many possible instances of design.


When does a design count as an architecture? We cannot turn to a dictionary to find an answer but it seems that the following two elements distinguish architectures from other designs.

  • Talking about an architecture, we always talk about components, the way they are connected, and the way this creates useful emergent properties of the system. So any design that cannot be described this way is not an architecture. The problem is that any design can be described this way. We can talk of the architecture of a system of law, of a holiday package, or of a requirements document. However, in some instances, such as a holiday package, the way the emergent properties arise from the relationships among the components is not very important. In those cases, we usually do not speak of an architecture.
  • We tend to speak of a system architecture when the system is large, complex, and requires the cooperation of several people to implement. Cities, houses and software systems have architectures; streets, rooms, and data structures have not. There is a vaguely defined lower limit of complexity below which we do not talk of architectures, although we can still talk of designs.


This gives us two subjective criteria for distinguishing architectures from designs: A structure is not an architecture if we do not describe it as a structure of components with useful emergent properties, or if we think the structure is relatively simple. Architectures are big, are realized in projects that contain several people, and involve several components that must work together to create the desired emergent properties. The architecture of the system usually corresponds to the work breakdown structure of the project.

Further Reading

A good introduction to engineering design is given by N.F.M. Roozenburg and J. Eekels, Product design: Fundamentals and Methods, Wiley 1995. Different definitions of the concept of software architecture are discussed in P. Clements, F. Bachmann, L. Bass, D. garlan, J. Ivers, R. Little, R. Nord, and J. Stafford, Documenting Software Architectures: Views and Beyond, Addison-Wesley, 2003.