top of page

A Security Architect: The Key Attributes

I’ve been doing a lot of thinking lately about my years in Information Security. I think it’s pretty normal for people my age with my years of experience to really start to reflect. And honestly, no matter what your age or years of experience, I think you should always be doing at least some level of reflection on what works, what doesn’t, and what you may want to do in the future (and of course, what you don’t want to do).

For me, I sense a change in my near(ish) future. I don’t know when and I don’t know where but I suspect my 10 years of bumbling around in Security Architecture are winding down.

Naturally, that got me thinking about what has made me a decent architect and what the key attributes are of a really successful one.

As we all tend to put things in buckets or categories, I’ve attempted to create some. I think there are two: Technical and Personal. One can play with these categories and think about ways in which there are overlaps and differing levels of inclusivity and exclusivity but I’m going to just leave it at these two buckets and move on with my life.


Networking. You have to know the basics for starters. How do networks work? Why do networks work the way they do? What are routers, switches, and hubs and what makes them different? Understanding what the OSI model is and how the different layers work is essential. TCP/IP is probably the single most important thing to know in my opinion. I think you have to know how to subnet and I think you have to know the basics of layers two through seven. Having had experience in the CLI and having dug into a network flow in Wireshark is an incredibly valuable experience.

Programming and Software. Some people start programming or scripting. Some people, like me, only learn the basics so they can function at work. A strong architect has to be familiar with programming languages like C (most CS courses start you in C or Assembly from what I’ve seen ) or object-oriented languages like Java. My take is that once you understand how syntax works you can translate that knowledge into almost any language and at least understand how it works. I’ve seen people take their programming knowledge and translate that into Python, Ruby, or Go products with little foreknowledge of the language. I’ve found programming to be the skill that many architects have in the least supply; myself included.

Endpoint. Knowing and understanding how the client and server function in an environment is an absolute must. I would include databases in this client-server model as well. One needs to have a working knowledge of Linux, Unix, Windows servers, and clients; I’m including Active Directory in that list. It’s important to understand how an OS works at the kernel level, how memory allocation works, and how it interacts with applications and calls both local and remote. Knowing the difference between kernel space and user space is important. It’s helpful to have been a system administrator in some capacity but I’m slightly biased. Understanding what the introduction of a platform to your environment means to your users, your apps, your network, your risk profile, and how you'll manage it is one of the most important things to grasp as an architect.

Communications. Having spent a few years doing Unified Communications (UC) I’m a tad biased here. And maybe one can make the argument that UC/Comms goes into the Platform bucket or the Networking bucket. Maybe yes. Maybe no. But once you understand UC, you’ll be able to make that argument. Either way, I think it’s important to understand communications protocols (SS7, h.323, SIP) and platforms (Cisco's CUCM, Avaya's Aura, etc). In my experience, there are few enterprise architects that can really dig into a comms platform. It’s critical to do so as so much of our enterprise risk is held in customer support platforms be they call centers, help desks, chat support, video support, etc.

Hardware. There’s no doubt we’re running our enterprises on software. I still contend, however, one has to know the basics of how hardware works. Understanding how things like memory, chips, storage, and peripherals work is important when being asked to design for a complete picture.


Education. I’m in no way saying you need a formal college education. Yes, that helps. I personally think there’s value in a traditional 4-year education and I also think if we’re talking about college education, a liberal arts education is a great thing. What I value and think is most helpful is a well-rounded individual. One who is able to talk about art, science, philosophy, public policy, history, economics, literature, and sports. Yes, one is exposed to those things while matriculating at a liberal arts college but again, while there is a correlation, there is not necessarily causality. Bottom line: find me a person well-read and conversant in the topics above and I’ll show you someone who has a leg up on the competition.

