In our architecture classes, we always spend some time discussing the difference between architecture and design. We say that architecture is a set of design decisions, so is there even a difference? In some domains, there really isn’t. In our organization, infrastructure architects generally take all infrastructure design decisions, and are responsible for the completeness of the design they deliver. Software architects sometimes leave detailed design to developers. Solution architects’ projects often encompass multiple technologies and domains, for which they cannot be expected to have mastered all the technology-specific skills to complete the detailed design work. Looking at architecture as a risk and cost management discipline (as RCDA does), the architect should focus on those design decisions that have the highest impact on the risk and cost associated with the solution.
When we ask architecture course attendants (most of whom are practicing architects) for their perception of the difference, a list similar to this one appears on the whiteboard:
|Fundamental properties||Detailed properties|
|Define guidelines||Use guidelines|
|Cross-cutting concerns||Individual components|
|Communicate with business stakeholders||Communicate with developers|
The table lists contrasting concepts, of which the one on the left is more generally associated with architecture, and the one on the right with design. The concepts are generally overlapping and not opposing. For example, some design details can have very much impact on the risk and cost of a solution, so an architect can never get away with just worrying about high-level stuff. Sometimes the devil is in the details, so the architect should look at some details – the trick is to know which ones. The fundamental properties come from the ISO 42010 definition of architecture. I think the bottom row is sort of wrong: architects should not communicate with business stakeholders more than with the delivery team, but sometimes it feels that way. The bottom row resonates with the distinction between Architectus Reloadus and Architectus Oryzus in Martin Fowler’s article “Who needs an architect?”
The last few years, I have added two rows to the table:
|Manage uncertainty||Avoid uncertainty|
The first of these is based on how we have seen typical architects and designers deal with uncertainty. When running into an item that has not been decided yet or is otherwise uncertain, successful designers usually put that item on the back-burner. They ask someone (a manager or architect) to resolve the issue, and then quickly move on to analyze the next use case or service item to keep up their productivity. Architects cannot afford to do that. Successful architects actively search for uncertainty, since uncertainty generally is associated with concerns with high impact on risk and cost, that need to be addressed as soon as possible.
The second additional contrast is Conceptual integrity versus Completeness. It pertains to the reason behind having two different roles for architecture and design. What is the main benefit of this role separation? When would you want to put one of the designers of a solution in a different role from the others, and call him architect? This only makes sense if it is too much work for one person to design the complete solution. If you need two or more persons to design a complete solution, it makes sense to appoint one of them to preserve the conceptual integrity across the whole solution. This person we call the architect, and the other designer(s) should make sure that the solution design is complete. Looking at it that way, the distinction between architecture and design is a separation of concerns. The concerns of conceptual integrity on the one hand and completeness on the other hand need to be separated, because they would otherwise compete for the scarce resource of human attention, at the expense of either one or the other.
So if you are wondering whether your skills are better employed as an architect or as a designer, ask yourself this question: how do you like to deal with uncertainty? At the end of the day, do you get more satisfaction out of a) delivering a nicely rounded, complete design, or b) chasing down unresolved issues and making suboptimal decisions based on incomplete information? If your answer is a), you are probably better off as a designer than as an architect.