Set aside personal preferences and attachments. Let data, design fit, and merit drive the decision, not your favourite tool and not your ego.
Ground every choice in the use case in front of you. A SWOT read or an Eisenhower matrix turns a vague "it depends" into a decision you can defend.
Cost, resilience, scalability, high availability all matter. The architect names which one matters most right now, with clarity and with evidence.
What you see is not always the whole truth. Learn to view a problem from every angle, not just your own lens. I call it 360 degree detail orientation.
Keep sharpening the core: design patterns, architectural principles, the fundamentals. Strong foundations are what make scalable decisions possible.
Do not just follow patterns. Question them. Innovation begins with curiosity, not conformity. Hold simplicity and disruption in the same hand.
Growth is not optional. Make learning your default mode, something that runs on its own, not a thing that depends on a nine to six job.
Great architects do not delay without reason. They move. But they also know exactly when to say no, and they say it early.
Ask what could go wrong before you ask what could go right. What if this fails? Name the factors that could break the decision later, and write them down.
Influence is not earned by being the loudest in the room. It is earned by being open, and by being kind, even when you hold your ground.
Support every recommendation with clear pros and cons, backed by research, including the risks you would rather not bring up.
In a high trust team, brilliance does not wear a badge. Value the idea over the hierarchy, no matter whose mouth it came out of.
Real leadership is the moment your team feels safe enough to challenge you, co-create with you, and grow, together.
AI now sits inside the systems you design and the decisions you make. Treat it as a structural force to architect for and with. Let it amplify your judgment and draft the work, but never let it hold the decision. That is still yours to own.
The mental models are the mindset, the value system you carry into any room. The skillset is where you spend it, and "architect" is not a single job. It is a family of roles that differ by the scope they own and the domain they go deep in, from the whole organisation down to the internals of one system. Here is how they sit together, and the path into each.
Enterprise Architect
Aligns the whole technology estate with where the business is going.
- Owns
- Target-state architecture, standards and principles, capability roadmaps, and build-versus-buy across the portfolio.
- Core skills
- Business strategy, capability modelling, governance, a framework such as TOGAF or Zachman, and stakeholder influence.
Master: capability mapping, portfolio governance, and multi-year roadmapping.
IT Architect
Keeps the organisation's systems and infrastructure working as one coherent whole.
- Owns
- Infrastructure, integration, platforms, and the non-functional standards that hold across the estate.
- Core skills
- Networks and infrastructure, integration patterns, security, operations, and breadth across platforms.
Master: integration, infrastructure at scale, and the whole-landscape view.
Solution Architect
Turns a business problem into an end-to-end technical solution.
- Owns
- The solution design across applications, integration, and infrastructure, with the technology choices and trade-offs behind it.
- Core skills
- Requirements to design, cross-system trade-offs, non-functional requirements, cost, and clear communication with business and delivery.
Master: trade-off analysis, cross-system design, and translating business into technical.
Application Architect
Shapes the structure of a specific application or family of applications.
- Owns
- Application layering and components, frameworks, integration points, and the app-level standards and quality.
- Core skills
- Application design, framework and platform depth, API design, and application security and performance.
Master: layered and component design, framework depth, and application integration.
Software Architect
Owns the internal structure and quality of a software system, closest to the code.
- Owns
- Modules and components, design patterns, internal APIs, the quality attributes, and the tech stack within the system.
- Core skills
- Design patterns, system decomposition, quality attributes, code-level trade-offs, and depth in the chosen stack.
Master: design patterns, system decomposition, and the quality attributes.
Cloud Architect
Designs and runs systems on cloud platforms.
- Owns
- Cloud platform design, migration, infrastructure as code, security, resilience, and cost on AWS, Azure, or GCP.
- Core skills
- One cloud platform in depth, networking, infrastructure as code, security, cost or FinOps, and the well-architected mindset.
Master: one platform deeply, infrastructure as code, and security and cost.
Data Architect
Designs how data is modelled, moved, stored, and governed.
- Owns
- Data models, pipelines and flows, storage from databases to lakes to warehouses, and data quality and governance.
- Core skills
- Data modelling, pipelines and ETL, SQL and the major stores, governance, and analytics enablement.
Master: data modelling, pipelines, and governance.
Test Architect
Engineers quality, and the strategy for it, across the whole lifecycle.
- Owns
- Test strategy, automation frameworks, environments and test data, performance and security testing, and the quality gates.
- Core skills
- Test strategy, automation engineering, CI/CD quality gates, performance and security testing, and shift-left practice.
Master: automation architecture, test strategy, and quality at speed.
Mobile Architect
Designs how mobile apps are built across iOS, Android, and cross-platform.
- Owns
- Mobile app architecture, offline and sync strategy, performance on constrained devices, security, and app-store release and lifecycle.
- Core skills
- iOS or Android depth or a cross-platform stack (Kotlin, Swift, Flutter, React Native), offline-first design, mobile security, and performance.
Master: platform depth, offline and sync, performance, and release engineering.
AI Architect
Designs how AI and machine learning are built into systems, safely and at scale.
- Owns
- Model and retrieval choices, the agent and data pipeline, evaluation, serving and MLOps, and the guardrails for safety, cost, and governance.
- Core skills
- ML and LLM foundations, RAG and agent design, data and feature pipelines, evaluation and observability, and responsible-AI practice.
Master: retrieval and agent design, evaluation, serving, and the safety guardrails.
These follow the industry-standard definitions from the bodies that name them: TOGAF, iSAQB, DAMA, ISTQB, and the cloud vendors. In practice the titles blur, and the exact scope shifts with company, country, and culture; most architects wear several of these hats at once. Read each as a baseline, not a rule. What stays constant is the change in scope, and the mental models above are what make a wider scope survivable.
The three sets are who you become. The lenses are how the room comes to rely on you. The day you hold the role, every function around you reads your work through its own eyes, and its own work starts to ride on your decisions. Knowing what each one expects, and where it depends on you, is half of earning the role and staying trusted in it.
- Expects of you
- Designs that serve where the business is going and hold the standards, with the risk named and owned.
- Leans on you for
- Defensible calls on the big, expensive technology bets.
- Earns their trust
- Trade-offs shown in the open, not decisions handed down.
- Loses it when
- The surprise lands in production instead of the design review.
- Expects of you
- A design the team can actually build, with the people and the time they have.
- Leans on you for
- Sequencing and guardrails that keep delivery predictable.
- Earns their trust
- Architecture sized to the real team, not the ideal one.
- Loses it when
- The plan assumes engineers, and a schedule, that do not exist.
- Expects of you
- Straight answers on what is feasible, at what cost, by when.
- Leans on you for
- The trade-offs behind a date they can promise a customer.
- Earns their trust
- A clear “yes, and here is the cost,” or “no, and here is the alternative.”
- Loses it when
- Feasibility quietly changes after the commitment is made.
- Expects of you
- Data ownership, models, and governance designed in, not bolted on.
- Leans on you for
- Where data lives, how it flows, and who is accountable for it.
- Earns their trust
- Data treated as a first-class part of the architecture.
- Loses it when
- Lineage, integrity, or privacy turns out to be an afterthought.
- Expects of you
- A design that scales and recovers without a surprise on the bill.
- Leans on you for
- The shape that sets cost, resilience, and on-call load.
- Earns their trust
- Operability and cost drawn into the first diagram.
- Loses it when
- “It works on paper” meets the production invoice.
- Expects of you
- Risk surfaced early and compliance built in, not reviewed at the end.
- Leans on you for
- The decisions that set the blast radius.
- Earns their trust
- Security invited into the design, not informed after it.
- Loses it when
- The audit, or the incident, finds what the review should have.
- Expects of you
- A real place for models, with the data, latency, and cost contracts they need.
- Leans on you for
- Where intelligence fits, and what it is allowed to touch.
- Earns their trust
- Probabilistic parts given honest boundaries inside a deterministic system.
- Loses it when
- A model is treated like a library that always returns the right answer.
- Expects of you
- Decisions explained, and room to build inside clear guardrails.
- Leans on you for
- The “why” behind the constraints they live in.
- Earns their trust
- Direction that frees them, instead of rules that box them in.
- Loses it when
- The design is a black box they are handed and told to obey.
The lenses do not change as you climb; their expectations rise. A Software Architect answers to the team and the system. A Solution or Enterprise Architect answers to all of these at once, across many systems, with more money and more careers riding on each call. Two of these lenses up close: When Architecture Becomes a Leadership Problem and We Cut Cloud Costs by 70%.
Cognitive Bias Is Enemy Number One
The architect's first and hardest discipline is taking yourself out of the decision. Why your favourite tool, your last design, and your own seniority are the biases you cannot see, and how to let data, fit, and merit decide instead.
360 Degree Detail Orientation
Perspective over perception. What you see is rarely the whole truth, so the architect learns to walk around the problem and read it from every angle before committing to one.
The Trade-off Is the Architecture
Cost, resilience, scalability, availability all matter, which is exactly why "it depends" is not an answer. How SWOT, the Eisenhower matrix, and an honest read of the scenario turn pragmatism into a defensible decision.
Invert the Problem
Inverted thinking, made a habit. Ask what could go wrong before what could go right, run the pre-mortem, and write down the factors that could break this decision a year from now. Grows from the essay of the same name.
Deep Roots, Fresh Growth
The architect's relationship with knowledge. Master the fundamentals so deeply you can question the patterns, and keep learning as a default mode rather than a thing that ends at six o'clock.
Decide, Then Say No
Reducing decision turnaround without becoming reckless. Why great architects do not delay for the sake of it, and why the most respected ones are also the quickest to say a clear, early no.
Ego-Free, Blame-Free, Radically Collaborative
The architect as the person who makes the room safe. Agree to disagree with grace, let the best idea win no matter whose it is, and build the psychological safety that lets a team challenge and co-create.
Make AI a First-Class Force
The newest discipline. Treat AI as a structural force you architect for and with, not a tool you bolt on at the end. Let it amplify judgment and draft the work, and never outsource the decision. Pairs with the AI in Practice guide.
Invert the Problem
The original case for inverted thinking: solve the hard problem by asking how it fails, not how it succeeds. The seed of Model 09.
Read →The Day I Realised I Was Not Ready
Fifteen minutes with a chief architect and the first design document I ever produced. The moment the engineer-to-architect gap became real, and personal.
Read →You're Not Architect Material
A three-minute review that became a thesis on permission versus readiness, and what it actually takes to earn the title rather than be handed it.
Read →