Social skills. It’s hard to be an architect and not be social. So much of what you do involves meeting and greeting. All of this socialization can be challenging for many in any field let alone InfoSec where so many of us tend to be anti-social. But you have to do it if you want to be successful and grow. Here are a few things I think are key:

  • Take meetings. If you’re invited to have drinks or dinner, go. If someone wants to have a 30-minute call to share their product with you, try to take it. Think of it as an opportunity to showcase your knowledge, skills, and abilities. The idea here is you’re either going to learn something for a project of yours (present or future), you're going to gain some nugget of information, or you’re going to meet a colleague who can help you later in your career (or vice-versa).

  • Form alliances and friendships. I don’t mean to be too obvious here but we all need friends and supporters and it’s good to be a friend and supporter to someone else. Alliances and friendships are needed in our projects tactically and we need them to build a career. I will point out that I’m drawing on Dale Carnegie here when I say you have to be sincere and your motivations have to be driven by honesty and forthrightness. If you want to get into some Machiavellian nonsense I’d say go read another post from another author.

  • Maintain a network. People that you can call for help are essential. Be accessible. Call people. Shake their hands when you see them. Keep in touch. But again, keep it sincere.

  • Honor social norms and have good etiquette. One of the things I noticed doing this job is how much time is spent over drinks, coffee, and eating. I’ve spent some days going from a coffee, to breakfast, to tea, to lunch, to afternoon beers, then to dinner, and then to evening drinks (this was one actual day). I’m also amazed by how many different types of people you meet in a variety of different circumstances. All this requires one to maintain social norms; and manners. Knowing the time and place is essential. Knowing what fork and spoon to use and when is good. Knowing how to order things at a bar or restaurant is valuable. Knowing what to wear and when can help make you look professional and prepared. On the flip side, working without these things can put a real damper on your career. I’ve worked with plenty of people over the years who were plenty talented technically. But socially, they were a disaster. They were excluded from sessions because they simply couldn’t function socially. 2

  • Limit gossip; stay positive. This bit of advice applies to work and life in general. An enterprise-level architect is expected to be a bit of a leader. You can’t lead if people know you’re a gossip. Of all of the traits that raise yellow or red flags with me, gossip is top of the list. Gossips are poison in a workplace, on a team, and in a friendship. I’ve found most gossips are also negative people. Either way, gossip is simply poison. Don’t do it. I’m glad I cleared that up. 3

  • Be collaborative. Whether it’s a Pre-Sales, Post-Sales, Enterprise, specialty, or some other type of Architect that I’m not thinking of, an architect has to be collaborative. One has to be able to lead a group, participate as a member of a group, gain consensus, and generally work with others to achieve a solution.

Curiosity with an open mind. Speaking generally, I find this to be a valuable trait for humans. When it comes to architecture, resting on designs from bygone eras can introduce cost, inefficiency, technical debt, and increased risk. Exploring new solutions, new ways of doing things, and being open to change are key attributes of a solid architect.

Solid presentation, writing, and speaking. Presenting and speaking one-on-one to presenting and speaking to large groups is a requirement of the job. Writing is also essential. I’m always looking to improve both written and oral communications and I’m always looking to hone my visual presentation skills.

Business acumen. I saved one of the most overlooked aspects of a good architect for last. Remember that a good architect needs to take a business requirement(s) and expectation(s) and create a solution that meets those requirements. This involves a familiarity with the business aspects of a technology integration. What are some of those things?

  • How to gather requirements and set expectations. What are the differences between the two?

  • How to run an RFI/ RFP

  • How to work with procurement

  • How to work with manufacturers and service providers on margins

  • Understanding how vendors, resellers/SIs, and service providers work and are structured

  • How do margins, discounts, and non-standard pricing arrangements work

  • How do maintenance and support contracts work

  • How do operational and capital expenses work

  • What are depreciation and amortization and how do they apply to technology

  • What is technical debt and what does it mean to the business?

Being a Security Architect is a fun and challenging job. One of the things I enjoy about it is how multi-faceted it is. There’s a lot to do and know across all the technical domains. At the same time, having the so-called “soft skills” and business skills is essential. I’m hopeful this brief synopsis of what I think those skills and abilities are has been helpful. Naturally, because I’m collaborative and have an open mind ;-), I’d love your feedback!

Notes and Comments:

  1. Brian, you left out “cloud.” I don’t think I did. It’s a platform made up of systems, containers, communications protocols, and programs.

  2. I once had a meeting with reasonably important people in Washington, D.C. After that meeting I called my mom while walking down H. Street to acknowledge and thank her for instilling in me good table manners. I can’t stress how much business gets conducted over meals. It’s staggering at times.

  3. I once supported a CSO that always answered the “How are you” questions with “I’m great!” Once I asked him about that on a day when we were not great. He paused and shared some stories from the life he’d lived, the family he had, the children he had raised, the wars he’d fought (literal wars, not metaphorical), and just general good times and bad. He said, “Brian, just for that moment, everything is great. I believe it. You believe it. It’s almost like an island; just for that moment.” I like that. I’ve tried to emulate it.

bottom of page