The Network Architect Part 2

I got some great comments from my readers on the first part of this post. I love engaging with readers! So I thought I would write a part two to explain some of my thinking which I described in some of the comments.

Does a network architect need to be technical?

Yes, he/she needs to be technical but what does that mean? Let’s say that two datacenters need to be connected. Layer two needs to be stretched between the two DCs. The architect should be able to know different solutions to the problem such as using fibres between the two DCs, clustering technologies, TRILL, OTV and so on. Does the architect need to be able to configure OTV off the bat? Nope. Does the architect need to know what different timers OTV uses? Nope. Those are not things that need to be considered at that point in time. Now, often the architect is involved in the actual design as well and in that case the architect is involved in creating the design and documenting what commands are needed and so on. So the architect needs to be technical but not super technical.

Does the network architect need operational experience?

Preferably yes but understand that there’s no way a person can have experience with all technologies. What about new technologies? How can you have operational experience with something that you have never deployed? The architect should be able to base decisions on design patterns, good practices and experience from other technologies. Remember, most technologies are just a new version of something old. Having operational experience is definitely a plus but can’t be expected. It’s difficult to be both an architect and in an operational role at the same time. The architect has other people that can provide low level knowledge of technologies and operational experience.

Challenging customers on requirements

Arie brought up a great point in the comments. One should not simply accept all requirements and wishes from the customer without challenging them. For example, the customer asks to stretch layer two between two DCs. This might lead to the following discussion:

Network Architect: Why do you want to stretch layer two?

CTO: Our sysadmins told me that we must have L2 between the DCs.

Network Architect: What is the application that needs this? Are you migrating workloads?

CTO: Yes, we need to vMotion VMs between the two DCs.

Network Architect: What is your BC plan? What is your MTTR? What is your RPO and RTO? Why do you need to move workloads?

CTO: I don’t know. My sysadmins just told me that we need it. Let me get back to you.

Maybe the sysadmins wanted L2 because that’s’ how they’ve always done it. Maybe they think vMotion is cool. But does the business require it? Does their BC plan require them to be up in the secondary DC if the first one crashes? How fast?

Always engage and challenge the customer on their requirements to “gold plating” the design, meaning that creating a more complex design than needed that is not designed per the requirements.

Not letting technology drive your decisions

I got an interesting question from Tom. How do I keep things separate when working both as an architect and a designer? How do I keep myself from thinking like a designer when I’m in the architect role? Like I mentioned in the comments there are some things to consider here. In my head I may be thinking about different technologies/solutions to a problem but I’m not letting it drive my discussions with the customer and my decision making. Let me give an example.

Let’s say we need to build a WAN. From the beginning there are no constraints. The only requirement is that the WAN must support segmentation. So as a designer I may be thinking about GRE, MPLS, VPNs from a provider, IPSec and so on. “Oh, the GRE code on vendor X has been really funky so I don’t want to use GRE”. “I normally use vendor Y and they don’t support MPLS”. I can’t let those kind of thoughts drive the discussion. “Product Z from vendor Y can only do GRE in software so performance is really horrible”. So as the network architect I must first gather requirements and find what the constraints are.

Network architect: So you want to build your own WAN or buy it from a provider?

CTO: What do you suggest?

Network architect: What’s your experience with your current provider? Do you have the staffing to roll your own?

CTO: Our current provider is quite slow to respond and buying additional VPNs is really expensive. We are adequately staffed to take over the WAN if needed. However we don’t want to migrate off the current provider until our contracts expire in two years.

Network architect: It would be possible to build your own topology over the providers network.

So what was driving the discussion here was the business needs. If we are building over someone elses network we can’t run MPLS natively without tunneling it so I didn’t even have to think about if a vendor supports MPLS, if the code is buggy or not. It would just have been wasted brain power. You have to let the business requirements and constraints guide you and then start discussing the appropriate technology to solve it.

Long term thinking

Alan correctly noted that the architect should have the long term best for the business in mind and try to deal with technical debt. I definitely agree. I don’t work as an enterprise architect so my view is biased towards that of a consultant but I always try to do what is best long term for the business and engage with the enterprise’s architects to see where they are coming from and what makes sense long term. One should always consider what operational impact something has when designing. It’s also important to try to get rid of technical debt if possible.