". . helmet-first architecture . ."
(From the desk of a recruiter who hires the people that make it happen)
When I say ‘IT architecture’ here, I’m talking about the practical design of how systems, data, and identities work together day-to-day .. not a specific framework or flavour (enterprise, solution, data, security).
The goal: make the safe path the easy path so sensitive data stays protected without heroics.
What we mean (so no one gets lost)
There are many ‘architectures’ (enterprise, solution, data, security etc etc). In this piece, think of architecture as guardrails that define:
- Who/what can access data (humans and non-human workloads).
- Where data lives and flows (stores, services, backups).
- How traffic moves safely (segmentation, trust boundaries).
- How we see and fix problems (observability, recovery).
The three pillars that actually keep data safe
1) Identity first (human + non-human)
Short-lived credentials, workload identity for services, least privilege by capability (not job title), joiner-mover-leaver automated.
Why it matters: If identities are tight, breaches don’t spread.
2) Data by design
Collect less; classify what you keep; encrypt at rest and in transit; own your keys; know lineage so you can find, prove, and delete specific records.
Why it matters: You can’t lose what you don’t hold, and you can’t protect what you can’t find.
3) Segmentation + visibility
Zero-trust posture, micro-segmentation, brokered egress, mTLS between services; traces/logs/metrics built in from day one; backups you’ve actually restored.
Why it matters: Contain blast radius, spot trouble quickly, and recover cleanly.
Where designs win
- Entitlements by capability: “This workload may read orders, not the whole database.”
- Contracts and versioning: Changes don’t break data flows, so teams avoid risky workarounds.
- Failure paths planned: If a queue backs up, we shed load safely and triage from a dead-letter stream.
- SLOs, not vibes: Latency, error budgets, trace completeness - measured and owned.
Common mistakes (and how to avoid them)
- Human governance for machine speed: Replace approval meetings with policy-as-code in pipelines.
- Immortal service accounts: Give every bot an owner, scope, and expiry.
- Copy-paste multi-region: Design sovereignty, failover, and reconciliation up front.
- Telemetry debt: “We have logs” ≠ “we can follow a customer record end-to-end.”
How I hire architects who keep data safe
I optimise for judgement and operability over tool lists.
Signals
- Explains confidentiality/integrity/availability as trade-offs business leaders understand.
- Talks workload identity and secrets lifecycle without hand-waving.
- Draws a small diagram you could implement tomorrow, then calmly narrates how it fails safely.
- Has a cost story (egress, KMS, storage tiers) that finance can follow.
Tools don’t make you safe .. architecture does, when it bakes identity, data design, segmentation, and visibility into how your systems run.
If you need people who think this way, that’s my lane. Finding architects who make data safety a property of the platform, not a policy on a slide.
