Preface

During Mid-Autumn Festival I got a rare chance to hang out with some friends. Watched the sunset, went camping and barbecued, drank and chatted until we were half asleep. Hadn’t seen each other in a year, yet nothing much had changed. Time waits for no one — two days flew by in a blink, and we said our goodbyes with plenty left unsaid. Hoping we find more chances to get together down the road.

Most of my previous posts have been about technical experiences and solutions, without much discussion of the friction involved in actually rolling things out. But engineers who’ve been through similar trenches can spot those problems at a glance. Anyway, it’s a fine autumn weekend, so I’m taking the chance to jot down the pain points I’ve been keeping notes on.

What a Security Architect Actually Does

Let’s start with the main responsibilities of a security architect. Broadly three buckets:

Risk Identification (Asset, IT, Infra, Cloud, Application, Data, Business, Legal, Compliance, etc.)
Security Design (Strategy, Policy, Architecture, Process, Workflow, etc.)
Security Consulting (Requirements review, Architecture review, Other)

On top of that there’s Security Governance, cross-team collaboration, balancing Risk and Effort, and Project Management, Cost Management, Risk Management and so on. At large companies each of these areas might have its own dedicated team with everyone owning a narrow slice. At smaller companies, if a security architect only has to deal with the above, that’s already a blessing — you might also be doing Security Product Design and even Deployment.

Now that the job scope is laid out, let’s dig into some real problems. But first, think about this: how do you use a model to actually ship all these design outputs? If you were the lead of the security architecture team, where would you take it?

Problem Areas Worth Thinking About

How do you make internal and external collaboration actually work?
First, draw clear boundaries (scope of responsibility). Second, establish processes (collaboration mechanisms and progress tracking). Third, communicate effectively. But keep in mind — boundaries are rarely absolute. Also, when defining boundaries you can organize them by security domain (Security Technology — Infra/App/Data), but when it comes to implementation, org structure should be your reference (e.g., Network & Cloud Security team, Security Platform team, AppSec team, Security Operations team, etc.). Say the security architecture team is responsible for producing output based on the work areas above — taking on internal security initiatives, providing constraints and guidance to other teams on delivering capabilities in a consistent way, and on the external side, enforcing policy and process constraints that pull business teams into the flow (e.g., applications go through SDLC, data goes through data governance processes). Internally, if a team is capable of designing their own solution, the architecture team ideally shouldn’t micromanage — just offer review-level feedback. If they can’t, then work with their capabilities to co-deliver a solution. Externally, if a business team won’t accept your collaboration or your proposal, you either provide alternative measures, route it through a special approval process, or make them own the risk themselves. But whether it’s a special process or accepted risk, there has to be a time limit and a higher bar — for example, special approval needs VP sign-off, and risk can’t persist for more than 3 months.
How do you communicate effectively?
Don’t be a blocker. Don’t act superior. Don’t assume the other person follows you. Don’t take things for granted. Don’t be a show-off. Don’t be oversensitive. Respect the other party’s principles. Most importantly — don’t run into someone impossible. Always explain things clearly and confirm whether the other person understood, and understood the same way you did. Even then, what was agreed in the meeting might come back to you in an email with their own reinterpretation. When someone’s just not on the same page, don’t rush and don’t get angry.
How do you measure results?
Security Consulting is relatively straightforward to measure — similar to security operations: volume handled plus quality assessments. For Security Design and Risk Identification, it’s more about tracking at the project level. For rework of existing systems you can at least show before/after comparisons. But for greenfield projects, meaningful metrics get sparse — though you can look at cost optimization, degree of automation, and so on. You can also eventually use some quality indicators from security operations as a proxy for architecture quality. I’ve had several conversations with my manager on this and we haven’t landed on a good answer. If you have thoughts, I’m all ears. Whether you approach it from “risks addressed” or “capabilities delivered,” neither gives you a clean measurement. That’s one of the clearest differences between architecture work and operational work.
How do you pick the right technical solution?
There’s no “best” solution — there’s only the most suitable one for your company. A lot of services and products publish Best Practices — AWS Security Best Practice being an obvious example. These are the product of accumulated technical insight and real-world experience, and they’re genuinely valuable. But that doesn’t mean you should just follow them wholesale because someone else published them. What I actually prefer looking at is Reference Architecture. Concretely — the design of any solution should start by asking whether it fits your business requirements and how much it costs the business to adopt (does it require changes? does it take significant ongoing operational effort?). You also need to assess whether it fits your current infrastructure and whether it satisfies existing system architecture constraints — things like service interaction patterns (in microservices: Broker/service discovery/Sidecar, or API Gateway/BFF, etc.), deployment environment (on-prem, private cloud, public cloud, multi-cloud, hybrid), and architectural standards (does it support HA, TLS, Audit, Monitoring, Backup/Recovery — does the application architecture fit existing patterns like microservices vs. traditional, circuit breaking, service discovery, config management — and so on at the data and network layer). In practice you constantly hear things like “Competitor X is using this solution,” “My last company was running this,” “Based on my experience this is how it should be done” — you name it. There’s also the gap between what buyers need and what vendors sell. Vendors in attack/defense spaces tend to come up with all kinds of creative plays (e.g., Aqua’s container and infra scanning, or the various SASE, SOAR, ASM, and CSPM products out there). But in operations, SDLC platforms and similar tooling — everyone has their own ideas, and a product that looks feature-complete and process-complete on paper might just add communication overhead and workflow complexity for the people who have to use it (the buyer-side architects and R&D teams). That’s probably part of the vendor/enterprise gap. One more thing — never try to solve every problem with a single solution, but also never let a single solution only address one problem. Try to consolidate related risks/needs under one solution. For example: build Secret Management, roll in Key Management and Encryption as a Service. Do Data Tokenization, bring in Data Classification, Scanning, and Tagging. One solution, multiple problems addressed.
How do you measure cost?
Cost is something you can never escape — headcount, services, whatever. Sure, cloud has already solved a lot of basic problems: spin up an RDS instance from the console, use it immediately, no DBA team required. Though on the flip side, your devs need to develop a lot more DevOps muscle. Cloud is great at cutting costs for early-stage companies, but as business scale grows and scenarios get more complex, cloud SaaS offerings increasingly struggle to keep up. Multi-cloud adds even more complexity — putting workloads across different clouds, using different CDNs, and so on. And of course all kinds of security issues follow: cloud resources, policies, the services themselves. A DDoS attack that triggers resource abuse could get your account suspended by the cloud provider — which is obviously a serious business impact. So this isn’t something you can just solve by hiring an AWS expert, and we shouldn’t put all our eggs in one vendor basket. What I’m really saying is: resources can never be spread thin across everything, so in a resource-constrained environment, prioritize stability and security for your core business and critical paths. One more thing — time is a cost, and costs change over time.

