19 comments on “Network Engineering vs Network Architecture

  1. I have to say, when I switched from being a hands-on engineer to an architect, it was one of the more difficult transitions I made in my career. Sit me down in front of a router and ask me to configure something and I’m fine, but it’s a far harder thing, even with years of experience, to work almost entirely on paper. The further you get from hands-on work, the harder it is to be an architect. Also, there really aren’t very good resources out there. I found a couple books on architecture, but most are not too helpful. Most CCDE resources were not specific to architecture, but were just technology books. Of course, to be an architect you have to master the technology, but there are architect-specific skills as well.
    Interesting post. I like the focus on the parallels with building architecture and engineering!

    Regards,

    Jeff M., CCIE #14023 (R&S, Sec)

    • Jeff, thank you for your comments. I really appreciate your feedback as one who has transitioned from Engineer to Architect.

      I think all engineers have the same dilemma when transitioning to architecture. We worked hard for a long time to acquire the hands on skills that we have but now we have to learn new skills which are much more obscure than the black and white reality we are used to.

      This is why I also think as the enterprise architecture profession becomes more refined we will start to see a more direct path towards the architecture profession. The inevitable delima is that architecture requires a foundation understanding of engineering thus why most Cisco design certifications require an engineer certification as a requisite such as CCNA/CCDA and CCNP/CCDP. The approach that Cisco seems to be taking is a career path through the professional level certifications as a baseline and then you can choose your expert level branch, either engineering or design, now with the CCDE program. However, by all accounts the CCDE requires a significant CCIE level experience and back ground.

      The goal of this blog is, as you stated as well, is the evaluate the similarities and contrasts between engineering and architecture. Further, I would like to have a solid definition and understanding of what constitutes high level network engineer and architect. Once we understand and agree on what roles the two sides should fulfill and what skills they should posses we can then look at the career progression of each and identify a clear path in the development of each. In other words Architect to end state.

      • The difference between architects and engineers is that architects decide WHAT to do while engineers have to make it happen and decide HOW.

        The problem with the certification tracking that says you should be an engineer before you can be an architect is that the skill sets are very different. I haven’t been able to configure a switch or a router for years, don’t remember syntax Etc. On the other hand I have designed some complex networks in that time. I can wave my hands and say “an appropriate routing protocol will take care of this” and rely on my engineer to tell me which protocol and how to configure it.

        Getting to be a good engineer, like a good low level programmer, requires attention to detail. Architecture requires the ability to see the big picture. Hard to do do both at the same time.

      • My thoughts exactly. Hopefully as the profession becomes more refined we can help upcoming technologist to clearly identify their different options and help them move towards the specialization that fits them best. However I do think that network architects will always require an engineering background and baseline understanding but the reverse will likely not be the case for engineers.

  2. I’ve held both titles at various times. My interpretation is that the pure architect draws it, while the pure engineer builds what the architect drew. In reality, I’ve never seen those roles be quite so pure. I’ve never not done architecture just because my title happened to be “engineer”. The reverse is also true.

    I’ve avoided becoming a pure architect, for the same reason I don’t especially enjoy being a people manager. Those roles distance me from the experiences gained when implementing a design. My best architecture work has come as a result of lessons learned while engineering.

    Now, I’m speaking in the context of network architecture. I believe the best network architect is one who is multidisciplinary. Similar to the list you articulated in one of your other posts, I have a list of other certs I’m going after to try to round myself out a bit. I feel as if I’ve lost sight of the larger IT picture by doing “all packets, all the time” for the last several years.

    • Agreed. My summary of the two is:
      Engineering 101: Reduce the moving parts. Build and spec the most efficient mechanisms possible.
      Architecture 101: Architect to end state. Identify where you want to be and build a road map to get where you are to where you want to be.

  3. Good post, and good comments.

    I think that in today’s networking world, the architect title is like being given a black belt in network engineering. Within your organization, the architect or architecture team has demonstrated a master understanding of the technologies that are important to the environment. They have a vision of where the network needs to go and how to get there. They may be right or they may be wrong, but they are given the challenge and they accept it and the risks that come along with it.

    Again, it’s organization specific – the architect role in one company usually cannot be directly compared to that of another company. This comes about due to technology and business differences between the companies, or can be a result of differences in the talent level between the two networking staffs. The network architect at company A might be considered grossly unqualified for the job at company B.

    So I would say that the being an architect comes down to how much faith the company has in you and how well you’re able to deliver. To be successful, you need to show that your vision was correct which can only happen in hindsight. It’s kind of like being a head coach or general manager in professional sports. You’re given the opportunity, now let’s see what you got. If you fail (your vision or approach was wrong and resulted in a undesirable end state), you may move on to another company as a network engineer or perhaps get another shot at architecture.

    In summary, the architect NEEDS all the same fundamental knowledge and experience that a good network engineer has. The difference is that the architect is able and willing to take the lead with their vision, whether right or wrong. Not all engineers can/want to do that. So I think the difference is less technical and more personality driven.

  4. Very interesting post. To me this is more about habits of mind than skillsets per se. Many people (including most engineers) learn “bottoms up” and tend to prefer to solve problems the same way, starting with a set of known facts, tools and conditions and building from there. Top-down thinkers, on the other hand, typically start with a desired future state in mind and reverse-engineer the solution. Often in doing so you find there are gaps that aren’t readily filled with standard tools or approaches, so you have to go figure out a workaround, or else develop a solution from scratch. This isn’t, emotionally, a particularly big deal to most “top-downers”, it’s just something you naturally have to do on the way to getting to where you’re going. But it often causes a fair amount of angst in engineers, who spend years being trained to think, “But how will we do it? Think of all the difficult things we’d have to do that depart from known, proven practices! How do we know, absolutely, it will work reliably? It could all go horribly, horribly wrong!” That risk aversion can be unlearned with practice, but it’s neither quick nor easy.

    To go back to your medieval cathedral master builder analogy–cathedrals were built over many generations. Architectural shifts occurred very slowly, and the underlying structural changes could be worked out gradually, via trial and error. People working in one city could learn from work being done in another that might be a bit further along. The two very different mindsets I described above were somewhat irrelevant. There was a sudden shift, though, at the beginning of the Renaissance, both in architectural style and also in the backgrounds of the architects. Neither Brunelleschi, who constructed the biggest dome of his time in Florence, nor Michelangelo, who later took many of his ideas to Rome, had any hands-on building experience. They were artists, people who by temperament were driven to seek out new ideas or to apply existing concepts in new ways, and who weren’t so embedded in doing things a certain way that it limited what they could imagine as possible. As sculptors, they had a solid understanding of structural stress, but they learned the details of brick production, joining, etc on the job from their workers (and even there, in several cases, thought of improvements).

    Finally, there’s the matter of personal valuation. Engineers generally value themselves and (importantly) each other on depth of specialized technical knowledge. That’s not fundamental to an architect’s job: breadth is, understanding interconnections and interdependencies is. To shift from one to the other requires letting go of much of what you’ve prided yourself and built your reputation on being “good at” and ceding that to others so that you can focus on–and get good at–other things that require a more generalist view.

    • Excellent reply! That seems to be one of the major differences between true architects and engineers. An engineer is focused on getting the most of of what they have now. An architect can see what the solution should be and the designs a path to get there.

  5. Great post and discussion. I was actually looking for articles about the differences between the two myself and stumbled upon this page.

    From what I’ve experienced so far, this is how it breaks down to me.

    In the traditional sense of “architecture” vs “engineering”, the terms stem from the construction world as you so pointed out. However, up until 2 or 3 years ago, there was no such thing as a “Network Architect” … at least in terms of job titles for the broader market. Yes, I have heard of a “lead architect” of some network or ISP, but that person was still an network engineer (probably the Sr. Engineer). The reason why is because without the very low level of understanding of networking and inter-networking, there’s no possible way to have a vision of “what can be” as an architect due to the difficulty of understanding _all_ of the emerging network technologies that are constantly changing and evolving.

    That said, a true network architect to me would be someone who doesn’t just drink from the “green” Cisco kool-aid, or just the “blue” Juniper kool-aid or (insert vendor of choice here) kool-aid. A true network architect should be able to take the best of any and all vendors in a given market space and give a true design of a network system that is heads and tails above anything most engineers have ever seen. Vendor X excels at doing task A, but vendor Y is much better at accomplishing task B. Task C needs a completely different approach, so open-source foundation Z gets the nod for it.

    Over the years, I’ve tried to diversify myself in as much technology as possible to come up with the best possible solution and design as I can possibly deliver. Be it all Cisco, Juniper, HP, etc or some combination of vendors.

    I think with Cisco and Microsoft branding an “architect” with giving them a silly new acronym is really just that, a silly new acronym for marketing purposes. While I may be a CCIE, I think all this new “architect” talk and branding is just another way for vendors to top the last great thing they have to offer and make money off of something that already exists. Does the word “cloud” ring a bell anyone 😉

    Congrats on your CCIE Brandon! I’m on a mailing list or two with you and will be following you blog from now on. Again, great post!!

    • Thanks for feedback. I agree with your points and yes I am getting so sick of hearing about “the cloud”, for more read my latest blog :D. I do have two small differences of opinion but I very much understand where you are going.

      First, on vendor selection, it has been my experience that choose vendor A for features X & Y and vendor C for feature Z may have its benefits but in moderation. Something I have become more aware of recently is the huge downside to trying to select the best vendor for every requirement. This sort of mentality results in a hodge podge network of half baked designs and partially implemented strategies (this comes from personal experience in our merger with United Airlines).

      I prefer aligning yourself with a vendor and utilizing to the full the features that vendor offers and only going to another vendor when there are obvious and major advantages. For example, at Continental, we chose to be completely a Cisco and Microsoft shop as long as those vendors had competitive solutions in a given space. This has resulted some very nice synergies and when things have not worked out as the ‘marketecture’ promised we can hold those vendors feet to the fire. We have chosen to use other vendors in a given space when there is an obvious advantage, one such example is our choice to use F5 for load balancing.

      So, I do agree with your point that an Architect should be surveying to full landscape of options without any preconceived bias towards any particular vendor. On the other hand I am very wary to get into a discussion about always trying to select the best point product for every need. When my incumbent vendor has a competitive solution in that space, I would much rather leverage that solution and maintain synergy. There are obvious advantages to this approach as well with staffing, you can train and develop your stuff much more efficiently the fewer vendors you have.

      The other is on the ‘Architect’ title. I agree 100% that currently it is more of a marketing gimmick than anything however I am not sure that it should be nor will it always be. As technology becomes more and more complex there need to be individuals who can re-simplify it. If you think of it, as we progress, we should be getting more done with less… right? Everyone has this assumption that networks are constantly getting bigger and more complex. I see it the other way around, I think we should be learning from the past and building networks that are simpler but much more scalable.

      Admittedly it takes a lot of wading through complex subjects and clunky protocols but I believe true Architects should be able to simplify the mess. There is a huge perception of complexity, as Architects, I think we should be able to boil complicated issues down to their basic components and using very straightforward methodologies build simple, straightforward designs that bridge current state with end state.

      This requires several skills that most engineers have no aspiration to attain. It requires a hands off approach and a lot of abstract thinking and white-boarding. It takes patience and a lot of good communication. In short, I believe that the Network Architecture profession has a LONG way to go and those of us who have risen from the ranks of engineering and aspire towards becoming Network Architects, we have a responsibility to forge a path for the next generation. To break down what appears to be a very complicated subject to its base components and determine the skills and experience that best fit the ideal persona of the visionaries that architects should be.

      • Hi Brandon,

        I completely agree with you about keeping it simple and staying the course with one vendor. That would have been very nice on many of the projects I’ve worked on in the past. I am all about the most simple, elegant solution possible. However, in an ISP environment, being able to do both of those is sometimes just not possible.

        I should clarify my remarks about the vendor selection with the best gear. I was referring to when you do not have an option with your main vendor. In the days before the ASR/Nexus lineup, Cisco had NO answer for a 2U or 4U solution that would take 7 or maybe 8 full v4/v6 BGP tables (millions of routes in the RIB), and 120 or so eBGP peers (accepting only local routes). I don’t count the 6503/4 because it just doesn’t do edge peering as well as many other solutions and had problems when we implemented it. We had to turn to Juniper to get the job done. In other cases, customers with Motorola, Adtran, Lucent, etc gear doesn’t want to purchase new equipment just because we couldn’t turn up OSPF between our edge boxes and their CPE for their L3 VPN. Unfortunately in the ISP business, “make it work” is the only option you have or you do not get the customer.

        On the architect branding though, I agree 100%. It still has a long way to go with the definition of that role and how to distinguish between it and an engineer. I do hope that the vendor certification eventually comes around to be something meaningful so that those of us that do have to step outside of our comfort areas and make decisions about solutions can obtain a cert that puts meaning to the title. I think that the “architect” term is more for marketing purposes right now but I do think it has the potential to really bolster the industry which makes it better for us all!! (Paycheck included 🙂

    • Currently, a good background understanding of network engineering is critical. Once you have that discipline down you can obviously work vendor design tracks (such as Cisco’s CCDP) and additional training around TOGAF, SixSigma, etc. Check out Links and Resources on my blog (https://ccie31104.wordpress.com/links-and-resources/).

      Once you have a solid grasp of the Architectural process you could then proceed to Cisco’s expert level design tracks, CCDE and eventually CCAr.

    • I look at any certification as a structured path to learning something new. The certification itself is only good for getting past recruiting screens and getting potential job interviews. After that, it’s simply a matter of what you know. How fine tuned are your skills. At the end of the day what will earn you a paycheck is having a skill in demand.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s