Architect or Designer?
Are you an architect or designer? What’s the difference? A reader asked this last week in email — my (probably) less than perfect response.
First, we have to dispense with this objection — network people aren’t “architects” in the first place. Nor are they “engineers.” Okay, so… A challenge: what else would you call someone who designs and builds things? When someone says, “You’re not a real architect, because you don’t build buildings, and you’re not held responsible for your work,” I tend to reply, “Why are you talking to me if I don’t exist?”
I’ve probably spent a lot more time than most people thinking about what the difference between design and architecture is, as it was a major issue when the CCDE and CCAr were split into two certifications (long ugly story — but then again, whenever marketing is involved, it normally is). With the help of some psychos (psychometricians, actually, but saying you worked with psychos for seven years to develop certification just sounds cooler somehow), we came up with some differentiators that I think are useful.
The difference is in focus, not task — the designer focuses on a solution to a narrower engineering problem, the architect focuses on a solution set to solve a business problem. To put it a different way, network designers focus on the seam between technologies, while network architects focus on the seam between people (or business) and technology.
To give some practical examples…
The network designer pushes back on technology choices; the network architect pushes back on the business itself. To put this another way, the network designer tries to understand what the business is trying to do; the network architect tries to get in front of where the business is going. This is why the CCDE is a practical in a lab, but the CCAr is an actual encounter with “a customer.” Candidates who don’t push back aren’t supposed to pass the CCAr.
The network designer looks at a technology toolbox and asks, “what fits?” The network architect looks at the underlying problem space, and says, “what sort of tool would fit here?” Once figuring out the shape of the tool, the architect can then go out and find the tool, rather than getting trapped in the current toolbox. For instance, I expect a designer to know when to implement EIGRP and when to implement IS-IS. I expect an architect to look at the problem and say, “this requires a control plane with characteristic x,” then to go find out what those solutions are, rather than assuming a tool he already knows is the right one.
The network designer can explain the idea, the network architect can sell it.
The network designer asks, “how can I build a fabric with 5 9’s of reliability?” The network architect asks, “based on these requirements, we need a fabric with 5 9’s of reliability,” or even, “I know what you read in a magazine on a plane, or what you received from someone in email, but we really don’t need 5 9’s of reliability, and here’s why…”
When looking for an architecture, I’m looking for goals that can be and are broken into smaller parts, and why those goals are important to the business. I don’t want to solve the goals, I want to know what they are. When looking for a design, I’m looking for how to solve the goals.
In reality, most network architects can do design — they wouldn’t be very useful if they couldn’t. But if you want to move from being a designer to being an architect, you need to learn to push back and to challenge, to see the shape of a technology that’s needed rather than just choosing something you know, and you need to ask why rather than how.
To truly cross into the architecture world, the designer needs to cross the boundary between technology and people.