Wrap-Up

Wanting things fast and good usually means higher costs — in headcount or tooling. Fast usually means insufficiently validated, so “good” is mostly wishful thinking. Wanting to cut costs usually means spending less — politely called “prioritizing,” less politely called something else. So wanting to cut costs while also going fast and shipping quality is obviously a huge gamble, or just unrealistic. You’re betting that it works out — that the right things weren’t cut, that efficiency gains were real, that speed didn’t cause incidents. That’s a little absurd on its face, but it’s often not just leadership making a calculated bet. It’s a collective one. Are leaders naive? No. But anyone can have their view blocked by the tree right in front of them. Some people only see “results-oriented” and don’t want to face the process. Or there is no process — so where do results even come from? It’s just sloganeering and self-deception. Some hold out a quiet hope: maybe we’ll win the bet. But reality usually tells you you’re not in the lucky 0.001%.

Back to security for a minute — I remember chatting with someone once who said “the essence of security is adversarial.” We didn’t get to dig into it much at the time. That statement is more precisely true for security offense and defense. For security governance, I’d say it’s more about balance — balancing risk and cost, making sure security keeps pace with business growth and IT evolution, keeping risk within an acceptable range. Of course everyone has their own take, nothing’s absolute.

A couple more thoughts on principles. Nothing is absolute, but a person without their own principles is not someone you can really be friends with. Small stuff is fine — joke around, it doesn’t matter, nothing is so serious. But there have to be personal principles. How you judge them, hard to say — maybe you just let time reveal it. The older I get, the more I value genuine sincerity — it’s rare and precious. As for work, it’s just work. Know what you absolutely won’t do; everything else has some flexibility. So there’s no need to get heated or blow things out of proportion. Just get things done honestly and solve the problems — everyone’s coming from a different position, that’s all. But always guard the boundary between work and life. Don’t let the mud stain you.