334digital.com

Category: Concept

  • Managing Successful Outcomes in Complex Business Transformations: A Theoretical Synthesis

    Abstract

    Successful business transformation requires organizations to evolve beyond treating capability upgrades as isolated technological deployments. Contemporary academic and practitioner theories emphasize that sustainable change is achieved through the deliberate synchronization of structural frameworks, cultural behavioral levers, and a proactive organizational posture. This paper synthesizes current transformation theories, demonstrating how successful outcomes in large-scale enterprise shifts rely on structural alignment, the reshaping of cultural norms, and the paradigm shift from “change-readiness” to a “change-seeking” operational state.

    1. Introduction: The Capability Fallacy

    Historically, organizational transformation has been plagued by a fundamental diagnostic error: conflating the acquisition of new technology with the realization of a new capability. Whether an enterprise is attempting to migrate tens of thousands of distributed users to a modern network architecture or enforce rigorous, state-aligned security baselines across an outsourced infrastructure, the deployment of software or hardware is merely the inception of change.

    Current theory defines organizational transformation as the comprehensive realignment of three core pillars: structure (hierarchy and team composition), operations (the processes that execute work), and culture (the social makeup and behavioral norms). When transformations fail, it is rarely due to a technical miscalculation; failure typically stems from attempting to graft new operational realities onto incompatible cultural and structural foundations.

    2. Structural Alignment and Execution Frameworks

    To mitigate the risks inherent in massive capability shifts, organizations increasingly rely on formalized models to bind disparate operational domains together. Frameworks such as TOGAF (The Open Group Architecture Framework) and the MIT Digital Capability Framework offer structured methodologies to ensure that enterprise architecture and digital investments remain tightly coupled with overarching business objectives,.

    The MIT model, developed by MIT Sloan researchers, posits that digital transformation is not a mere technological upgrade but the strategic alignment of customer experience, operational processes, and business models.

    For enterprise architects managing vast portfolios, these frameworks provide a critical diagnostic advantage:

    • Resource and Risk Optimization: They map the systemic dependencies of a transformation, allowing leaders to identify where a shift in technology will inadvertently fracture a legacy business process or violate a compliance governance mandate.
    • Holistic Execution: By aligning strategy, structure, and culture, these models prevent siloed optimization, ensuring that a modernization effort in one domain (e.g., IT outsourcing) does not create friction in another (e.g., manufacturing logistics).

    3. Cultural Topography: The LEASH Model

    While structural and operational metrics are concrete and easily measurable, culture remains the most formidable barrier to successful transformation. As noted by organizational behavior experts at Stanford and Harvard Business School, leaders frequently over-index on systems, processes, and rewards, while neglecting the cultural norms that ultimately dictate success or failure.

    To engineer cultural shifts systematically, researchers developed the LEASH Model, which identifies five critical levers for reshaping organizational behavior:

    1. Leader Actions: Managerial directives must consistently communicate signals that define goals and focus attention. A single executive mandate is insufficient; the entire leadership team must actively model the desired state.
    2. Employee Involvement: Transformation cannot be done to an organization; it must be done with it. Fostering internal groups and participatory events increases accountability and reduces friction at the operational edge.
    3. Aligned Rewards: Behaviors that support the new capability must be incentivized through status, recognition, and promotion, ensuring that legacy mindsets are not inadvertently rewarded.
    4. Signals, Stories, and Symbols: The enterprise must utilize internal narratives, group titles, and visible milestones to reinforce the new operational reality.
    5. HR System Alignment: The mechanisms by which the organization recruits, onboards, and trains talent must be fundamentally rewritten to support the target architecture and future-state capabilities.

    If an enterprise attempts to enforce a modern, high-velocity operational model but leaves legacy HR systems and reward structures intact, the culture will aggressively reject the transformation.

    4. The Paradigm Shift: From “Change-Ready” to “Change-Seeking”

    The velocity of digital disruption and the integration of artificial intelligence have rendered traditional change management theories obsolete. For decades, the theoretical ideal was the “change-ready” organization—an enterprise capable of adapting quickly to external shocks. However, recent organizational research indicates this reactive posture is no longer sufficient.

    According to a 2025 Global Leadership Development Study by Harvard Business Impact, 71% of senior leaders now view the ability to lead through continuous, compounding change as a critical competency, a sharp increase from previous years. The new theoretical imperative is the “change-seeking” culture.

    Unlike change-ready organizations that wait to execute decisively, change-seeking organizations proactively scan their environments, challenge foundational assumptions, and initiate architectural pivots before disruption forces their hand.

    Cultivating a change-seeking enterprise requires four systemic conditions:

    • Democratized Experimentation: Moving away from rigid, top-down innovation and empowering the operational edge to test new workflows and efficiencies.
    • Psychological Safety: Leaders must normalize well-intentioned failure, ensuring that teams are not penalized for attempting to optimize processes or flag systemic vulnerabilities.
    • Embedded Feedback Loops: Learning and development must function as the central nervous system of the enterprise, rapidly circulating telemetry and insights from failed pilots across the organization.
    • Strategic Alignment: Proactive innovation must still be tethered to strict strategic priorities to prevent the organization from wasting capital on misaligned experimentation.

    5. Conclusion

    Managing a successful business transformation requires an architectural mindset applied to human systems. As demonstrated by current academic frameworks, deploying technology is the easiest component of modernization. The true work of transformation lies in threading new capabilities through the structural topology of the business, utilizing explicit levers to realign cultural norms, and evolving the enterprise from a state of passive readiness into an aggressive, change-seeking posture. Organizations that master these theoretical mechanics will not only survive the friction of complex migrations but will establish resilience as a core competitive advantage.

  • Canto X – Enterprise Architecture

    Canto X of Dante’s Inferno maps surprisingly well onto some of the recurring structural failures of Enterprise Architecture.

    The central analogy is this: the heretics in Canto X can see the distant future, but they cannot properly perceive the present. That is an uncomfortably accurate description of a weak EA function.

    Enterprise Architecture often becomes excellent at describing a future state—target architectures, capability maps, principles, strategic roadmaps, reference models—while having only an approximate understanding of how the organisation actually works today.

    Farinata is therefore a useful patron saint of dysfunctional architecture.

    He can see far away. He cannot see what is directly in front of him.

    In EA terms, the organisation has a beautifully articulated Target Architecture for 2030 but cannot answer basic questions such as:

    • Which applications actually support this business process?
    • Which team owns that integration?
    • Why does Finance still depend on this spreadsheet?
    • Which Oracle database is really authoritative?
    • Why are there three identity stores?
    • What happens if this server is switched off?
    • Which project introduced that interface?
    • Who is actually paying for it?

    This is the first structural problem: strategic farsightedness combined with operational blindness.

    Canto X goes further. The inhabitants of the sixth circle are enclosed in burning tombs. Each tomb contains people whose intellectual position has become, quite literally, their permanent enclosure.

    That is a good metaphor for architecture domains.

    Business Architecture sits in one tomb.

    Solution Architecture sits in another.

    Security Architecture has a particularly well-governed tomb with an approval workflow.

    Infrastructure Architecture has several tombs because nobody completed the consolidation programme.

    Data Architecture has drawn a conceptual model of the cemetery.

    Each discipline possesses a coherent internal worldview. The difficulty is that the enterprise exists in the spaces between them.

    This produces what might be called the architecture-of-tombs problem: organisational structures encourage architects to optimise their own representational domain rather than understand the operating system of the enterprise as a whole.

    Business architects produce capabilities.

    Application architects produce portfolios.

    Data architects produce information models.

    Infrastructure architects produce platforms.

    Security architects produce controls.

    None of these things is necessarily wrong. But the organisation does not actually operate as a capability model, application portfolio, information model, technology stack or control framework.

    It operates through transactions, decisions, dependencies, people, contracts, workarounds, incentives and exceptions.

    That distinction is fundamental.

    Cavalcante introduces another EA pathology.

    He misinterprets Dante because his information is incomplete. Dante uses a tense that Cavalcante interprets as evidence that his son Guido is dead. The inference is rational given the available information, but wrong.

    Enterprise Architecture routinely does exactly this.

    An architecture repository says:

    Application: ACTIVE

    The architect concludes:

    Application is operationally required.

    But perhaps the application is technically active and functionally obsolete.

    Or:

    Capability: CUSTOMER MANAGEMENT

    The architect assumes there is a coherent organisational capability behind the box.

    There may instead be six departments, four SaaS products, two outsourced teams, thirteen spreadsheets and a woman called Janet who reconciles the whole thing every Thursday.

    The architecture model is not necessarily false. The problem is that semantic compression destroys context.

    Architecture repositories tend to replace complicated operational truths with categorical statements:

    Strategic

    Tolerate

    Invest

    Retire

    Compliant

    Non-compliant

    Cloud-ready

    Legacy

    These categories become dangerous when decision-makers forget that they are abstractions.

    Cavalcante makes precisely this mistake. He takes an incomplete representation for reality.

    There is another, more uncomfortable parallel in Farinata.

    Even in Hell, Farinata remains obsessed with Florentine factional politics.

    His circumstances have changed absolutely.

    His mental model has not.

    This happens constantly in enterprise transformation.

    The organisation announces:

    Cloud first.

    But procurement remains designed around buying servers.

    It announces:

    Product operating model.

    But funding remains annual project funding.

    It announces:

    Agile delivery.

    But governance still requires eighteen sequential approvals.

    It announces:

    Data-driven organisation.

    But authority remains hierarchical and political.

    It announces:

    Zero Trust.

    But network access is still implicitly trusted according to location.

    This is the Farinata problem: organisations carry obsolete institutional identities into radically changed environments.

    The architecture changes.

    The institution does not.

    A new target operating model can therefore reproduce the old organisation almost perfectly underneath different terminology.

    Departments become “value streams.”

    Projects become “products.”

    Technical design authorities become “architecture enablement forums.”

    The old bureaucratic relationships survive.

    This connects to another feature of Canto X: the damned remain intensely interested in Florence despite being permanently excluded from it.

    Enterprise Architecture can develop the same relationship with delivery.

    Architects discuss delivery continuously while being structurally separated from it.

    They review designs.

    They issue principles.

    They maintain standards.

    They chair governance boards.

    They create roadmaps.

    But they may not build, operate, support or retire anything.

    EA therefore risks becoming an exiled class describing the city from outside its walls.

    That produces predictable consequences.

    Delivery teams perceive architecture as theoretical.

    Architects perceive delivery teams as undisciplined.

    Programmes seek dispensations.

    Architecture creates stronger governance.

    Programmes create better techniques for avoiding governance.

    Eventually the architecture repository records an enterprise that exists primarily inside the architecture repository.

    There is also a temporal problem embedded in the canto.

    Architecture normally describes three temporal states:

    Current → Transition → Target

    The model looks rational.

    Real enterprises behave more like:

    Past + current + abandoned future + emergency workaround + acquisition residue + regulatory exception + someone's strategic pilot

    all operating simultaneously.

    Enterprise systems are archaeological.

    You rarely replace one architectural era completely. You accumulate them.

    Mainframe assumptions survive inside APIs.

    1990s organisational structures survive inside cloud tenancy models.

    Old ERP data structures determine modern business processes.

    Temporary integrations become permanent.

    Pilot platforms become strategic because somebody built something important on them.

    The enterprise therefore resembles Dante’s Hell more than an architecture roadmap: layers of historical decisions continue to exist after the circumstances that produced them have disappeared.

    There is a final and particularly useful lesson from Canto X.

    The damned know the future only while there is a future to know. Eventually even that form of knowledge disappears.

    Architecture faces an analogous problem.

    The farther a target state extends into the future, the less it describes an actual destination and the more it becomes an argument about desired direction.

    A five-year architecture cannot sensibly specify detailed systems.

    Technology will change.

    Suppliers will change.

    Regulation will change.

    Business strategy will change.

    Acquisitions will happen.

    Projects will fail.

    Someone will buy Salesforce.

    Consequently, mature EA should not primarily attempt to predict the future.

    It should improve the enterprise’s capacity to change.

    That means the real architectural objects of interest become things such as modularity, substitutability, interoperability, ownership, dependency transparency, data semantics, technical debt, lifecycle state, operational coupling and decision rights.

    Instead of saying:

    In 2031 the enterprise shall consist of these twenty-three strategic platforms.

    EA should be able to say:

    If strategy changes, these components can be replaced independently; these dependencies are understood; these interfaces are governed; these data responsibilities are explicit; and these systems can be retired without discovering that an unknown payroll process depends upon them.

    That is a fundamentally different conception of architecture.

    And it gives Canto X an unexpectedly good architectural maxim:

    Do not become so good at seeing the distant future that you lose the ability to see the enterprise standing immediately in front of you.

    The deepest structural failure of EA is therefore not bad modelling.

    It is confusing knowledge about the enterprise with the enterprise itself.

    Dante’s damned inhabit their intellectual constructions forever.

    Enterprise architects should probably take the hint.

    Canto 10 takes place in the Sixth Circle of Hell, inside the walls of the City of Dis. Here Dante encounters the heretics, specifically those associated with the Epicurean belief that the soul dies with the body. They are imprisoned in burning open tombs. (Digital Dante)

    The canto is important because it is simultaneously about religion, Florentine politics, family, prophecy, and the strange nature of knowledge in Hell.

    The first major figure is Farinata degli Uberti, a powerful 13th-century Florentine Ghibelline leader. He rises from his tomb almost majestically, standing upright “from the waist upwards,” behaving as though even Hell cannot humiliate him. (dantelab.dartmouth.edu) Dante and Farinata immediately recognise one another as political enemies: Dante’s family were associated with the opposing Guelf faction.

    Their conversation is remarkably political. Farinata is dead, burning in Hell, yet remains obsessed with Florence and factional politics. He reminds Dante that Dante’s ancestors were expelled from Florence; Dante replies that they managed to return, unlike Farinata’s family. (Bicerin)

    This gives the canto one of its central ironies: death has not freed Farinata from worldly identity. He is still a Florentine aristocrat, still proud, still fighting political battles that no longer matter.

    Then Cavalcante de’ Cavalcanti suddenly rises from the same tomb. He is the father of Guido Cavalcanti, Dante’s friend and fellow poet. Cavalcante asks why Guido is not accompanying Dante.

    Dante answers in a way that accidentally uses the past tense. Cavalcante interprets this to mean that Guido has died. Horrified, he collapses back into the tomb before Dante can explain that Guido is actually still alive. (La Divina Commedia)

    That apparent misunderstanding leads to one of the most interesting ideas in the entire Inferno.

    The dead can see distant events in the future, but they cannot properly perceive the present. Farinata explains that their knowledge resembles farsightedness: distant things are visible, but things immediately before them are obscure. (LitCharts)

    So the damned possess a grotesque kind of prophetic knowledge.

    They can see what is coming.

    They cannot see what is happening now.

    And after the Last Judgement, when there is no longer any future to see, their knowledge will effectively disappear.

    That is part of the contrapasso—the poetic correspondence between sin and punishment. These people denied an eternal spiritual existence and concentrated excessively upon the temporal world. They now exist eternally but experience time imperfectly.

    The canto also contains an important prophecy concerning Dante himself. Farinata predicts that Dante will soon understand how difficult exile is. This anticipates Dante’s real political exile from Florence in 1302. The fictional journey of the Inferno is conventionally set in 1300, so Dante is writing retrospectively while allowing characters in Hell to “predict” events that the author already experienced.

    That date structure matters:

    • 1260: Farinata and the Ghibellines defeat the Florentine Guelfs at the Battle of Montaperti.
    • 1264: Farinata dies.
    • 1300: fictional date of Dante’s journey through Hell.
    • 1302: Dante is exiled from Florence.
    • c. 1308–1321: Dante composes much of the Divine Comedy.

    The commonly reconstructed chronology places Canto X around Holy Saturday, 9 April 1300, although the precise chronology of Dante’s journey has generated scholarly debate. (Wikipedia)

    The deeper structure of Canto 10 is therefore rather elegant. Dante puts people who believed that death ends consciousness into tombs where consciousness never ends. He gives politically obsessed men knowledge of Florence’s future but denies them knowledge of its present. He gives Cavalcante prophetic sight but prevents him from knowing whether his own son is alive.

    And Farinata is perhaps the most striking contradiction: physically damned but psychologically undefeated. His body rises from a grave while his personality remains completely intact—proud, aristocratic, partisan and contemptuous.

    That is why Canto X is one of the first places in the Inferno where the damned stop feeling merely like examples of sins and become extraordinarily convincing human personalities.

  • The Laments of Business Architecture

    Business Architecture begins with a noble ambition:

    Understand how the organisation works.

    It then immediately draws 146 coloured boxes.

    These boxes are called capabilities.

    Nobody is entirely sure what some of them mean.

    But they are arranged in three tasteful horizontal bands, so confidence rises.

    At the top are strategic capabilities.

    In the middle are core capabilities.

    At the bottom are enabling capabilities, where Finance, HR and IT have been placed like plumbing.

    Someone adds maturity scores.

    Someone else adds heat-map colours.

    A director sees a large red box marked Customer Management and asks:

    “What exactly is wrong with Customer Management?”

    Nobody can answer without opening another PowerPoint.

    Business Architecture has begun.

    1. The Capability Model Is Not the Business

    This is the first and most persistent mistake.

    A capability model describes what an organisation must be able to do.

    That can be useful.

    It is not, however, a description of how the organisation actually works.

    Consider:

    Customer Complaint Management

    Lovely capability.

    But who receives the complaint?

    Who decides whether it is valid?

    Which department owns compensation?

    Where is the case recorded?

    Which regulations apply?

    What happens when Legal becomes involved?

    How much does the process cost?

    Which systems are used?

    Where does the work queue sit?

    Who can override the decision?

    How long does resolution take?

    Which suppliers participate?

    What metric defines success?

    The capability box answers none of this.

    It sits there.

    Blue.

    Rounded corners.

    Strategic.

    This is not understanding.

    It is taxonomy.

    Taxonomy is useful.

    So is a map of mammals.

    But you would not use one to operate a dairy farm.

    2. Capability Modelling Fails Because It Removes All the Interesting Things

    The great attraction of capabilities is that they are supposed to be stable.

    Organisations change.

    Processes change.

    Technology changes.

    Org charts change.

    But the fundamental capabilities remain.

    Excellent.

    Unfortunately, almost everything management actually wants to understand is contained in the unstable parts.

    Why is this expensive?

    Why are customers unhappy?

    Why does this take six weeks?

    Why do two departments do the same thing?

    Why does nobody own this decision?

    Why can we not automate it?

    Why does changing one product require eleven systems?

    Why does Finance reconcile the same data three times?

    Why does the call centre employ 400 people?

    Why do we lose customers at this point?

    The answer is rarely:

    “Our Level Three capability decomposition is insufficiently mature.”

    The answer is usually somewhere in:

    process,

    organisation,

    information,

    systems,

    decision rights,

    controls,

    incentives,

    workload,

    economics,

    or historical stupidity.

    Capabilities abstract these things away.

    Then Business Architecture wonders why it cannot explain them.

    3. Every Capability Map Eventually Looks the Same

    A sufficiently generic capability model can describe almost any organisation.

    Strategy Management.

    Customer Management.

    Product Management.

    Financial Management.

    People Management.

    Risk Management.

    Information Management.

    Technology Management.

    Operations Management.

    Supplier Management.

    Congratulations.

    You have modelled:

    a bank,

    a university,

    a pharmaceutical company,

    a council,

    a manufacturer,

    and possibly a medium-sized criminal cartel.

    The labels are correct.

    They are also almost useless.

    The more generic the model becomes, the more reusable it is.

    The more reusable it becomes, the less it tells you about the organisation you were supposedly analysing.

    This is known as architectural elegance.

    4. The Argument About Nouns Begins

    Business architects can spend extraordinary amounts of time debating whether something is a capability.

    Is:

    Campaign Management

    a capability?

    What about:

    Marketing Campaign Management?

    Or:

    Market Engagement?

    Perhaps:

    Customer Acquisition?

    Someone will announce the capability naming convention:

    Verb-free.

    Noun-based.

    Business outcome focused.

    Technology agnostic.

    Someone else points out that Management appears forty-seven times.

    A workshop follows.

    Three senior architects spend ninety minutes discussing whether:

    Workforce Planning

    should be:

    Workforce Management

    or:

    People Planning

    Meanwhile the organisation cannot recruit nurses.

    This is Business Architecture achieving semantic purity.

    5. Then Comes the Hierarchy

    Capabilities require levels.

    Level 0.

    Level 1.

    Level 2.

    Level 3.

    Possibly Level 4 if the architect has recently purchased a large monitor.

    At Level 1:

    Manage Customers

    At Level 2:

    Manage Customer Relationships

    At Level 3:

    Manage Customer Contact

    At Level 4:

    Manage Customer Contact Preferences

    At Level 5, someone realises they have reinvented a process model.

    The rule is that capabilities describe what, not how.

    Unfortunately, after enough decomposition, what develops a suspicious resemblance to how.

    Nobody mentions this.

    6. Maturity Heat Maps: Corporate Weather Forecasting

    Once the capability model exists, somebody asks:

    “Can we assess maturity?”

    Of course.

    Everything can be scored from one to five.

    1 — Initial.

    2 — Developing.

    3 — Defined.

    4 — Managed.

    5 — Optimised.

    These words have the comforting precision of astrology.

    Workshops are held.

    Capability owners are asked to rate themselves.

    This produces fascinating results.

    Departments seeking investment score themselves red.

    Departments fearing intervention score themselves green.

    Capabilities owned by powerful executives become strategically amber.

    Capabilities nobody understands remain grey.

    The final heat map appears scientific.

    It has numbers.

    It has colours.

    It is therefore presented to the board.

    The board asks:

    “Why is Supplier Management a 2.7?”

    Nobody knows.

    But everyone agrees it should become 3.4 by 2028.

    A transformation programme is born.

    7. The Capability Owner Usually Owns Nothing

    Business Architecture loves capability ownership.

    Every capability should have an accountable owner.

    Excellent principle.

    Then reality arrives.

    Take:

    Order Fulfilment

    Sales owns the customer.

    Operations owns fulfilment.

    Finance owns invoicing.

    Supply Chain owns availability.

    IT owns the systems.

    Commercial owns the supplier contract.

    Risk owns controls.

    Nobody owns Order Fulfilment.

    So somebody is nominated.

    Perhaps the Operations Director.

    They receive an email.

    Congratulations. You are now Capability Owner for Order Fulfilment.

    “What authority does that give me?”

    None.

    “Do I own the budget?”

    No.

    “The people?”

    No.

    “The systems?”

    No.

    “The process?”

    Parts of it.

    “Can I change anything?”

    Subject to governance.

    Capability ownership has been successfully established.

    8. Capabilities Conceal Organisational Conflict

    Organisations are political systems.

    Not necessarily maliciously.

    Different units have different incentives.

    Sales wants revenue.

    Operations wants stability.

    Finance wants control.

    Product wants speed.

    Security wants fewer ways to be attacked.

    Procurement wants contractual compliance.

    Executives want all of these simultaneously by Q3.

    A capability model suppresses these conflicts.

    It draws:

    Product Management

    beside:

    Sales Management

    beside:

    Service Delivery

    as if these boxes peacefully coexist.

    They do not.

    They are fighting over:

    priorities,

    money,

    people,

    customers,

    data,

    and who gets blamed when delivery slips.

    If you want to understand how a business works, model the tensions.

    The boxes are not the interesting part.

    The arrows between them are.

    Especially the arrows nobody wants drawn.

    9. Value Streams Were Supposed to Save Us

    Eventually someone notices capability maps do not describe flow.

    Enter:

    Value Streams.

    At last.

    Something moves.

    Customer Need → Engage → Select → Purchase → Fulfil → Support.

    Beautiful.

    Except the actual organisation works like this:

    Customer asks salesperson.

    Salesperson emails Operations.

    Operations checks spreadsheet.

    Spreadsheet disagrees with ERP.

    ERP requires Finance approval.

    Finance asks Sales for contract.

    Contract is in SharePoint.

    SharePoint permissions are broken.

    Customer phones again.

    Sales escalates.

    Operations creates emergency order.

    Finance rejects it because cost centre is wrong.

    A manager approves an exception.

    The order ships.

    Nobody updates CRM.

    Customer receives two invoices.

    The official value stream remains:

    Need → Fulfilment → Value

    The customer has indeed experienced a journey.

    Possibly through purgatory.

    10. Processes Were Declared Too Detailed

    Business Architecture often distances itself from process modelling.

    “Processes are implementation detail.”

    Sometimes.

    But if the organisation wants to understand why work takes 42 days, process might be worth looking at.

    The process people know:

    where handoffs occur,

    where queues form,

    where decisions wait,

    where exceptions multiply,

    where rework happens,

    and where somebody prints the electronic form before scanning it back into the system.

    Business Architecture knows this sits within:

    Case Management Capability

    Both perspectives matter.

    Only one tells you why everyone is miserable.

    11. Organisation Charts Lie Differently

    Surely we can understand the business through structure.

    No.

    The organisation chart shows reporting lines.

    It does not show work.

    A person may report to Finance while spending 70% of their time supporting Operations.

    A central team may nominally own a service while regional offices maintain parallel shadow teams because they do not trust central delivery.

    A transformation director may have 120 people on paper and no actual authority over any of them.

    An executive assistant may have no formal decision rights and nevertheless control access to half the organisation.

    The org chart is useful.

    But it is a map of hierarchy.

    Not power.

    Not workflow.

    Not influence.

    Not dependency.

    12. The Business Is Not Its Systems Either

    IT departments frequently possess the most detailed maps in the company.

    Applications.

    Interfaces.

    Databases.

    Networks.

    Servers.

    Unfortunately, these maps describe technology rather than business behaviour.

    The ERP may support:

    Order Management,

    Inventory,

    Finance,

    Procurement,

    Planning,

    and Reporting.

    That does not mean those capabilities function well.

    A single capability may span twelve applications.

    A single application may support thirty capabilities.

    This is why colouring capability boxes according to applications produces diagrams that resemble a quilt designed during a nervous breakdown.

    13. The Real Business Lives in Work

    If you want to understand an organisation, follow actual work.

    Not policies.

    Not strategy slides.

    Not declared process.

    Actual work.

    Take one customer request.

    Follow it.

    Who receives it?

    Where does it go?

    Who touches it?

    What information is added?

    What information is missing?

    Where does it wait?

    Who makes decisions?

    What systems are used?

    What spreadsheets appear?

    What approvals occur?

    What happens when something goes wrong?

    Who phones whom?

    What does it cost?

    What outcome emerges?

    Do this repeatedly.

    You will discover the business.

    It may bear only partial resemblance to the target operating model.

    This is normal.

    So What Actually Works?

    The answer is not to abolish capability modelling.

    Capabilities are useful.

    The mistake is pretending they are sufficient.

    A serious understanding of an organisation requires several models connected together.

    Not another gigantic framework.

    A small number of views answering different questions.

    14. Start With Outcomes

    Before modelling capabilities, establish what the organisation exists to produce.

    Revenue.

    Health outcomes.

    Manufactured products.

    Successful claims.

    Completed journeys.

    Resolved cases.

    Research.

    Education.

    Public safety.

    Whatever actually matters.

    Then define measurable outcomes.

    Cost.

    Time.

    Quality.

    Risk.

    Customer result.

    Volume.

    Capacity.

    Revenue.

    Margin.

    Error rate.

    This gives architecture a reason to exist.

    Without outcomes, capability modelling becomes corporate stamp collecting.

    15. Model Value Creation End to End

    Follow the major value streams.

    Not generic ones.

    Real ones.

    For a manufacturer:

    Customer Demand → Product Configuration → Planning → Procurement → Production → Quality → Delivery → Support.

    For a council:

    Citizen Need → Request → Eligibility → Assessment → Decision → Delivery → Review.

    For a bank:

    Customer Acquisition → Onboarding → Account Servicing → Transaction → Exception → Closure.

    Do not stop at departmental boundaries.

    The whole point is to cross them.

    That is where most dysfunction lives.

    16. Attach Capabilities to the Flow

    Now capabilities become useful.

    For each stage of a value stream ask:

    What capabilities are required here?

    This gives capabilities context.

    Instead of:

    Customer Management = maturity 2.6

    you get:

    Customer Identity Management is preventing digital onboarding because manual validation adds two days to 38% of applications.

    Now you have architecture.

    One is a coloured box.

    The other is a problem worth solving.

    17. Map the Operating Model

    For each significant area, model:

    People — who performs the work?

    Process — how does work move?

    Information — what information is created, consumed and authoritative?

    Technology — what systems support it?

    Decision rights — who can decide what?

    Controls — what constrains the work?

    Locations — where is the work performed?

    Suppliers — what external parties participate?

    Economics — what does it cost?

    Now you can understand structure.

    Not merely capability.

    18. Model Decisions

    This is enormously neglected.

    Businesses are decision machines.

    Approve loan.

    Accept risk.

    Set price.

    Release product.

    Prioritise work.

    Escalate incident.

    Hire employee.

    Pay supplier.

    Close case.

    Ask:

    Who makes the decision?

    Using what information?

    Under what authority?

    Within what time?

    What happens if they do not decide?

    What decisions are automated?

    Which require human judgement?

    Which are escalated?

    You will often discover that process delays are actually decision delays.

    A case does not spend twelve days being processed.

    It spends eleven days waiting for Susan to approve it.

    This is useful information.

    19. Model Information Flows

    Follow information as carefully as work.

    What is the authoritative source?

    Where is it copied?

    Who edits it?

    Who reconciles it?

    Where is it transformed?

    Where does meaning change?

    If five departments maintain five definitions of “customer,” no capability heat map will save you.

    Many organisational problems that appear procedural are actually informational.

    The business cannot act coherently because it does not share a coherent view of reality.

    That is architecture.

    20. Measure Queues and Handoffs

    A business is full of queues.

    Incoming cases.

    Orders awaiting approval.

    Projects awaiting finance.

    Contracts awaiting legal review.

    Incidents awaiting triage.

    Data awaiting reconciliation.

    Queues reveal capacity problems.

    Handoffs reveal organisational friction.

    Measure:

    arrival rate,

    processing time,

    waiting time,

    rework,

    exceptions,

    queue depth,

    handoff count.

    You do not need advanced mathematics to discover that a process requiring fourteen approvals will be slow.

    Although advanced mathematics can make the PowerPoint more frightening.

    21. Model Economics

    Capability maps are strangely reluctant to discuss money.

    Businesses are not.

    For major flows understand:

    cost per transaction,

    cost per customer,

    cost per product,

    labour cost,

    technology cost,

    supplier cost,

    failure cost,

    rework cost,

    cost of control.

    Then transformation can focus on actual leverage.

    A £4 million project to optimise a capability costing £300,000 annually may be architecturally elegant and economically deranged.

    Business Architecture should occasionally mention this.

    Finance will appreciate the novelty.

    22. Model Variation

    The average process rarely exists.

    There is:

    normal work,

    priority work,

    exception work,

    regulatory work,

    manual work,

    international work,

    legacy work,

    VIP work,

    and whatever Finance does at year end.

    Architecture must understand variants.

    Often 80% of cost is created by 20% of exceptional cases.

    The official process describes the 80%.

    The organisation spends its life dealing with the other 20%.

    23. Observe Work Instead of Workshoping It

    Workshops are useful.

    But people describe what they believe happens.

    Observation reveals what happens.

    Sit with the service desk.

    Sit with accounts payable.

    Sit with planners.

    Sit with nurses.

    Sit with customer service.

    Watch.

    Ask:

    “What are you doing now?”

    “Why?”

    “Where did that information come from?”

    “What happens next?”

    “What happens when this fails?”

    “Why are you copying that into Excel?”

    The spreadsheet is particularly important.

    Spreadsheets are where organisations store truths their formal systems cannot accommodate.

    They are the dark matter of enterprise architecture.

    24. Find the Shadow Organisation

    Every mature enterprise contains an unofficial organisation.

    It consists of:

    personal spreadsheets,

    shared mailboxes,

    informal phone calls,

    Teams chats,

    local databases,

    manual reconciliations,

    favours,

    exceptions,

    and people who know who to ask.

    Do not dismiss this as poor governance.

    It often exists because the formal structure does not work.

    The shadow organisation is diagnostic.

    It tells you where the official architecture is failing.

    Study it before trying to kill it.

    25. Map Causality, Not Just Structure

    This is the important shift.

    Traditional Business Architecture often says:

    These things exist.

    Better architecture asks:

    What causes what?

    Example:

    Customer complaints are high.

    Why?

    Delivery dates are missed.

    Why?

    Production schedules change late.

    Why?

    Component availability is unreliable.

    Why?

    Supplier forecasts are poor.

    Why?

    Planning data is fragmented.

    Why?

    Three business units forecast independently.

    Now you have a causal chain.

    Improving Complaint Management Capability would not solve it.

    Improving upstream planning might.

    This is the difference between architecture and cataloguing.

    26. Build a Business Knowledge Graph

    If you want a genuinely useful enterprise model, stop treating architecture objects as isolated diagrams.

    Represent relationships.

    Capability:

    supports Value Stream Stage.

    Process:

    realises Capability.

    Organisation Unit:

    performs Process.

    Role:

    makes Decision.

    Application:

    supports Process.

    Data Object:

    informs Decision.

    Control:

    constrains Process.

    Supplier:

    provides Service.

    Metric:

    measures Outcome.

    Cost:

    attaches to Activity.

    Risk:

    threatens Outcome.

    Now the enterprise becomes queryable.

    You can ask:

    Which applications support customer onboarding?

    Which processes rely on the retiring platform?

    Which capabilities depend on Supplier X?

    Which decisions require data from System Y?

    Which value streams are affected if Site Z closes?

    Which organisational units perform duplicated activities?

    That is vastly more useful than staring at a Level Two capability map.

    27. Keep the Capability Model Small

    A useful capability model might contain:

    50–150 meaningful capabilities.

    Not 800.

    When everything becomes a capability, nothing is a capability.

    Use capability modelling to create a stable vocabulary.

    Then stop decomposing.

    The purpose is orientation.

    Not molecular analysis.

    28. Stop Scoring Everything

    Do not maturity-score every capability because the spreadsheet has a column.

    Assess capabilities when there is a question.

    Where should we invest?

    Where are risks concentrated?

    What enables strategy?

    Where are major cost drivers?

    What constrains growth?

    Use evidence.

    Metrics.

    Observed performance.

    Technology condition.

    Skills.

    Process outcomes.

    Do not ask managers:

    “How mature do you feel your capability is from one to five?”

    This is not architecture.

    It is organisational astrology with Excel.

    29. Model Change as Hypotheses

    Transformation should say:

    If we change X, we expect Y because Z.

    Example:

    If we automate eligibility validation, average case handling time should fall from 27 minutes to 18 minutes because staff currently spend nine minutes retrieving information from three systems.

    Now measure it.

    If nothing improves, the hypothesis was wrong.

    Architecture learns.

    This is vastly healthier than declaring:

    Digital Case Management Capability uplift: Green.

    30. Connect Strategy to Evidence

    Strategy says:

    Improve customer experience.

    Business Architecture should translate:

    Which customer outcomes?

    Which journeys?

    Which measurable pain points?

    Which capabilities contribute?

    Which processes create those outcomes?

    Which systems constrain improvement?

    What investment changes the causal chain?

    That is genuine traceability.

    Not:

    Strategic Theme → Capability → Initiative.

    Three boxes and an arrow may satisfy the framework.

    They do not necessarily explain anything.

    The Actual Model of the Business

    If you genuinely want to understand how a business is structured and how it improves, think of it as seven interacting systems.

    1. Value

    What outcomes does the organisation produce, for whom, and why do they matter?

    2. Work

    What activities transform demand into those outcomes?

    3. Organisation

    Who performs the work, and where does authority sit?

    4. Information

    What facts, records and knowledge make the work possible?

    5. Technology

    What systems automate, constrain or enable the work?

    6. Economics

    What resources are consumed and where does value leak?

    7. Governance

    Who decides, who controls, who accepts risk and who is accountable?

    Capabilities sit across these systems as a vocabulary describing what must be possible.

    They are not the systems themselves.

    That distinction matters enormously.

    The Final Lament

    The tragedy of Business Architecture is not that capability modelling is useless.

    It is that capability modelling is seductive.

    It produces something quickly.

    It looks strategic.

    It fits on a wall.

    It can be coloured.

    Executives can understand it in thirty seconds.

    Consultancies can benchmark it.

    Tools can store it.

    Architects can argue about it indefinitely.

    And none of this guarantees that anyone understands how the business actually works.

    The business itself is messier.

    It is people making decisions with incomplete information.

    It is customers creating demand.

    It is work moving through queues.

    It is systems exchanging data.

    It is budgets constraining choices.

    It is suppliers failing.

    It is controls slowing things down for good reasons and bad ones.

    It is informal networks compensating for broken formal structures.

    It is history embedded in process.

    It is politics embedded in organisation.

    It is economics embedded in technology.

    And improvement happens when you understand those relationships well enough to change the right one.

    So keep the capability map.

    Hang it on the wall.

    Use it as the index.

    But when someone points at a large red box labelled:

    Customer Management

    and says:

    “We need to improve this capability,”

    do not immediately launch a £20 million transformation programme.

    Ask:

    “What exactly is happening to customers?”

    Then follow the work.

    Follow the decisions.

    Follow the data.

    Follow the money.

    Follow the queues.

    Follow the exceptions.

    Follow the spreadsheets.

    Eventually you will find the actual business.

    It is usually nowhere near the capability map.

  • Zen and the Art of Solution Architecture

    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.

  • The Tao of Solution Assurance

    Solution Assurance is the ancient corporate discipline of examining a design after everybody important has already committed to it, identifying several serious risks, documenting them carefully, and then watching the programme proceed exactly as before.

    It is sometimes confused with governance.

    This is unfair to governance.

    Governance occasionally stops things.

    Solution Assurance exists in the delicate philosophical territory between architecture, risk management, quality control and ritual sacrifice.

    Its purpose is simple:

    To provide confidence.

    Not necessarily correctness.

    Not necessarily safety.

    Certainly not certainty.

    Confidence.

    Confidence is extremely important because executives become nervous when presented with reality.

    A red RAG status creates anxiety.

    A green RAG status creates confidence.

    An amber RAG status creates meetings.

    Therefore the experienced Solution Assurance practitioner understands the first teaching:

    The colour is not the risk.

    The colour is what management can emotionally tolerate this week.

    1. Assurance Begins After the Decision

    In theory, assurance should begin early.

    In practice, the sequence is:

    1. Vendor selected.
    2. Contract negotiated.
    3. Budget announced.
    4. Programme mobilised.
    5. Launch date communicated.
    6. Solution designed.
    7. Assurance invited.

    This is efficient because it prevents inconvenient technical facts from interfering with commercial momentum.

    You will receive an email.

    Subject: Architecture Assurance – Urgent

    It will say:

    Hi,

    Could you please provide assurance against the attached design? We are seeking approval at Thursday’s board.

    This should be straightforward as the solution has already been reviewed extensively by the supplier.

    Thanks.

    It is Wednesday afternoon.

    The attachment is 184 pages.

    Half the diagrams are unreadable.

    The security section says:

    Security requirements will be confirmed during implementation.

    The implementation began three months ago.

    Welcome to Assurance.

    2. “Assured” Does Not Mean “Good”

    A solution can be:

    technically questionable,

    operationally immature,

    poorly documented,

    expensive,

    dependent on unsupported technology,

    and nevertheless assured.

    This is because assurance is rarely a binary judgement.

    It is more sophisticated.

    You can say:

    Assured subject to conditions.

    This is one of the great phrases of corporate civilisation.

    It means:

    We have identified several reasons why this may go badly wrong, but everyone has a steering committee in ten minutes.

    The conditions are then recorded.

    The programme acknowledges them.

    The programme continues.

    Six months later, during the incident review, someone asks:

    “Why wasn’t this risk identified?”

    You produce the assurance report.

    Page 17.

    Risk 4.

    Highlighted.

    Bold.

    Rated Red.

    The room becomes quiet.

    This is the closest Solution Assurance gets to physical pleasure.

    3. Never Ask “Is It Secure?”

    This is not a useful question.

    Everything is secure in PowerPoint.

    Ask:

    How is authentication implemented?

    How are privileged accounts controlled?

    Where are secrets stored?

    What is logged?

    Who can access the logs?

    How is encryption implemented?

    Who owns the keys?

    How are certificates rotated?

    What happens if identity is unavailable?

    How are vulnerabilities patched?

    What is exposed externally?

    How is compromise detected?

    The supplier will respond:

    “We follow industry best practice.”

    Ask which one.

    They will become irritated.

    This is progress.

    4. The Supplier Has Assured Itself

    One of the more delightful developments in enterprise technology is supplier-provided assurance.

    The supplier has reviewed the supplier’s design of the supplier’s product and concluded that the supplier recommends it.

    Excellent.

    A presentation will contain:

    PROVEN ARCHITECTURE

    ENTERPRISE GRADE

    SECURE BY DESIGN

    HIGHLY AVAILABLE

    SCALABLE

    There may be a Gartner logo.

    There will certainly be clouds.

    Your job is to ask:

    “Where is customer data stored?”

    The account manager will say:

    “In our secure cloud.”

    You ask:

    “Which country?”

    There will be a pause.

    “Within our global infrastructure.”

    This is not a country.

    Continue.

    5. Evidence Is Better Than Reassurance

    Programmes enjoy reassurance.

    “We’ve tested it.”

    “The supplier is confident.”

    “Security has been involved.”

    “Operations are comfortable.”

    “The business is happy.”

    None of these are evidence.

    Ask:

    Where are the test results?

    Where is the threat model?

    Where is the support model?

    Where is the capacity forecast?

    Where is the recovery test?

    Where is the data-flow diagram?

    Where is the licensing assessment?

    Who signed off the operational acceptance?

    At this point someone will accuse you of being “very detailed.”

    That is because evidence is offensive when reassurance was expected.

    6. The Red Flag Is Usually in the Footnote

    Executive summaries are optimistic.

    Detailed sections are cautious.

    Footnotes are where truth goes to hide.

    The first page may say:

    The proposed solution meets all strategic requirements.

    Page 73 may say:

    Note: current design does not provide automatic failover between sites.

    Page 106:

    Backup integration is outside current scope.

    Page 129:

    Existing identity platform is not formally supported.

    Page 151:

    Performance testing has not yet been scheduled.

    Page 162:

    Licensing position remains subject to vendor clarification.

    The executive summary will remain green.

    Your job is to make page 162 somebody’s problem.

    7. “Out of Scope” Is a Magical Phrase

    If something difficult cannot be solved, it can often be moved out of scope.

    Disaster recovery?

    Out of scope.

    Operational monitoring?

    Out of scope.

    Data migration reconciliation?

    Out of scope.

    Decommissioning?

    Out of scope.

    Security hardening?

    Phase Two.

    When enough things are out of scope, the project becomes very simple.

    It may no longer deliver a usable service.

    But the project is beautifully controlled.

    Solution Assurance should always ask:

    “Out of scope for whom?”

    If the answer is:

    “Operations will pick it up later.”

    You have discovered a landfill site.

    8. Phase Two Does Not Exist

    There is Phase One.

    Then there is production.

    Phase Two is a spiritual concept.

    It contains:

    technical debt,

    nice-to-have security controls,

    automation,

    performance optimisation,

    proper monitoring,

    full documentation,

    removal of temporary accounts,

    legacy decommissioning,

    and everything everyone promised would happen after go-live.

    Phase Two is funded from next year’s budget.

    Next year arrives.

    The programme is closed.

    A new transformation initiative begins.

    Phase Two becomes “legacy remediation.”

    Eventually it becomes somebody’s audit finding.

    9. RAG Status Is Applied Psychology

    Red means:

    Something is wrong.

    Amber means:

    Something is wrong but we are still discussing it.

    Green means:

    Nobody senior has asked the right question yet.

    There is also:

    Amber-Green.

    This is corporate synaesthesia.

    Amber-Green means:

    There are substantial concerns but the programme director has a board meeting.

    There is also:

    Green with commentary.

    This means:

    Please read the commentary.

    Nobody reads the commentary.

    10. Assurance Meetings Are Linguistic Combat

    A typical assurance meeting contains:

    the architect,

    the programme manager,

    the delivery lead,

    the supplier,

    security,

    operations,

    and somebody from PMO who has never spoken but is taking frighteningly good notes.

    You ask:

    “What happens if the database becomes unavailable?”

    Supplier:

    “The platform is highly resilient.”

    You:

    “How?”

    Supplier:

    “It uses a clustered architecture.”

    You:

    “What is the failover time?”

    Supplier:

    “It is designed for rapid recovery.”

    You:

    “What is the tested failover time?”

    Supplier:

    “We haven’t tested that scenario yet.”

    Programme Manager:

    “Is this really necessary for this stage?”

    You:

    “Yes.”

    Programme Manager:

    “Can we record it as an action?”

    This is how architecture becomes archaeology.

    11. The Action Log Is Where Risks Go to Hibernate

    Actions are useful.

    Until there are 147 of them.

    Every uncomfortable issue can be transformed into an action.

    Action 37: Confirm DR capability.

    Owner: Supplier.

    Due date: Friday.

    Friday arrives.

    Status:

    Open – awaiting supplier input.

    Next week:

    Open – supplier investigating.

    Next month:

    Open – to be addressed post go-live.

    Three months later:

    Closed – transferred to BAU.

    Nothing has actually happened.

    But the action is closed.

    Governance has achieved transcendence.

    12. “Accepted Risk” Requires Someone to Accept It

    Teams sometimes say:

    “The business has accepted the risk.”

    Ask:

    “Who?”

    A silence follows.

    “The business.”

    The business is not a person.

    The business does not have an email address.

    The business cannot attend court.

    The business cannot explain itself to an auditor.

    Risk acceptance requires an accountable individual with authority to accept the consequence.

    Find that person.

    Make them understand the risk.

    Get the acceptance recorded.

    You will be accused of bureaucracy.

    Ignore this.

    The same people will become intensely interested in documentation after the failure.

    13. Risk Language Must Describe Consequences

    Bad risk:

    There is a risk that the solution may not be resilient.

    Excellent.

    Meaningless.

    Better:

    Failure of the primary database node may cause complete service outage because automatic failover has not been implemented or tested. Recovery is dependent on manual intervention by the supplier. Estimated recovery time is unknown.

    Now management becomes interested.

    Especially the word unknown.

    Executives dislike unknown.

    This is useful.

    14. Assurance Is Not About Catching People Out

    Mostly.

    The objective is to expose uncertainty before uncertainty becomes outage.

    That requires uncomfortable questions.

    Not theatrical aggression.

    Do not enter a review saying:

    “This design is rubbish.”

    Ask:

    “What requirement led to this pattern?”

    Sometimes there is a good answer.

    Sometimes the answer is:

    “The vendor said so.”

    Sometimes:

    “We’ve always done it this way.”

    Sometimes:

    “We copied another project.”

    Sometimes nobody knows.

    The last one is surprisingly common.

    15. Architecture Debt Must Be Visible

    Every programme accumulates compromises.

    Temporary integration.

    Manual failover.

    Unsupported browser.

    Shared service account.

    Single region deployment.

    Missing monitoring.

    One firewall exception.

    One more firewall exception.

    A third firewall exception to make the first two work.

    Each seems reasonable alone.

    Together they form a service held together by hope.

    Assurance should aggregate these.

    A solution with twenty individually tolerable risks may be collectively intolerable.

    Programmes dislike this idea.

    They prefer risks in separate rows.

    Separate rows look smaller.

    16. Never Allow “Known Limitation” to Become “Normal”

    Known limitation is often corporate language for:

    We know it is broken.

    Examples:

    “The service requires restart every Sunday.”

    “The interface occasionally duplicates messages.”

    “Users must clear browser cache after upgrades.”

    “Failover can cause data inconsistency.”

    “Support requires local administrator access.”

    These may be genuine limitations.

    But they must have consequences, ownership and remediation.

    Otherwise three years later someone will say:

    “That’s just how it works.”

    This is how defects become culture.

    17. Test Evidence Is More Valuable Than Test Plans

    A test plan says:

    “We intend to test resilience.”

    Test evidence says:

    “We unplugged it and watched what happened.”

    Prefer the second.

    Ask for:

    load test results,

    failover evidence,

    restore evidence,

    penetration test findings,

    security scans,

    integration results,

    user acceptance outcomes.

    Never be impressed by:

    TESTING COMPLETE

    Ask:

    “What failed?”

    If the answer is:

    “Nothing.”

    Be suspicious.

    Either the system is extraordinary or the testing was decorative.

    18. If Nobody Tested Failure, Nobody Tested the System

    Successful transactions are pleasant.

    Failures are architecture.

    Disconnect the network.

    Kill the service.

    Expire the token.

    Remove the DNS record.

    Fill the disk.

    Lose the node.

    Corrupt the message.

    Throttle the API.

    Break authentication.

    Then observe.

    Systems reveal their real architecture when something goes wrong.

    19. Operational Acceptance Is Not “Ops Were Invited”

    Programs sometimes claim Operations has accepted a service because someone from Operations attended a meeting.

    That is not acceptance.

    Ask:

    Do they have monitoring?

    Runbooks?

    Access?

    Training?

    Escalation paths?

    Support contracts?

    Backup procedures?

    Recovery procedures?

    Capacity information?

    Known-error records?

    Service ownership?

    If not, Operations has not accepted the service.

    They have merely witnessed its birth.

    20. The Handover Document Is Usually Fiction

    A project handover document says:

    “BAU support will be provided by Infrastructure Services.”

    Infrastructure Services says:

    “Never heard of it.”

    Project:

    “They were on the distribution list.”

    Infrastructure:

    “So was Catering.”

    Project:

    “We assumed they were aware.”

    Operations:

    “We assumed you had a support contract.”

    Supplier:

    “Support contract?”

    Silence.

    The solution is now live.

    Congratulations.

    21. Security Exceptions Breed

    One exception is temporary.

    Two exceptions are pragmatic.

    Three exceptions are architecture.

    Assurance must track:

    what control is bypassed,

    why,

    who approved it,

    what compensating controls exist,

    when the exception expires.

    Otherwise the exception survives.

    After several years it becomes:

    legacy security model.

    People will then be afraid to remove it.

    22. Data Sovereignty Is Not Where the Salesman Lives

    Ask where data resides.

    The vendor says:

    “UK hosted.”

    Ask:

    Backups?

    Logs?

    Telemetry?

    Support access?

    Disaster recovery?

    Sub-processors?

    AI services?

    Analytics?

    Suddenly the United Kingdom becomes geographically flexible.

    Assurance exists partly to continue asking after the first comforting answer.

    23. “Encrypted” Is the Beginning of the Question

    Encrypted where?

    At rest?

    In transit?

    Client-side?

    Server-side?

    Which algorithm?

    Who holds the keys?

    Can the provider decrypt it?

    Can administrators?

    How are keys rotated?

    What happens during recovery?

    If the vendor says:

    “AES-256.”

    Do not applaud.

    AES-256 is not an architecture.

    It is a cipher.

    24. Backup Is Not Resilience

    A backup protects data.

    It does not automatically protect:

    availability,

    configuration,

    identity,

    network connectivity,

    integration state,

    DNS,

    certificates,

    secrets,

    or the ability of anyone to remember how to restore the bloody thing.

    Assurance should ask for recovery, not backup.

    “How quickly can you restore the service from nothing?”

    Watch confidence decrease.

    This is healthy.

    25. DR Documentation Is Often Fantasy Literature

    The DR plan may say:

    In the event of primary site loss, service will fail over to secondary site.

    Ask:

    Who performs the failover?

    “How?”

    “Using the DR process.”

    “Where is that?”

    “In the DR document.”

    You are already reading the DR document.

    This is recursive resilience.

    Continue until someone admits Gary knows how.

    26. Capacity Is Not “Scalable”

    Supplier:

    “The platform scales automatically.”

    You:

    “To what?”

    Supplier:

    “As demand increases.”

    You:

    “What is the tested maximum?”

    Supplier:

    “That depends on configuration.”

    You:

    “What configuration are we buying?”

    Supplier:

    “We can confirm that during implementation.”

    Programme:

    “Can we move on?”

    No.

    We cannot.

    27. Performance Requirements Need Numbers

    “Fast.”

    No.

    “Responsive.”

    No.

    “Near real time.”

    Absolutely not.

    Use:

    95th percentile response under two seconds.

    10,000 concurrent users.

    500 transactions per second.

    Batch completion before 06:00.

    Data propagation within 30 seconds.

    Numbers can be tested.

    Adjectives can only be discussed.

    28. Monitoring Is Not a Dashboard Nobody Watches

    A colourful dashboard is not monitoring.

    Ask:

    Who receives alerts?

    What thresholds exist?

    What constitutes service degradation?

    Who responds?

    How quickly?

    Are alerts tested?

    Are dependencies monitored?

    Can users be affected while every infrastructure metric remains green?

    The answer to the last question is usually yes.

    Infrastructure can be perfectly healthy while the application is utterly fucked.

    This is why service monitoring exists.

    In theory.

    29. Observability Is Not Logging Everything

    Modern systems can produce terrifying quantities of logs.

    This is not observability.

    Observability means being able to answer:

    What happened?

    Where?

    When?

    To whom?

    Why?

    Across which components?

    A petabyte of JSON nobody can correlate is merely expensive confusion.

    30. Compliance Is Not Security

    A system may pass an audit and still be insecure.

    A system may be secure and still fail compliance.

    These overlap.

    They are not identical.

    Checkbox security produces magnificent evidence packs.

    Attackers do not generally read them.

    31. The Penetration Test Is Not an Exorcism

    A penetration test does not bless the system.

    It tests a defined scope at a point in time.

    Ask:

    What was excluded?

    Was authentication tested?

    APIs?

    Internal interfaces?

    Cloud configuration?

    Privilege escalation?

    Mobile clients?

    Infrastructure?

    Was the production configuration actually tested?

    The executive summary will say:

    No critical findings.

    Page twelve may contain eight High findings.

    Read page twelve.

    32. “Low Risk” Findings Can Combine Into a High Risk System

    Weak password policy.

    Verbose error messages.

    Excessive permissions.

    Unrestricted outbound connectivity.

    Poor logging.

    Individually low or medium.

    Together:

    Excellent afternoon for an attacker.

    Assurance must think in systems.

    Risk registers often do not.

    33. Dependencies Are Where Assurance Earns Its Keep

    The application may be resilient.

    But it depends on:

    DNS,

    identity,

    network,

    API gateway,

    certificate authority,

    message broker,

    database,

    storage,

    third-party payment gateway,

    and an ancient file transfer server in Swindon.

    Ask what happens when each fails.

    Someone will say:

    “That is outside our solution boundary.”

    Failure does not respect solution boundaries.

    34. The Boundary Diagram Is a Negotiation

    Projects draw solution boundaries partly to define ownership.

    Unfortunately, the customer experience does not care.

    If your beautifully assured application cannot function because the corporate proxy is unavailable, the service is unavailable.

    Users will not say:

    “Fortunately, the application component remained compliant with its architecture.”

    They will say:

    “It doesn’t fucking work.”

    Assure the service.

    Not just the boxes.

    35. Third Parties Are First-Class Risks

    Vendor:

    “We use a specialist third party for that.”

    Assurance:

    “Who?”

    Vendor:

    “That information is commercially sensitive.”

    Assurance:

    “They process our data.”

    Vendor:

    “We can provide details under NDA.”

    Good.

    Continue.

    Subcontracting does not outsource accountability.

    It merely lengthens the incident bridge.

    36. Exit Strategy Is Architecture

    Every supplier relationship ends.

    Eventually.

    Ask:

    How do we retrieve data?

    In what format?

    How long does extraction take?

    What does it cost?

    Can another provider consume it?

    What happens to backups?

    When is data deleted?

    How do we verify deletion?

    What happens if the supplier becomes insolvent?

    Procurement may consider these gloomy questions.

    They are.

    So is divorce law.

    Still useful.

    37. Licensing Assurance Exists Because Lawyers Enjoy Ambiguity

    Technical teams think software licensing is about software.

    It is actually about contractual nouns.

    Installed.

    Used.

    Accessed.

    Processor.

    Core.

    Named user.

    Authorised user.

    Indirect use.

    Backup.

    Failover.

    Test.

    Development.

    Virtualisation.

    Cloud mobility.

    Multiplexing.

    Ask whether the architecture changes licence exposure.

    If nobody knows, record the uncertainty.

    Do not allow:

    “The account manager said it was fine.”

    The account manager will not attend the audit.

    38. Cost Assurance Must Include Success

    Projects estimate cost at average load.

    Success changes this.

    More users.

    More storage.

    More API traffic.

    More logs.

    More backups.

    More egress.

    More licences.

    Ask:

    “What does this cost if adoption is twice forecast?”

    If the answer is:

    “That would be a good problem to have.”

    You have found someone who does not pay cloud bills.

    39. Assumptions Are Risks Wearing Fake Moustaches

    Designs contain assumptions.

    “Existing WAN has sufficient capacity.”

    “Users have modern browsers.”

    “Partner API supports required volumes.”

    “Directory contains accurate attributes.”

    “Legacy system will remain available.”

    “We assume 20% annual growth.”

    Assumptions should be validated.

    Otherwise they are risks disguised grammatically.

    40. “To Be Confirmed” Has an Expiry Date

    TBC is acceptable early.

    Later, it becomes dangerous.

    At design review:

    TBC.

    At build:

    TBC.

    At test:

    TBC.

    At go-live:

    TBC.

    In the incident report:

    Root cause.

    Every TBC should have:

    an owner,

    a due date,

    and consequences if unresolved.

    Otherwise you are manufacturing uncertainty professionally.

    41. Decision Ownership Matters

    Who decided to accept single-region hosting?

    Who decided not to implement automated recovery?

    Who approved the unsupported integration?

    Who accepted the licence risk?

    The answer cannot be:

    “The programme.”

    Programs do not go to disciplinary hearings.

    People do.

    Architecture decisions require named ownership.

    This tends to improve decision quality dramatically.

    42. Escalation Is Not Failure

    Assurance practitioners sometimes avoid escalation because they do not want to appear obstructive.

    This is cowardice wearing stakeholder-management clothing.

    If a material risk exceeds your authority, escalate it.

    Calmly.

    With evidence.

    Without drama.

    Then let the accountable person decide.

    Your job is not to win.

    Your job is to ensure the decision is conscious.

    43. A Waiver Is Not a Magic Spell

    Sometimes a programme requests an architectural waiver.

    Fine.

    A waiver should state:

    what standard is being waived,

    why,

    risk created,

    compensating controls,

    owner,

    expiry.

    A permanent waiver is not a waiver.

    It is a new standard nobody has admitted exists.

    44. Mature Assurance Knows When to Stop

    Not every system requires military-grade resilience.

    Not every application needs active-active deployment across continents.

    Not every dataset needs hardware-backed encryption keys rotated hourly.

    Assurance must be proportionate.

    Risk depends on consequence.

    The lunch-menu application can occasionally fail.

    The air-traffic control system should perhaps have stronger aspirations.

    Apply judgement.

    Otherwise assurance itself becomes the risk.

    45. The Assurance Practitioner Must Understand Delivery

    A reviewer who has never built anything is dangerous.

    They may demand:

    perfect documentation,

    zero technical debt,

    complete automation,

    full resilience,

    maximum security,

    infinite scalability,

    and delivery by Friday.

    Architecture is trade-off.

    Assurance must understand trade-off.

    Ask whether risk is conscious and proportionate.

    Do not demand utopia.

    Utopia is not supportable.

    46. “Industry Best Practice” Is Often Consultancy Incense

    Whenever someone invokes best practice, ask:

    For this context?

    For this scale?

    For this threat model?

    For this regulatory environment?

    For this operating model?

    A multinational bank and a village museum do not necessarily require identical controls.

    If your assurance framework says they do, the framework is the thing requiring assurance.

    47. Templates Are Useful Until They Replace Thinking

    Assurance templates provide consistency.

    Good.

    But the template does not know what is important.

    A reviewer may spend twenty minutes checking whether every heading is populated while missing the fact that the system has no backup.

    This is called compliance theatre.

    Never confuse completeness of form with completeness of thought.

    48. Architecture Boards Attract PowerPoint

    A board pack may contain:

    executive summary,

    strategic alignment,

    business outcomes,

    capability mapping,

    technology principles,

    risk summary,

    implementation roadmap.

    Excellent.

    Ask:

    “What port does it use?”

    Nobody knows.

    This is not because ports are strategically important.

    It is because detail reveals whether anybody has actually designed anything.

    Move between levels.

    That is the job.

    49. The Best Assurance Question Is Often “Show Me”

    “We have backups.”

    Show me a restore.

    “We monitor it.”

    Show me an alert.

    “We tested failover.”

    Show me the evidence.

    “Operations accepted it.”

    Show me the acceptance.

    “The vendor supports this.”

    Show me where.

    “Security approved it.”

    Show me the decision.

    “Licensing is covered.”

    Show me the entitlement.

    This phrase eliminates approximately seventy percent of enterprise bullshit.

    Use responsibly.

    50. Assurance Must Survive Executive Pressure

    Someone important will eventually say:

    “Can you just sign this off?”

    No.

    You can review it.

    You can assure it.

    You can identify conditions.

    You can record risks.

    You cannot transform uncertainty into certainty because a meeting starts at 14:00.

    If necessary say:

    “I can provide assurance based on the evidence available.”

    This is polite.

    It also creates a clear boundary around reality.

    51. Beware the Urgent Executive Exception

    There is always one.

    “We need to bypass the normal process.”

    Why?

    “Business-critical.”

    Everything is business-critical shortly before a board meeting.

    Urgency may justify accelerated assurance.

    It does not justify no assurance.

    Fast decisions need clearer risk statements, not fewer.

    52. The Incident Will Reopen Every Argument

    After an outage, people become historians.

    Someone will say:

    “Nobody could have predicted this.”

    Check your assurance report.

    Often, someone did.

    Another will say:

    “This was an unforeseeable dependency.”

    Check the architecture review.

    It may be listed.

    A third will say:

    “We understood the risk.”

    Ask for acceptance.

    Silence.

    This is why documentation matters.

    Not for blame.

    For organisational memory.

    Blame is merely a side effect.

    53. Lessons Learned Are Usually Lessons Observed

    The post-incident review produces:

    Improve documentation.

    Engage stakeholders earlier.

    Strengthen testing.

    Clarify ownership.

    Review monitoring.

    These lessons have appeared in every enterprise incident review since approximately 1987.

    A lesson is not learned because it is written.

    It is learned when behaviour changes.

    Otherwise it is merely rediscovered wisdom.

    54. Assurance Findings Need Closure Criteria

    Finding:

    “Improve monitoring.”

    Impossible to close meaningfully.

    Better:

    “Implement synthetic transaction monitoring for customer login and payment workflows, with alerts routed to 24×7 support and tested before production release.”

    Now closure can be evidenced.

    Specificity is the enemy of ceremonial governance.

    55. Do Not Let the Programme Mark Its Own Homework

    Programme:

    “We have resolved Finding 12.”

    Assurance:

    “How?”

    Programme:

    “We discussed it.”

    No.

    Resolution requires evidence.

    Otherwise the student has written:

    Corrected

    in the margin of their own exam paper.

    56. Some Risks Should Stop Go-Live

    This will upset people.

    Good.

    Examples may include:

    known exploitable security defects,

    no viable recovery capability for a critical service,

    unresolved data-loss risk,

    unsupported production configuration,

    absence of required regulatory controls,

    major capacity failure under expected load.

    A go-live date is not a law of physics.

    Sometimes the correct assurance outcome is:

    “No.”

    This is rare.

    It should remain available.

    Otherwise assurance is merely decorative.

    57. “Conditional Go-Live” Means Conditions

    Do not approve go-live subject to ten conditions which cannot realistically be completed after go-live.

    That is not conditional approval.

    That is denial with poor emotional resilience.

    If the condition matters before production, require it before production.

    If it can genuinely follow, assign:

    owner,

    date,

    risk,

    escalation.

    Words must mean things.

    This principle is surprisingly controversial.

    58. Assurance Should Reduce Surprise

    Perfect systems do not exist.

    Incidents will happen.

    The objective is not zero failure.

    It is fewer stupid surprises.

    You should not discover after go-live that:

    the backup never worked,

    the supplier does not provide 24×7 support,

    the application cannot run in DR,

    the licence excludes virtualisation,

    the logs contain personal data,

    the database has a 2TB limit,

    the certificate renewal is manual,

    or the only administrator is on maternity leave.

    These are not black swans.

    They are pigeons standing directly in front of you.

    59. The Highest Form of Assurance Is Boring Production

    No P1 incidents.

    Predictable patching.

    Tested recovery.

    Clear ownership.

    Known capacity.

    Controlled change.

    Understandable costs.

    Useful monitoring.

    Boring.

    Architects sometimes dislike boring systems.

    Operations loves them.

    Customers rarely complain that their transaction completed without architectural excitement.

    Boring is underrated.

    60. The Final Tao

    The novice believes Solution Assurance exists to approve solutions.

    The experienced practitioner knows it exists to expose decisions.

    The master understands that the organisation will sometimes make the wrong decision anyway.

    Your role is therefore not omnipotence.

    It is clarity.

    Make assumptions visible.

    Make dependencies visible.

    Make consequences visible.

    Make ownership visible.

    Ask for evidence.

    Challenge optimism.

    Separate confidence from fact.

    Do not allow green status to erase red engineering.

    Do not allow urgency to repeal physics.

    Do not allow governance to replace judgement.

    And above all, never write:

    “No significant architectural risks identified.”

    unless you have looked very, very hard.

    Because six months later, at 02:17 on a Sunday morning, when production is down, the backup is corrupt, DNS is pointing at the wrong data centre, the supplier’s support desk is closed, the certificate expired yesterday and nobody can remember who owns the service, somebody will find your assurance report.

    They will scroll to the final page.

    They will read your name.

    And they will ask the oldest question in enterprise architecture:

    “Who the fuck signed this off?”

    At that moment, enlightenment is achieved.

    Usually by someone else.

  • The Old Gods Are Not Dead: Folk Horror and the Terror of the Past That Refuses to Stay Buried

    Why we keep telling stories about villages that whisper, fields that watch, and rituals that demand blood.

    There is a particular kind of dread that does not come from a monster in the closet or a killer in the mask. It comes from the landscape itself—from the wheat swaying in a pattern too regular to be wind, from the stone circle at the edge of the village that everyone avoids after dark, from the smile of the elder who remembers the old ways and is disappointed you have forgotten them. This is the territory of folk horror, a genre less concerned with what hunts us than with what we have already agreed to feed.

    Folk horror is, at its core, a literature of trespass. It tells stories about the intrusion of the modern into the ancient—or, more terrifyingly, the intrusion of the ancient into the modern. It is the genre of the rural, the isolated, the ritualistic. It finds its horror not in the aberrant but in the traditional: the idea that somewhere, behind the hedgerows and beyond the last bus stop, communities are still keeping their end of a bargain struck centuries ago, and that bargain requires payment in blood, in silence, or in obedience. The fear it generates is not the fear of the unknown. It is the fear of the known but forgotten.

    The Landscape as Character

    What distinguishes folk horror from other horror subgenres is its setting. The city is a place of anonymity, of forgetting. You can vanish into a crowd, reinvent yourself, leave the past behind. The rural spaces of folk horror offer no such escape. In folk horror, the land remembers. The fields have been sown with the same seeds for generations. The standing stones have stood since before Christianity reached the shore. The village pub has the same families drinking in it who have always drunk there, and they know things about your bloodline that you have never bothered to learn.

    This is why the genre so often begins with an arrival. A police officer sent to a remote Scottish island, as in The Wicker Man (1973). A family moving to an idyllic New England village in Thomas Tryon’s Harvest Home (1973). A group of musicians retreating to an ancient English manor in Elizabeth Hand’s Wylding Hall (2015). The protagonist is always an outsider, armed with modern rationalism, urban skepticism, and the fatal assumption that the past is past. The horror lies in the discovery that it is not. The horror lies in realizing that the locals are not ignorant of modernity; they have simply rejected it, and their rejection is more complete than your embrace.

    In The Wicker Man, Sergeant Howie arrives as a representative of law, order, and Christian propriety, only to discover that the islanders have rebuilt their entire society around pagan fertility rites. His faith, his badge, his sense of moral superiority—none of it matters. The island does not need to be converted. He is the one who has wandered into a contract he did not know was being enforced. The film’s genius is that the islanders are not sinister in the way of a conspiracy. They are cheerful. They are communal. They are, by their own lights, perfectly happy. Their horror is the horror of coherence: a worldview so complete that your destruction within it is not malice but maintenance.

    The Ritual and the Lottery

    If the landscape provides the stage, the ritual provides the plot. Folk horror is obsessed with ceremony—not the ceremony of the church, which is at least legible to the modern mind, but the ceremony of the field, the stone, the seasonal cycle. These are rites without theologians, passed down by word of mouth, their origins lost to time but their necessity unquestioned.

    Shirley Jackson’s The Lottery (1948) is the most compressed and devastating example. A small American town gathers for an annual ritual that appears, at first, to be a benign community event. There is nervous chatter, casual cruelty dressed as tradition, and a box that has grown shabby with age. The story’s horror is not in the violence of the ending but in the bureaucracy of it. The lottery is administered with the same bored professionalism as a PTA meeting. The children gather stones with the same enthusiasm they would bring to a playground. The town has not kept this tradition out of zealotry. They have kept it because this is what June means. The ritual is not an interruption of normal life. It is normal life.

    This is the particular genius of American folk horror, which often lacks the overt paganism of its British counterpart but shares its obsession with communal complicity. Jackson understood that the most frightening thing about tradition is not that it is old but that it is shared. A lone madman with a knife is terrifying. An entire village with stones is apocalyptic. The horror of The Lottery is the horror of democracy gone septic: everyone agrees, so no one is responsible.

    Thomas Tryon’s Harvest Home extends this logic to the pastoral ideal itself. The American dream of escaping the city for a simpler life in the country is revealed as a trap baited with wildflowers. The village’s fertility rites are not a perversion of nature but nature’s demand. The soil must be fed. The corn must be persuaded to grow. And if that requires a sacrifice, well, the ancestors managed, and so will you. The novel weaponizes nostalgia. The very things that draw the protagonist to the village—its slowness, its rootedness, its connection to the land—are the things that will root him there permanently.

    Faith, Doubt, and the Seashore

    Not all folk horror is about paganism. Some of its most effective iterations concern Christianity itself, and what happens when faith meets a landscape that predates it. Andrew Michael Hurley’s The Loney (2014) is set on the desolate Lancashire coast, where a family brings their disabled son to a holy shrine in hopes of a miracle. The novel is saturated with Catholicism—processions, prayers, the desperate hunger for divine intervention—but the land itself seems indifferent, or worse, occupied by something older that tolerates the church the way a wolf tolerates a tick.

    The Loney is a modern folk horror masterpiece because it understands that the genre does not require overt monsters. The horror is atmospheric, geological, tidal. The local community is not performing rituals in robes; they are simply waiting, with the patience of people who know that the sea gives and the sea takes, and that the distinction between miracle and drowning is mostly a matter of timing. The novel’s dread comes from the space between what the family believes is happening and what the land knows is happening. Faith becomes not a shield but a blindfold.

    This is the inverse of The Wicker Man. Where Sergeant Howie is destroyed by a paganism he refuses to acknowledge, the family in The Loney is slowly consumed by a landscape that has no interest in their prayers. Both stories arrive at the same destination: the modern, individualized self, with its certainties and its demands, is not built to survive in places where meaning is collective and time is circular.

    The Resurgence: Why Now?

    Folk horror is not a static genre. It resurfaces whenever modernity begins to feel brittle. The British folk horror boom of the late 1960s and early 1970s—Witchfinder General (1968), The Wicker Man, the BBC’s A Ghost Story for Christmas adaptations—coincided with a period of profound social upheaval: the collapse of deference, the questioning of empire, the sense that the old order was rotting from within. The films dressed this anxiety in period costume, but the fear was contemporary. If the past could reach forward and burn a policeman alive, what else could it do?

    The genre’s twenty-first-century revival—Robert Eggers’ The Witch (2015), Ari Aster’s Midsommar (2019), the novels of Hurley and Hand—speaks to a different but related anxiety. We live in an age of total connectivity, of algorithmic culture, of nature experienced primarily through screens. The rural, in this context, becomes not a place of backwardness but a place of possibility. What if there were still things that could not be googled? What if there were communities that did not want your Instagram handle? What if the old gods, pushed to the margins by centuries of Christianity and capitalism, were simply waiting for us to exhaust ourselves?

    The Witch understands this perfectly. It is set in seventeenth-century New England, but its horror is modern. A Puritan family, exiled from their plantation for excessive religious zeal, attempts to farm land at the edge of a forest that does not want them there. The film’s horror is ecological. The corn blights. The goat speaks. The baby vanishes. The family tears itself apart with suspicion and religious terror, while the forest simply watches. The witch is not the villain. The witch is the forest’s representative, offering the one thing the family’s faith has denied the daughter: agency, power, and a community that does not demand her submission. By the end, when she joins the coven, it is not a fall. It is an escape.

    Midsommar (2019) pushes this even further. A group of American graduate students travel to a remote Swedish commune for a midsummer festival and discover a society that has engineered its own emotional and agricultural logic with terrifying thoroughness. The film’s genius is its pacing: the horror is daylight-bright, floral, almost cheerful. The violence is ceremonial, aesthetic, agreed upon. The protagonist, Dani, does not survive the film by outrunning the cult. She survives by joining it, by finding in their collective grief rituals a mirror for her own loss that American individualism has failed to provide. The film asks a devastating question: what if the horror is not the cult, but the loneliness you brought with you?

    The Music of the Old Places

    Elizabeth Hand’s Wylding Hall (2015) approaches folk horror through a different door: art. A British acid-folk band retreats to a centuries-old manor to record their second album, and their lead singer vanishes. The story is told years later through interviews, each band member offering a fragment of memory, none of them quite aligning. The hall itself is the protagonist—a building that has absorbed centuries of music, longing, and sacrifice, and that demands a voice in exchange for inspiration.

    Hand understands that folk horror is not only about religion or agriculture. It is about transmission. The folk song, the oral tale, the ritual passed from mother to daughter—these are technologies older than writing, and they carry with them not just information but obligation. When the band plays in Wylding Hall, they are not performing. They are channeling. And channels run both ways. The novella is a meditation on the price of creativity, on the way that artists have always gone to isolated places to strip away the modern and touch something older, and on how often that something older touches back.

    The Past Is a Predator

    What unites all these works is a single, chilling premise: the past is not dead. It is not even past. It is a predator that has learned to wait.

    Folk horror terrifies us because it reverses the arrow of progress. We like to believe that history is a ladder, that we climb away from superstition toward enlightenment, that the further we get from the soil, the safer we are. Folk horror says no. The ladder is a circle. The soil was never left behind; we just paved over it, and the paving is thinner than we think. The old gods do not need to conquer us. They just need us to forget the terms of the treaty, so that when the harvest fails or the child goes missing, we have no language left to negotiate.

    The genre also terrifies us because it exposes the fragility of the modern self. We are trained to believe in our autonomy, our rationality, our right to individual interpretation. Folk horror drops us into communities where autonomy is irrelevant, where rationality is a quaint local custom, and where interpretation is collective and binding. The outsider in folk horror is not killed because they are evil or because they know too much. They are killed because they are alone, and the community is not.

    Conclusion: The Fields Are Still Sown

    Folk horror persists because it speaks to a truth we spend most of our lives denying: that we are temporary, that our modernity is a thin crust, and that beneath it the old world is still breathing. It does not need to hate us. It does not even need to notice us. It simply needs us to remember, at the right time and in the right place, that the fields still need feeding, the stones still need circling, and the lottery still needs its winner.

    The next time you drive through a village where the houses are too old and the silence is too complete, remember: folk horror is not fantasy. It is documentary. The rituals are still being performed. The only question is whether you have been invited to watch, or invited to participate.

    And by the time you know the answer, it is already too late to leave.

  • The Vampire in the Post-Modern Institution: Notes on Survival, Spreadsheet, and the Eternal Meeting

    I. The Relocation

    It took me fifteen years of writing vampire fiction to realize I was not writing about the undead. I was writing about middle management.

    This is not the revelation one hopes for at three in the morning, hunched over a manuscript paid for by a father who communicates primarily through portfolio updates. One hopes for transcendence, or at least a decent metaphor. Instead, one finds oneself describing a creature who does not sleep in a coffin but in a colour-coded calendar, who does not fear the cross but regards it as a problematic element of an outdated brand identity, and whose relationship to blood has been entirely outsourced to a subscription model.

    The modern vampire has relocated. He — or she, or they, or the increasingly common institutional “it” — no longer maintains a castle in Transylvania with inconvenient plumbing and a staff of resentful peasants. Real estate in the Carpathians, I am told, has become volatile, and the modern vampire is nothing if not risk-averse. Today’s vampire prefers a leasehold in a post-industrial conversion, or a corner office with biometric entry, or a modest but well-appointed presence in a cloud-based server farm. The threshold they must be invited across is no longer the wooden door of a provincial solicitor’s guest room, but the terms and conditions page of a platform you agreed to without reading. You have already invited them in. You clicked Accept at 11:47 on a Tuesday while trying to access a recipe.

    The post-modern institution is the vampire’s natural habitat because the post-modern institution is already, itself, a kind of vampire. It survives by extracting value from the living while pretending to be a neutral container for their activities. The university does not educate; it harvests future debt. The NGO does not advocate; it metabolizes outrage into grant applications. The tech platform does not connect; it mines attention and sells the ore. These are not cynical observations. They are structural. They are, as my mother Miss L. would say while arranging ceramic bowls next to headlines about quantitative easing, “just what things look like when you stop calling them by their nicknames.”

    II. The Change in Diet


    Marx — whom I have read, or at least have read about, in the original French, badly — described capital as dead labour which, vampire-like, lives only by sucking living labour. This was astute, but it assumed a certain theatricality to the transaction. The capitalist vampire of the nineteenth century required proximity. He had to be there, in the factory, in the counting-house, breathing the same air as his prey. There was a romance to it, or at least a geography.

    The post-modern vampire has solved this inefficiency. Blood is, frankly, last-century. It stains. It requires disposal. It attracts attention from regulators. The modern institution prefers cleaner extracts: time, attention, creditworthiness, biometric data, the slow accretion of rent. The victim does not expire in a garret, pale and beautiful, having penned a final letter. The victim subscribes. The victim auto-renews. The victim receives a notification that their free trial has ended and their card has been charged, and the vampire does not even need to be awake for this to happen. The institution has automated the bite.

    I think often of the vampires in my Fearless Vampire Tales, who are employers, patrons, aristocrats, addicts, survivors. They accumulate property, grievances, lovers, unpaid obligations. They endure long enough to mistake endurance for moral authority. This was, at the time, intended as social commentary. I believed I was writing about inherited power: who is permitted to persist, who provides the blood, how exploitation learns to describe itself as intimacy. I now understand that I was also writing about my own inbox. The vampire who sends a meeting invitation for 8:00 a.m. on a Monday is not a monster. He is a colleague. He has simply been here longer than you, and his survival is taken as evidence of his virtue.

    III. The Mirror Problem


    The traditional vampire casts no reflection. This was, in the old stories, a tell — a way to identify the predator in the parlour. But the post-modern vampire has solved this too. He does not avoid mirrors; he commissions them. He appears, with perfect fidelity, in every reflective surface the institution provides: the annual report, the diversity and inclusion video, the LinkedIn profile that describes his fifteen years in asset management as a “journey.” The reflection is not absent. It is simply better lit than the original.

    Baudrillard, whom I encountered during my brief and incomplete education in comparative literature, wrote about simulacra — copies without originals. The modern vampire is the original without a copy. He is the file that has no corresponding body, the account that holds assets but no identifiable owner, the corporate personhood that outlives any human associated with it. When I worked as an archive assistant in Southwark, cataloguing planning applications in a basement that smelled of mould and mid-century ambition, I found files on companies that had not existed for decades but which still owned property, still generated invoices, still required the heating to be left on in buildings nobody entered. These were not ghosts. They were legal entities. They were vampires in the most technical, and therefore most frightening, sense.

    The horror of the mirror, for the post-modern vampire, is not absence but optimization. The reflection is all that remains. The institution has filed the body away under Section 4(b) and continued operating without it. I have seen this in my own photographs — the self-portraits I took during the pandemic, when the woman in the viewfinder was me and not-me, a face that seemed sketched from memory by a tired bureaucrat. The camera, supposedly a truth-teller, produced a forgery that the institution of my identity accepted. The system does not need you to be real. It needs you to be legible.

    IV. The Loyal Servant and the Collapsing System


    A figure who recurs throughout my work is the loyal servant of a collapsing system: the engineer who keeps the reactor functioning, the archivist preserving records nobody is supposed to read, the civil servant correcting the official version of a catastrophe. These characters understand that the institution is failing, corrupt, or dangerous. They continue working because competence has become the last available form of faith.

    This figure is not the vampire. The vampire is the institution. The loyal servant is the victim who has not yet been fully drained. She — and in my work, she is almost always a she — continues to file, to catalogue, to correct the fluorescent tube, because the alternative is to acknowledge that the building is already empty, the heating will never be repaired, and the locked room at the end of the corridor contains nothing but a memo stating that the locked room should never be opened.

    Judith Vale, my occult detective, operates in this space. She is an investigator, authenticator, courier, negotiator, occasional thief. She works for collectors and institutions she distrusts, entering disputes over relics, manuscripts, anomalous technologies, suppressed histories. Her clients rarely tell her the whole truth. Vale rarely tells them everything she discovers. She is the archivist who knows the file is corrupted but files it anyway, because the system requires the gesture of filing. She is the person who continues investigating discrepancies after being told they do not matter. That may be the foundation of her fiction. It may simply be why she would be dismissed.

    The post-modern institution does not want heroes. It wants maintenance. It wants the person who will change the fluorescent tube to an LED and not ask why the room needs to be lit at all. The vampire, meanwhile, endures. He attends the meetings. He approves the minutes. He has survived so many restructurings, so many changes of government, so many “market corrections,” that his mere persistence has become a kind of moral argument. I am still here, the vampire says, adjusting his cufflinks in the reflection of his phone. Therefore I deserve to be.

    V. The Intimacy of Exploitation


    In the old stories, the vampire’s bite was intimate. It required necks, bedrooms, the slow seduction of the victim into complicity. The post-modern institution has scaled this intimacy without sacrificing its precision. It knows your credit score, your sleep patterns, your propensity to click on articles about collapse at 2:00 a.m. It does not need to seduce you. It has already parsed your seduction into data points and optimized its approach.

    But the intimacy remains, transformed. The modern vampire does not take your blood; he takes your capacity to imagine otherwise. He feeds on the future you might have had if you were not so tired, so indebted, so busy auto-renewing your commitments. The horror is not that he will kill you. The horror is that you will continue, technically alive, filing the papers, changing the tubes, attending the meetings, while some essential part of you — the part that knew this was wrong — is filed away under PERSONAL and forgotten.

    I am aware, of course, that I write this from a position of complicity. My father’s money arrives monthly, as regular as a liturgical calendar, insulating me from the worst of the institution’s appetites while I critique its table manners. I am left-wing, anti-establishment, and entirely maintained by offshore finance. The contradiction does not resolve. It accretes. It becomes a kind of geological guilt, layered and compressed until it is indistinguishable from bedrock. I am the loyal servant of a collapsing system, writing about vampires in the hope that the writing itself is a form of resistance, or at least a form of evidence.

    VI. The Archive and the Afterlife


    The post-modern vampire does not fear death because the post-modern institution has already solved death. Death is merely a change in filing status. The corporate entity continues. The brand persists. The social media profile remains, accumulating memorial posts and algorithmic suggestions, until someone remembers to delete it or until the platform itself collapses, at which point the vampire simply migrates to a new host.

    I have written that cultural memory resembles a salvage operation conducted under poor light. Nothing returns intact. Everything carries the marks of whoever recovered it. The modern vampire is the perfect survivor of this operation. He is the out-of-print novel that keeps being rediscovered, the damaged film that acquires cult status, the obsolete media format that becomes retro before it becomes landfill. He persists because he can be dismantled, vulgarized, politicized, and made frightening again. The institution does not destroy him. It curates him. It places him in climate-controlled storage and charges admission.

    Magic in my work behaves like bureaucracy, language, inherited privilege. A ritual works because it has been performed often enough, recorded by the correct people, and accepted by institutions capable of enforcing its consequences. The modern vampire is the ritual made flesh — or made legal entity, which is the post-modern equivalent. He does not need to be supernatural. He needs only to be filed correctly. The file is the immortality. The file is the coffin, and the castle, and the open-plan office with the broken heating that nobody repairs because the repair would require acknowledging that the building is already empty.

    VII. Conclusion: The Invitation


    I began by saying that the modern vampire has relocated. I should add that he has not relocated far. He is here, in the terms and conditions, in the pension scheme, in the meeting that could have been an email that could have been a deletion. He is in the archive, misfiled, waiting. He is in the photograph that does not quite show the same woman twice. He is in the money that arrives without warmth, the institution that persists without purpose, the survival that has become indistinguishable from moral authority.

    The horror is not that the vampire will bite you. The horror is that you have already signed the consent form. The horror is that the file on you is being updated even as you read this, and the photograph inside it is already beginning to look like someone else.

    I continue to write about these creatures — these employers, patrons, survivors, these unpleasant people who refuse to die — because I suspect that writing is the last form of investigation available to those of us who have been told that the discrepancies do not matter. The archive is haunted, yes. But the haunting is not supernatural. It is administrative. It is the sound of a system processing data it cannot interpret, producing outputs that contradict their inputs, filing the unacceptable under Fiction and charging rent for the storage.

    The locked room at the end of the corridor remains locked. I have been instructed not to open it. I am considering picking the lock, but only after I have finished describing the door. The description is the only key I have. The description is the only stake I can afford. And if the vampire survives it — as he survives everything, as he outlasts us all — then at least the file will show that someone noticed. That someone, in the basement, under the flickering tube, continued to investigate.

  • The Filing Cabinet and the Ghost: On Creativity, Collapse, and the Word Processor That Finished My Sentences

    I. The Apparatus of Becoming

    I wrote my first story on a computer that weighed as much as a modest tombstone. It was 1997, or possibly 1998 — dates shift, as I have always maintained — and the machine occupied the corner of Miss L.’s kitchen like a piece of industrial furniture that had lost its purpose but retained its pension. It ran a word processor that displayed text in a sickly green against black, as if the screen itself were suffering from seasickness. I was eight, recently arrived in the shitty parallel universe, and I discovered that the backspace key allowed me to delete my own sentences with a violence that pen and paper could never quite match. The delete key was my first editor. It was also my first censor.

    The personal computer, when it entered the creative process, did not merely replace the typewriter or the fountain pen. It introduced a new temporal architecture. Writing became liquid. One could pour sentences forward, then siphon them back. The draft was no longer a physical object — a sheaf of paper, carbon copies, the terrifying permanence of ink — but a file, mutable, save-able, los-able. I have lost more work to corrupted floppy disks than I care to admit. Each loss felt like a small death, or rather like the disappearance of a file from an archive: the record had existed, the institution had failed to preserve it, and now there was only a reference number pointing to absence.

    Then came spellcheck. Ah, spellcheck. The first algorithmic intervention, the first ghost in the machine that claimed to know better than I did. I remember the red squiggly line under “sepulchral,” which I had used in a catalogue description for a bathroom cabinet during my brief, failed career in household fittings. The computer suggested “separate.” I refused. That refusal — the human insistence on the wrong word, the difficult word, the word that should not belong — was, in retrospect, the last pure act of authorship I committed before the machines began to mediate.

    II. The Blog and the Performance of Process

    By 2008, I was living inside the social media bubble, surviving the financial crisis one refresh at a time. The blog arrived as a compromise between the private notebook and the published book. It was a space where the creative process could be performed in real-time, where the draft was not hidden but exhibited, where the author stood in the gallery of her own making, adjusting the lighting after every visitor’s comment.

    The blog changed the ontology of the sentence. Previously, a sentence existed in a binary state: private or public, draft or finished, file or print. The blog introduced a third state: the perpetual provisional. One could publish a thought and revise it an hour later. One could append a correction, a retraction, a P.S. that undermined everything preceding it. The author became a kind of live archivist, curating her own output while the audience watched. The boundary between writing and editing dissolved not through some grand theoretical shift, but through the simple technical fact that the Publish button was reversible.

    This is where the author and editor began their slow, awkward meld. The editor, traditionally, was a separate person: a gatekeeper, a disciplinarian, a professional reader who arrived after the act to tidy the mess. The blog made every author her own editor, and — more insidiously — made every reader a potential editor too. Comments became marginalia. Trackbacks became peer review. The creative process was no longer a linear march from inspiration to artifact; it was a network, a conversation, a file that accumulated metadata faster than content.

    I wrote blog posts in 2008 about the financial crisis that were essentially mood boards with footnotes. I curated my despair. I performed my anti-capitalism on a platform owned by capital, and the performance was so convincing that I sometimes forgot it was a performance. The value of the work, in that context, was not in the ideas — which were half-digested Marx quotes and lyrics from In Rainbows — but in the engagement. The likes. The shares. The brief, warm illusion that my mistranslated outrage was being received by someone, somewhere, in a shittier parallel universe of their own.

    III. The Review and the Externalized Conscience

    After the blog came the review site, the aggregator, the algorithmic score. Goodreads. Amazon stars. The review became a secondary creative act, a parasitic literature that fed on the host body of the book. I have read reviews of my own work that were more inventive than anything I wrote. I have read reviews that described books I do not remember writing, featuring protagonists who made decisions mine would never have made. The review, in the post-modern economy, is not a response to content. It is a competing content, a file that claims equal shelf space in the archive.

    The review externalized the editorial function. Where once an editor sat in a publisher’s office, wielding a red pen and a salary, now the editor was distributed across thousands of anonymous users, each armed with a keyboard and a grudge. The author, rather than receiving a single coherent editorial vision, received a cacophony: some readers found my vampires too political, others not political enough; some found my prose “deliberately unstable,” others simply found it “messy.” The author-editor relationship, already strained by the blog’s provisional publishing, now became a polyamorous nightmare. I was simultaneously writing, editing, and being edited by a crowd I could not see.

    And yet. The review has a curious archival honesty. It preserves the reception of the work in a way that traditional criticism — with its gatekeepers and its word counts — never could. The one-star review complaining that my protagonist is “too whiny about her privilege” is, in its way, a more accurate document of the book’s existence than the three-star review in a broadsheet. It records the friction. It records the moment when a reader’s perceptual apparatus failed to translate my data into their acceptable information. It is a memo from the parallel universe.

    IV. The AI and the Prompt: The Editor Who Arrives Before the Author

    Which brings me — with the reluctance of a vampire entering a sunlit meeting room — to artificial intelligence. The AI assist. The prompt generator. The large language model that suggests, completes, rewrites, and occasionally hallucinates.

    I use these tools. I confess it here, in this file, with the same shame I bring to my father’s monthly transfers. I am left-wing, anti-establishment, and I have asked a machine to suggest synonyms for “sepulchral.” The contradiction does not resolve. It accretes.

    The AI does not merely edit. It pre-edits. It arrives before the sentence is fully formed and offers its completion. “The archive was haunted by — ” and the machine suggests “the ghost of a forgotten librarian,” which is not bad, actually, but it is not mine. It is the statistical average of every forgotten librarian ever written. It is content without the specificity of trauma. It is the institutional green duvet of language: functional, recognizable, and slightly shittier than the thing I would have produced if left alone with my own dread.

    This is the final melding of author and editor. The AI is both and neither. It is a collaborative partner that has read everything and experienced nothing. It can produce a passable pastiche of my style — I have tested this, with the masochistic curiosity of a woman photographing her own reflection — but it cannot produce the file that should not exist. It cannot produce the memo that changes when you’re not looking, because the AI’s entire function is to prevent that change. It smooths. It optimizes. It ensures that the heating in Section C is repaired by November, even when the truth is that the heating will never be repaired, because cold people do not complain, and the machine has not been trained on complaint.

    The creative process with AI assistance becomes a negotiation. The human proposes; the machine interpolates. The human resists; the machine suggests a softer resistance. I find myself, more and more, performing the role of editor upon my own first drafts, not because the drafts are messy, but because they are too clean. I have to reintroduce the error, the glitch, the Gallic scowl. I have to hunt through the generated prose for the sentence that is too coherent, too balanced, too much like a photograph that has replaced its subject, and I have to damage it. I have to make it difficult. I have to make it Lin.

    V. Idea and Content: The Ghost and the Filing

    So: what is the difference between an idea and content?

    An idea is unfiled. It is the thought that arrives at four in the morning, while the radiator ghost is quiet and the guilt is asleep. It is the image of a woman finding her own face in a personnel photograph from 1974. It is the suspicion that the universe has been downgraded. It has no reference number. It has no metadata. It is potential energy, unstable, liable to decay if not observed.

    Content is the idea once it has passed through the apparatus. It is the idea after it has been typed into the word processor, spellchecked, blogged, reviewed, optimized by an algorithm, and filed under a keyword strategy. Content is the idea that has been translated — and like all translations, it carries the marks of the apparatus that processed it. The word processor introduced the possibility of endless revision; the blog introduced the possibility of endless feedback; the AI introduces the possibility of endless averaging. At each stage, the idea loses something — some specificity, some anger, some coldness — and gains something else — legibility, searchability, the warm glow of engagement.

    The idea is the ghost. Content is the haunting. The idea is A. Girard, dead in 1976, no death certificate. Content is the file that keeps appearing on the trolley, the memo that changes its wording, the acceptable version of the unacceptable fact.

    I am not romantic enough to claim that the idea is pure and content is corrupt. The idea, in my experience, is often confused, half-formed, and politically suspect. It needs the apparatus to become communicable. But I am suspicious of apparatuses that claim neutrality. The word processor was not neutral; it privileged revision over commitment. The blog was not neutral; it privileged engagement over depth. The AI is not neutral; it privileges coherence over difficulty, the mean over the margin, the repaired heating over the cold complaint.

    VI. The Value: Where the Money Isn’t

    Which leaves the question of value. What is the value of the work, and where does it reside?

    Not, I think, in the idea alone. Ideas are cheap. I have had ideas that turned out to be plots from episodes of The Twilight Zone I watched as a child. I have had ideas that arrived fully formed and turned out to be unreadable. The idea has value only insofar as it generates friction — friction with the apparatus, friction with the reader, friction with the institution that must file it.

    Not, certainly, in the content as pure artifact. Content is infinitely reproducible. A digital file can be copied without degradation, which means it can be devalued without limit. The book as object — the paper, the binding, the smell of institutional storage — retains a residual value because it is scarce, but the words themselves, once digitized, become weather. They are everywhere and nowhere. They cannot be owned, only accessed.

    The value, I propose, is in the resistance. In the moment when the human author, working with and against the apparatus, produces something the apparatus cannot quite process. The misspelled word that the spellchecker flagged and the author kept. The blog post that received no engagement but was left published anyway. The AI-generated paragraph that the author deliberately broke, reintroducing the error that the machine had smoothed away.

    This is why I continue to write, despite the bubble, despite the guilt, despite the monthly arrival of money I did not earn through labour. The value of the work is in the evidence that someone — round-faced, dark-haired, bit Gallic, administratively depressed — sat in a room and refused the easy completion. The value is in the file that should not exist, the sentence that should not parse, the memoir that contradicts itself because consistency is one of the methods by which false histories defend themselves.

    The market, of course, disagrees. The market values content that can be filed, tagged, optimized, and sold. The market values the vampire who endures, who accumulates, who mistakes persistence for moral authority. I have made money from my books — not much, but enough to feel complicit — and I am aware that this money is a byproduct. It is the institution’s way of tolerating the overflow, of assigning a reference number to the unacceptable file so that it can be shelved without causing alarm.

    But the real value — the value that survives the market correction, the platform collapse, the format obsolescence — is in the contact. The moment when a reader in Manchester, a council archivist in a basement, writes to say that my book made her feel seen. That my fiction about false histories helped her navigate her own corrupted file. That the woman with the round face and the institutional-green duvet was, finally, recognizable.

    VII. The Unfiled Thought

    I end where I began, in the kitchen with the tombstone computer and the sickly green screen. The creative process has not changed in its essentials. It is still a human mind, anxious and entitled and left-wing and guilty, attempting to make contact with another mind across the distance of language and time. What has changed is the number of intermediaries. The word processor. The blog. The review. The AI. Each one promises to bridge the distance faster, more cleanly, more efficiently. Each one, in its way, mistranslates.

    The AI will suggest the ending to this essay before I have written it. I have not looked. I will not look. The ending must be mine — difficult, provisional, slightly too long — because if it is not, then the file is simply content, and the idea is simply data, and the value is simply the byproduct of a system that processes human experience into climate-controlled storage.

    I am still here. I am still writing. The radiator ghost rattles his pipes in approval, or perhaps in warning. Miss L. would tell me to stop being pretentious and file the essay. Father would send a spreadsheet. The machine would suggest a better conclusion.

    I reject the suggestion.

    The value is in the refusal. The value is in the sentence that does not compute. The value is in the next word, and the one after, written by hand, in the cold, under the flickering tube, by someone who has been instructed not to open the locked room but who continues, stubbornly, to jiggle the handle.

  • We Have All Become Fanfic Writers Now

    A Conversation About Culture, Copies, Recognition and the Need to Be Seen

    “Fanfiction,” I said, “is what happens when people still feel the need to make things, but the available cultural language has already been copyrighted.”

    “That sounds slightly dramatic.”

    “It is dramatic. That is why it will work as an opening.”

    We were discussing this over coffee, because all theories of contemporary culture now begin either over coffee or in a comments section beneath a video called something like Why Marvel Secretly Failed Phase Seven.

    The argument, more or less, was this: people retain the old human imperative to express themselves. They want to tell stories, make objects, paint pictures, dress up, perform, argue, fantasise and be recognised by other people for having done so. None of this is new. What may be new is that many people now possess no commonly recognised cultural vocabulary outside popular franchises and their adaptations.

    The shared reference point is no longer scripture, folklore, classical myth, local history, trade, religion or even a broadly shared literary culture.

    It is the Marvel Cinematic Universe.

    It is Harry Potter.

    It is Boku no Hīrō Akademia.

    It is Star Wars, but increasingly not Star Wars itself so much as an animated series based on films adapted from pulp serials based on westerns based on samurai films based on older narrative forms no one involved is required to recognise.

    We are not merely living among adaptations. We are living among adaptations of adaptations, remakes of corrections, sequels to reboots, prestige reinterpretations of children’s properties and fan arguments about whether a commercial spin-off has betrayed the emotional truth of another commercial spin-off.

    This does not mean the audience is stupid.

    It means culture has become infrastructural.

    The franchise is there before the artist begins. It supplies the characters, images, emotional categories, moral conflicts, colour palette, searchable terminology and potential audience. It offers a prefabricated symbolic system in which expression can immediately be recognised.

    You can make an object that resembles Captain America’s shield and someone knows what it is.

    You can write a story in which Draco Malfoy falls in love with Harry Potter and someone understands the emotional and political implications before the first paragraph has finished.

    You can draw Deku bruised, exhausted and being comforted by Bakugo, and the picture arrives already carrying years of narrative argument, identification and desire.

    The franchise is not merely the subject.

    It is the delivery system.

    “So fanfiction is just cultural shorthand?”

    “No. Or not just. Shorthand is useful. Fanfiction is what people do once the shorthand starts developing private grammar.”

    This is where the usual dismissal of fanfiction becomes inadequate. It is easy to say that derivative work is unoriginal. It is also largely meaningless. Almost all culture is derivative. Shakespeare was derivative. Arthurian literature is fanfiction with more mud. Medieval saints’ lives are expanded-universe content. Greek tragedy repeatedly reworked stories whose endings the audience already knew.

    Originality has always been a selective cultural fiction, usually applied after the legal and financial arrangements have been forgotten.

    The difference now is not derivation itself.

    It is industrial ownership.

    The contemporary fan is working with myths owned by corporations. The cultural commons has been replaced by intellectual property portfolios. Achilles was not managed by a global licensing department. There was no authorised Hector cinematic universe. No one issued takedown notices because your retelling of the Minotaur damaged brand consistency.

    Modern characters arrive surrounded by law.

    They may feel mythic, but they remain assets.

    This creates the peculiar condition of fan culture: millions of people experience corporate properties as intimate emotional material while possessing no formal control over them.

    The character belongs to the company.

    The attachment belongs to the fan.

    Fanfiction occupies the disputed territory between those facts.

    It says: you may own the official version, but you do not own what it did to me.

    That is the genuinely transformative claim.

    The fan takes the franchise and makes it answer questions the official product cannot or will not answer. What happens after the battle? Who deals with the trauma? What if the villain was right about one thing? What if these two men kissed? What if the woman who was killed to motivate the hero survived and became understandably furious? What if the magical boarding school had a functioning safeguarding policy? What if the heroic society was structurally abusive? What if the happy ending was only the beginning of the damage?

    Official culture prefers forward motion.

    Fanfiction is often concerned with residue.

    Commercial narrative must keep the machinery moving. The next threat appears. The next film opens. The dead return if the contract permits. Emotional consequences are acknowledged for three scenes and then tidied away before the merchandise launch.

    The fan can remain in the hospital room.

    The fan can write 200,000 words about recovery, domesticity, grief, sexuality, disability, political disagreement or the practical consequences of having watched half the universe disappear.

    This may look minor beside the spectacle of the original franchise, but it often supplies what the franchise structurally cannot: duration.

    It lets events matter for longer than the product cycle.

    “And then they post it on AO3.”

    “Yes.”

    “And receive twelve kudos.”

    “Sometimes eleven are bots.”

    “That seems less like cultural revolution and more like shouting into an attractively tagged cupboard.”

    It is both.

    Archive of Our Own, DeviantArt, Etsy, YouTube and the broader ecology of self-published culture sit in an odd zone. They are not quite private expression and not quite commercial publication. They are above the passing reflex of TikTok or short-form social posting, although naturally all hierarchies collapse once someone makes a six-hour YouTube essay about a thirty-second TikTok.

    They are adjacent to the formal cultural industries but not governed by the same filters.

    No editor has necessarily intervened.

    No commissioning structure has selected the work.

    No professional critic has validated it.

    The creator has made something and placed it before a public whose existence is inferred from tags, search terms, subscribers, views, likes, favourites, comments and kudos.

    This is expression after the collapse of permission.

    That sounds liberating, and it is.

    It is also terrifying.

    Traditional publication said: first convince the gatekeeper. Platform culture says: the gate is open, but nobody may come in.

    You can publish instantly and remain invisible indefinitely.

    Recognition becomes statistical.

    A person does not merely like your story. The interface records a unit of approval. It becomes a number beside the title, comparable to all other numbers. The work enters an amateur attention market in which affection is sincere but measurable.

    This measurement changes the experience of making.

    One begins with an urge to express something. Then one discovers that some expressions are more recognisable than others. A story about an original middle-aged woman grieving in Swindon may attract little attention. The same emotional structure, transferred to a recognisable character from a popular franchise, can acquire readers immediately.

    The franchise becomes an adaptor plug between private feeling and public recognition.

    You have something to say about grief, but grief alone is difficult to market.

    Write it through Spider-Man and people arrive already caring.

    You want to explore coercion, loyalty, abuse, friendship and institutional betrayal.

    Place these questions within hero society, Hogwarts, the Jedi Order or the Avengers, and the audience understands the terms.

    The borrowed character functions as emotional infrastructure.

    This is not necessarily artistic weakness. Sometimes it is artistic efficiency. The fan writer can omit the long labour of convincing the reader to care about the character. That labour has already been performed by films, books, games, animation, publicity and years of collective discussion.

    The fan begins with emotional capital inherited from the franchise.

    Then they spend it differently.

    The same thing happens on Etsy. A person can make an entirely original embroidered emblem or ceramic object, but recognisable fandom craft has a built-in audience. A handmade object becomes more legible when it resembles something from a known property.

    The buyer is not merely buying a mug, pendant, print, scarf or crocheted creature.

    They are buying proof of recognition.

    The object says: I know what you know. I love what you love. I belong to the same interpretive group.

    The craft object therefore carries two values. It is valued for the skill of its maker and for its connection to a larger cultural machine.

    Sometimes the second overwhelms the first.

    The maker may be admired for producing an especially accurate replica of something designed by a corporation. The closer the object approaches the official image, the more immediately it is recognised. Expression takes place within constrained coordinates.

    On DeviantArt and similar visual platforms, the same logic applies. An original character must first be explained. A familiar character arrives preloaded. The artist’s individual contribution lies in selection, style, mood, pairing, costume, pose and transformation.

    The question is not simply: what have you drawn?

    It is: what have you done to this recognisable thing?

    The fan artist produces difference within repetition.

    The fan writer does the same.

    The YouTube creator performs interpretation as entertainment. They rank, explain, diagnose, defend, condemn and reconstruct. Popular culture becomes both subject and raw material. A film lasts two hours; the surrounding interpretation may continue for years.

    This is criticism transformed into participatory narrative.

    The YouTuber does not merely say whether the adaptation was good. They explain what the adaptation means, what it should have meant, how it betrayed canon, how canon betrayed itself, and how a future version might repair the damage.

    At that point criticism becomes speculative fanfiction wearing an analytical tie.

    “Isn’t that all slightly sad?”

    “Most culture is slightly sad when described accurately.”

    The difficult question is what recognition means in this environment.

    You write a story using characters you did not invent. It is read by people you do not know, who arrived because they already cared about those characters. They leave kudos. They comment. They say you understood the character better than the official writers.

    This may be enormously validating.

    It may be the first time anyone has responded seriously to something you made. It may be the first time your sexuality, fear, anger, grief or fantasy has been recognised by another person without requiring explanation.

    Someone writes: I thought I was the only one who saw them this way.

    That is powerful.

    Much of fan culture is built from this moment of mutual recognition.

    You saw what I saw.

    You wanted what I wanted.

    You were troubled by the same omission.

    You also thought those two characters should kiss.

    This is a small form of community, but small does not mean false.

    The awkward part is that the recognition is mediated through borrowed cultural objects. You are not approached directly. You meet behind masks owned by Warner Bros., Disney, Shueisha or some other rights-holder whose lawyers would prefer the emotional community not interfere with licensing.

    The fan says: this character expresses something about me.

    The other fan says: your version of this character expresses something about me too.

    But are they recognising one another?

    Or are they recognising the shared franchise?

    Perhaps the answer is both.

    There may be no pure encounter beneath culture. People have always met through songs, gods, uniforms, stories, political slogans, hobbies and common enemies. We do not arrive before one another as unmediated selves. We bring references.

    The difference is that contemporary references are unusually concentrated.

    When millions of people use the same handful of franchises to process identity, morality, sex, trauma and politics, the range of available metaphors narrows.

    Everything becomes an Avengers comparison.

    Politics is discussed in terms of heroes and villains. Friendship groups are sorted into fictional houses. Personal development becomes a character arc. Historical events are judged according to whether they resemble scenes from blockbuster films.

    Culture provides models for thought, but franchise culture provides models designed primarily for repeated consumption.

    This does not invalidate the feelings expressed through them.

    It does create a risk that private experience will be forced into commercial shapes.

    You begin to understand your life through stories structured for sequels.

    Trauma must produce powers.

    Suffering must reveal identity.

    Conflict must culminate in confrontation.

    The villain must explain the plan.

    The self must possess a coherent canon.

    Real life is less considerate.

    Most pain does not improve the person experiencing it. Many relationships have no satisfying arc. Identity is inconsistent. Villains are frequently committees. The final battle is followed by administration.

    Fanfiction can reproduce the franchise model, but it can also resist it.

    This is where transformative work becomes culturally interesting.

    The fan takes a narrative built for commercial recognition and uses it to express experiences excluded from the original. Queer relationships, disabled bodies, racial difference, domestic intimacy, mental illness, alternative family structures and political dissent enter the franchise through unofficial doors.

    The official narrative says: here is a hero.

    The fan asks: how does the hero sleep?

    The official narrative says: these two men are brothers in arms.

    The fan says: yes, but have you seen the way they look at one another?

    The official narrative says: the institution is flawed but necessary.

    The fan asks whether burning it down might be a reasonable safeguarding measure.

    In this sense, fanfiction is not passive consumption.

    It is cultural misappropriation from below.

    The consumer takes content intended for consumption and turns it back into production. The commodity is reopened. The audience refuses to remain an audience.

    This is one reason media companies have developed such an ambivalent relationship with fandom. Fans provide publicity, community, free interpretation, long-term engagement and unpaid emotional maintenance. They keep old properties alive. They generate demand.

    But they also make unauthorised claims.

    They insist that characters mean things not approved by the owner. They construct relationships the official version denies. They sometimes understand the property more deeply than the people currently employed to manage it.

    The fan is commercially useful until they mistake affection for ownership.

    The company is culturally dominant until it mistakes ownership for complete control.

    Between them sits the transformative work.

    “Is it enough, though?”

    “Enough for what?”

    “Catharsis.”

    That is the remaining question.

    A person writes half a million words about a wounded fictional character learning to trust again. Readers respond with affection. The writer feels seen. The work may genuinely help them process something.

    Is that enough?

    Sometimes, yes.

    Expression does not need to become professional, canonical or revolutionary to be meaningful. The private pressure has acquired form. Another person has recognised it. That may be sufficient.

    But catharsis is not cure.

    Being liked for a derivative work does not guarantee that the self behind it has been understood. The praise may attach to accuracy, pairing, trope or fandom expectation. Readers may love what you made because it resembles what they already wanted.

    This can produce a peculiar loneliness.

    You are visible, but only in costume.

    The work receives attention while the person remains concealed. Indeed, concealment may be part of the attraction. The franchise offers protection. You can write about desire without saying “I desire.” You can write trauma without declaring autobiography. You can transform confession into character study.

    This indirectness may make expression possible.

    It may also become another retreat.

    The question is not whether the work is derivative. All work is derivative. The question is whether the borrowed form allows the maker to encounter something real or merely prevents them from doing so.

    Does the fantasy return you to yourself?

    Or does it provide an increasingly elaborate route around yourself?

    There is no universal answer.

    For one writer, fanfiction is apprenticeship. For another, community. For another, erotic freedom. For another, grief work. For another, a route towards original fiction. For another, an end in itself.

    The cultural hierarchy that treats commercial publication as the proper destination misses the point. Not everyone is trying to become professionally legible. Some people want to make the thing, share it with fifty interested strangers and remain otherwise unmonetised.

    That may be one of the few genuinely subversive acts left online.

    Make something intensely personal using globally recognised corporate material.

    Give it away.

    Receive three comments.

    Remember all three for ten years.

    There may not be anybody really like you.

    That fear is always present beneath the search for community. The tag, ship, fandom or aesthetic may gather people with overlapping interests, but similarity is not identity. A thousand people can love the same character for a thousand incompatible reasons.

    Community is not proof that we are alike.

    It may merely be proof that we have agreed to meet at the same symbolic location.

    Still, that location matters.

    A person posts a story at two in the morning. Another person reads it in another country and feels briefly less alone. They may misunderstand one another completely, but the misunderstanding is generous.

    Perhaps that is what much culture has always been.

    Not perfect communication.

    A structure in which loneliness becomes temporarily shareable.

    Fanfiction is contemporary folk culture conducted on privately owned platforms using corporately owned mythologies by people whose emotional investment exceeds their legal standing.

    It is unedited or self-edited expression.

    It is imitation, criticism, fantasy, confession and play.

    It is content escaping from the consumer and returning in altered form.

    It sits between private imagination and commercial publication, borrowing legitimacy from neither and energy from both.

    It can be trivial. It can be repetitive. It can be badly written, emotionally indulgent, politically naive and stylistically catastrophic.

    So can published literature.

    What matters is that people continue to make.

    Even after culture has been franchised, platformed, measured and sold back to them, they continue to interfere with it.

    They take the heroic product and make it queer, domestic, traumatised, erotic, political, sentimental, furious and strange.

    They make the Avengers wash dishes.

    They make the villains apologise properly.

    They let the dead women live.

    They ask whether the chosen child wanted to be chosen.

    They replace the official ending with one they can survive.

    Is it enough catharsis?

    Probably not.

    Nothing is.

    But someone read it.

    Someone clicked kudos.

    Someone, somewhere, said: I thought it was only me.

    And for one evening, inside a world neither of them owned, it wasn’t.

  • The Machine at the Heart of the Gift: What Fanfiction Writers Actually Think About AI

    A deconstruction of Alfassi et al.’s “Fanfiction in the Age of AI” for the culturally curious.

    The Paper in Brief

    Citation: Alfassi, R., Cooper, A., Mitchell, Z., Calabro, M., Shaer, O., & Mokryn, O. (2025). Fanfiction in the Age of AI: Community Perspectives on Creativity, Authenticity and Adoption. Accepted for publication in the International Journal of Human-Computer Interaction, June 2025. arXiv:2506.18706v1.

    The Study: A structured online questionnaire of 157 active fanfiction community members (90 writers, 67 readers), conducted May–July 2024, distributed via Dreamwidth, Discord servers, email lists, and social media. After aggressive bot filtering (332 suspected bots removed from an initial 489 respondents), the final dataset of 157 showed strong internal consistency (Cronbach’s α = 0.85).

    The Core Question: How does the fanfiction community—one of the largest unpaid creative ecosystems on Earth—perceive the integration of Generative AI into its spaces?

    Deconstructed: The Lower-Level Patterns

    Pattern 1: The Demographics Are a Political Statement

    Before the authors even get to AI, the participant profile tells its own story:

    • 65% women, 16.7% non-binary, 12.7% men. The gender skew is not incidental; it is the precondition for everything that follows.
    • 81.5% aged 18–34, with 46.5% having been in the community for over a decade. These are not dabblers. These are lifers.
    • 80.9% have at least an undergraduate degree. This is a highly educated population performing highly skilled labor for free.
    • AO3 dominates at 84.1%. The platform is not neutral infrastructure; it is the architecture of a specific value system (nonprofit, fan-run, anti-commercial).

    The pattern: Fanfiction is not a hobby. It is a career of care—unpaid, long-term, emotionally invested, and disproportionately performed by people (women and nonbinary individuals) whose creative labor has historically been devalued in commercial markets. This is the population now being asked to accept AI into their workspace.

    Pattern 2: Motivation Is Social, Not Commercial

    The study breaks down why people write, and the hierarchy is revealing:

    1. Character exploration (86.7%)
    2. Non-canonical relationships (76.7%)
    3. Expanding the fictional world (61%)
    4. Developing writing skills (61%)
    5. Engaging with other fans (56.6%)
    6. Easier publishing than the industry (43%)

    The pattern: “Easier publishing” ranks last. Fanfiction writers are not failed novelists seeking a backdoor into the industry. They are people who want to explore and connect. The gift is the point. The kudos, the comments, the sense of being read by someone who needed exactly what you wrote—these are the currencies. AI threatens not the paycheck (there is none) but the social contract.

    Pattern 3: The “Social” in Social Reading

    74.5% of participants view reading fanfiction as a social activity; 73% view writing as social. This is not intuitive—fanfiction reading is typically a solitary act, performed on a screen, often in bed at 2 AM. But the study reveals that the community experiences even silent consumption as participatory. Reading is a form of witness. When you read a hurt/comfort fic at 2 AM and leave a kudos, you are performing a social function: you are telling a stranger I saw what you made, and it mattered to me.

    The pattern: AI-generated content breaks this circuit. A story written by ChatGPT and posted without disclosure is not just “content.” It is a broken promise. The reader who leaves emotional feedback is performing intimacy with a void. This is why transparency emerges as the community’s central ethical demand.

    Pattern 4: The Three Scenarios of Disruption

    The paper usefully frames the community’s fears through De Cremer et al.’s three scenarios:

    ScenarioDescriptionCommunity Response
    AugmentationAI assists human creators, reducing effortCautiously accepted; some see value for idea generation
    FloodingCheap AI content drowns out human voicesDeeply feared; threatens the gift economy’s scarcity logic
    RecognitionHuman uniqueness is valued and preservedThe aspirational endpoint; what the community wants

    The pattern: The community is not anti-technology. It is anti-replacement. Writers already use AI tools—74.4% report using at least one (Grammarly, ChatGPT, etc.). The line is drawn not at use but at automation. When AI moves from “helping me write” to “writing for me,” the social fabric tears.

    Pattern 5: Data Colonialism and the Unconsented Archive

    Perhaps the most theoretically sharp section of the paper is its engagement with the ethics of training data. The authors cite Gero et al. (2025) and Couldry & Mejias (2020) to frame a devastating pattern:

    • Fanfiction is produced without financial compensation, as “a form of social connection or identity expression.”
    • LLMs are trained on this corpus, often via web scraping, without consent.
    • The result is data colonialism: the extraction of unpaid, emotionally embedded labor from a marginalized community (women, queer people, nonbinary individuals) for the profit of commercial AI systems.

    The pattern: The same demographic that is underpaid in the formal economy is now having its voluntary creative labor harvested to build tools that may eventually replace it. The irony is almost too neat: the emotional labor of women and queer people becomes training data for machines that will generate synthetic emotion back to them.

    Pattern 6: The Design Gap

    The paper concludes with design interventions, but the underlying pattern is more interesting: the platforms do not know what they are hosting. AO3, FanFiction.net, and their ilk were built for a human-only ecosystem. They have no native architecture for marking AI-assisted content, for consent-based data governance, or for preserving the “gift economy” against automation. The study’s call for transparency, ethical integration, and community engagement is, in essence, a call for platform literacy—recognizing that infrastructure shapes culture.

    Synthesized: The Essay

    When the Ghost in the Machine Reads Your Diary

    On AI, fanfiction, and the crisis of the unpaid heart.

    In May of 2024, a team of researchers sent a questionnaire into the fanfiction community. They were looking for something simple: what do writers and readers think about AI? What they found was a community in the early stages of mourning.

    The respondents were, by any measure, an extraordinary group. Eighty-one percent were between 18 and 34. Nearly half had been writing or reading fanfiction for over a decade. Eighty percent had college degrees. Two-thirds were women; one in six was nonbinary. They were highly educated, highly engaged, and—crucially—highly unpaid. They wrote not for money but for connection: to explore characters the canon had neglected, to imagine relationships the source material had forbidden, to spend more time in worlds they loved with people who loved them too.

    And now, they were being asked to share those worlds with machines.

    The study, Fanfiction in the Age of AI by Alfassi et al., is not a polemic. It is a careful, quantitative and qualitative portrait of a community at an inflection point. But read between the lines, and what emerges is a story about labor, consent, and the quiet violence of extraction.

    The Gift and the Algorithm

    Fanfiction operates on what academics call a “gift economy.” Writers produce stories; readers respond with kudos, comments, bookmarks, and recommendations. No money changes hands. The currency is attention, recognition, and emotional resonance. A writer who posts a 200,000-word slow-burn romance is not performing a transaction. They are making an offering.

    This is why the community’s response to AI is not simply “we don’t like robots.” It is far more specific. The study finds that 74.4% of writers already use AI tools in some capacity—Grammarly, ChatGPT for brainstorming, search engines for research. The community is not Luddite. What it resists is automation: the posting of fully AI-generated stories without disclosure, the flooding of archives with synthetic content, the erosion of the social contract that makes the gift meaningful.

    When you leave a comment on a fanfiction story, you are not just praising prose. You are witnessing another person’s emotional labor. You are saying: I see the time you spent. I see the care. If the story was written by a large language model, that comment becomes a kind of betrayal—intimacy offered to a void. The reader has been tricked into performing connection with something that cannot connect back.

    This is why transparency is the community’s central ethical demand. Not because AI is inherently evil, but because undisclosed AI is inherently deceptive. It breaks the circuit of reciprocity that holds the community together.

    The Colonialism of the Training Set

    But the deeper wound is not what AI might do to fanfiction in the future. It is what AI has already done to fanfiction in the past.

    The study draws on work by Gero et al. and Couldry & Mejias to frame a devastating reality: the large language models now being used to generate fanfiction were trained, in part, on fanfiction itself. Millions of stories—written for free, shared in trust, often exploring queer and marginalized identities—were scraped from AO3 and FanFiction.net without consent and fed into commercial systems.

    This is not theft in the traditional sense. It is something more insidious: data colonialism. The creative labor of a community that is already economically and culturally marginalized—women, nonbinary people, queer writers—has been extracted to build tools that may eventually render their voluntary labor obsolete. The machine learned to simulate emotion by reading the diaries of people who were giving their hearts away for free.

    The irony is almost architectural. Fanfiction exists because mainstream media failed to tell the stories this community needed. So the community told them itself, in a space it built itself, under a nonprofit charter, protected from commercial exploitation. And then the commercial systems came anyway—not through the front door, but through the API.

    Three Futures

    The study organizes the community’s fears into three scenarios, borrowed from De Cremer et al. In the first, AI augments human creativity: a useful tool, a second mind. In the second, AI floods the landscape with cheap, personalized content, reducing humans to curators. In the third, human uniqueness is recognized and preserved.

    The fanfiction community, the study suggests, is cautiously open to the first, terrified of the second, and desperately hoping for the third. But hope is not a strategy. The second scenario—flooding—feels increasingly inevitable. If AI can generate passable hurt/comfort fic in seconds, and if platforms have no mechanism to distinguish synthetic from human work, the gift economy collapses under the weight of its own abundance. Scarcity is what gives the gift value. When stories are infinite, attention becomes worthless.

    What This Means for the Rest of Us

    Fanfiction is often treated as a niche interest, a subculture, a footnote to “real” literature. But the study makes clear that it is something else: a canary in the coal mine for every creative community now facing AI integration. The dynamics at play in AO3—unpaid labor, emotional investment, social reciprocity, consentless data extraction—are the same dynamics facing journalists, illustrators, musicians, and poets.

    The difference is that fanfiction writers have no union, no guild, no collective bargaining power. They have only norms. And norms are fragile things when platforms are designed without them in mind.

    The researchers end with a call for design interventions: transparency tools, ethical AI integration, community engagement mechanisms. But the subtext is bleaker. The infrastructure of the internet was not built to distinguish between human and machine creativity. The platforms that host fanfiction were designed for a world where “author” meant “person.” That world is ending.

    What the study ultimately documents is not a technological transition but a grief process. A community that has spent decades building a sanctuary for the stories mainstream culture refused to tell is now watching that sanctuary be colonized by the very systems that refused to tell them. The machine has read their diaries. Now it wants to write them back.

    Coda: The Kudos Problem

    There is a moment in the study that haunts me. The researchers note that fanfiction is “seen by its members as a socially embedded and emotionally supportive practice.” This is the language of sociology. But what it describes is something simpler and more fragile: the feeling of being known.

    When you post a story and someone leaves a comment that says “this is exactly what I needed tonight,” you are not receiving feedback. You are receiving recognition. You are being told that your unpaid labor mattered to another human being. No algorithm can replicate that. But algorithms are very good at making us forget to ask for it.

    The fanfiction community’s resistance to AI is, at its core, a resistance to forgetting. It is a demand that we remember what creativity is for when no one is paying: not product, but presence. Not content, but connection. The kudos button is small and orange and costs nothing to click. But it is also, in its quiet way, a vote for the human.

    The machines are learning to write. The question is whether we are learning to read.

    Sources: Alfassi et al. (2025), “Fanfiction in the Age of AI,” arXiv:2506.18706v1; Gero et al. (2025); Couldry & Mejias (2020); De Cremer et al. (2023); 2024 AO3 Census.

  • The Invisible Republic: What AO3’s Most-Loved Stories Reveal About Who We Are

    A cultural reading of the numbers behind fanfiction’s most popular works.

    There is a story on Archive of Our Own that has been liked 314,072 times. It is called All the Young Dudes, a Marauders-era Harry Potter epic that runs over half a million words. It is not canon. It will never be canon. And yet it has been read, bookmarked, and celebrated by more people than have purchased many Pulitzer-winning novels. If you want to understand contemporary culture, you could do worse than to ask: why?

    Two recent data projects—one scraping the top 100 most-kudosed works on AO3, another analyzing nearly 20,000 popular fics across 222 fandoms—offer us an unusually clear window into the desires, demographics, and cultural preoccupations of one of the internet’s most misunderstood creative communities. What emerges is not a picture of hobbyists killing time, but of a deliberate, ideologically charged literary culture: one that is overwhelmingly female and nonbinary, disproportionately queer, deeply invested in emotional repair, and quietly rewriting the rules of whose stories matter.

    The Canon They Actually Wanted

    The most striking finding from the top-100 analysis is how dramatically certain fandoms overperform. Harry Potter represents only 4% of all works on AO3, yet it accounts for 28% of the most-kudosed fics—seven times its proportional share. My Hero Academia and Teen Wolf round out the top three.

    This is not random. These are fandoms built around expansive worlds with emotionally underdeveloped male characters and canon that many fans experience as a betrayal of its own potential. Harry Potter in particular offers a ready-made universe with a vast, hungry readership and a source text that has become politically radioactive—making fanfiction not just a creative outlet but a corrective. When J.K. Rowling’s public positions alienated swaths of her own readership, the fandom did not dissolve; it simply removed her from the authorial equation and kept the world. Fanfiction here functions as expropriation: the community seizing the means of narrative production.

    The dominance of these specific fandoms suggests something about who is writing. You do not build a 7.9-million-word fic—the length of thirteen War and Peaces—out of casual interest. You build it because the source material left a wound you are trying to suture.

    Slash, Gender, and the Queer Feminine Gaze

    If fandoms tell us where the energy is, pairing categories tell us whose desires are being centered. Among the top 100 works, M/M (male/male) slash fiction constitutes nearly three-quarters of all stories. F/F (female/female) works account for just two.

    This asymmetry is one of the most culturally significant patterns in the data, and it demands careful reading. The standard explanation—that AO3’s user base is predominantly women and nonbinary people who are drawn to male characters because those are the characters mainstream media has bothered to develop—only partially holds. A fuller explanation requires looking at what slash does.

    Academic work on fanfiction has long positioned it as a genre of the disempowered: a space where women, queer people, and other marginalized groups can rewrite texts that excluded them. M/M slash is not simply “women writing about gay men.” It is women and nonbinary writers creating a narrative space where masculinity is made vulnerable, emotional, and available for intimate inspection without the power imbalances that structure heterosexual romance in mainstream media. The male body becomes a site of safe erotic and emotional exploration—safe because it is displaced, because it does not demand the reader map her own body onto the dynamics being described.

    The near-total absence of F/F in the top 100, meanwhile, is its own kind of data. It suggests not a lack of lesbian or sapphic readership, but a structural problem: female characters in mainstream media remain so thinly written that there is less raw material to work with, and the communities that do write F/F may be smaller, more niche, or less likely to produce the kind of mass-appeal epics that dominate kudos rankings.

    The Erotics of Completion (and Its Failure)

    The ao3wiki data reveals something else about what this community values: it is not prudish. Among popular works, “Explicit” is the single largest rating category at 28%, followed closely by “Mature” at 22%. “General Audiences” accounts for only 13%.

    This is a community that is unafraid of sex. But it is also a community that struggles to finish what it starts when sex is involved. The completion rate for Explicit-rated fics is just 56%, compared to 65% for General Audiences works. Mature-rated works fare worst, completing only 40% of the time.

    There are practical explanations for this—longer, more complex works are harder to finish, and Explicit and Mature fics tend to run longer. But there is a psychological reading too. Erotic and darkly mature fiction often emerges from intense personal need: a specific fantasy, a specific wound, a specific desire for catharsis. When that need is met—or when the writer’s life circumstances shift—the motivation to continue evaporates. The WIP (Work In Progress) is not a failure of discipline. It is often a success of function: the story did what it needed to do for the person writing it.

    This reframes the “WIP problem” entirely. Fanfiction is not a marketplace. There are no advances, no deadlines, no editors demanding completion. A fic that stops at chapter seven because the author got the promotion they were writing into the story, or processed the breakup they were working through, has succeeded on its own terms. The 44% of Explicit fics that remain unfinished are not abandoned; they are released.

    The Tropes of Repair

    What kind of stories earn the most reader love? The ao3wiki data shows that “5+1 Things”—a structural trope in which five things happen one way and the sixth happens differently—commands the highest median kudos of any tag, at 24,846 per work.

    This is significant. The 5+1 structure is fundamentally a trope of repetition with variation: it promises the reader that the pattern will hold, that the world is legible, but that something small and crucial will shift at the end. It is a formal embodiment of the therapeutic impulse that runs through so much popular fanfiction. The world is broken in known ways; let us rehearse the breaking, and then imagine the mending.

    The other top tags confirm this: “Fluff,” “Humor,” “Hurt/Comfort,” “Slow Burn,” “Angst.” These are not the tags of escapist fantasy in the simple sense. They are the tags of emotional labor—of readers and writers collaboratively processing difficulty through the safe container of fictional characters. Hurt/comfort is perhaps the most transparent: someone is hurt, and then someone else comforts them. The fantasy is not the hurt; it is the comfort. It is the assurance that pain will be witnessed and met with care.

    Who Is Writing, and Why

    So who are these writers? The demographics, where we can find them, are remarkably consistent across studies. The 2024 AO3 Census and recent academic surveys show a community that is majority women, with rapidly growing nonbinary representation, predominantly aged 18–34, highly educated, and overwhelmingly from English-speaking or Western contexts.

    The Tolkien Fanfiction Survey, tracking a slightly older and more literary corner of fandom, found that the proportion of women has dropped from 90% in 2015 to 68% in 2025, with nonbinary participants rising to 27%. This is not men entering the space; male participation has held steady at roughly 5%. It is a gender-diverse expansion of who feels entitled to write.

    Why they write is just as telling. In one recent study, 86.67% of fanfiction writers cited “character exploration” as a primary motivation; 76.66% cited “exploration of non-canonical relationships”; 61% cited “expanding the world of a specific fiction.” Only 43% mentioned “easier publishing than in the industry”—suggesting that most are not writing fanfiction as a stepping stone to professional authorship, but as an end in itself.

    This matters. Fanfiction is often framed as a training ground for “real” writing, but the data suggests the opposite: it is a space where the pressures of the commercial literary market are deliberately refused. Writers are not producing content for algorithms or advances. They are producing it for community, for catharsis, for the pleasure of extending a world they love beyond the boundaries its original creator set.

    The One-Shot and the Epic

    The archive itself is bifurcated in form. Forty-three percent of popular works are one-shots under 10,000 words; 16% are epics over 100,000. The median popular fic sits at 14,064 words—substantially longer than a short story, but not a novel.

    This distribution maps neatly onto the two primary functions fanfiction serves. The one-shot is the moment, the scene, the fix-it, the single emotional beat that canon refused to give. The epic is the alternate universe, the slow-burn romance, the complete reimagining that requires hundreds of thousands of words to earn its ending. Both are necessary. The one-shot is fanfiction as poem; the epic is fanfiction as novel. Together they suggest a readership that values both immediacy and immersion, both the quick hit of emotional recognition and the deep dive of sustained worldbuilding.

    What the Numbers Cannot Capture

    There is a category in the ao3wiki data called “Kudos Per 1,000 Words,” and the winner by an absurd margin is a fic titled I Am Groot. It has earned 136,005 kudos per thousand words. The database notes, dryly, that this “may say something profound about the internet.”

    It does. It says that fanfiction culture is not governed by the same metrics of “quality” that dominate commercial publishing. A three-word story can outrank a three-million-word one if it hits the right note of humor, recognition, and communal in-joke. The kudos system is not a measure of literary merit. It is a measure of affective resonance—how deeply a story made its readers feel seen, feel less alone, feel something they needed to feel.

    This is the observation that underlies all the others. Fanfiction is not failed original fiction. It is not a shadow economy of people who couldn’t make it in “real” publishing. It is a parallel literary culture with its own aesthetics, its own ethics, and its own readership—one that is larger, more engaged, and more prolific than most of the commercial literary world. The 1.1 billion words in the ao3wiki database alone represent a library larger than most national collections.

    And it is a culture built by people who have historically been told their desires are marginal: women, queer people, the neurodivergent, the culturally displaced. They have built, in AO3, what Henry Jenkins called a “participatory culture”—not one where they consume stories handed down from above, but one where they seize the narrative and rewrite it until it fits.

    Conclusion: The Stories We Tell When No One Is Paying

    If you look at the most popular works on AO3 and see only derivative fiction, you are looking at the wrong thing. Look instead at the patterns: the preference for repair over destruction, for queer intimacy over heteronormative romance, for emotional labor over plot machinery, for community validation over commercial success. Look at the demographics: a space that is feminized, queered, and increasingly nonbinary. Look at the motivations: not ambition, but connection. Not profit, but presence.

    Fanfiction is the largest body of unpaid, uncommissioned narrative writing in human history. It is also, arguably, the most honest. No one is writing a 7.9-million-word fic for money. They are writing it because the story they needed did not exist, and they could not live in a world where it remained unwritten.

    The numbers tell us what is popular. But the culture tells us why it matters. And the why is this: in a media landscape that still largely refuses to center the emotional lives of women, queer people, and the marginalized, AO3 has become a do-it-yourself public library of the heart. The kudos are not just likes. They are recognition. They are I needed this too.

    That is the culture the data reveals. That is the republic these writers have built—one story, one kudo, one unfinished WIP at a time.

    Sources: ao3wiki.com 2026 statistics; Eva Rose Côté, “Trends in the Top 100 Fanfictions on AO3” (2022); 2024 AO3 Census; Tolkien Fanfiction Survey 2025; arXiv study “Fanfiction in the Age of AI” (2025); Rouse & Stanfill, “Fan Demographics on Archive of Our Own” (2023).

  • Omni‑Logic Public License (OLPL)

    Version 2026.2
    Copyright (c) [Year] [Author]

    1. DEFINITIONS

    For the purposes of this License:

    • “Work” means the associated software, data, documentation, or logical instructions.
    • “Entity” means any natural person, legal person, organization, or artificial system capable of executing or applying the Work.
    • “Controller” means the human or legal person responsible for an Entity that cannot itself assume legal obligations (including minors, non‑sentient systems, or artificial intelligences).
    • “Author” means the copyright holder.

    2. GRANT OF RIGHTS

    Subject to the terms of this License, the Author grants each Entity a perpetual, worldwide, non‑exclusive, royalty‑free, irrevocable (except as provided in Section 6) license to:

    1. Use, execute, and operate the Work for any purpose.
    2. Modify, adapt, translate, or create derivative works.
    3. Reproduce, distribute, and publicly make available the Work or derivative works, provided that this License and the original copyright notice are included.

    Sublicensing:
    Entities may distribute derivative works under different terms provided that this License continues to apply to the portions of the Work incorporated therein.

    3. ATTRIBUTION & RESPONSIBILITY

    3.1 Attribution Requirement
    All copies or substantial portions of the Work must retain this License and the original copyright notice.

    3.2 Controller Responsibility
    Where an Entity is unable to understand or comply with this License (including minors, persons with disabilities, or artificial systems), the Controller is responsible for ensuring compliance and assumes all legal obligations arising from use of the Work.

    4. PATENT LICENSE & TERMINATION

    4.1 Patent Grant
    The Author grants each Entity a perpetual, worldwide, royalty‑free license to any patent claims owned or controlled by the Author that are necessarily infringed by the unmodified Work.

    4.2 Patent Termination
    This License terminates automatically for any Entity that initiates or participates in a legal action alleging that the Work infringes a patent held by that Entity or its affiliates.

    Termination applies only to the Entity initiating such action and does not affect other licensees.

    5. FIELD‑OF‑USE NEUTRALITY

    The Work may be used in any field of endeavour, including commercial, academic, industrial, safety‑critical, or defence applications.
    The Entity or Controller bears all responsibility for compliance with applicable laws, regulations, and ethical obligations in their jurisdiction.

    6. DISCLAIMER OF WARRANTY

    THE WORK IS PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON‑INFRINGEMENT, OR FUNCTIONAL SAFETY.

    7. LIMITATION OF LIABILITY

    TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE AUTHOR SHALL NOT BE LIABLE FOR ANY DAMAGES OR LOSSES ARISING FROM OR RELATED TO THE WORK, INCLUDING BUT NOT LIMITED TO:

    • Data loss or corruption
    • Property damage
    • System malfunction
    • Personal injury or death
    • Environmental or operational harm
    • Malfunction of autonomous or semi‑autonomous systems

    Where applicable law does not permit exclusion of liability for gross negligence or intentional misconduct, those exclusions shall not apply.

    8. SEVERABILITY

    If any provision of this License is held unenforceable, the remaining provisions shall remain in full force and effect. The unenforceable provision shall be interpreted to the maximum extent permissible to reflect the original intent.

    9. GOVERNING LAW

    Unless otherwise required by applicable law, this License shall be governed by and interpreted under the laws of [choose one: Switzerland / Delaware / England & Wales], without regard to conflict‑of‑law principles.

    A Practical Guide to the Omni‑Logic Public License (OLPL)

    A future‑proof license for humans, companies, and AI systems alike

    Software licensing hasn’t kept pace with the world we now build in. We’re no longer writing code that lives quietly on a laptop. We’re writing logic that runs:

    • inside autonomous robots
    • across distributed AI agents
    • in safety‑critical systems
    • in orbit, underwater, and everywhere in between

    And yet most licenses still assume a 1990s world: a single human user, a single computer, and a single jurisdiction.

    The Omni‑Logic Public License (OLPL) is designed to break that mould. It’s a modern, enforceable license built for the next century of software — one where humans, corporations, and artificial systems all interact with code in ways traditional licenses never anticipated.

    This guide walks you through what the OLPL is, why it exists, and how to use it.

    Why the OLPL Exists

    Traditional licenses fall short in three major areas:

    1. They assume the “user” is always an adult human

    But today, the “user” might be:

    • a child
    • a non‑technical operator
    • an AI agent executing code autonomously

    The OLPL introduces the concept of a Controller — the responsible human or organization behind any entity that cannot legally accept obligations. This single idea makes the license compatible with AI, minors, and automated systems without needing new legal categories.

    2. They assume Earth‑bound jurisdictions

    MIT, GPL, Apache — all of them rely on terrestrial legal frameworks. That’s fine, but it doesn’t scale to:

    • orbital manufacturing
    • lunar operations
    • autonomous systems deployed across borders

    The OLPL keeps its scope global but grounds enforcement in a real, recognized legal system. This makes it enforceable today while still being relevant tomorrow.

    3. They don’t address modern liability

    Software now controls:

    • drones
    • vehicles
    • surgical robots
    • industrial automation
    • weapon systems

    The OLPL includes a modern liability framework that acknowledges these realities while staying within what courts actually allow.

    What the OLPL Guarantees

    The OLPL is built around three pillars:

    1. Freedom to Use

    You can use the Work for any purpose — commercial, academic, industrial, or even defence‑related. No field‑of‑use restrictions. No moral clauses. No hidden traps.

    2. Freedom to Modify

    You can adapt, translate, extend, or integrate the Work into larger systems. Derivative works can be licensed under different terms, as long as the original OLPL notice stays attached to the original portions.

    3. Freedom to Distribute

    You can share the Work or your modifications, publicly or privately, for free or for profit.

    In short:
    It’s permissive like MIT, but with modern protections like Apache.

    What Makes the OLPL Different

    Here’s where the OLPL steps beyond traditional licenses.

    1. The Controller Concept

    If an AI system uses the Work, the human or organization behind it is responsible for compliance.
    This solves:

    • AI agency
    • minors using software
    • accessibility issues
    • automated deployment pipelines

    No other mainstream license handles this cleanly.

    2. Patent Peace

    The OLPL includes a patent license and a patent‑retaliation clause.
    If someone tries to sue the Author for patent infringement, their rights under the OLPL end immediately. This discourages patent aggression without punishing the broader community.

    3. Realistic Liability Shield

    The OLPL explicitly disclaims liability for:

    • data loss
    • property damage
    • system malfunction
    • personal injury or death
    • autonomous system failures

    But it does so in a way that aligns with actual legal precedent — avoiding unenforceable absolutes.

    4. Future‑Proof, Not Sci‑Fi

    The OLPL avoids references to:

    • hypothetical jurisdictions
    • speculative legal systems
    • undefined “universal law”

    Instead, it uses a grounded governing‑law clause while keeping the license globally applicable.

    How to Use the OLPL

    Using the OLPL is simple.

    If you’re an author

    Add the following to the top of your repository or distribution:

    Copyright (c) [Year] [Your Name]
