What’s the difference between a network architect and a network designer? What is network architecture and what is network design? These are questions I asked myself a couple of years ago and that I get asked frequently from others. The reason I wanted to write this post is to help people that want to be network architects understand what it is about. I also wanted to help people that are studying for the CCDE to get into the right mindset. If you go in to the practical with the mindset of a designer, you will fail. You need to think like an architect.

This post is not about if an architect is more advanced than a designer. They are both needed and often they are the same person. I work as both but my title is network architect. Some people use the title to indicate it’s a senior role although the role might not be heavily geared towards design.

So what does a network architect do? And how is that different from the network designer?

The network architect is the one that is fronting the business. What does this mean? The network architect is the one that is meeting stakeholders such as the CIO, CTO, CSO, architects of the customer and other technical people and other key persons. The architect is interested in learning where the business is coming from and where they are going. What are the most important initiatives? Let me explain with a made up discussion.

CTO: We are spending way too much money on the WAN. Our WAN costs are 30% of our total IT spend.

Network architect: Have you analyzed what’s driving the cost for the WAN?

CTO: We are using a centralized internet model and 50% of our WAN cost is from backhauling internet traffic to the DC.

Network architect: In order to minimize the WAN costs, each site should implement a local internet breakout.

CSO: How will this affect our security model? Today all internet traffic is filtered at the firewall at the DC.

Network architect: There are several considerations here. It is possible to deploy local firewalls, use DNS filtering, client security, cloud proxies and so on.

What the network designer is thinking:

How to design the local breakout. How to ensure the local default route is better than the one over the WAN. How to perform NAT for the local subnets. How to setup GRE tunnels in case a cloud proxy is deployed.

CSO: We’ve had some security incidents recently where infected hosts in our office network have spread towards our servers in our production facilities. What should we do to prevent this from happening again?

Network architect: So today you have a flat topology where the office network can directly access the production network without any filtering, right?

CSO: That is correct.

Network architect: We must ensure that the office network can’t directly access the production network. This can be done by segmenting the network. Clients should have adequate protection. People that need access to the production network should use dedicated computers to access the production network. It would be desirable to implement a DMZ so that traffic into the production network goes through properly locked down jump hosts.

What the network designer is thinking:

How to segment the networks using VLANs and possibly VRFs. If and where firewalls should be deployed. Should they be in transparent or routed mode. What traffic should be allowed to the DMZ? How can endpoints be protected? What firewalls would be suitable to handle the amount of traffic in this network?

It should be clear based on the discussion above that the network architect is focusing on solutions, not products. The network designer will create the actual design and pick suitable products.

So what are the responsibilities of the architect? This is not an all inclusive list but here are some tasks the architect will perform:

  • Fronting the business
  • Gathering requirements
  • Creating a high level design
  • Presenting the design to the business
  • Interacting with network designers
  • Helping in writing business cases and other documents used to pick the direction going forward

In some projects I just act as the architect and in some projects I also act as the designer and do the detailed design with products, selecting the software, producing all of the configuration and so on.

I hope this post has given you an insight into what a network architect does and the mindset of the architect.

The Network Architect

