Solution Architecture begins with a simple question:
“What are we actually trying to do?”
This question is rarely welcomed.
The project has already been named.
The budget has been estimated.
The vendor has been selected.
The steering committee has approved a roadmap.
A programme manager has produced a slide containing six coloured arrows moving confidently toward TARGET STATE.
Everyone is therefore extremely busy.
Your question is considered disruptive.
This is your first lesson.
1. The Architecture Is Not the Diagram
The diagram is evidence that architecture may have occurred.
It is not architecture.
A rectangle labelled API GATEWAY connected to a rectangle labelled CLOUD by a tasteful blue arrow does not constitute a design.
Nor does adding:
ZERO TRUST
in the corner.
The architecture is the set of decisions, constraints, interfaces, assumptions, failure modes, operational consequences and compromises represented imperfectly by that diagram.
Unfortunately, nobody wants to read those.
They want the diagram.
Make the diagram.
Then keep the important material somewhere adults can find it.
2. Begin With the Problem
Projects rarely begin with problems.
They begin with solutions.
“We need Salesforce.”
“We need Kubernetes.”
“We need AI.”
“We need a data lake.”
“We need to move to Azure.”
“We need microservices.”
“We need Zero Trust.”
“We need blockchain.”
The architect’s first duty is to ask:
“Why?”
Do not say it aggressively.
Say it gently.
Like a therapist.
“What outcome are we trying to achieve?”
There may be a silence.
Someone will eventually say:
“Modernisation.”
This is not an outcome.
Try again.
“What becomes better?”
Another pause.
“User experience.”
Still not an outcome.
Eventually, after enough patient excavation, someone may admit:
“Our order system takes four days to update stock.”
Excellent.
Now you have something.
You may discover that the £14 million cloud transformation can be replaced by fixing three SQL queries.
Do not expect gratitude.
3. Requirements Are Things People Remember Later
At the beginning of a project, requirements are vague.
“We need it secure.”
“It needs to be fast.”
“It must be resilient.”
“It should scale.”
Users will insist there are no further requirements.
This is because the real requirements are hiding.
They emerge after design approval.
“Oh, by the way, users in Singapore need access.”
“We forgot to mention the classified network.”
“It has to work offline.”
“There are 40,000 users.”
“The database is 18 terabytes.”
“We can’t change the client.”
“We can’t change the server.”
“We can’t change the network.”
“We can’t install software.”
“We need it by Christmas.”
“What year?”
“This year.”
A mature architect assumes hidden requirements exist.
A wise architect goes hunting for them.
4. Functional Requirements Are the Easy Ones
Functional requirement:
“The user shall submit an expense claim.”
Non-functional requirement:
“The service must remain available during payroll processing, survive loss of a data centre, return results within two seconds, support 12,000 concurrent users, comply with retention policy, integrate with legacy identity, operate through the corporate proxy and cost less than the existing service.”
Everyone will discuss the expense form.
You should worry about everything after it.
Systems rarely fail because nobody knew the button should say Submit.
They fail because nobody asked what happens when 9,000 people press it at 16:55 on Friday.
5. Constraints Are Architecture
A blank sheet of paper is not architecture.
It is fantasy.
Real architecture happens because something unpleasant is true.
The WAN is slow.
The database cannot be changed.
The vendor only supports Windows.
The security team prohibits inbound connections.
The site has intermittent power.
The budget is fixed.
The deadline is ridiculous.
The application is twenty years old.
These constraints are not inconveniences around the design.
They are the design.
Anyone can architect a perfect system with infinite money, infinite time and no legacy estate.
This person is called a conference speaker.
6. The Existing Estate Is Not a Mistake
The phrase legacy system is often pronounced with disgust.
Be careful.
Legacy means:
“It has been useful long enough to become inconvenient.”
That Unix server may be ugly.
It may use an authentication protocol that predates several members of the project team.
But it has processed every transaction correctly since 2003.
Your shiny replacement has been alive for six weeks and already requires a hotfix.
Show respect.
The old system knows things.
7. Never Assume the Network
Application architects sometimes draw:
USER → APPLICATION
Between these objects lies:
Wi-Fi,
LAN,
WAN,
firewalls,
proxies,
load balancers,
NAT,
DNS,
VPN,
TLS inspection,
SD-WAN,
identity controls,
routing policy,
and occasionally a satellite link nobody mentioned.
The arrow is doing considerable emotional labour.
Talk to Network.
Early.
8. Identity Is Not “SSO”
A requirement will say:
“Must support SSO.”
This sounds simple.
It is not.
Ask:
Which identity provider?
Which user populations?
Employees?
Contractors?
Partners?
Customers?
Devices?
Service accounts?
Privileged administrators?
Which protocol?
SAML?
OIDC?
Kerberos?
LDAP?
Something proprietary invented in 2009?
What happens when identity is unavailable?
What about break-glass access?
Who owns lifecycle?
Who removes access when Bob leaves?
Identity architecture begins where the box labelled SSO becomes embarrassing.
9. Security Is a Design Property
Security added at the end is usually a firewall rule and some regret.
Bring security into the design early.
Not because security teams are always right.
They are not.
But because discovering in week forty-two that the proposed service cannot legally transmit data to its chosen cloud region is professionally tiring.
Also, never accept:
“Security says no.”
Ask:
“What threat or control requirement are we addressing?”
This transforms theatre into engineering.
Sometimes.
10. Availability Has Arithmetic
The business will ask for:
“Five nines.”
Ask why.
They may not know what it means.
99.999% availability allows only a few minutes of downtime per year.
That is expensive.
It implies engineering.
It implies operational maturity.
It implies redundancy.
It implies maintenance design.
It implies monitoring.
It implies people answering phones at unpleasant hours.
Then ask:
“How much revenue do we lose during one hour of outage?”
If the answer is £400, perhaps five nines is excessive.
Architecture includes knowing when reliability is worth buying.
11. Disaster Recovery Is Not a Second Data Centre
A second copy of broken infrastructure is not resilience.
Ask:
What is the RTO?
What is the RPO?
Who declares disaster?
How is failover initiated?
How is data reconciled?
How do users reconnect?
What happens to DNS?
What happens to authentication?
How do you fail back?
Has anyone tested it?
If the answer to the last question is no, you do not have disaster recovery.
You have disaster optimism.
12. Integration Is Where Systems Go to Die
Every project says integration will be simple.
“It’s just an API.”
This sentence has killed millions of project hours.
Ask:
Who owns the API?
Is it documented?
Is it synchronous?
What is the timeout?
What is the retry policy?
What is the rate limit?
What happens if the downstream system is unavailable?
How are messages deduplicated?
What happens when schemas change?
How are errors reconciled?
Someone will eventually say:
“We can just use CSV.”
Do not laugh.
CSV has outlived technologies that mocked it.
13. Data Has Owners Until You Ask Them to Make a Decision
Every organisation claims data ownership.
Then you ask:
“Who defines the authoritative customer address?”
Silence.
CRM says it owns customer data.
Finance says billing is authoritative.
Sales has another address.
The warehouse has a spreadsheet.
Marketing bought a list.
A regional office maintains its own database because “the central one is always wrong.”
Architecture reveals political geography.
The data model is often just the map.
14. Cloud Is Not an Architecture
Cloud is a hosting model plus several thousand services and an invoice.
“We’re cloud-first.”
Fine.
Which cloud pattern?
Managed service?
Containers?
Virtual machines?
Serverless?
SaaS?
Hybrid?
Private connectivity?
Public endpoints?
Data residency?
Identity federation?
Landing zone?
Logging?
Key management?
Backup?
FinOps?
Saying “cloud” does not answer these questions.
It merely provides more expensive ways to avoid them.
15. Microservices Are Not Small Services
A monolith is not automatically bad.
Microservices are not automatically modern.
Microservices introduce:
distributed transactions,
network failure,
service discovery,
versioning,
observability,
deployment orchestration,
eventual consistency,
and several additional ways for developers to blame each other.
Use them when organisational and technical boundaries justify them.
Do not use them because somebody saw Netflix architecture slides.
You are not Netflix.
Your organisation sells insurance in Coventry.
16. Kubernetes Is Not a Business Requirement
Nobody wakes at 03:00 and thinks:
“I wish my council tax portal had more container orchestration.”
Kubernetes is useful.
It is also operationally substantial.
If your entire application consists of three services used by 400 people, ask whether you need:
clusters,
operators,
service meshes,
ingress controllers,
Helm charts,
and six engineers who now describe themselves as platform specialists.
Sometimes a virtual machine is fine.
This statement may cause offence.
Proceed.
17. Buy Versus Build Is Mostly About Regret
Build:
Total control.
Total responsibility.
Buy:
Less control.
Different responsibility.
SaaS:
Minimal control.
Subscription regret.
There is no universally correct answer.
Ask:
Is this capability differentiating?
Do we have engineering capability?
How long will we own it?
What is the exit strategy?
How portable is the data?
What happens when the vendor doubles the price?
What happens when they discontinue the product?
Architecture must include how you leave.
Nobody wants to discuss divorce during the wedding.
Discuss it anyway.
18. Vendor Diagrams Are Aspirational Literature
Vendor architecture diagrams have several common features:
everything is blue,
everything is secure,
nothing fails,
and every arrow leads toward their product.
Their solution is always:
scalable,
resilient,
AI-enabled,
enterprise-grade,
zero-trust,
cloud-native,
and transformative.
Ask difficult questions.
Where is state stored?
What are the limits?
What fails closed?
What fails open?
How are upgrades handled?
What is excluded from the licence?
What requires professional services?
The account manager will stop inviting you to lunch.
This is acceptable.
19. Licensing Is Architecture
An architect who ignores licensing can design a technically elegant financial disaster.
A four-node cluster may require licensing all physical cores.
A passive DR site may not be passive according to the contract.
Virtual mobility may widen the licensed estate.
A “free” feature may require an enterprise tier.
Ask early.
Licensing constraints can change topology.
This is deeply annoying.
It is still architecture.
20. Cost Is a Technical Requirement
If the system works beautifully but nobody can afford to run it, it does not work.
Include:
compute,
storage,
network,
support,
licensing,
backup,
monitoring,
operations,
people,
DR,
growth,
and exit costs.
Cloud solutions especially need cost modelling under load.
A technically perfect design that generates £80,000 per month of unexpected egress is simply a sophisticated billing incident.
21. Operations Begins Before Go-Live
Ask who will operate the system.
Someone will say:
“BAU.”
BAU is not a team.
It is a mystical destination where projects send responsibilities they no longer wish to discuss.
Who monitors it?
Who patches it?
Who restores it?
Who owns certificates?
Who handles alerts?
Who handles capacity?
Who talks to the vendor?
Who renews support?
Who knows when the licence expires?
If nobody has names, you have not finished the architecture.
You have merely moved the problem forward in time.
22. Supportability Beats Cleverness
Architects enjoy elegance.
Operations enjoys sleeping.
Choose accordingly.
A clever design requiring rare expertise may be technically superior and operationally catastrophic.
Ask:
Can the organisation support this at 02:00?
Can new staff understand it?
Can it be diagnosed?
Can it be patched?
Can it be recovered?
Can a supplier support it?
If the answer is no, simplify.
Complexity is a debt instrument.
Interest is payable during incidents.
23. Every Exception Becomes Permanent
“Temporary firewall rule.”
“Temporary admin account.”
“Temporary bypass.”
“Temporary integration.”
“Temporary manual process.”
There is no temporary.
There is only:
not yet documented as permanent.
If an exception is genuinely necessary, give it:
an owner,
an expiry date,
a review point,
and a removal plan.
Otherwise it will still exist in twelve years.
Someone will call it heritage.
24. Architecture Principles Are Useful Until They Collide
Typical principles:
Cloud first.
Reuse before buy.
Buy before build.
Secure by design.
API first.
Data is an asset.
Automation first.
Open standards.
User centred.
Minimise technical debt.
All excellent.
Then reality arrives.
The legacy vendor has no API.
The approved cloud cannot host the workload.
The budget does not fund replacement.
Security requires an appliance.
The deadline is six weeks.
Architecture is the practice of resolving contradictions among desirable principles.
The principle that always wins is:
“The service must still work.”
25. Standards Are Guardrails, Not Holy Scripture
Standards reduce chaos.
They improve supportability.
They prevent every project inventing its own authentication system.
Good.
But standards also age.
A standard that exists only because nobody has reviewed it since 2016 is not governance.
It is sediment.
Architects should know when to comply.
They should also know when to request an exception.
The important word is request.
Do not simply ignore standards.
That creates archaeology.
26. Technical Debt Is Sometimes Rational
Not every shortcut is stupid.
Sometimes the correct decision is:
“We will tolerate this ugly workaround for eighteen months because replacing the underlying platform now costs £2 million.”
That is not failure.
That is a conscious trade-off.
Technical debt becomes dangerous when:
nobody records it,
nobody owns it,
nobody prices it,
and everyone assumes someone else will repay it.
Record the debt.
Record the interest.
Record the exit.
Then make the decision visible.
27. Decision Records Are More Valuable Than Beautiful Documents
Six months after implementation, nobody remembers why a design decision was made.
They remember opinions.
“That was Security.”
“No, Network insisted.”
“The vendor said we had to.”
“I thought Architecture chose it.”
Use Architecture Decision Records.
Short ones.
Decision.
Context.
Options.
Rationale.
Consequences.
Date.
Owner.
Future architects will bless you.
Or at least swear at you less.
28. Never Confuse Consensus With Correctness
Architecture boards sometimes attempt to reach consensus.
This is admirable.
It can also produce grotesque systems designed to offend nobody.
The network team wants one thing.
Security wants another.
Applications wants another.
Operations wants another.
The project wants all of them satisfied.
The resulting solution uses:
two identity systems,
three integration methods,
four hosting patterns,
and a special exception for Finance.
Everyone approves.
Nobody is happy.
Good architecture sometimes requires a decision.
Make it.
Document it.
Own it.
29. Governance Should Reduce Risk, Not Generate Theatre
Good governance asks:
Is the problem understood?
Are requirements credible?
Are risks visible?
Are decisions justified?
Is the solution supportable?
Bad governance asks:
Has slide 14 been updated to the approved template?
Architecture assurance is not a ritual blessing.
Do not become the priest who stamps diagrams.
Ask questions that can still change something.
If all decisions have already been made, you are not governing architecture.
You are conducting an autopsy.
30. The Architecture Review Board Is Not a Court
Do not arrive intending to defeat the project.
Projects are not criminals.
Usually.
Your role is to improve the probability of success.
Ask hard questions.
But explain why.
“Where is the session state?”
is useful.
“This is rubbish.”
is not.
Architects who gain a reputation for obstruction stop being invited early.
Then they complain architecture is engaged too late.
This is not Zen.
This is self-harm.
31. Never Say “Best Practice” Without Context
Best practice for whom?
A global bank?
A ten-person charity?
An aircraft manufacturer?
A hospital?
A startup?
A submarine?
Architecture is contextual.
A solution appropriate for one environment may be absurd in another.
Prefer:
“Given these requirements and constraints, this pattern reduces these risks.”
It is longer.
It also means something.
32. The Target Architecture Is a Direction, Not a Destination
Target architectures often contain an enchanted future in which:
all applications use APIs,
identity is unified,
data is governed,
technical debt is gone,
everything is automated,
legacy systems are retired,
and users are delighted.
This world does not exist.
Before you reach it, the organisation will:
merge,
restructure,
buy another company,
change strategy,
replace the CIO,
and purchase a large SaaS platform nobody told Architecture about.
Target architecture is a compass.
Not a railway timetable.
33. Roadmaps Are Negotiations With Entropy
A roadmap should show dependencies, transition states and sequencing.
It should not simply contain:
2026 — TRANSFORM
2027 — OPTIMISE
2028 — INNOVATE
That is astrology.
A useful roadmap tells you:
what changes,
in what order,
why,
what enables what,
what can coexist,
and where risk reduces.
It should also acknowledge that Year Three is approximately fictional.
34. Sometimes the Correct Architecture Is “Do Nothing”
This is rarely popular.
Projects exist to change things.
Architects are paid to design things.
Vendors are paid to sell things.
But sometimes:
the system is stable,
the risk is understood,
the replacement cost is unjustified,
and there is no meaningful business benefit.
“Do nothing for two years while reducing operational risk” can be excellent architecture.
Do not confuse activity with progress.
35. Proof of Concept Does Not Mean Production
A developer demonstrates the technology on a laptop.
It works.
Management becomes excited.
“Can we go live next month?”
No.
The proof of concept has:
one user,
no monitoring,
no backup,
no security model,
no support model,
no DR,
no performance testing,
no audit logging,
and credentials stored in the source code.
The purpose of the proof of concept was to establish feasibility.
It has done so.
Do not punish it by promoting it into production.
36. “Scalable” Is Not a Number
Every solution is described as scalable.
Ask:
From what to what?
100 users to 1,000?
10,000 to 1 million?
Ten transactions per second to 20?
What dimension scales?
Compute?
Storage?
Connections?
Tenants?
Geographies?
Staff?
If nobody knows the expected load, scalability is decorative language.
37. Latency Is Geography Collecting Rent
You cannot architecture-diagram your way around the speed of light.
If users are in Australia and the application is in London, something will take time.
If the application makes twenty sequential database calls per transaction, it will take more time.
If each call crosses an inspected VPN tunnel twice, congratulations: you have invented interactive archaeology.
Put workloads near users and data where possible.
Reduce chatty protocols.
Measure.
Physics is an unusually stubborn stakeholder.
38. Logs Are Part of the Product
When designing systems, architects often draw happy paths.
User authenticates.
Request processed.
Response returned.
Also design:
failure,
timeout,
retry,
rejection,
partial completion,
and investigation.
Can Operations determine what happened?
Can Security reconstruct an event?
Can Support correlate a user complaint?
Can you trace a transaction across services?
If not, the system will eventually fail invisibly.
Invisible failures are especially popular with executives.
39. Time Is Infrastructure
Clock synchronisation matters.
Certificates care about time.
Kerberos cares about time.
Distributed logs care about time.
Databases care about time.
Auditors care intensely about time.
When two systems disagree by seven minutes, debugging becomes metaphysics.
Architect time.
Nobody will thank you.
This is normal.
40. The Most Dangerous Box Is “Other”
Whenever a diagram contains:
OTHER SYSTEMS
ask what they are.
Likewise:
External Users.
Third Parties.
Legacy Interfaces.
Partner Network.
Shared Services.
Miscellaneous Data Sources.
Every vague box contains future incidents.
Ambiguity is where dependencies breed.
41. Architecture Is Mostly Asking Embarrassing Questions Early
Who owns this?
How many users?
Where is the data?
What happens if it fails?
Who supports it?
What does the licence permit?
Why are we doing this?
What happens when the contract ends?
What happens if the supplier disappears?
How do we recover?
Has anyone tested that?
Who pays?
What does “real time” mean?
Who approved the risk?
These are not glamorous questions.
They are extremely valuable.
42. You Will Be Asked to Approve Things You Did Not Design
A project will arrive three days before go-live.
They will say:
“We just need Architecture sign-off.”
Do not sign.
Review it.
If it is acceptable, say so.
If risks exist, state them.
If information is missing, state that.
Never allow architectural approval to mean:
“An architect was present near the end.”
Your name will remain attached to the decision long after everyone else has moved on.
43. Never Become the Diagram Monkey
You are not there merely to make Visio attractive.
Although attractive diagrams help.
You are there to:
clarify,
structure,
challenge,
model,
analyse,
trade off,
communicate,
and decide.
If every meeting ends with:
“Can you update the diagram?”
ask whether you are performing architecture or desktop publishing.
Then update the diagram anyway.
Because apparently the arrows are the wrong colour.
44. Architecture Is Social Engineering Without the Phishing
Technical decisions happen through people.
You will need to persuade:
developers,
security,
operations,
programme managers,
vendors,
finance,
procurement,
and executives.
Being technically correct is insufficient.
You must explain consequences in language each audience understands.
To engineers:
failure modes.
To finance:
cost.
To executives:
risk and outcome.
To operations:
supportability.
To security:
control.
To programme managers:
dependency and schedule.
The architecture does not exist until enough people understand it to build and operate it.
45. Do Not Fall in Love With Your Design
You will create something elegant.
Then a requirement will appear that ruins it.
This is painful.
Do not defend the design because it is yours.
Architecture is not sculpture.
If the constraints change, change the solution.
The best architects abandon their favourite ideas faster than mediocre architects defend theirs.
46. Simplicity Must Be Defended
Complexity arrives automatically.
Every stakeholder adds one requirement.
Every vendor adds one component.
Every risk adds one control.
Every integration adds one interface.
Nobody owns total complexity except Architecture.
Therefore say:
“No, we don’t need another platform.”
“We can reuse this service.”
“This component adds no value.”
“Remove that hop.”
“Why are there two databases?”
Simplicity is rarely created.
It is excavated.
47. There Is No Perfect Architecture
There are only trade-offs.
Availability versus cost.
Security versus usability.
Consistency versus latency.
Speed of delivery versus technical debt.
Standardisation versus flexibility.
Build versus buy.
Centralisation versus autonomy.
The architect who claims to have eliminated trade-offs has usually hidden them.
Find them.
Write them down.
Make the organisation choose consciously.
That is much of the job.
48. The Best Architecture Document Is the One Someone Uses
A 180-page solution design nobody reads is less valuable than five pages everybody understands.
Documentation should answer questions.
What are we building?
Why?
How does it work?
What depends on what?
How is it secured?
How does it fail?
How is it operated?
What decisions were made?
Where are the risks?
Write enough.
Not everything.
Nobody has ever been saved during a Severity One incident because the architecture document had an excellent glossary.
49. Eventually You Become the Person People Ask
Years pass.
You learn the estate.
You learn the politics.
You know which standards matter.
You know which vendor diagrams lie.
You know which legacy systems genuinely cannot be touched.
A project manager will eventually enter a meeting and say:
“We need Peter because he knows how all this joins together.”
This is flattering.
It is also a warning.
Write things down.
Teach other architects.
Do not become another undocumented dependency.
The enterprise already has enough of those.
50. The Final Zen
Solution Architecture is not the art of designing perfect systems.
It is the practice of making imperfect decisions under incomplete information while twenty-seven people have different definitions of success.
You will rarely have enough time.
You will never have complete requirements.
The technology will change.
The organisation will change.
The budget will change.
Someone will acquire another company during implementation.
A vendor will rename the product halfway through your document.
Yet the architect continues.
Ask the awkward question.
Draw the useful diagram.
Find the hidden dependency.
Expose the assumption.
Quantify the risk.
Simplify the design.
Record the decision.
And when somebody finally asks:
“So, is this architecture future-proof?”
Do not laugh.
Look thoughtful.
Then say:
“It gives us a controlled path for future change.”
This sounds wise.
More importantly, it does not promise anything impossible.
You have achieved architectural enlightenment.