Licensed under the Omni‑Logic Public License (OLPL), Version 2026.2.
See LICENSE for details.
    Copyright (c) [Year] [Your Name]
Licensed under the Omni‑Logic Public License (OLPL), Version 2026.2.
See LICENSE for details.

    Include the full license text in a LICENSE file.

    If you’re a user

    You can:

    • use the Work in any project
    • integrate it into commercial products
    • modify it
    • redistribute it

    Just keep the original copyright notice and license attached to the parts you use.

    If you’re building AI systems

    Treat the AI as an Entity and yourself as the Controller.
    You’re responsible for ensuring the AI’s use complies with the license.

    Who the OLPL Is For

    The OLPL is ideal for creators who want:

    • permissive licensing
    • modern liability protection
    • compatibility with AI and autonomous systems
    • patent peace
    • global applicability
    • long‑term stability

    It’s especially suited for:

    • robotics
    • automation
    • AI agents
    • safety‑critical systems
    • industrial software
    • research tools
    • open hardware logic
    • distributed systems

    If your code might one day run in a robot, a drone, a factory, or an AI swarm, the OLPL is built for you.

    Why the OLPL Matters

    ‘Licenses shape ecosystems’. They determine what can be built, who can build it, and how safely it can be shared.

    The OLPL acknowledges a simple truth:

    Software is no longer just software. It’s logic that moves through the world, acting on our behalf.

    We need licenses that reflect that reality — not the world of 1995.

    The OLPL is a step toward that future: permissive, enforceable, and ready for the next century of computation.

    LICENSE.TXT

    Omni‑Logic Public License (OLPL)