15 thoughts on “The Network Architect

  • February 7, 2018 at 1:24 am
    Permalink

    Top post Daniel – love the clarity of the distinction between the roles, and you get it spot on for me here. Sometimes we’re one thing, often both, but there is a breadth of view to being the architect, understanding the business impact of technology choices.

    Reply
    • February 7, 2018 at 12:47 pm
      Permalink

      Thanks, Darren!

      Reply
  • February 7, 2018 at 4:57 am
    Permalink

    Daniel, thanks for the great article. The conversation format is great – I’d love to see more scenarios like this if you’re up to it. It really helps get into the architect’s mindset.

    In my career when I have been in the architect role I have always been designer and architect all in one. How do you mentally shift gears between the two roles? How do you keep yourself from mentally going down technical rabbit holes during discussions with the business?

    Reply
    • February 7, 2018 at 12:53 pm
      Permalink

      Thanks, Tom!

      Might be a nice way of writing posts if I can come up with some more.

      You bring up an important consideration. There are a few things to consider here. What goes on in my head and what I communicate can be different things. Someone at executive level is not going to understand all of the details so I shouldn’t:

      a) Bother them with details unless it fills a purpose
      b) Find a way to explain it to them so that they understand

      Now what you are asking is I think more around how I prevent myself from going to deep technology wise and not focusing on solutions. I think this comes with experience and being methodological in the approach. What problem am I trying to solve? In what ways can that problem be solved? What are the pros of cons of each method? Which one is more cost effective? Of course as I go through that process I have to give some thought to products etc but it’s not what is driving my thought process and my decision. My decision is based on requirements and constraints. After I have decided what path forward is the best then can I drill down into the technology and products.

      Hope that gives you some insight.

      Reply
  • February 7, 2018 at 7:18 am
    Permalink

    Nice write-up! I agree with it all.

    Another aspect of Architecture vs. Design is Functional vs. Technical requirements. For example the requirement to stop backhauling Internet traffic is a business level or functional requirement. It doesn’t say how to solve the issue, it just asserts a state we want to achieve. Another functional requirement would be to not reduce the security level offered to users.
    The technical requirement would be to have a local Internet feed, solve the security issues etc.

    Another important part of an architect’s (but also senior designers) role is to qualify requirements. The fact that someone (CTO?) stated a requirement, it doesn’t mean it’s what they really need. Discussing through the rationale and alternatives is a big part of the role.

    Reply
    • February 7, 2018 at 12:56 pm
      Permalink

      Great hearing from you Arie and fully agree.

      Writing documents like a customer requirements document may not be flashy but they serve a purpose. What are the requirements and constraints that are the input parameters for the design? This document should not be a “wish list” from the customer but drive the discussion and like you said it’s important to challenge them on the requirements.

      I try to think at business and functional level first but sometimes the requirements relate a lot and it may be difficult to qualify a requirement as business or functional but the most important is to catch them of course.

      Reply
  • February 7, 2018 at 9:07 am
    Permalink

    Sorry but I don’t agree entirely. An architect who doesn’t know the details will create an unsolvable spec for the designers to nut out. A good architect knows enough detail to not propose a high level solution that is unworkable or impractical on the details and has already hedged his bets on a lot of the actual workings. Too many people these days flaunt the title without the technical chops. Just my perspective

    Reply
    • February 7, 2018 at 1:00 pm
      Permalink

      Hi,

      We don’t disagree. It’s my firm belief that architects that come from a strong technical background and has some operational experience have a better chance of succeeding in their role. That has certainly been my path and many others although there are always exceptions.

      I’m not saying that an architect shouldn’t be knowledgable about details but it’s not what should be driving the discussion. So for example say that we are tasked with building a WAN. Now, maybe I know that a feature is horribly broken on a platform. So I don’t want to build it with that feature but that is not what should drive my decisions. I first have to go through what is required and what solution is the best. Then I can go into details and mention real life experience etc if I think that there’s a risk with going forward with a solution.

      Reply
  • February 7, 2018 at 10:36 am
    Permalink

    Very clearly explained about 2 roles.
    Good job.
    Welldone.

    Reply
    • February 7, 2018 at 1:01 pm
      Permalink

      Thanks and thanks for reading!

      Reply
  • February 7, 2018 at 10:48 am
    Permalink

    He Daniel,

    Great article but I believe you missed one very important aspect that I firmly believe to be part of the architects role.

    In your description the architect is purely reactive to the business (not uncommon if you come in as a consultant).

    However architects could/shoild also be proactive and try to understand new technology and where they can benefit the business.

    In your WAN example the architect could also be steering this by informing the CIO that developments like SDWAN could possibly lower costs, but would need some PoC to confirm this.
    And the same applies for the CSO in relation to CASB/cloudbased SWGs.

    By being proactive and taking the long term view I believe as an architect you can add value without getting stuck in every hype or building up debilitating technical debt.

    Oh and the architect should keep track of the technical debt that needs to be resolved or that is being accrued..

    Any how thanks for the write up really appreciate it.

    Regards.

    Alan Wijntje

    Reply
    • February 7, 2018 at 1:03 pm
      Permalink

      Hi Alan,

      I definitely agree. Since I don’t work for an enterprise my view is biased towards coming in as a consultant. But even then it’s important to think long term and engage with architects at the customer and find a long term solution that solves problems and makes sense operationally as well.

      Thanks for reading!

      Reply
  • February 7, 2018 at 1:56 pm
    Permalink

    Great article, Daniel.
    I really value the clear terminology and this post is a wonderful example of this clarity 🙂

    Reply
    • February 7, 2018 at 11:06 pm
      Permalink

      Thanks, Sergey!

      Reply
  • October 22, 2018 at 1:23 am
    Permalink

    My brother is planning to launch his startup tech company and needed to have a good network design. It was explained here that network architecture is needed in a company because they meet the stakeholders. Furthermore, it’s recommended to hire professionals for quality network architecture services.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: