Tom Graves / Tetradian

This topic came up in a discussion on LinkedIn, in which Ron Segal asked “Why are we shy of ‘design’?“:

As an observation, the business and enterprise architecture communities seem remarkably reticent to use the word ‘design’ to describe what we do (e.g. see this group’s ‘what do you do’ discussion). Why is this, as although not all design is architecture, isn’t all architecture design?

There’s a lot of confusion between the two terms and the respective business-roles, so I thought throw in my own view on this, as follows:

Architecture and design are closely related; the main difference between them is really about which way we face.

Architecture faces towards strategy, structure and purpose, towards the abstract.

Design faces towards implementation and practice, towards the concrete.

Most designers and architects will do both types of work; but most will describe themselves as either a ‘designer’ or an ‘architect’ according to which way they most often face.

Architecture without design does nothing: it can too easily remain stuck in an ‘ivory-tower’ world, seeking ever finer and more idealised abstractions.

Design without architecture tends toward point-solutions that are optimised solely for a single task and context, often developed only for the current techniques and technologies, and often with high levels of hidden ‘technical debt’.

Both architecture and design are essential. We may only arrive at appropriate, useful, maintainable solutions when architecture and design are both in use and in appropriate balance.

One of the reasons that good architects are relatively rare is that, to work well, the architecture must cover an ever-wider scope, linking across more and more domains, yet still remain grounded in the immediacy of everyday practice. Designers need only focus on the single task at hand (though it always helps if they pay attention to proven architecture principles such as re-use, re-purpose, consistency and so on).

There are plenty of good designers out there; and a good architect will know how to identify, use and respect their skills. Unfortunately, many designers – even the good ones – often regard architecture as a hindrance to getting the job done. Which, from that perspective, it is – if the only focus is on getting the job done, without consideration for the purpose or appropriateness of the work in the first place… Good design is about doing things right; good architecture is about ensuring we’re doing the right things; we need both to ensure that we’re doing the right things right.

Domain architecture – such as process-architecture, applications-architecture, security-architecture, technology-architecture – constrains the architectural scope within predefined bounds. It keeps the architectural discussion closer to the practicalities, but still needs an overlighting ‘higher-level’ architecture to link it with other domains. In the business context, this is the proper meaning of ‘enterprise architecture’, as the architecture of the whole enterprise – and not solely of the enterprise IT.

By definition, the skills of a designer should lead to practical, concrete results, and hence should be amenable to training and certification-type evaluation.

By definition, architectural skills may cover almost any scope, and hence are not amenable to simple certification. One unfortunate result is that there is no easy way to identify a good architect other than by their work-history, experience and overall attitude: certification indicates only that the person has some grasp of theory, but not necessarily of practice.

All of the above applies to all forms of architecture and design.