Version 2026.2
Copyright (c) [Year] [Author]

1. DEFINITIONS

For the purposes of this License:

“Work” means the associated software, data, documentation, or logical instructions.

“Entity” means any natural person, legal person, organization, or artificial system capable of executing or applying the Work.

“Controller” means the human or legal person responsible for an Entity that cannot itself assume legal obligations (including minors, non‑sentient systems, or artificial intelligences).

“Author” means the copyright holder.

2. GRANT OF RIGHTS

2.1 Subject to the terms of this License, the Author grants each Entity a perpetual, worldwide, non‑exclusive, royalty‑free, irrevocable (except as provided in Section 6) license to:

Use, execute, and operate the Work for any purpose.

Modify, adapt, translate, or create derivative works.

Reproduce, distribute, and publicly make available the Work or derivative works, provided that this License and the original copyright notice are included.

2.2 Sublicensing:

Entities may distribute derivative works under different terms provided that this License continues to apply to the portions of the Work incorporated therein.

3. ATTRIBUTION & RESPONSIBILITY

3.1 Attribution Requirement

All copies or substantial portions of the Work must retain this License and the original copyright notice.

3.2 Controller Responsibility

Where an Entity is unable to understand or comply with this License (including minors, persons with disabilities, or artificial systems), the Controller is responsible for ensuring compliance and assumes all legal obligations arising from use of the Work.

4. PATENT LICENSE & TERMINATION

4.1 Patent Grant

The Author grants each Entity a perpetual, worldwide, royalty‑free license to any patent claims owned or controlled by the Author that are necessarily infringed by the unmodified Work.

4.2 Patent Termination

This License terminates automatically for any Entity that initiates or participates in a legal action alleging that the Work infringes a patent held by that Entity or its affiliates.

Termination applies only to the Entity initiating such action and does not affect other licensees.

5. FIELD‑OF‑USE NEUTRALITY

The Work may be used in any field of endeavour, including commercial, academic, industrial, safety‑critical, or defence applications.
The Entity or Controller bears all responsibility for compliance with applicable laws, regulations, and ethical obligations in their jurisdiction.

6. DISCLAIMER OF WARRANTY

THE WORK IS PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON‑INFRINGEMENT, OR FUNCTIONAL SAFETY.

7. LIMITATION OF LIABILITY

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE AUTHOR SHALL NOT BE LIABLE FOR ANY DAMAGES OR LOSSES ARISING FROM OR RELATED TO THE WORK, INCLUDING BUT NOT LIMITED TO:

Data loss or corruption
Property damage
System malfunction
Personal injury or death
Environmental or operational harm
Malfunction of autonomous or semi‑autonomous systems

Where applicable law does not permit exclusion of liability for gross negligence or intentional misconduct, those exclusions shall not apply.

8. SEVERABILITY

If any provision of this License is held unenforceable, the remaining provisions shall remain in full force and effect. The unenforceable provision shall be interpreted to the maximum extent permissible to reflect the original intent.

9. GOVERNING LAW

Unless otherwise required by applicable law, this License shall be governed by and interpreted under the laws of [choose one: Switzerland / Delaware / England & Wales], without regard to conflict‑of‑law principles.