A residential property management company oversees rental portfolios for close to three hundred landlords across a mid-sized city. For four years, nearly every maintenance request above a modest dollar figure lands on the founder's desk before a tradesperson gets approved. Every landlord upset about a vacancy, a late payment, or a repair bill that ran over eventually gets put through to her directly. Every tenant complaint the front-line coordinators can't resolve in one call sits in her inbox by the end of the day.

The business grows steadily. Landlords refer other landlords. By year four, she hires an operations manager specifically to take maintenance decisions and landlord relationships off her desk, the thing that's been eating her calendar for longer than she'd like to admit.

Three months later, she is just as busy. The new hire is competent, well-liked, clearly working hard. And somehow the founder is still approving the same maintenance requests, still getting looped into the same landlord calls, still fielding the same escalated tenant complaints. Just one email thread later than before.

The Task Moved. The Decision Didn't.

The easy read here is that the hire was wrong, or that the founder can't actually let go, whatever she tells herself about wanting to. Neither is usually true, and both miss what's actually happening.

Delegating a task and transferring the capability behind it are not the same action, even though they feel identical in the moment of handing something over. A task has a beginning and an end: here is the work, go do it. Capability is different. It is the standing to decide what "done well" means without checking first, and it only exists once several specific things have actually moved from one person's head into somewhere the new person can reach them.

Hand over the task without the rest of it, and the work genuinely leaves the founder's desk. It just doesn't stay gone. It comes back wrapped in a question, a meeting, an email asking whether this is okay to approve, because nobody ever decided out loud what "okay" means.

What Actually Has to Travel With the Work

*The Designed Business* is specific about what that "rest of it" consists of. Before concluding that a new hire simply isn't ready, the book suggests checking five things directly: does this person know the result they're responsible for, not just the task list in front of them? Do they know which decisions they're allowed to make on their own? Do they have the information required to make those decisions well? Do they know exactly when to escalate, and when not to? And do they understand the standard the work is judged against, not just what needs doing?

Miss any one of these, and the task returns home disguised as something else entirely: a training problem, a confidence problem, a give-it-more-time problem. It is usually none of those. It is a specific, nameable thing that was never handed over, sitting quietly underneath a task that was.

Where the Operations Manager Actually Stood

Run those five questions against the property company's new hire, and the gap stops being mysterious.

The result she owned was never defined precisely. "Handle maintenance and landlord relationships" sounds like a result. It's actually a task list with no finish line attached, no number or outcome she could point to and call good for the month.

The decision right was never named either. Nobody had said, in words, that she could approve a repair up to a certain amount without checking first, or offer a dissatisfied landlord a specific concession within a defined range. So every maintenance call above a token amount, and every uncomfortable landlord conversation, kept arriving at the founder's desk by default. Not because the operations manager lacked judgment, but because nobody had told her she was allowed to use it.

The information gap was quieter but just as real. The founder carried years of context that never made it into any file: which contractors actually show up on time, which landlords get anxious and need a call rather than an email, which properties have a history that changes how a routine request should be handled. None of that lived anywhere the new hire could reach it. She wasn't failing to use judgment. She was making calls with half the facts the founder had been using for years.

The standard existed only as a feeling. The founder knew what "handled well" looked like the moment she saw it, and had never once described it in words specific enough for someone else to check their own work against before it reached a landlord.

And the escalation boundary ran backward. Instead of a clear line marking what truly needed the founder's input, the operations manager had absorbed, correctly, that almost anything might need it, so she escalated early and often, just to be safe. From the founder's side, that looked like someone who wasn't ready to take ownership. It was actually someone behaving exactly as the business had trained her to behave.

Four of the five things never moved. The task did.

Turning What's in Your Head Into Something the Business Can Use

The useful part of this isn't the diagnosis. It's that each of the five gaps closes differently, and none of them closes by waiting for the new hire to get more comfortable.

A pattern the founder repeats without thinking about it can usually become a method someone else can follow: the specific sequence she actually runs through before approving an unusual repair, written down once, rather than relived from scratch every time. A standard she recognizes instantly but has never described can become a short, concrete checklist, not a sprawling manual, just the two or three things that separate acceptable from not. A decision she keeps making the same way whenever a familiar situation recurs can become an explicit rule, stated once, rather than a fresh judgment call every time it comes up. Information that currently lives only in her memory can move into whatever the team actually uses day to day, a shared note, a property file, a short briefing, so the right person has the right detail without needing to ask her for it. And the boundary for when something genuinely needs her, rather than everything needing her by default, has to be stated as a specific line, not a vague sense that she's generally available if something comes up.

None of this requires documenting every thought the founder has ever had. It requires identifying the handful of things that keep recreating the same bottleneck, and moving exactly those, deliberately, instead of hoping proximity and time will eventually do it on their own.

Before Handing Off the Next Task

A few questions worth running honestly against whatever you're about to delegate, or already have.

Can you state, in one sentence, the actual result this person owns, separate from the list of things they're doing?

Have you told them, explicitly, which decisions are theirs to make without you, or have they only learned the boundary by watching what gets overturned afterward?

If the answer to either is no, the problem probably isn't the person you hired. It's the things you haven't handed over yet, still waiting underneath the one you have.

A Team Is Something You Design, Not Something You Hope For

None of this argues against hiring, or suggests a founder should document every decision before trusting anyone with anything. Early in most businesses, staying close to the work is exactly right. The founder needs to see where things actually go wrong before she can describe it to someone else.

The shift that matters is simpler than it sounds: noticing when a task keeps bouncing back, and asking which specific thing beneath it, the result, the decision right, the information, the standard, the escalation line, was never actually handed over. Delegation that only moves tasks will always feel, eventually, like it made things busier rather than lighter. Delegation that moves capability is the only kind that ever actually lightens the load it was supposed to.

The property company's founder didn't need a different hire. She needed to notice that she'd handed over the easiest of the five things and quietly kept the other four for herself, the way most founders do, right up until someone points out that they're still holding them.


If this sounds like your business, last week's piece looks at the other half of the same problem: not what a new hire still needs, but what the founder herself has been personally carrying all along, trust, judgment, memory, standards, or courage, and why that's usually several different problems wearing one name. Worth reading alongside this one: The Founder Is Not Always the Real Bottleneck.

Both approaches move beyond coding assistants. Their practical value depends on how organisations manage context, enforce controls and retain ownership.

An engineering team generates a feature in an afternoon. Security reviews it the following week. An integration assumption surfaces during testing. Operations asks who approved the recovery approach.

Implementation has accelerated. The decisions around it still take time.

In AI Will Not Fix a Broken Delivery Model, I explored why organisations need to redesign delivery around AI. AWS’s AI-Driven Development Life Cycle and Anthropic’s AI-native SDLC playbook offer two practical approaches to that redesign.

I see value in both. The comparison becomes useful when we examine how each connects business intent, engineering execution and human accountability.

AWS starts with how the team makes decisions

AWS introduced AI-DLC around Inception, Construction and Operations. AI proposes plans, seeks clarification and generates work. People validate the direction and make critical decisions.

Mob Elaboration and Mob Construction bring the team together around requirements and implementation, with context retained in the repository. AWS’s AI-DLC methodology

For enterprise leaders, that collaborative model deserves attention.

A customer onboarding change can involve product, identity, security, integration and operations. Each function understands a different consequence. An agent needs those perspectives before its plausible solution becomes an approved one.

The benefit I would look for is earlier resolution of conflicting assumptions.

AWS also makes the workflow adaptive. Teams can adjust the stages and depth to the task rather than imposing the same analysis on every change. AWS’s adaptive workflow guidance

That principle needs protecting during adoption. A straightforward defect should not acquire a collection of generated documents simply because the framework can produce them.

Anthropic makes the connections between stages explicit

Anthropic retains six familiar stages: Plan, Design, Build, Test, Deploy and Maintain.

The practical shift is how work connects across them. Versioned intent, specifications, plans, code, tests and review findings provide inputs to subsequent activities. Repository instructions and skills carry institutional knowledge; hooks enforce defined checks. Evaluations assess agent behaviour, while production findings feed back into planning. Human judgement remains necessary, particularly for critical and regulated changes. The plays are modular rather than a mandatory linear sequence. Anthropic’s AI-native SDLC playbook

The implication interests me more than the filenames.

A requirement normally passes through conversations, tickets, documents and interpretation. Each transition creates an opportunity to lose context.

When people and agents work from the same approved artefact, the organisation has a clearer basis for checking whether implementation still reflects the original decision.

But an accessible file can still contain an ambiguous requirement. Someone must resolve that ambiguity.

The approaches overlap more than the labels suggest

My reading is that AWS places greater emphasis on collaborative decision-making and adaptive orchestration. Anthropic makes the connections between artefacts, agent instructions and execution controls particularly concrete.

This is a comparison of emphasis, not exclusive capabilities.

Even the stage counts need care. AWS’s original method describes three phases; its current open-source implementation describes five and supports multiple coding environments. AI-DLC implementation guide

I would assess either approach against the organisation’s delivery problems before choosing a framework.

Executable controls still need owners

The supplied commentary makes a useful distinction between skills that guide behaviour and hooks that enforce checks. It goes too far when it suggests that hooks make compliance certain.

A hook can block a defined action within the boundary it controls. It cannot establish that the rule is complete, the configuration is correct or every relevant path passes through it.

Consider customer data. A check might prevent credentials entering a code change while missing sensitive information written to application logs.

The check worked. The organisation’s control coverage was incomplete.

Each automated control needs an owner, a defined scope, evidence that it works and a response when it fails. Those responsibilities become more consequential as agents gain authority.

Review must follow the risk

I would also resist treating plan approval as sufficient assurance for the resulting code.

A sound plan can produce a flawed implementation. Tests can encode the same misunderstanding as the code. An automated reviewer can miss a business constraint that nobody supplied.

Reviewing the plan helps settle direction early. Release assurance still requires evidence about what was built.

For a bounded internal change, automated checks and targeted human review may be proportionate. Changes to identity, payments, customer data or production permissions warrant closer scrutiny.

The organisation should define those boundaries before increasing autonomy.

Production feedback is established practice

The supplied article suggests traditional SDLC lacked a production feedback loop. DevOps and SRE already connect incidents, monitoring and operational learning to engineering work.

The useful development here is making that connection more executable: preserving diagnostic context, initiating corrective work and limiting agents to authorised actions.

I would judge that capability by how reliably it recognises when to stop and escalate.

Start with one complete delivery path

For a first implementation, I would combine the strongest practices from both approaches.

Bring the relevant people together to validate the outcome and constraints. Record the approved context where agents can use it. Connect implementation to meaningful checks. Define approval boundaries and recovery authority.

Then measure the complete path: delivery time, review queues, rework, escaped defects and operational effort.

A faster build is useful. Whether the organisation can release, operate and support that change with confidence determines how much delivery it should delegate next.

Is your organisation ready to delegate more of software delivery to AI?

I work with technology leaders to clarify delivery ownership, strengthen architecture governance and define where AI agents can act safely.

If you’re evaluating AWS AI-DLC, Anthropic’s AI-native SDLC or your own approach, let’s discuss what fits your organisation and where to start.

Let’s discuss your AI delivery approach

A commercial insurance brokerage has been running for nineteen years. Four account managers handle day-to-day client relationships. A claims coordinator manages the paperwork when something goes wrong. The firm has a genuine book of business and a reputation built across two decades in a mid-sized market.

The founder still touches almost everything that matters. Every renewal above a certain premium gets her review before it goes out. A client who’s had a serious claim wants to hear from her personally, not whoever happens to answer the phone. When a prospective client asks an unusual question about coverage, the team’s instinct is still to walk down the hall and ask her.

Her staff aren’t incompetent. Her systems aren’t primitive. On paper, she runs a real business. Nineteen years in, she is still the person almost everything runs through.

The easy conclusion is that she’s the bottleneck. Delegate more. Learn to let go. Maybe she holds on too tightly, or maybe the team just isn’t ready yet.

That conclusion is usually wrong, or at least badly incomplete. It treats “the founder is involved in too much” as a single, simple problem with a single, simple fix. It rarely is.

“Just Delegate More” Misses What’s Actually Happening

When a business has outgrown its founder but nothing moves, the standard advice arrives fast: delegate, hire, document, let go. Sometimes that genuinely works. More often something stranger happens. The founder hands off a task, and a few weeks later the same work is somehow back on her desk, this time wrapped in a meeting and two more people waiting on her opinion before anything can proceed.

That isn’t a failure of delegation so much as a sign that delegation was never the actual problem. Giving someone a task is different from giving them the standing to decide alone. An account manager can draft a renewal competently. Whether she can decide, on her own authority, that a client’s risk profile has shifted enough to warrant different coverage, without checking first, is a separate question entirely. If nobody has ever answered that second question out loud, handing over the first task just moves the bottleneck one desk over. It doesn’t remove it.

This is the trap in making founder dependence personal. “I’m too involved” sounds like a character flaw, something about an unwillingness to let go. It’s usually closer to a staffing gap that has nothing to do with headcount: the business itself was never taught to do several specific things it has only ever watched her do.

Five Different Things a Founder Might Be Carrying

The Designed Business names this more precisely than “founder dependence” usually gets named. A founder who can’t step back typically isn’t carrying one thing. She’s carrying some combination of five, and each one needs a different fix.

Sometimes she’s carrying trust. Clients believe the recommendation because of her personally, built over years of direct contact, not because they trust the firm as an institution. An account manager can give the technically correct answer and still not be believed in the same way.

Sometimes she’s carrying judgment. The team can execute the process, but the harder interpretive call  which risk is genuinely dangerous and which is boilerplate noise, which client question deserves a careful answer and which doesn’t  still only happens reliably in one head.

Sometimes she’s carrying memory. She remembers why a particular client has an unusual policy exclusion from four years ago, which supplier underperforms on claims, which client gets anxious at renewal time and needs more reassurance than the paperwork strictly requires.

Sometimes she’s carrying standards. Everyone on the team knows a renewal review needs to be thorough. Nobody but her could actually describe, in enough detail for someone else to check their own work against it, what thorough means.

And sometimes she’s carrying courage: the willingness to tell a client their risk appetite doesn’t match reality, decline a deal that’s commercially tempting but wrong for the client, or push back on a renewal priced too aggressively just because a competitor undercut it. The team may see exactly the same problem she does. Only she feels entitled to say so out loud.

Collapsing all five into “she needs to delegate more” guarantees the wrong fix, because trust doesn’t transfer the way memory does, and memory doesn’t transfer the way courage does. A firm that tries to close a courage gap by writing a procedure manual will end up with a very well-documented version of the same stall.

What Thirty Days Away Would Actually Reveal

The Designed Business offers a sharper way to find out which of the five is actually in play, rather than guessing. It’s the book’s second diagnostic test: what does the customer lose if the key person disappears for thirty days?

Run it honestly against the brokerage. If she took a genuine month off, no calls, no check-ins, what specifically would happen?

Most renewals would probably still go out. The account managers know the clients, know the process, know how to draft a policy. That part of the business has already moved past her.

But a handful of larger renewals would likely stall, waiting for a sign-off nobody else feels authorized to give. That’s not a trust gap or a memory gap. It’s a courage gap wearing a process costume: nobody has been told, in words, “you can approve this without me,” so nobody does.

A long-standing client’s unusual exclusion from several years ago might get missed entirely at renewal, because the reason for it exists only in her memory, never in the client’s file. That’s a different failure, and no amount of delegated authority fixes it. What’s missing is information that was never written down, not permission that was never granted.

And if a serious new prospect, the kind who wants real reassurance before signing, gets handed to an account manager instead of her, the deal might simply be lost. Not because the account manager is unqualified, but because the client’s trust was never in the firm. It was in her, specifically, and nobody ever worked on moving it.

Three different outcomes from the same thirty-day absence. Three different diagnoses. Only one of them, the missing memory, gets fixed by better documentation. None of them gets fixed by “delegate more” treated as one instruction.

The Fix Has to Match the Form

This is the part that gets skipped when founder dependence is treated as one problem with one solution.

A trust gap closes slowly, by deliberately putting someone other than the founder in front of clients early and often, before a crisis forces it, so trust has time to attach to a second name.

A judgment gap closes by making the invisible decision rule visible: naming, specifically, what the founder is actually checking for when she reviews a renewal, until someone else can apply roughly the same test without her in the room.

A memory gap closes by building the habit of recording the why alongside the what, not just that an exclusion exists, but why it was granted, so the reasoning survives even when she isn’t there to supply it.

A standards gap closes by writing down what “good” actually means in concrete, checkable terms, rather than leaving it as a feeling only she recognizes.

A courage gap, probably the hardest of the five to fix with a document, closes through explicit decision rights: a rule that says exactly when someone else is allowed to say no to a client, decline a deal, or flag an underpriced renewal, without needing anyone’s personal bravery, because the business has already decided the answer in advance.

None of these fixes is “work less” or “trust your team more.” Each one is a specific, nameable thing currently sitting in one person’s head that has to move somewhere else.

A few honest questions

Which of the five- trust, judgment, memory, standards, or courage   does your own business most obviously still run through you?

If you disappeared for thirty days starting tomorrow, what specifically would stall, and is that a gap in permission, in information, or in belief?

Has anyone on your team actually been told, in words, which decisions they’re allowed to make without checking with you first, or have they only ever learned by watching what gets overturned afterward?

The Founder Isn’t the Problem. The Undesigned Part Is.

None of this argues that a founder’s involvement never matters, or that a well-designed business removes judgment and leaves only procedure behind. Some things should stay personal: a particular eye, a particular relationship, a standard that genuinely deserves to stay scarce. The point isn’t to erase the founder from the business.

It’s to stop treating “I’m too involved” as a personal failing and start asking which specific thing the business has never been taught to carry. A founder who hears “you need to let go” for the fourth time and tries the same vague instruction again will get the same result as last time. A founder who can say, specifically, “this is a courage gap, not a trust gap,” knows exactly which fix to try next.

That’s the real difference between a business that eventually outgrows its founder and one that just keeps adding people around the same unresolved dependency.

If this pattern sounds familiar, Chapter One of The Designed Business, “The Business That Still Depends on You,” goes several layers deeper into exactly this breakdown. Worth the hour, read with your own business in mind.

A boutique commercial photography studio spends three years earning one relationship. The founder, a photographer by training, personally scouts every room in a boutique hotel group’s flagship property, builds each shot list around what the listing actually needs to sell, and does the final color grading on every image before it goes anywhere near a booking site. The hotel’s occupancy improves. The marketing director notices, and mentions it to her counterparts across the group.

Then the call comes: the group wants to make the studio its exclusive photography partner across the entire portfolio, twelve properties, starting with three in the next six weeks.

The founder says yes before she’s finished the sentence in her head. Most people would. Driving home afterward, though, a quieter question arrives, one that has nothing to do with whether the opportunity is good. It’s whether the business, as it currently exists, can actually survive saying yes to it.

The Instinct to Answer With a Resourcing Plan

Ask most founders what would happen if demand for their business doubled, and the answer arrives fast: hire someone, extend the hours, rent more space, spend more on the tools already in use. It’s not an unreasonable first instinct. Growth does often require more of something.

The trouble is that this answer treats every kind of strain as the same kind of strain, as if a business under pressure simply needs more of itself, applied faster. It skips the actual question, which isn’t whether more resource would help. It’s what, specifically, would fail first if nothing else changed.

That distinction matters more than it sounds like it should, because the two answers point at completely different problems.

What the Question Is Actually Asking

*The Designed Business* frames this directly as one of two diagnostic tests worth running before chasing more demand: what breaks if demand doubles? The book is specific that “we’d need more people” doesn’t count as an answer, because it’s too vague to act on. The real question is which part fails first, and why. The founder’s calendar. The accuracy of a quote. How fast a new client actually gets started. The consistency of the finished work. Whether cash arrives in time to cover what delivery costs before the invoice clears.

Most businesses have never actually answered this with any precision, because until growth forces the question, there’s rarely a reason to sit with it. Revenue looks fine. Customers keep showing up. The strain, if it exists, stays private and manageable, the kind of thing a founder absorbs quietly rather than diagnoses. A sudden jump in demand removes that shelter fast. Whatever the business was quietly compensating for becomes visible to everyone, usually at the worst possible moment to discover it.

A Break About Capacity, and a Break About Design

Not every point of failure means the same thing, and collapsing them into one category is exactly what leads founders toward the wrong fix.

A capacity break is a genuine resourcing shortfall. There simply isn’t enough of something: hours, hands, inventory, equipment, working capital. The method for doing the work is sound. There just isn’t enough of it to go around at the new volume. More resource, applied to a capacity break, actually solves it.

A design break is different. It’s a point where the business has never actually decided how something should work once it’s not the founder personally handling it. No amount of additional resource fixes a design break, because the missing thing was never quantity. It was a decision, a standard, or a boundary that nobody has yet made explicit. Hiring a second person to make an undefined judgment call doesn’t remove the dependency on judgment. It just adds a second person waiting for permission.

Most founders run straight past this distinction because both kinds of break feel identical from the inside: too much to do, not enough time to do it. They only look different once you ask, specifically, what would actually happen first.

The Studio Runs the Numbers

Back to the photography studio, now facing three properties in six weeks instead of one property a year. The founder sits down and forces herself past “we’d need another shooter” to ask what would genuinely fail first.

The first candidate is her own calendar. Every property still needs her personally to scout it, because the shot list depends on judgment she’s never described to anyone else: which rooms actually drive bookings, which angles flatter a space that photographs poorly in person, when a property’s real selling point isn’t the room at all but the view or the light at a certain hour. That’s a design break. A second shooter with a camera doesn’t inherit an eye that’s never been taught.

The second candidate is final quality control. Every image currently passes through her personal color grading before a client sees it, and “good” has only ever lived in her own judgment, never written down as anything another editor could apply consistently. Also a design break.

The third is onboarding. Each new property needs its shot list built from scratch around what that specific property is trying to sell, and right now that process exists only as something she does, not something anyone else has been shown how to do. A third design break.

The fourth is cash flow. Three simultaneous shoots mean equipment hire, contractor day rates, and travel costs land well before the client’s invoice clears. That one actually is a capacity break: a real, quantifiable gap that more working capital, arranged in advance, would close.

Of the four points most likely to fail, three have nothing to do with how many people are on the roster. Hiring a second shooter, the obvious first move, would have addressed exactly one of the four, and not the one most likely to break first.

Where to Look Before Saying Yes

None of this means turning down the opportunity, and it isn’t an argument for over-preparing before every reasonable next step. Early growth almost always outruns perfect readiness, and that’s normal. The value of the question isn’t caution for its own sake. It’s finding out, before the pressure arrives, which parts of the business are genuinely ready to carry more weight and which parts have simply never been tested.

A useful way to run the exercise honestly: look at the last time volume actually rose, even briefly, a busy month, a seasonal spike, a single large client. Notice the first thing that felt like it was about to give way. That’s rarely random. It tends to be the same point every time, because it’s the same structural gap, not a new one each occasion.

What the Honest Answer Looks Like

A few questions worth answering specifically, not in general terms:

If the next surge of demand arrived this month, what is the first thing that would fail, not eventually, but within the first two weeks?

Is that failure point a shortage of resource, or a decision, standard, or judgment call that currently exists only in one person’s head?

If it’s the second kind, what would need to become explicit, a written standard, a decision rule, a documented method, before more resource would actually help rather than just multiply the confusion?

The specificity matters more than the answer. “We’d struggle” isn’t useful information. “The third property’s shot list would get built at midnight by someone guessing what I’d want” is.

The Answer Is Information, Not a Verdict

Running this diagnostic honestly doesn’t produce a pass or fail grade. It produces a map: which parts of the business would hold, and which one would give way first, and why. That’s worth knowing before the opportunity arrives, not while it’s already underway and there’s no room left to fix anything quietly.

The photography studio still said yes. It just said yes knowing precisely which three things needed to change before the first new property was shot, instead of finding out live, on the worst possible week to learn it.

Run the exercise on your own business before the next opportunity arrives: if demand doubled tomorrow, what would actually break first, and is that a shortage of resource or a decision nobody has made explicit yet? Reply and tell me what you found. The specific answer tends to be more useful than the general shape of the question.

At a dinner party, a founder describes her business in one breath: twelve staff, national clients, an office lease, seven figures a year. Said like that, it sounds unmistakably like a business, the kind you build once and then own, rather than the kind that quietly owns you.

Driving home, she runs a quieter tally. Every proposal over fifty thousand dollars waits for her sign-off. Every difficult client conversation gets escalated to her personally. Two of the people she hired specifically to take things off her plate still check in with her before finishing anything that matters. The revenue is real. The staff are real. Whether what she described over dinner is actually a business, in the sense that matters, is a separate question, and one she's never had reason to ask, because nothing about the word "business" forces the distinction.

One Word Covering Three Different Arrangements

"Business" is one word doing the work of at least three different arrangements, and most of the confusion founders feel about their own company starts right there.

The first is an income-producing activity. A person does skilled work and gets paid for it: a consultant sells sessions, a designer takes on briefs, a tradesperson takes on jobs. The revenue can be excellent. It sits mainly in the time, judgment, and presence of one individual, and if that person stops working, the income stops with them. That isn't a flaw waiting to be corrected. It's simply what the arrangement is.

The second is a founder-dependent business. There's a team now, maybe a brand, repeat customers, a system or two, staff to handle the phones and manage delivery. From the outside it looks like a real company, and in most legal and financial senses it is one. The trust, the hard calls, and the final word on quality still concentrate around one person, though. The business exists. Its center of gravity has never actually moved off the founder.

The third is a designed business. The founder can still matter enormously here. Their judgment, their standards, their reputation can remain part of what makes the offer work. The difference is that some of that value has turned into something the business itself carries: a method, a standard, a decision rule, an escalation path, a way information reaches the right person without anyone having to ask the founder to remember it.

Size doesn't sort these three. A four-person studio can be genuinely designed if it has a clear promise, a reliable way to deliver it, and a way of noticing when it's falling short. A four-hundred-person company can still be, underneath its org chart, one large founder-dependent business wearing a headcount as a disguise.

*The Designed Business* names these three conditions because founders rarely do, and the test that actually separates them has nothing to do with revenue, team size, or how the company sounds at a dinner party. It's blunter than that: can the value the customer is paying for be reproduced by the business, or only by the person?

A Catering Business at Three Different Points in Its Life

Consider a composite example. A private chef starts out cooking for a handful of families each week. She takes the enquiry, plans the menu, buys the produce, cooks the meal, and delivers it herself. Every dollar she earns is a direct trade for her own time and skill. This is an income-producing activity, and for years it's a good one. She works when she wants, charges what her reputation supports, and turns away anything that doesn't interest her. Nothing about that arrangement is broken. It simply is what it is.

Word of mouth eventually grows her client list past what one person can cook, so she hires two chefs and starts taking corporate events alongside private dinners. Five years later she has a small commercial kitchen, seven staff, and a booking calendar that runs months ahead. But every menu still gets her final tasting before it leaves the kitchen. Every event above a certain size, every client who's hosted something important before and knows exactly what they want, still asks for her by name and gets a call from her personally. Her staff are talented cooks. None of them has ever been told what she's actually checking for when she tastes a dish before it goes out, because that standard has only ever lived in her mouth and her memory. This is a founder-dependent business: real, valuable, staffed, and still entirely dependent on one person's palate and presence.

The shift into a designed business wouldn't show up as a bigger kitchen or another hire. It would show up the day she writes down, specifically, what she's actually tasting for: not "good food," but four or five concrete things a dish has to do before it's ready to serve, things a head chef could learn to check without her standing there. It would show up when a client asks for her personally and someone can explain, accurately, why that isn't necessary for this particular event, and mean it. Nothing about the food, the client list, or the revenue would need to change for that shift to happen. What changes is where the standard lives.

Why These Aren't Stages on a Ladder

It's tempting to treat those three as stages, each business climbing automatically from the first to the third as it grows. That isn't how it works, and assuming it is tends to send founders looking for the wrong fix.

An income-producing activity isn't an unfinished version of a designed business. A specialist who wants to keep working with a handful of clients, charge well, and stay personally close to the work has made a legitimate choice. It isn't half finished. The trouble starts when that same person wants an outcome the arrangement was never built to produce: a buyer, a team that runs without them, income that keeps arriving after they've stopped showing up. That mismatch, wanting a result the current design can't create, is the actual problem. The category itself never was.

A founder-dependent business carries a different risk. It's easy to mistake a team, a brand, and a system or two for proof the business has already crossed into the third category. Hiring people doesn't move a business between categories by itself. It just adds more people whose work still depends on checking with the same person before anything that matters gets decided. A company can accumulate staff for a decade and never once shift its center of gravity anywhere.

Which One Are You Actually Running?

A few honest questions, not for scoring yourself against some ideal, but for finding out which of the three sentences actually describes what's been built.

If you took a genuine month away, no calls, no messages, would the work keep arriving at roughly the same quality, or would it thin out the moment you weren't the one answering?

Can you name, specifically, what you personally check, decide, or approve that nobody else has ever been shown how to check, decide, or approve?

If someone offered to buy what you've built tomorrow, what would they actually be buying: your future working hours, or something that keeps producing value with you nowhere near it?

Before the Next Decision About the Business

Most founders don't make a considered choice about which of these three they're running. They inherit whichever one accumulated while they were busy serving the next client. That isn't a failure of ambition. It's just what happens when a business grows faster than anyone stops to examine it.

Naming the category honestly doesn't fix anything by itself. It changes what the next decision should actually address. A founder running an income-producing activity who wants something shaped by a future sale or a team-led growth model needs to build economics that don't require her name on every job. A founder running a founder-dependent business who wants to eventually step back needs to find out exactly what she's still personally carrying, and start moving pieces of it into the business, on purpose. Neither problem gets solved by working harder inside the arrangement already in place.

If this distinction landed, send it to a founder who's convinced they've built a business but privately isn't sure. It tends to be an easier conversation to have about someone else's company first.

At some point, most growing businesses reach for the same word: structure. The business needs to become "more professional, more structured, more like a proper business." In practice that usually means an org chart, a staff handbook, a project management tool, and a weekly reporting rhythm. All reasonable things to want.

Eighteen months later, the org chart exists. So does the handbook. Meetings happen on a schedule instead of whenever something breaks. And the business still runs exactly the way it always did: every important decision waits for the same person, every awkward client conversation gets escalated to the same desk, every new hire spends their first six months learning things nobody ever wrote down.

The paperwork changed. The business underneath it didn't.

This confusion is worth naming precisely because it looks like progress from almost every angle except the one that matters. Formality is not design. A business can accumulate structure, documents, dashboards, and layers of management, and still have no real answer to the questions that decide whether it can carry weight without buckling.

So what does "designed" actually mean, if it isn't size, headcount, or paperwork?

When Structure Isn't the Same as Design

A two-hundred-person logistics company can have an approvals process for almost everything and still be unable to say, in one sentence, which customer problem it exists to solve. Ask five people in five different departments and you'll get five different answers, all plausible, none quite matching. A three-person design studio can run with almost no formal process at all and still know exactly why clients choose it, what they're actually buying, and what happens if a job goes wrong.

Neither company's size tells you which one is better designed. Only the questions do.

This cuts the other way too. A business doesn't earn the label "designed" just by staying small and informal. A solo consultant who has never written anything down, and whose entire practice would stop the day she gets sick, isn't undesigned because she lacks a handbook. She's undesigned because nobody, including her, could say with confidence what happens to a client relationship if she's not the one holding it. Smallness protected her from finding that out. It didn't fix it.

Design and formality are simply different axes. A business can be informal and well designed, formal and badly designed, or any combination in between. Confusing the two leads founders to chase the wrong fix: adding structure to a business that actually needs clarity, or avoiding structure in a business that's confusing informality for freedom.

Five Questions Every Business Answers, One Way or Another

Underneath the paperwork, every business is making the same five kinds of decisions, whether or not anyone sat down to make them on purpose.

Which problem is the business taking responsibility for? What change does the customer actually walk away with, distinct from what gets delivered to them? Why should someone believe the promise before they've experienced it? How does the promised result actually get produced when the founder isn't the one producing it? And what does the business do differently after something goes wrong, beyond fixing that one instance?

Call these Problem, Value, Trust, System, and Learning. They aren't five separate departments or five items on a checklist. They're five questions a business cannot avoid answering, because a business that has no answer to "which problem" or "why believe us" still operates as though something had been decided. Someone said yes to the first customer who showed up. A senior person's judgment quietly became the whole trust model. A team learned to route anything unusual to whoever fixed the last one. Nobody wrote any of it down, and it became the answer anyway.

That's the real distinction underneath this whole framework: not whether a business has answers, but whether those answers were chosen or just accumulated. A chosen answer can be examined, defended, and changed on purpose. An accumulated one usually can't be explained at all, only pointed to, the way you'd point at a load-bearing wall nobody remembers building.

There's a sharper test worth applying here, and it's the one I'd actually use to check whether something counts as designed rather than merely decided in someone's head. Could a second person, someone other than the founder, state the answer back accurately, without checking first? If the answer to "what problem do we solve" or "why should someone trust us" only exists reliably in one person's head, it isn't a design yet. It's a habit with that person's name on it. The moment it survives being said by someone else, in roughly the same way, it has become something the business actually owns.

A Bookkeeping Practice and a Marketing Agency

A composite comparison makes this concrete. Picture a three-person bookkeeping practice serving trades businesses: electricians, plumbers, small building contractors. The founder can state, without hesitating, what her clients are actually buying: not "bookkeeping," but the ability to make pricing and hiring decisions without guessing whether the business can afford them. Every client gets the same monthly reporting format, built around three numbers that answer that specific question. When a client's numbers look wrong, there's a standing rule about who flags it and how fast. Nothing about the practice is elaborate. All of it is legible. Either of the two staff members could explain the promise to a prospective client and land on nearly the same words the founder would use.

Now picture a sixty-person digital marketing agency down the street. It has a proper org chart, a account-management handbook, a shared drive full of case study templates, and a weekly leadership meeting with a fixed agenda. Ask three different account managers what the agency actually promises a new client, and you'll get three different answers: "results," "a strategic partner," "more leads." None of them wrong exactly, none of them the same thing. When a campaign underperforms, the response depends on which account manager picked up the account and which senior strategist they happen to be friendly with. The agency has far more structure than the bookkeeping practice. It has considerably less design.

Neither business is a cautionary tale about ambition or a fable about staying small. The comparison exists to isolate one variable: legibility of the five answers, independent of headcount, revenue, or how many binders sit on a shelf.

What Deliberate Design Actually Looks Like

None of this requires a founder to slow down, overthink every decision, or bury a young business under process before it's earned the right to have any. Early businesses need speed, closeness to customers, and a tolerance for improvising. The point isn't to eliminate accident. It's to notice when an accidental answer has quietly hardened into the permanent one, and to make it deliberate before growth puts real weight on it.

In practice, deliberate design tends to look small and unglamorous. It's a founder who can state the problem, the promise, and the trust basis in the same words twice in a row, a week apart. It's a team that has actually been told, not just assumed to know, which decisions they're allowed to make without asking. It's a business that changes something structural after a mistake, not only apologizes and moves on. None of that requires size, funding, or a management consultant. It requires the founder to have actually decided, out loud, in a form someone else could repeat.

Five Sentences Worth Trying to Write

A short exercise makes the gap visible. Try writing one plain sentence for each of the five, no qualifiers, no hedging:

The problem we take responsibility for is __________.
The change a customer walks away with is __________, not the thing we hand them.
Someone should believe our promise before trying us because __________.
When I'm not the one delivering, the result still happens because __________.
The last time something went wrong, what we changed afterward was __________.

Some of these will come quickly. One or two probably won't. The sentence that's hardest to finish, or that only makes sense with several extra clauses attached, is usually pointing at the part of the business still running on memory and improvisation rather than design. That's not a failure. It's information about where the next real work is.

Before the Next Handbook

None of this is an argument against structure. Org charts, handbooks, and reporting rhythms can genuinely help a business that already knows its own answers communicate them consistently. The mistake is expecting the paperwork to generate the answers it was only ever meant to record.

Before the next hire, the next handbook, or the next round of "getting more organized," it's worth writing the five sentences honestly and seeing which one gives you trouble. That sentence, more than the org chart, is the real state of the business.


Try writing the five sentences above about your own business, and reply and tell me which one was hardest to finish. That answer is usually more revealing than anything an org chart shows.

Every business has already made a set of foundational choices, whether anyone sat down and made them deliberately or not. Some businesses arrive at those choices on purpose. Someone decided which problem the business would take responsibility for, what change customers should expect, why trust should extend beyond one person’s reputation, how the work actually gets delivered, and how the business notices when something has gone wrong. Other businesses accumulate their design by accident, one improvised answer at a time, until the whole pattern is just however things have always been handled.

The chapters ahead in this series work through five areas where those foundational choices get made: the problem a business takes responsibility for, the change it promises to create, the trust it earns before and after the sale, the systems that deliver on the promise without heroics, and the way the business learns when reality disagrees with the plan. This week stays above all five, because before examining any one of them, it helps to see why growth makes ignoring them so much more expensive than it used to be.

Both kinds of business can produce real revenue. Under normal conditions, they can look nearly identical from the outside. The difference only becomes visible under load, and growth is one of the fastest ways to put a business under load.

Here’s the distinction worth sitting with: growth proves that something is wanted. It does not prove that the business can carry more of it. Those are two separate questions, and most founders spend years answering only the first one.

Two Clinics, One Moment of Opportunity

Consider two physiotherapy clinics, both in the same fast-growing suburb, both featured in the same short segment on a local news program about treating recreational running injuries. Within a week, both practices had a full inbox of new inquiries.

At the first clinic, growth changed very little about how the place actually ran. New clients filled out an intake form built years earlier, designed to capture exactly the details a therapist would need before the first session. Every therapist worked from the same assessment framework, so a runner with a sore knee received a consistent standard of care regardless of who was rostered on that day. The clinic had already decided which conditions it treated well and which it referred elsewhere, so it didn’t try to be everything to every caller. The owner spent the surge fielding a handful of unusual cases and adjusting the roster. Everyone else simply did more of what they already knew how to do.

At the second clinic, the same surge arrived differently. The practice had built its reputation almost entirely around its founding therapist, a genuinely skilled clinician whose hands-on technique patients specifically requested by name. The other therapists on staff were competent, but standards had never been written down. Which cases were routine and which needed the senior therapist’s judgment had always lived in her head, not in any shared method. Within two weeks her calendar was booked out a month in advance, the newer therapists were quietly declining anything complicated out of caution, and the front desk was fielding complaints from patients who couldn’t get the appointment they’d been promised.

Both clinics had a good week of publicity. One turned it into a stronger business. The other turned it into a longer waitlist and a more exhausted founder.

Both clinics worked hard through the surge, so effort wasn’t the difference. The second clinic’s founding therapist was also, by any reasonable measure, excellent at her job, so skill wasn’t the difference either. What separated the two practices had been decided long before the news segment aired: what a good session looks like, who is allowed to make which call, when a case needs escalation, and what the practice will and won’t take on. The first clinic had already answered those questions. The second clinic never had to, because its founder had always been available to answer them personally, one case at a time. Growth removed the option of answering them personally for every case at once.

What Growth Actually Tests

This is the pattern worth checking for in your own business, whatever it sells. Growth does not ask a business to work harder. It asks whether the decisions that used to happen inside one person’s head can now happen without that person in the room.

Questions Worth Sitting With

A few questions are worth sitting with honestly, before the next campaign, the next hire, or the next big client:

If your next ten customers arrived this week, what would break first: your calendar, your standards, your cash flow, or your ability to turn away the wrong kind of client?

Which parts of your recent growth made the business more capable, and which parts simply made it busier?

If you disappeared for a month, what would the business still be able to do without you, and what would quietly stop?

None of these questions are about blame. Every business starts with a founder holding more than the business can yet hold on its own. The real question is whether that’s still true after years of apparent success.

Before You Grow Faster

Growth is usually treated as a reward for good work, a signal that the hardest part is finally over. It behaves more like a stress test. It applies pressure to whatever already exists, and it doesn’t much care whether that thing was designed on purpose or assembled under pressure over several years.

Before asking how to grow faster, it’s worth asking a quieter question first: what exactly is about to be amplified? A business that already knows the answer can grow with some real confidence. A business that doesn’t is about to find out the hard way, at exactly the moment it can least afford to.

This article opens a year-long series working through what it actually means to design a business deliberately, one idea a week. If the tension in this piece feels familiar, join The Designed Business newsletter to get each week’s diagnosis as it’s published.

Better data can expose better options, but if the customer still cannot decide, the business has not solved the real problem.

Better Data is one of the easiest ideas to believe in when you come from a technology, analytics or product background.

It feels logical. If people have better information, they should make better decisions. If the market is confusing, show them more signals. If the options are hard to compare, build a better dashboard. If the customer is uncertain, give them more analysis.

For a long time, I believed some version of this.

That belief was not completely wrong. Data can reduce confusion. It can reveal patterns that are otherwise hidden. It can challenge assumptions. It can make a market, a process or a decision more visible. In many industries, the absence of good data is a real problem.

But building AbodeFinder taught me that data alone rarely completes the customer’s journey.

The Assumption Behind Better Data

AbodeFinder started inside Intellicy. It was not originally a standalone property advisory business.

At the time, I was thinking about a broader problem inside consulting. Consulting creates value, but it also has a structural limitation: much of the value is tied to expert time. More clients usually mean more hours, more delivery pressure and more dependence on the judgement of specific people.

That led me to explore how parts of our expertise could become more repeatable through software, data and AI-enabled services. This was before ChatGPT became the public symbol of AI. We were not trying to follow a trend. We were trying to answer a business-model question: how can knowledge, judgement and analysis become more scalable without losing their usefulness?

One of the products that came out of that thinking eventually became AbodeFinder.

The original idea behind AbodeFinder was simple. Property buyers face an overwhelming amount of information. They need to compare suburbs, understand market signals, look at affordability, assess opportunity and avoid emotional or poorly informed decisions. A better product could organise that information and help buyers see the market more clearly.

So we built in that direction.

When Useful Is Not Enough

The application was designed to make property analysis more accessible. It could bring together information, compare locations and help buyers think about opportunities with more structure.

From a product perspective, this made sense.

From a data perspective, it made sense.

From a founder’s perspective, it felt like a useful answer to a real problem.

But usefulness is not the same as completion.

A customer could look at better suburb data and still feel uncertain. They could understand a market more clearly and still not know whether the decision made sense for their personal situation. They could compare locations and still feel exposed.

That was the uncomfortable lesson.

The customer was not only asking, “Where is the opportunity?”

They were also asking, “Is this the right decision for me?”

Those are different questions.

The Difference Between Information and Confidence

The first question can often be supported by data. The second question requires a broader decision journey.

It involves borrowing capacity, financial position, risk tolerance, lifestyle, timing, confidence, trade-offs and sometimes emotional pressure. A dashboard can support that decision, but it does not automatically carry the customer across it.

This is where many product-led and technology-led businesses make a quiet mistake. They assume that if the information is useful, the value has been delivered.

But customers do not usually buy information for its own sake.

They buy progress.

They buy a reduction in uncertainty.

They buy the ability to act with more confidence.

That distinction changed how I thought about AbodeFinder.

Why AbodeFinder Had to Evolve

We had to move beyond the idea that the product was only an information tool.

The real customer journey was bigger than the original product boundary. People did not simply need more property data. They needed to understand what that data meant in relation to their budget, borrowing capacity, goals and risk. They needed a path from analysis to action.

That is why financial services and advisory support became part of the model.

Not because the original product was useless, but because the original product was incomplete. The data was part of the value, but it was not the whole value.

This changed how I think about business design more broadly.

A business can be technically correct and still fail to solve the full customer problem. A product can work and still leave the customer stuck. A report can be accurate and still not change the decision. An AI recommendation can be impressive and still not create trust.

The Better Question to Ask

The question is not only:

“What can we show the customer?”

The better question is:

“What can the customer now decide, avoid or achieve because this exists?”

That question forces the business to become more honest about value.

If the customer still cannot decide, the business may not have designed the value clearly enough. If the customer still feels exposed, the business may not have designed trust deeply enough. If the customer needs a human to explain every important step, the business may not have designed the system properly. If the product keeps producing information but the customer journey does not improve, the business may be measuring output instead of progress.

AI Makes This Problem Bigger

This is especially important now because AI makes it easier than ever to produce more.

More reports. More summaries. More recommendations. More dashboards. More content. More analysis. More personalised outputs.

But more output does not necessarily mean more value.

AI can accelerate the creation of information, but it does not automatically understand the customer’s decision context. It can make a product feel smarter, but that does not mean the customer feels more confident. It can produce a recommendation, but it cannot replace the need to design the path that makes that recommendation useful, trusted and actionable.

This is why I am cautious when companies begin with the question, “Where can we use AI?”

It is not a bad question, but it is often asked too early.

A better starting point is:

“Where is the customer currently stuck, and what kind of progress are we responsible for helping them make?”

Only after that question is clear does AI become a useful design choice.

Data Needs to Sit Inside Value Design

In the case of AbodeFinder, the lesson was not that data was unimportant. The lesson was that data needed to sit inside a more complete value design.

The product had to support a decision, not simply display information. The customer needed clarity, but also confidence. They needed insight, but also a way to act on it.

That lesson is not limited to property.

It applies to consulting, where clients often receive detailed recommendations but still struggle to make decisions internally. It applies to enterprise transformation, where dashboards can show performance without changing accountability. It applies to AI adoption, where organisations produce more automated output without redesigning the process around it. It applies to media and content, where publishing more information does not automatically build trust.

In each case, the same pattern appears.

The business believes it has delivered value because it has delivered information, analysis or output. But the customer is still carrying the harder part of the journey alone.

What This Taught Me About The Designed Business

This is one of the reasons I am writing The Designed Business.

The central idea of the book is that growth does not fix the business. It reveals what has already been built. If a business has not clearly designed the problem it solves, the value it creates, the trust it requires, the system that delivers it and the learning loop that improves it, growth will not quietly repair those gaps. It will expose them.

AbodeFinder exposed one of those gaps for me.

It showed me that the value of a business is not always where the founder first thinks it is. I thought the product was mainly about better property data. The customer showed me that the deeper value was confidence in a decision.

That shift matters.

When a business understands that shift, it designs differently. It sells differently. It uses technology differently. It decides what should be automated and what should remain human. It measures success differently. It stops asking only whether the product works and starts asking whether the customer has moved.

That is a much harder standard.

But it is also a more useful one.

The Real Destination Is Not the Dashboard

Better Data can make the world more visible. It can show patterns, risks and possibilities. It can help customers think more clearly than they could before.

But visibility is not the same as progress.

A customer can see more and still hesitate. They can understand more and still feel uncertain. They can receive better analysis and still not know what to do next.

That is the point where the real business design begins.

Not at the dashboard.

Not at the report.

Not at the AI output.

At the moment where the customer asks:

“So what should I do now?”

The businesses that answer that question well are not just providing information. They are designing confidence.

Software engineering was built for a deterministic world.

Same input. Same logic. Same output.

That assumption shaped the way we designed systems, tested systems, deployed systems, and governed change. The traditional Software Development Lifecycle, or SDLC, was built around one central question:

Did we build the software correctly?

If the code was clean, the tests passed, the security controls were in place, and the deployment pipeline worked, we could reasonably assume the system would behave as designed.

That assumption worked when software followed explicit paths written by developers.

It starts to break when the software itself begins to participate in decisions.

AI agents do not behave like normal application features. They interpret context. They make bounded decisions under uncertainty. They use tools. They call APIs. They coordinate actions. They may trigger workflows across systems that sit outside the original application boundary.

That changes the architectural problem.

The question is no longer only:

Did we build the software correctly?

The new question is:

Did we design, constrain, verify, and operate the agent safely and effectively?

That is a very different discipline.

The Old SDLC Was Designed for Predictable Behaviour

Traditional software architecture assumes that system behaviour comes from code and configuration.

A developer writes the logic.
An architect defines the integration pattern.
A tester checks the expected outcomes.
A release pipeline moves the change into production.

This model works because the system is deterministic enough to be tested against known scenarios.

Of course, production systems still fail. APIs break. Databases slow down. Infrastructure goes down. Users do unexpected things. But the behaviour of the software is still mostly traceable to something we designed, coded, configured, or deployed.

AI agents introduce a different type of uncertainty.

An agent may receive a new context, interpret that context differently, select a tool, call an external service, and generate a real operational effect.

The code may be correct.

The infrastructure may be available.

The integration may be working.

And the system may still do the wrong thing.

That is the uncomfortable part.

Correct code does not automatically mean controlled behaviour when the software is capable of interpreting, deciding, and acting.

AI Agents Are Not Just Features

One of the biggest mistakes organisations make is treating AI as a feature to be inserted into an existing delivery model.

A chatbot here.
An automation layer there.
A workflow assistant inside an existing platform.
A model connected to a few internal tools.

At small scale, this feels manageable. The agent is seen as a productivity enhancement, not a change to the architecture of control.

But an AI agent is not just another module.

Once an agent can use tools, access data, make decisions, or trigger actions, it becomes part of the operational fabric of the organisation. It is no longer only producing text. It is participating in business execution.

That means the architecture must change.

The model is only one component. Around it, the organisation needs policies, boundaries, telemetry, approval flows, exception handling, audit trails, and human escalation paths.

Without those controls, the organisation is not deploying intelligence.

It is deploying uncertainty.

The New Failure Modes Are Behavioural

Traditional engineering teams are trained to look for familiar failures.

Does the code compile?
Do the tests pass?
Is the API available?
Is the database healthy?
Is the deployment secure?
Is the service observable?

All of this still matters.

But agentic systems introduce failure modes that standard CI/CD pipelines were not designed to catch.

An agent may take an action it was not authorised to take.

It may misunderstand the meaning of a business instruction.

It may use the right tool for the wrong purpose.

It may act on incomplete evidence.

It may produce a decision that cannot be explained later.

It may complete a workflow successfully from a technical point of view, while still violating business policy, compliance requirements, or customer expectations.

These are not simple software bugs.

They are failures of control.

This is why testing an agent cannot stop at functional correctness. We also need to test intent, context, authority, evidence, and escalation.

The real question becomes:

Can we prove the agent remained inside its authorised operating boundary?

Agentic Architecture Requires Runtime Control

Traditional architecture relies heavily on design-time structure.

We define the components.
We define the interfaces.
We define the data flows.
We define the security controls.
We define the deployment model.

Agentic architecture needs all of that, but it also needs active runtime discipline.

The reason is simple: agentic behaviour emerges at runtime.

It emerges from model outputs, live context, policy data, tool responses, user instructions, environmental signals, and previous state.

That means control cannot live only in a design document.

It must be enforced while the agent is operating.

Policies need to be machine-readable.
Boundaries need to be executable.
Approvals need to be built into the workflow.
Telemetry needs to capture not only what happened, but why the agent acted.
Escalation needs to be part of the operating model, not an afterthought.

This is where many AI initiatives fail.

They focus on model capability before they design operational control.

They ask, “What can the agent do?”

Architects need to ask a more important question:

What is the agent allowed to do, under what conditions, with what evidence, and with what human oversight?

The Six Design Pillars of a Governable Agent

Before building an agentic system, architecture needs to define the control model.

I would frame this around six design pillars.

1. Intent Design

Intent design defines the purpose of the agent.

Not in vague terms like “improve productivity” or “automate support”.

It must define the agent’s specific goal, the business outcome it supports, and the negative space around that goal.

Negative space matters because it clarifies what the agent must not do.

A well-designed agent needs a narrow and explicit purpose. The broader the intent, the harder the system is to govern.

2. Boundary Design

Boundary design defines the agent’s authority.

What data can it access?
What tools can it use?
What systems can it touch?
What actions can it trigger?
What value threshold requires approval?
What risk level requires escalation?

This is where architecture becomes practical.

An agent that can read information is very different from an agent that can update records, send messages, move money, approve claims, change configurations, or communicate with customers.

Autonomy must be proportional to risk.

3. Semantic Design

Semantic design defines shared meaning.

This is often ignored, but it is critical.

AI agents operate through language, context, and interpretation. If business terms are ambiguous, the agent may make technically valid but operationally wrong decisions.

What does “approved” mean?
What does “urgent” mean?
What does “high risk” mean?
What does “customer consent” mean?
What does “complete evidence” mean?

In traditional systems, ambiguity often hides inside human process.

In agentic systems, ambiguity becomes executable risk.

4. Policy Design

Policy design converts governance into machine-readable constraints.

This is where organisations need to move beyond PDF policies and static documents.

The agent needs runtime constraints it can follow and the platform can enforce.

A policy should define what is allowed, what is blocked, what requires approval, what must be logged, and what must be escalated.

In an agentic world, policy becomes part of the system architecture.

It should be versioned, tested, monitored, and reviewed with the same seriousness as code.

5. Protocol Design

Protocol design defines how the agent coordinates with systems, people, and other agents.

This includes approval flows, handoffs, retries, exception routing, timeout behaviour, and fallback paths.

Agents should not improvise critical coordination patterns.

If a decision requires human approval, the approval protocol must be explicit.

If an external system fails, the recovery protocol must be explicit.

If confidence is low, the escalation protocol must be explicit.

The agent should not be trusted to invent the operating model at runtime.

6. Assurance Design

Assurance design defines how we prove the system behaved correctly.

This includes telemetry, audit trails, evidence capture, decision provenance, simulation results, test outcomes, and post-incident review.

For normal software, observability often focuses on performance and availability.

For agentic systems, observability must also capture intent, context, decision path, policy evaluation, and tool usage.

Operators need to know more than whether the system was up.

They need to know whether the agent was under control.

The SDLC Must Expand

The traditional SDLC is not dead.

We still need requirements, design, build, test, deploy, and operate.

But for AI agents, those steps are no longer enough.

An Agentic SDLC needs additional stages.

It needs intent definition before solution design.
It needs boundary modelling before tool access.
It needs semantic validation before workflow automation.
It needs policy design before deployment.
It needs simulation before production release.
It needs runtime monitoring after go-live.
It needs exception handling as part of the core architecture.
It needs feedback loops that refine the agent’s operating boundaries over time.

This is the shift.

We are not only building applications anymore.

We are building governable systems of action.

That requires a different mindset from both engineering and architecture teams.

The Model Is Not the Architecture

A common mistake in AI discussions is to overfocus on the model.

Which model should we use?
Which vendor is better?
Which benchmark looks stronger?
Which tool has the best demo?

These questions matter, but they are not the architecture.

In production, the model is only the engine.

The real architecture is the system around the model.

The policies.
The data boundaries.
The orchestration layer.
The APIs.
The approval flows.
The monitoring.
The audit trail.
The incident process.
The human escalation path.

A powerful model inside a weak control environment is not an enterprise capability.

It is a risk multiplier.

The organisations that succeed with AI agents will not be the ones that simply adopt the most advanced models.

They will be the ones that design the most governable operating systems around those models.

Change Management Must Also Change

In traditional software delivery, change management focuses on code, infrastructure, configuration, and release artefacts.

In agentic systems, change management needs to expand.

We must version policies.
We must version prompts.
We must version semantic definitions.
We must version tool permissions.
We must version escalation rules.
We must version operating boundaries.

A small change to a policy can change what an agent is allowed to do.

A small change to a prompt can change how it interprets a situation.

A small change to tool access can change the operational risk profile of the entire system.

This is why AI governance cannot sit outside delivery.

It must be embedded into the engineering lifecycle.

The Real Architecture Question

The future of software delivery is not just about faster coding.

That is the shallow conversation.

The deeper conversation is about controlled autonomy.

How do we design systems that can reason, act, and adapt without losing organisational control?

How do we allow agents to create value without allowing them to create unmanaged risk?

How do we move from experimentation to production without pretending that AI agents behave like normal software?

This is where architecture becomes essential.

Not as a documentation function.

Not as a governance bottleneck.

But as the discipline that creates clarity between business ambition, engineering capability, operational risk, and long-term control.

AI agents will force organisations to rediscover the real purpose of architecture.

Architecture is not about drawing diagrams.

Architecture is about designing the conditions under which change can happen safely.

Final Thought

Correct code is no longer enough.

A system can pass every traditional test and still behave in ways the organisation cannot explain, control, or defend.

That is the challenge of agentic software.

The next generation of SDLC must be built around governability.

Not just delivery.

Not just automation.

Not just intelligence.

Governability.

Because when software starts making decisions and taking action, the real measure of success is not whether the system works.

It is whether the system remains under control.

Thinking about introducing AI agents into your business? Don’t start with the model. Start with the control architecture.

I help technology leaders, founders, and executive teams design AI-enabled systems that are safe, governable, and ready for real business operations.

Before you connect an agent to your data, workflows, or customer-facing systems, you need clear answers to four questions:

What is the agent allowed to decide?
What actions can it take?
When must it stop and escalate to a human?
How will you prove later that it acted within policy?

If your organisation is exploring AI agents, automation, or AI-enabled operating models, I can help you assess the architecture, risks, governance model, and delivery approach before the system becomes expensive to fix.

Book a consultation to design your AI agent architecture before you deploy autonomy into the business.

For the last few years, much of the conversation about AI in software development has focused on one promise: developers will write code faster.

The assumption is simple. Give engineers better coding assistants, reduce time spent on boilerplate, automate testing and documentation, and delivery velocity will improve.

But software delivery has never been limited by how quickly a developer can type code.

The real constraints usually sit elsewhere: unclear requirements, delayed decisions, fragmented ownership, missing context, late security reviews, inconsistent architecture, slow environments, weak governance and teams working from different versions of the same problem.

AI can generate code quickly. It cannot, by itself, repair a delivery system built on ambiguity.

That is why the conversation needs to move beyond AI-assisted coding and towards something more fundamental: an AI-native development lifecycle.

The productivity paradox should make leaders uncomfortable

A 2025 randomised controlled trial by METR studied experienced open-source developers working on mature repositories they already understood well. The developers expected AI tools to make them 24% faster. Even after completing the work, they believed AI had made them around 20% faster.

The measured result was the opposite. With AI tools available, they took 19% longer to complete the tasks.

This does not prove that AI is ineffective in software engineering. It does prove that perceived velocity and actual delivery performance are not the same thing.

That distinction matters.

AI-generated output creates a strong feeling of progress. Code appears quickly. Documentation can be drafted in seconds. Test cases can be suggested. Sequence diagrams can be generated. The blank page disappears.

But in a complex enterprise environment, output is not the same as value.

Every generated artefact must still be understood, validated, integrated, secured, tested, operated and governed. When the AI lacks the right business, architecture or operational context, teams may move faster in producing material while spending more time reviewing, correcting and aligning it later.

That is not transformation. It is faster production of uncertainty.

The two ways organisations get AI wrong

Most teams currently approach AI in one of two ways.

The first is to treat AI as an autonomous delivery engine: provide a prompt, expect a working solution and assume the team can review the output later. This may produce an impressive prototype. It becomes dangerous when applied to complex products, regulated environments, shared platforms or systems with important non-functional requirements.

AI does not naturally understand the full consequence of a design decision. It does not know which shortcut creates a future support burden, which integration assumption breaks a control boundary, or which apparently simple implementation introduces compliance or operational risk.

The second approach is safer, but often underwhelming. Teams use AI as a personal assistant for isolated tasks: complete this method, generate this unit test, explain this error, tidy this document.

That may save individual effort. It rarely changes the delivery outcome because the organisation is still operating through the same slow lifecycle: the same handovers, the same decision delays, the same scattered knowledge and the same governance checkpoints arriving too late.

One approach over-trusts AI. The other underuses it.

Neither changes the system of delivery.

AI-DLC is not a new coding technique

AWS introduced the concept of the AI-Driven Development Life Cycle, or AI-DLC, as an AI-centric approach in which AI creates plans, asks for clarification and implements work only after human validation. The second part of the model is equally important: cross-functional teams collaborate dynamically around decisions rather than operating through long, sequential handovers.

This is the important shift.

AI-DLC is not simply adding AI tools into an existing agile process. It is a challenge to the structure of that process.

Traditional delivery models often assume that work should move through stages: discovery, requirements, design, development, testing, security, deployment and operations. Each stage creates artefacts for the next group. Questions move backwards. Decisions wait for meetings. Important assumptions are discovered after implementation has already started.

AI changes the cost of producing options, documenting decisions, creating models, analysing code and testing assumptions. But those benefits only become meaningful when the people who need to make decisions are brought together around the same context.

This is why the concept of collaborative, AI-supported working sessions matters more than the coding assistant itself.

Bring product, architecture, engineering, quality, security and operations into the same problem space. Give the AI the right context. Ask it to produce options, surface gaps, create the initial artefacts and challenge assumptions. Then let the humans make the decisions that require accountability and judgement.

The value is not that AI replaces the team.

The value is that the team spends less time waiting for alignment and more time making informed decisions together.

Discovery changes first

The greatest opportunity for AI-native delivery may not be in development. It may be in discovery.

Many delivery failures start long before any code is written. The opportunity was poorly framed. The business outcome was vague. System impacts were incomplete. Dependencies were missed. Non-functional requirements appeared late. Delivery teams were asked to estimate a solution before the actual problem was understood.

Used properly, AI can help teams interrogate an opportunity earlier.

It can turn an initial business idea into structured questions. It can identify missing stakeholder decisions. It can map likely impacted systems. It can draft journeys, use cases, risks, assumptions, architectural options and test scenarios for the team to validate.

But the discipline matters: AI should not invent certainty. It should accelerate the identification of uncertainty.

A stronger discovery outcome is not a longer document generated faster. It is a team that can say, earlier and with greater confidence:

• This is the business outcome we are solving for.

• These are the systems and controls affected.

• These are the decisions that must be made.

• These are the risks we will accept, mitigate or avoid.

• This is the smallest useful slice we can safely deliver.

That is architecture creating decision clarity, with AI improving the speed at which the clarity can be reached.

Design becomes a conversation, not a handover

In many organisations, solution design is still treated as something an architect prepares and then presents to delivery teams for review.

That model becomes less useful in an AI-native environment.

AI can quickly generate multiple design options, sequence diagrams, integration patterns, data flows, failure scenarios and initial threat considerations. The architect’s role is not reduced by this capability. It becomes more important.

Someone must decide whether the options are sensible in the real organisational context.

Someone must understand the existing platform constraints, the regulatory boundary, the long-term operating model, the technical debt already present and the trade-offs the organisation is genuinely willing to carry.

The architect is no longer spending most of the time creating the first draft of every diagram. The architect is shaping context, challenging generated options, guiding decisions and ensuring the design remains coherent beyond the immediate feature.

This is not architecture being automated away.

It is architecture moving closer to where its real value has always been: judgement.

Delivery becomes faster only when context is controlled

One of the most important principles in AI-driven delivery is that context matters more than prompting cleverness.

A developer asking AI to work across a large codebase without explaining system boundaries, integration contracts, architectural standards, security expectations or acceptance criteria is not accelerating delivery. They are asking the tool to make guesses faster.

In an AI-native delivery model, context must become an engineered asset.

That includes approved architecture principles, system boundaries, API specifications, coding standards, non-functional requirements, security patterns, deployment expectations, test strategies, previous decisions and known constraints.

Teams that curate this context will get better results from AI. Teams that leave their knowledge scattered across outdated documents, chat messages, individual memories and disconnected tickets will struggle.

This is a major organisational point.

AI adoption is not only a tooling decision. It is a knowledge architecture decision.

Before leaders ask how many developers have access to AI tools, they should ask whether the organisation has made its delivery context usable by those tools.

Governance cannot remain at the end

There is an obvious risk in AI-enabled delivery: teams can generate more code, more options and more artefacts than governance functions can reasonably review through traditional processes.

The answer is not to remove governance. It is to make governance continuous and closer to the work.

Security requirements, architecture principles, compliance controls, operational expectations and evidence needs should be part of the context given to AI from the beginning. The tool can help teams assess proposed changes against those expectations throughout discovery, design and development.

Human accountability remains essential. AI can identify a possible control gap. It cannot accept the risk on behalf of the organisation. AI can draft evidence. It cannot be accountable for whether that evidence is accurate and sufficient. AI can recommend an architecture option. It cannot carry the operational consequences if that option fails in production.

In regulated or high-trust environments, this distinction is critical.

AI should help governance become earlier, more consistent and more evidence-driven. It should never be used as an excuse to weaken ownership.

Accountability does not disappear when the code is generated

The most dangerous sentence in AI-enabled software delivery is: “The AI wrote it.”

That sentence has no value when a customer is affected, a vulnerability is discovered, a payment fails, data is exposed or a regulator asks how a control was implemented.

The organisation still owns the outcome.

The engineer approving generated code must understand what it does. The architect approving the solution must understand its trade-offs. The product owner accepting the feature must understand what problem has been solved. The security and compliance functions must understand whether required controls are present and effective.

AI can participate in the delivery lifecycle. It cannot become the accountable party.

That is why AI-native delivery is not a permission to reduce engineering discipline. It requires more disciplined context, clearer decision rights and stronger evidence of why a solution is safe to release.

The real leadership question

The wrong question for technology leaders is: Are our developers using AI?

That question measures adoption of tools, not improvement in delivery.

The better questions are:

Are we using AI to improve discovery before we generate code?

Are product, architecture, engineering, security, quality and operations making decisions together, or are we simply pushing AI-generated outputs through the same slow handovers?

Have we curated the context AI needs to produce solutions aligned with our architecture and controls?

Can we demonstrate that AI-supported delivery is improving cycle time, quality, risk management and business outcomes, rather than simply increasing the volume of generated artefacts?

And most importantly: who remains accountable when AI-generated work reaches production?

AI will become part of how modern software is designed and delivered. That direction is no longer difficult to see.

But organisations will not become AI-native simply by giving developers new tools.

They will become AI-native when they redesign how problems are understood, how decisions are made, how context is managed, how solutions are governed and how accountability is maintained.

Because the future of software delivery is not about generating code faster.

It is about creating clarity faster and turning that clarity into safe, valuable delivery.

Is your organisation using AI tools or redesigning delivery for an AI-native future?

AI adoption is no longer just an engineering productivity discussion. It is becoming an architecture, governance and operating model question.

I work with technology leaders to turn complex delivery challenges into clear architecture decisions, practical operating models and scalable technology strategies.

If your organisation is exploring AI-enabled delivery, platform transformation or architecture governance, let’s connect.

The biggest risk with AI in delivery is not that engineers will write code faster.

The bigger risk is that organisations will change how work gets done without changing how decisions are governed.

That is where many AI programmes will quietly fail.

A team adopts AI for requirements analysis. Another team uses it for code generation. Product managers use it to summarise discovery notes. Architects use it to draft diagrams. Testers use it to create test cases. Delivery leads use it to summarise risks and progress.

On the surface, everything looks faster.

But under the surface, something more important has changed.

The organisation has introduced a new layer into its delivery lifecycle. AI is now influencing discovery, design, implementation, testing, documentation and governance. It is shaping decisions, producing artefacts, interpreting requirements and sometimes nudging teams towards options they do not fully understand.

If the operating model does not change with it, speed can become a risk multiplier.

That is why I think the next serious conversation is not only about AI tools.

It is about AI-DLC.

AI-DLC means embedding AI into the full delivery lifecycle in a controlled, traceable and human-owned way. Not as a side tool. Not as a chatbot sitting next to the team. Not as an experiment hidden inside individual workflows.

As part of the delivery system itself.

AI-DLC is not SDLC with a chatbot

Most organisations will start with the easy version.

They will give teams access to AI tools and measure whether work feels faster. Code completion improves. Documents are drafted more quickly. Meeting notes are summarised. Test cases appear earlier. Architects can produce first-draft diagrams in minutes rather than days.

That is useful.

But it is not an operating model.

AI-DLC is not simply the software delivery lifecycle with AI sprinkled across it. It is a different way of thinking about how decisions, evidence, controls and delivery artefacts move through the organisation.

A traditional delivery lifecycle often assumes humans create artefacts, humans interpret them, humans review them, and humans carry context from one stage to another.

AI changes that.

It can generate artefacts. It can interpret artefacts. It can connect artefacts. It can challenge gaps. It can detect inconsistencies. It can also hallucinate, over-simplify, miss context, expose sensitive information, or create outputs that sound correct but are not fit for the organisation.

That is the trade-off.

AI can reduce effort, but it can also create a new form of architecture debt if the organisation does not control how it is used.

The answer is not to slow everything down.

The answer is to make the lifecycle clearer.

Discovery: stop losing architecture in workshop noise

Discovery is where many delivery problems begin.

Not because teams do not care. They usually do. The problem is that discovery creates a lot of fragmented information: workshop notes, Slack messages, Jira tickets, customer pain points, process maps, Figma screens, vendor documents, assumptions, risks, constraints and half-formed options.

A good architect can bring structure to that noise.

AI can help.

In AI-DLC, discovery should become less dependent on memory and more dependent on structured evidence. AI can read discovery material and help identify the business problem, impacted capabilities, current-state constraints, upstream and downstream dependencies, open assumptions, likely non-functional requirements and decision points.

That does not mean AI decides the architecture.

It means AI helps the team see the discovery landscape earlier.

The practical value is simple: fewer hidden assumptions.

In many programmes, the expensive problems are not the ones teams knew about early. They are the assumptions nobody wrote down. The dependency that was “obvious”. The data boundary nobody challenged. The support model that was assumed to exist. The vendor limitation discovered after the design had already been shaped.

AI can help surface those signals earlier if it is given the right material and the right guardrails.

This connects to a point I have written about before in Where Business Analysis Ends and Solution Architecture Begins. Business analysis helps clarify the need. Solution architecture has to test whether that need can survive the real system constraints.

AI-DLC should make that handover stronger, not blur it further.

The discovery question should not be:

Can AI summarise the workshop?

The better question is:

Can AI help us identify the decisions, risks and assumptions that must be owned before we move into design?

That is where the value is.

Design: architecture needs to become AI-readable

AI-DLC will not work if architecture remains trapped in scattered diagrams, stale Confluence pages and tribal knowledge.

AI needs context.

Engineers need context.

Governance needs context.

If the architecture artefacts are fragmented, outdated or hard to query, AI will not fix the problem. It will only make the gaps less visible.

This is why architecture-as-code matters.

I do not mean turning every architecture decision into heavy documentation. I mean making architecture artefacts structured, versioned, searchable and usable by both humans and AI.

A practical architecture-as-code repository might include:

/architecture
  /decisions
  /patterns
  /nfrs
  /risks
  /controls
  /api-contracts
  /data-boundaries
  /sequence-diagrams
  /operational-readiness

The format does not need to be complicated. Markdown, Mermaid, PlantUML, OpenAPI, JSON and YAML can be enough.

The point is not the format.

The point is that architecture intent becomes explicit.

If AI is going to help developers write code, refine stories, generate tests or review pull requests, it needs to understand the approved patterns, system boundaries, integration contracts, security controls and non-functional expectations.

Otherwise, AI will optimise for generic correctness rather than organisational fit.

That is dangerous.

A generated implementation may look technically reasonable and still violate the actual architecture. It may bypass an approved integration pattern. It may log sensitive data. It may introduce coupling the platform was trying to avoid. It may produce code that works locally but creates supportability problems later.

This is why I keep coming back to technical ownership.

Technical ownership is not about being the person who writes the code. It is about protecting the technical integrity of the outcome across architecture, delivery, security, data, integration, operations and long-term maintainability.

AI does not remove that responsibility.

It makes it more important.

Delivery: context before code

The most visible AI use case in delivery is code generation.

That is also where many organisations will make the shallowest mistake.

They will measure AI adoption by how many developers use a coding assistant. That may be useful as a productivity signal, but it does not prove the organisation is delivering better systems.

Good delivery is not only about writing code faster.

It is about building the right thing with the right constraints, in a way the organisation can operate, secure, change and govern.

In AI-DLC, AI-assisted delivery should be grounded in context. A developer should not only give the AI a Jira ticket and ask it to produce code. The AI should also understand the architecture decision, approved pattern, API contract, data classification, security controls, observability expectations and test strategy.

That is the difference between AI coding and AI-assisted delivery.

A Jira story on its own can be too thin. It may describe the task but not the architecture consequence. It may tell the engineer what to build but not explain what not to break.

The context bundle matters.

Before AI generates implementation guidance, the team should be able to attach:

- The user story or delivery ticket
- The relevant architecture decision record
- The approved integration pattern
- The API or event contract
- The data classification
- The non-functional requirements
- The threat model or control checklist
- The expected test coverage
- The observability requirements
- The release and rollback guardrails

This is where AI-DLC becomes practical.

AI can help turn architecture decisions into acceptance criteria. It can generate negative test cases from risks. It can suggest missing logs and metrics. It can compare a pull request against an approved design. It can highlight where the implementation has drifted from the decision record.

But the human team still owns the judgement.

AI can accelerate the path.

It cannot own the consequence.

Governance: move from late review to continuous assurance

Traditional architecture governance often arrives too late.

A team has already shaped the solution. Engineering has already started. Dependencies are already committed. Then the architecture review asks whether the design is aligned.

At that point, governance can become a theatre of approval.

AI-DLC gives us a better option.

Governance can become more continuous.

That does not mean more meetings. It should mean fewer surprises.

AI can help check whether key artefacts exist, whether risks have mitigations, whether decision records are linked to delivery work, whether data classification has been considered, whether non-functional requirements are missing, and whether implementation evidence supports the architecture intent.

This matters because AI creates a traceability problem.

If teams are using AI across discovery, design and delivery, leaders need to know how decisions are being shaped. Which outputs were generated? Which were reviewed? Which were accepted? Which risks were identified? Which controls were applied? Who made the final call?

That is not bureaucracy.

That is accountability.

I wrote about decision ownership in RAPID vs DACI: The decision matrix every CIO should steal. The same principle applies here. AI can assist the decision process, but it cannot replace decision rights.

Someone still needs to own the call.

Someone still needs to record the why.

Someone still needs to revisit the decision when assumptions change.

AI-DLC should make this easier by creating living evidence, not more paperwork.

The governance model must include AI-specific risk

There is another layer that cannot be ignored.

AI introduces risks that traditional delivery governance was not designed to handle properly.

Prompt injection. Sensitive data disclosure. Insecure tool use. Model hallucination. Unreviewed generated code. Excessive agent permissions. Weak audit trails. Private information being pasted into external tools. AI outputs being treated as evidence when they are really suggestions.

These are not theoretical risks.

They are delivery risks.

They need to be managed in the same lifecycle as architecture, security, privacy and operational readiness.

This is where external frameworks are useful, but they are not enough on their own. NIST’s AI Risk Management Framework gives a useful risk management structure around Govern, Map, Measure and Manage. OWASP’s LLM guidance highlights application-level risks such as prompt injection and sensitive information disclosure. Google’s SAIF gives a security lens for AI systems. Microsoft’s Responsible AI material connects governance with engineering practices and team enablement.

But frameworks do not implement themselves.

The architecture question is:

How do these controls show up in daily delivery?

A policy document is not enough.

The controls need to appear in story refinement, design review, code review, testing, release readiness, vendor assessment, access control, logging, incident response and post-implementation learning.

Otherwise, AI governance becomes another document that looks mature but does not change behaviour.

That is one of the most common enterprise architecture anti-patterns: governance that exists on paper but not in the operating model. I explored that broader problem in When Enterprise Architecture Goes Sideways: 4 Anti-patterns and Fixes.

AI-DLC needs to avoid the same trap.

The real operating model

The practical AI-DLC operating model is not complicated.

But it does need to be explicit.

Discovery should produce decision-ready evidence.

Design should produce AI-readable architecture intent.

Delivery should use AI with controlled context, not isolated prompts.

Testing should be generated from requirements, risks and failure modes.

Governance should continuously check traceability, controls and evidence.

Post-implementation review should feed learning back into the architecture knowledge base.

That last part is important.

AI-DLC should improve with every delivery cycle. If a design assumption was wrong, capture it. If a generated test missed an edge case, update the pattern. If a security review found a new class of risk, add it to the control library. If a prompt created poor output, improve the reusable prompt pattern. If engineers repeatedly ask the same architecture question, make the architecture guidance clearer.

This is how AI-DLC becomes a learning system.

Not because AI is magic.

Because the organisation finally treats delivery knowledge as an asset.

Do not confuse AI speed with platform maturity

AI can make immature delivery look more productive for a while.

That is the trap.

A team with unclear ownership can produce more documents. A team with weak architecture can produce more diagrams. A team with poor testing discipline can produce more test cases. A team with fragmented governance can produce more evidence packs.

But volume is not maturity.

The real test is whether AI improves decision quality.

Are assumptions clearer?

Are risks surfaced earlier?

Are architecture decisions easier to trace?

Are security controls applied consistently?

Are teams reusing approved patterns?

Are non-functional requirements being designed in, not added late?

Are support, observability and operational readiness considered before release?

Are leaders making better trade-offs with better evidence?

If the answer is no, AI is probably accelerating activity rather than improving the system.

This is similar to the issue I described in Operational Over-Tooling: When Your Stack Becomes the Product. More tools do not automatically create better operations. More AI does not automatically create better delivery.

The operating model matters.

Data quality becomes even more important

There is one uncomfortable truth many AI transformation plans underplay.

AI is only as useful as the context it receives.

If requirements are vague, architecture documents are stale, system ownership is unclear, data classification is inconsistent and decision records do not exist, AI will not magically create maturity. It may simply produce confident output from poor inputs.

Bad input becomes bad guidance.

Bad guidance becomes delivery risk.

That is why data quality and knowledge quality matter in AI-DLC. Your architecture repository, delivery artefacts, risk registers, design patterns and operational runbooks become part of the context that AI uses to support the team.

If that context is weak, the AI output becomes weak.

This connects directly to the issue I wrote about in Bad Data Virus: The Enterprise Anti-Pattern That Breaks Trust. Bad data does not always fail loudly. It quietly contaminates decisions.

The same is true for bad architecture knowledge.

If your AI assistant is learning from stale patterns, unclear boundaries and old assumptions, it may help teams move faster in the wrong direction.

AI-DLC needs clean, governed, current knowledge.

Not perfect knowledge.

But trustworthy enough to support decisions.

What leaders should ask before adopting AI-DLC

The wrong question is:

Which AI tool should we buy?

The better questions are:

What parts of our lifecycle are ready for AI assistance?

Which decisions must always remain human-owned?

What data can and cannot be shared with AI tools?

How will AI outputs be reviewed?

Where will architecture decisions be stored?

How will generated code be tested and traced?

How will we detect architecture drift?

How will we prove security and compliance controls were considered?

How will we prevent every team from creating its own AI delivery process?

These questions are not designed to slow adoption.

They are designed to make adoption safe enough to scale.

There is a difference between experimentation and operating model change. Experimentation can live inside a team. Operating model change affects the enterprise.

AI-DLC is an operating model change.

That means architecture, security, engineering, product, delivery and governance need to work together from the start.

A practical AI-DLC maturity path

The first step is not to automate everything.

The first step is to create clarity.

Start by mapping where AI is already being used across discovery, design, delivery, testing and governance. Most organisations will discover that AI adoption is already happening informally.

Then classify the usage.

Low-risk use cases might include summarising public documentation, drafting meeting notes or producing first-draft outlines.

Medium-risk use cases might include story refinement, test generation, documentation updates and architecture draft support.

High-risk use cases include code generation for critical systems, AI agents with tool access, security-sensitive workflows, customer data handling, regulated processes and decisions that affect financial, legal, privacy or operational outcomes.

Once the organisation understands the usage, it can define guardrails.

Not every AI use case needs the same control.

A draft meeting summary does not need the same review model as generated code in a payments platform. A public blog outline does not need the same governance as an AI agent with access to internal systems.

Good governance is proportionate.

That is how you avoid both extremes: uncontrolled adoption and governance theatre.

Architecture’s role in AI-DLC

Architecture should not try to own every AI tool.

That would be the wrong model.

Architecture should own the integrity of the lifecycle.

That means helping the organisation define where AI fits, what context it needs, what decisions it can support, what decisions it cannot own, what artefacts must be traceable, and what risks need controls.

Architecture should also help create the reusable patterns.

Prompt patterns. Design patterns. Review checklists. Architecture-as-code templates. Decision record formats. Control libraries. Context packs. Governance workflows.

This is where enterprise architecture can become more useful, not more bureaucratic.

The value is not in telling teams, “You need approval before using AI.”

The value is in giving teams a safe path to use AI without creating hidden risk.

That is a different kind of governance.

It is governance as enablement.

The strategic lesson

AI-DLC is not about replacing delivery teams.

It is about making delivery knowledge more structured, more reusable and more governed.

Used well, AI can help teams move faster with better evidence. It can surface risks earlier, connect decisions to implementation, generate stronger test coverage, improve documentation and make governance more continuous.

Used poorly, it can hide risk behind speed.

That is the delivery trap.

An organisation may believe it is becoming AI-native because teams are using AI tools. But AI-native delivery is not measured by tool usage. It is measured by whether the organisation can use AI while still protecting decision quality, architecture integrity, security, supportability and accountability.

The real question is not:

Are our teams using AI?

The better question is:

Can our delivery lifecycle absorb AI without losing control of the decisions that matter?

That is where AI-DLC becomes important.

Not as another framework.

As a way to make sure speed does not outrun ownership.

Subscribe to Designed to Scale

I write about enterprise architecture, AI systems, platform strategy and the real trade-offs behind technical decisions.

Subscribe to Designed to Scale if you want practical architecture thinking for leaders building systems that need to survive real delivery, real growth and real operational pressure.

Read more from Designed to Scale

• AI Infrastructure Strategy for Enterprise Architects

• Where Business Analysis Ends and Solution Architecture Begins

• When Enterprise Architecture Goes Sideways: 4 Anti-patterns and Fixes

• RAPID vs DACI: The decision matrix every CIO should steal

• Operational Over-Tooling: When Your Stack Becomes the Product

Every tap-and-go payment is a trust event.

A customer taps a card, a phone, or a wearable and expects the transaction to feel effortless. Underneath that simplicity sits a chain of systems, networks, service providers, and decisions that must work securely in seconds. When they do, nobody notices. When they fail, the damage is rarely limited to one bug or one team. It becomes a trust problem, an operating problem, and often a board-level problem. That is the real business context behind PCI DSS. In your series, PCI DSS is framed not as an auditor’s checklist, but as disciplined engineering: segmentation, minimalism, encryption, accountability, and continuous vigilance.

Most CIOs do not need to memorise the standard. They do need to understand five things:

1. how a payment flows in plain English

2. where card data appears

3. how scope quietly expands

4. what controls matter most

5. what questions leadership should ask before an incident forces the answer

That is the purpose of this brief.

Tap-and-Go in plain English

At a high level, a card payment is simple.

Customer taps card → merchant app or terminal → payment gateway or processor → card network and issuer → approval or decline returns

The customer sees a beep and a receipt. The architecture team sees something else: data crossing trust boundaries. A single transaction may pass through multiple organisations and systems before a decision comes back. Each hop is a chance to expose cardholder data if the architecture is sloppy, if data is logged carelessly, or if connected systems absorb more information than they should. Part 1 of your series makes this point clearly: payment security is not abstract. It is about what happens to card data wherever it lives, moves, or hides.

This is why PCI DSS matters to CIOs. Not because the document is long, but because payment architecture tends to sprawl unless somebody at leadership level keeps asking the right questions.

The architecture boundary that matters most

When people hear “PCI”, they often jump straight to encryption, firewalls, or audit evidence. The more important starting point is scope.

Before you can protect anything, you need to know what data you are dealing with and where it exists. Part 2 of your series separates payment data into two categories: Cardholder Data (CHD), such as PAN, cardholder name, and expiry date; and Sensitive Authentication Data (SAD), such as CVV, PINs, or full track or chip data. CHD may be stored if properly protected. SAD must not be retained after authorisation, even if encrypted.

That distinction is not academic. It is the difference between a bounded payment environment and a contaminated estate.

The CIO question is not only, “Do we store card data?” The sharper question is, “Where can payment data appear today, including by accident?” Because scope expansion is rarely dramatic. It is usually quiet.

A developer turns on verbose logging.

A tester copies production transactions into QA.

An analytics feed consumes transaction payloads for “customer insights”.

A support workflow exposes more than masked data.

A monitoring platform indexes payloads that nobody meant to retain.

Each of those decisions can pull new systems into PCI scope. Your series treats this as one of the core lessons: the biggest PCI cost is often not the initial design, but the systems that become in scope because the architecture was not kept deliberately small.

That is why the most important architectural principle in payments is simple:

Keep card data away from internal systems wherever you can.

Tokenisation, strong encryption, segmentation, and careful provider choices all support that goal. Mature payment architecture is not about heroics. It is about keeping the island small.

What PCI DSS really tests

PCI DSS is often described as a compliance standard. In practice, it is also a test of operational discipline.

Part 3 of your series translates the standard into a clearer idea: protect payment data through strong design, disciplined operation, and continuous vigilance. That is a much better executive framing than “12 requirements”. The standard may be structured as twelve requirements across six families, but a CIO should see it as a way to test whether payment handling is deliberate or accidental.

A strong payment environment usually shows the same characteristics:

• clear boundaries

• minimal data exposure

• deliberate encryption and key handling

• tightly controlled privileged access

• secure change practices

• monitoring that catches drift early

• teams that understand their role in keeping scope small

A weak environment usually shows the opposite:

• unclear ownership

• logs and tools treated as harmless by default

• PCI left to security alone

• audit evidence assembled late

• delivery speed bought at the cost of discipline

That is why PCI maturity is as much about habits as it is about controls. Part 4 and the final review both reinforce that compliance does not live in the document library. It lives in everyday decisions, every commit, every test path, every deployment, and every exception someone thinks is temporary.

The CIO’s 1-page architecture and control checklist

Below is the version I would put in front of a CIO, not as an audit worksheet, but as a leadership checklist.

1) Keep the payment estate small

Can the team clearly show where card data enters, moves, and stops? Can they explain which systems are in scope today and why? If this map is vague, your risk is already higher than you think. Part 2 repeatedly emphasises that scope definition is the most overlooked part of compliance and the one that shapes how painful everything else becomes.

2) Keep sensitive data out of general systems

Can the team prove that CVV, PIN-related data, full track data, and other prohibited elements are not being retained after authorisation? Can they prove that logs, dashboards, tickets, support tools, and email templates do not expose more than they should? Your series is very clear here: some data can be protected and retained under strict controls; some data simply must not remain.

3) Protect every hand-off

Are transmissions encrypted across all relevant paths, not only internet-facing ones but internal APIs and service-to-service communications as well? Are certificates validated properly? Is storage protection deliberate rather than assumed? Part 3 notes that internal traffic is often wrongly treated as “safe”, even though encryption in transit matters there too.

4) Restrict privileged access and make it attributable

Who can access payment systems, secrets, logs, consoles, and supporting platforms? Is that access limited by role, reviewed regularly, and attributable to named individuals? Strong PCI posture requires accountability, not generic administrative convenience. That theme runs across Part 1, Part 3, and Part 4.

5) Build controls into delivery, not after delivery

Do architecture reviews, design patterns, code reviews, testing, release gates, and project plans include payment-control expectations from the start? Or does PCI only become visible near audit time? Your series consistently argues that good compliance is a natural extension of good engineering, not a clean-up exercise at the end.

6) Detect scope drift early

Would the organisation know quickly if PAN-like data appeared in logs, databases, reports, analytics feeds, or non-production environments? Part 4 recommends automated scans for PAN-like patterns and treating that detection capability as part of normal engineering hygiene, not an emergency response technique.

7) Rehearse response, not just prevention

If card data appeared tomorrow in a non-CDE system, what happens next? Who owns containment? Who verifies eradication? Who re-assesses scope? Who informs stakeholders? The final review in your series makes an important point: PCI competence is not just knowing the rules when calm, but applying them instinctively under deadline pressure and operational stress.

Three red flags every CIO should recognise

Red flag 1: “We don’t store card data”

This statement is often true in spirit and false in practice.

Many teams mean they do not deliberately store card data in a business database. That does not answer whether card data appears in debug logs, observability tooling, reports, email templates, message queues, or copied test datasets. Your series uses multiple examples of accidental contamination to show that unplanned exposure is still exposure.

Red flag 2: PCI is treated as the security team’s job

That is a governance smell.

Architects define boundaries. Developers decide what gets logged and transmitted. Testers validate masking and data hygiene. Project managers decide whether compliance work is visible or perpetually postponed. Part 4 makes this explicit: compliance happens in daily choices across roles, not inside one specialised function.

Red flag 3: Audit readiness begins late

When evidence gathering starts close to assessment time, it usually means controls are not embedded deeply enough in delivery.

Healthy environments produce evidence naturally because the underlying habits already exist: controlled access, repeatable builds, disciplined logging, scanning, segmentation, and clear ownership. Unhealthy ones produce frantic spreadsheet work. PCI is expensive when it is bolted on. It is much cheaper when it is built in. That is one of the clearest through-lines of the entire series.

Three questions every CIO should ask this quarter

The point of this brief is not to turn CIOs into assessors. It is to sharpen leadership questions.

Here are the three I would use.

1. Where exactly can PAN appear today across production, logs, observability, support workflows, and non-production environments?

A vague answer here is a genuine warning sign. Scope cannot be managed if data location is fuzzy.

2. Which systems would become in scope tomorrow if a developer enabled verbose logging or if real data was copied into a test path?

This question gets people thinking about blast radius, not just current-state diagrams. It also exposes whether teams understand contamination pathways.

3. Who owns payment-scope reduction as an architecture objective, not just a compliance activity?

If nobody owns scope reduction, scope expansion will happen by default. This is one of the most important strategic ideas in your series.

The leadership takeaway

The real lesson of PCI DSS is not that payment systems need more paperwork. It is that payment systems need sharper boundaries.

When payment architecture is deliberately small, heavily bounded, and handled with engineering discipline, compliance becomes more manageable. Audits become less painful. Incidents become less likely. Delivery becomes more predictable. When payment data is allowed to drift into logs, tooling, test environments, and loosely governed integrations, every future change becomes harder and every future assurance activity becomes more expensive. That is the operating logic running through all five pieces in the series.

So the best CIO question is not:

“Are we compliant?”

It is:

“Can we prove our payment scope is as small and controlled as we think it is?”

That question does more than prepare you for an assessment. It drives better architecture.

Continue the payments series

This article is the canonical entry point for the full series.

1. Foundations: The secret rulebook behind every tap-and-go payment (Part 1), why PCI DSS exists and why trust matters.

2. Data & Scope: The secret rulebook behind every tap-and-go payment (Part 2), what counts as cardholder data, what belongs in scope, and how scope expands.

3. The 12 Requirements: The secret rulebook behind every tap-and-go payment (Part 3), the control model in plain language.

4. Roles & Breach Lessons: The secret rulebook behind every tap-and-go payment (Part 4), how everyday decisions turn theory into practice.

5. Final Review: PCI DSS Final Review: Real-World Scenarios, Scope Reduction & the PCI Mindset, scenarios, judgement, and the final mindset test.

If you’re a CIO choosing RAPID vs DACI for architecture decisions, use the matrix above. Pick one model per decision, name the roles in 10 minutes, and write the decision down in an ADR so you don’t relitigate it next month. Because the fastest way to slow a tech organisation down isn’t a bad architecture choice, it’s a decision that never actually lands. You’ve seen the pattern: “just one more stakeholder”, “we need alignment”, “let’s socialise it”, and suddenly a simple call turns into a four-week saga. This article gives you a clean way to choose the right decision model, run the meeting, and ship the outcome without turning governance into theatre.

The real problem isn’t the framework, it’s decision fog

Decision fog is what happens when nobody can clearly answer three questions: What are we deciding? Who decides? When is it decided? In architecture, it shows up as endless pre-reads that nobody finishes, “quick alignments” that turn into debate clubs, silent vetoes that appear after the meeting, and surprise stakeholders joining late with “one more concern” that resets the whole conversation.

The cost isn’t just frustration. Decision fog slows delivery, pushes teams into building their own versions of “the standard”, and creates security gaps because controls get negotiated differently every time. Over a few quarters, it turns into platform drift: five logging patterns, three ways of doing auth, two pipelines “temporarily” bypassing checks, and an Architecture Review Board that feels like a weekly rerun.

Mini-story: I’ve sat in ARB sessions where the room is full of smart people and the doc is 20 pages long… and still, nobody can name the decider. Everyone has input, someone has a concern, the meeting ends with “we’ll take it offline”, and the team ships anyway because the sprint clock doesn’t care.

By the end of this, you’ll know when to use RAPID vs DACI, and you’ll have templates you can copy-paste into your next decision so it sticks.

RAPID and DACI in one minute

RAPID (roles)

RAPID is built for decisions where ownership and follow-through are the main risks. It forces you to name who proposes, who can block, who ships, and who makes the final call.

• R — Recommend: writes the proposal and options

• A — Agree: limited, explicit veto / approval points

• P — Perform: owns delivery and adoption

• I — Input: consulted experts

• D — Decide: final decision maker

DACI (roles)

DACI is built for decisions where coordination and clarity are the main risks. It makes the process visible: who drives it, who approves it, who contributes, and who just needs to know.

• D — Driver: runs the process, keeps it moving

• A — Approver: final call

• C — Contributors: provide input and work

• I — Informed: kept in the loop, not part of the decision

The difference in one line: RAPID makes execution ownership explicit; DACI makes facilitation and participation explicit.

When RAPID wins for architecture decisions

RAPID is your pick when the decision isn’t the hard part, getting it executed across teams is. It’s built for calls that need a clear decider, explicit guardrails, and a named owner who will actually make it real in delivery.

Best-fit decision types (examples)

Use RAPID for decisions like these:

• Cloud landing zone standards, guardrails, and exceptions

Things like network patterns, identity boundaries, logging baselines, and the “no, you can’t do that” rules, plus the exception process.

• “Build vs buy” for a shared platform capability

CI/CD platforms, observability stacks, API gateways, feature flag platforms, and secrets tooling choices that will shape teams for years.

• Security boundary calls

CDE scope, tokenisation boundaries, encryption approach, key management patterns, where secrets live, what’s allowed in which environment.

• Integration patterns that affect many squads

Sync vs async, eventing vs request/response, canonical models, contract standards, idempotency rules, the stuff that becomes organisational muscle memory.

What to watch for (failure modes)

RAPID works brilliantly… until people blur the roles.

• Too many “Agree” roles becomes a hidden committee

“Agree” is not “everyone who cares”. Keep it to true veto points (security, risk, legal) or you’ve rebuilt the problem you were trying to fix.

• The decider avoids deciding and turns “Input” into voting

If “Input” becomes a poll, you’ll get “alignment” and still no outcome. Input is advice, not a referendum.

• “Perform” isn’t named, so the decision never lands in production

This is the silent killer. If there’s no delivery owner, the decision becomes a document, not a change. RAPID only works when “Perform” is a real person with capacity and a plan.

When DACI wins for architecture decisions

DACI is the better tool when the main problem is coordination. You don’t need a heavyweight decision chain; you need one person to drive the process, pull in the right contributors, and land the outcome cleanly without everyone feeling like they have to attend every meeting.

Best-fit decision types (examples)

DACI works well for decisions like:

• API standards updates and versioning rules

Naming conventions, error formats, pagination rules, deprecation timelines, and decisions that need consistency and a simple way to socialise change.

• Reference architecture updates

Logging and tracing standards, CI/CD guardrails, “golden path” patterns where the goal is repeatability and predictable adoption.

• Repeated “same-shaped” decisions across squads

The sort of decisions you make every month: “Which pattern is the default?”, “What’s the exception path?”, “What’s the minimum bar?” If you’ll do it again, DACI keeps it lightweight.

• Tooling choices inside a lane

Observability, feature flags, testing strategy, secrets tooling, especially when it’s a platform capability that needs input from a few teams but shouldn’t become an all-hands debate.

What to watch for (failure modes)

DACI breaks down when the roles become symbolic.

• The Driver becomes a note-taker instead of a closer

The Driver’s job is to move the decision to a finish line: set deadlines, chase inputs, frame options, and force a call with the Approver. If the Driver is only capturing comments, you’ll loop forever.

• Too many Contributors, no quality bar for input

If everyone is a contributor, nobody is accountable. Keep contributors tight, and ask for input in a useful shape: risks, trade-offs, and a recommendation, not essay-length opinions.

• “Informed” stakeholders show up late and try to reopen the call

This is where DACI needs backbone. Informed means they get the decision, not a seat at the table. If someone comes in late with new information, treat it as a change request; don’t replay the whole decision.

The “architecture decision types” checklist (pick a model fast)

Use this like a quick diagnostic. Don’t overthink it. Count the “yes” answers and pick the model that matches the shape of the decision.

Score RAPID if you answer “yes” to 3+

• Does the decision require cross-team execution and adoption? (Multiple squads will need to change how they build, deploy, or integrate.)

• Are there true veto points (security, risk, legal, finance)? (Someone must be able to say “no” for real reasons, not preference.)

• Will this decision change delivery roadmaps or operational load? (New work across teams, new on-call burden, new runbooks, new costs.)

• Is there a high cost of rollback? (Undoing it later would be expensive, disruptive, or risky.)

Score DACI if you answer “yes” to 3+

• Is the main pain coordination and stakeholder clarity? (The decision itself isn’t scary, the process keeps wobbling.)

• Is this a recurring decision pattern (you’ll do it again soon)? (Standards, templates, playbooks, “default patterns” that repeat.)

• Do you need one person to drive inputs and timeboxes? (The herding cats problem. You need a Driver who closes.)

• Is the change easy to roll forward with a clear standard? (You can iterate, refine, and improve without massive rollback risk.)

Templates (copy-paste)

These are designed to be fast. Paste them into Confluence/Notion/Google Docs, fill the blanks, and you’re ready to run the decision.

Template 1: RAPID roles table (one decision)

Decision statement: [One sentence: what are we deciding?]

Timebox + meeting date:

• Input closes: DD MMM

• Decision meeting: DD MMM (max 30–45 mins)

• Decision locked in ADR by: DD MMM (same day)

“Agree” guardrails (what counts as a veto):

• Veto is valid only if it’s tied to: security / legal / risk / finance policy

• Must include: specific concern + impact + proposed mitigation/alternative

• No “veto by vibe”

Template 2: DACI roles table (one decision)

Decision statement: [One sentence: what are we deciding?]

Input deadline + decision date:

• Input due: DD MMM (written input, max 5 bullets each)

• Decision date: DD MMM

• Publish outcome by: DD MMM (same day)

How the outcome will be shared:

• Posted in: #architecture (Slack/Teams) + linked in Confluence

• Recorded as: ADR-###

• Rollout note: who changes what by when

Template 3: One-page architecture decision brief (works for both)

Title: Decision: [X]

Owner: [Name]

Decision date: DD MMM YYYY

Framework: RAPID / DACI

Context (3 bullets)

• What’s happening / why now?

• What’s broken or at risk?

• What success looks like

Options (2–3 options, with trade-offs)

• Option A: …

  • Pros: …

  • Cons: …

  • Risks: …

• Option B: …

  • Pros: …

  • Cons: …

  • Risks: …

• Option C (if needed): …

Recommendation (1 paragraph)

State the call, the core reason, and the trade-off you’re accepting.

Risks and mitigations

• Risk: … → Mitigation: …

• Risk: … → Mitigation: …

Rollout plan (who, when, how we measure)

• Who: Perform/Owners

• When: milestones + dates

• Measures: adoption %, incident rate, cost, latency, time-to-ship, etc.

Decision record (ADR link)

• ADR-###: [link]

Template 4: ADR mini-template (so decisions stick)

Title: Decision: [X]

Status: Proposed / Accepted / Superseded

Date: DD MMM YYYY

Owner: [Name]

Decision

What we decided, in 2–5 lines.

Rationale (trade-offs)

• Why this option over the others

• What we’re optimising for

• What we’re consciously accepting

Consequences

• Positive: …

• Negative: …

• Follow-ups: … (tickets, migration plan, deprecation)

Links

• Decision brief: …

• Threat model / risk assessment: …

• Diagrams: …

• Related ADRs: …

Meeting scripts (short lines that actually work)

These are the lines you can use in the room without sounding like you’re quoting a framework. Short, calm, and they move things forward.

When the meeting starts to spiral

• “We’re mixing input with decision. Who’s the decider for this call?”

• “Let’s timebox. What do you need to be comfortable, and by when?”

When someone wants a vote

• “Happy to take input. We’re trading off, not running a poll.”

When late stakeholders try to reopen it

• “If there’s new information, let’s log it as a change request against the ADR.”

How to operationalise this in your architecture governance

Frameworks don’t fix anything on their own. What changes behaviour is making the decision process repeatable and boring: same roles, same timeboxes, same place to record outcomes. That’s what enterprise architecture governance is meant to do: keep standards consistent, make decision rights visible, and stop every team inventing their own “rules” in isolation.

Where it fits

• Squad-level decisions (DACI most of the time)

Most day-to-day architecture calls are local: API patterns, small tooling choices, reference implementation updates. DACI keeps it lightweight and fast, with a clear Driver and Approver so it doesn’t stall.

• Cross-domain decisions (RAPID for clarity)

When a decision spans squads, platforms, or risk domains, RAPID keeps it clean: one decider, explicit veto points, and a named “Perform” who owns delivery and adoption.

• ARB as “red lines only” with explicit veto criteria

Treat the ARB like a safety rail, not a weekly court hearing. If something doesn’t hit a red line (security boundary, compliance, material risk, major cost), it shouldn’t need ARB airtime. And if it does hit a red line, the veto criteria should be written down so it’s predictable, not personal.

Simple cadence

• Weekly decision slot (30 mins)

One recurring slot for decisions that need cross-team visibility. Keep it tight: two decisions max, timeboxed discussion, clear outcome.

• Decisions written same day (ADR link)

Don’t rely on memory. Publish the decision and the “why” while it’s fresh, then link it everywhere the delivery teams will actually see it.

• Monthly review of exceptions and drift (standards vs reality)

This is where governance earns its keep. Review what teams are deviating from, why they needed exceptions, and whether the standard should change. Standards that don’t match reality don’t get followed, they get worked around.

Close: your operating model in 5 lines

• Pick one model per decision.

• Name roles in 10 minutes.

• Timebox inputs.

• Decide once, record it (ADR).

• Review exceptions, not old arguments.

If you want architecture playbooks you can run on Monday morning, subscribe to my newsletter.

Friday 4:47 pm. A payment flow is failing. Slack is loud. Someone drops a screenshot of a red dashboard… then another. Then a link to logs. Then a different log tool “because this service ships there”. Traces are in a third place. Alerts are coming from a bot only one person knows how to tune, and they’re away today. Twelve tabs later, you still don’t have a single story of what happened, just fragments, guesses, and rising heart rates.

This is operational over-tooling in the wild. It doesn’t just add licences; it adds load. It turns incident response into a scavenger hunt and makes “moving fast” feel like gambling.

Over-tooling is an architecture anti-pattern because it shifts complexity out of code and into day-to-day operations, where it taxes every release and every outage.

Before you buy “one more tool”, use this decision matrix. It forces the real question: keep, consolidate, or retire and who owns it.

What “operational over-tooling” looks like in real teams

It usually starts with a good reason.

A team ships a new service. They need visibility fast, so they pick a monitoring tool they already know. Another team has a different stack and chooses something else. Security rolls out a scanner “just for coverage”. A platform team adds a CI/CD tool to unblock delivery. None of these choices are reckless. In isolation, they’re sensible.

Then a Friday incident happens and all the sensible choices collide.

You’re in the war room and the questions sound familiar: “Where are the logs for this one?” “Which dashboard is the source of truth?” “Why is the alert firing when the trace looks clean?” Someone shares a link, then another, then another. The team isn’t debugging the payment flow anymore they’re debugging the tooling around the payment flow.

That’s operational over-tooling: when your stack becomes a second system you have to operate before you can operate the product.

The symptoms you can feel (not just measure)

• Same job, three tools. Monitoring is split, CI/CD is split, feature flags are split. Everyone has a reason. Nobody has the full picture.

• Incidents become a scavenger hunt. Logs live here, traces live there, alerts come from somewhere else, and correlation becomes guesswork.

• “Hidden” work becomes the real work. Agents, connectors, pipelines, retention rules, token rotation, webhook retries. It’s not visible on the roadmap, but it eats the roadmap anyway.

• Ownership gets blurry. When something breaks, the question isn’t “how do we fix it?” — it’s “who even owns this tool?”

• Tooling turns into a career moat. One person can tune the alerting bot, manage the permissions model, or fix the pipeline when it jams. When they’re away, progress slows to a crawl.

The giveaway is emotional, not technical: teams start sounding tired. They stop trusting signals. They default to “ask Sam, he knows the system”. That’s not resilience, that’s dependency.

The root cause (it’s rarely the tool)

This pattern doesn’t exist because teams are bad at picking tools. It exists because the organisation is bad at owning them.

• Procurement-by-pain. The last incident hurts, so the next purchase feels urgent. Speed beats design, and the tool ships faster than the operating model.

• Local optimisation beats global outcomes. Each team improves their corner, but the company pays the integration and support tax across every corner.

• No thin-core standards. Without a few non-negotiables (identity, observability, policy enforcement), every new tool becomes its own mini-platform with its own rules.

• Decisions don’t get revisited. Tool choices get made once, then slide into auto-renew. The cost isn’t just the licence, it’s the permanent operational burden.

If you’ve ever watched an incident drift from “what’s failing?” to “which tool do we trust?”, you’ve seen the anti-pattern. And it’s exactly why the decision matrix matters: it forces a clear call to keep, consolidate, or retire before “one more tool” becomes “one more system to run.”

Why it’s an architecture anti-pattern (not a shopping problem)

If this was just a shopping problem, you could solve it with a better shortlist, a sharper RFP, and a hard negotiation. But operational over-tooling keeps coming back because it’s really an architecture and operating-model problem: you’re creating more moving parts than your organisation can reliably run.

It increases operational load faster than delivery speed

Every tool promises “faster delivery”. Then it quietly adds a new slice of operational reality that someone has to own, secure, integrate, monitor, upgrade, and pay for. Multiply that by a few teams, a few years, and a few “temporary” exceptions, and your stack becomes a second product.

Each new tool tends to add:

• another auth model (roles, groups, service accounts, break-glass access)

• another data model (naming, tagging, schemas, retention rules)

• another billing line (renewals, tier creep, usage surprises)

• another integration surface (agents, APIs, webhooks, connectors, plugins)

• another failure mode (outages, rate limits, misconfig, noisy alerts)

That’s why tool-centric DevOps without the operating model creates failure and fatigue. You don’t just buy software, you buy ongoing work, plus a new way to fail.

It slows incident response

Over-tooling doesn’t usually break the system directly. It breaks the story of the system.

When telemetry is split across tools, teams lose the ability to correlate signals quickly: the alert fires in one place, the logs are somewhere else, traces are incomplete, and dashboards disagree. Time-to-detect stretches because nobody trusts the first signal. Time-to-recover stretches because you’re stitching together fragments under pressure.

The result looks like this: more Slack messages, more screenshots, more “can someone check X?” and less actual diagnosis.

It makes governance either heavy or useless

Tool sprawl pushes governance into two bad extremes.

• Heavy governance: endless approvals and architecture reviews because nobody trusts the stack’s risk profile anymore. Every tool request becomes a debate about identity, data access, auditability, and support because those basics aren’t standardised.

• Useless governance: “teams can choose anything” until a breach, audit finding, or major outage forces a reset. Then you swing back to heavy governance, usually with a blunt consolidation program and a lot of resentment.

A healthy setup sits in the middle: a thin core of standards, clear ownership, and a simple decision loop. Without that, you’re not managing tools, you’re managing chaos with invoices attached.

The “keep vs consolidate” decision framework

Here’s the mistake most organisations make: they treat every tool decision like a feature decision. One team has a need, they pick a tool, and the business moves on. That works right up until the tool becomes shared infrastructure, then you’re no longer choosing a product, you’re choosing an operating burden.

So instead of arguing “Tool A vs Tool B”, make the first decision simpler: is this a local choice, or does it belong on the platform? Once you agree on the lane, the vendor discussion becomes much easier (and a lot less political).

Scannable checklist (copy/paste ready)

A tool can be a local choice only if all of these are true:

• No customer data classification surprises

  It doesn’t store, process, or expose sensitive data in ways that will bite you later.

• No privileged access outside standard IAM

  It uses your normal identity patterns (SSO, MFA, least privilege). No rogue admin accounts.

• No dependency in incident response

  If the tool is down, you can still debug production. It’s helpful, not required.

• Can be replaced inside a sprint

  Low switching cost. If you had to rip it out, you wouldn’t need a six-month program.

• Has a named owner and a clear exit plan

  Someone is accountable for cost, security, and lifecycle, and you already know how you’d leave.

If any answer is “no”, it goes into the platform lane. That means: standardise it, support it properly, and make it part of the “thin core” rather than another optional add-on.

And yes, this ties straight back to the matrix at the top: local choice = keep, platform lane = consolidate, and anything that fails both (duplicate, low value, no owner) is a retire candidate.

Relatd Artciles:

• Stop “Design by Committee” in Architecture

• Bad Data Virus: The Enterprise Anti-Pattern That Breaks Trust

• Stop Building the Swiss Army Knife Integration Hub

Fix pattern 1: Build a thin core, then give teams freedom above it

The fastest way to shrink tool sprawl without starting a civil war is to separate standards from preferences. Most teams don’t actually want unlimited choice. They want freedom where it helps delivery and consistency where inconsistency hurts.

That’s the “thin core + autonomy above” move: lock down the few foundations that make systems safe and operable, then let teams innovate on top without reinventing the basics every time.

The non-negotiables (thin core)

These are the pieces that should feel boring because boring is reliable:

• Identity and access patterns

  SSO, MFA, least privilege, consistent service account handling, break-glass rules.

• Observability standards

  Common fields, correlation IDs, agreed retention, and one standard pipeline for logs/metrics/traces.

• Deployment and rollback guardrails

  Release patterns, rollback expectations, feature toggle rules, and what “safe deploy” means here.

• Policy enforcement points

  Where controls live: gateway for ingress policy, runtime for service controls, CI for build-time checks.

This pattern shows up again and again because it reduces sprawl without freezing delivery. Teams can still move quickly, they’re just moving quickly on rails instead of inventing a new train track each sprint.

What autonomy actually means (examples)

Autonomy isn’t “do whatever you want”. It’s “choose freely inside safe boundaries”.

• Teams can choose UI dashboards, but logs must land in the standard pipeline with the standard fields.

• Teams can choose feature flag products, but kill switches follow one pattern (naming, ownership, where they’re documented).

• Teams can experiment, but experiments expire unless adopted (time-boxed, owned, and reviewed).

The goal isn’t to win an argument about tools. It’s to make sure every tool choice doesn’t quietly become a company-wide dependency.

Fix pattern 2: Platform engineering and an Internal Developer Platform (IDP)

If thin core is the rules, an IDP is the shortcut.

Most tool sprawl happens because teams are trying to assemble a working delivery and operations experience from scratch: build, deploy, observe, secure, repeat. An Internal Developer Platform bundles those capabilities into something that’s supported, consistent, and easy to adopt.

What an IDP does (plain English)

• Provides “golden paths” that make the right thing the easy thing

  Create a service, get standard logging, safe deploy, sensible alerts, and a runbook template without begging three teams.

• Reduces tool sprawl by packaging a supported set of capabilities

  Build, deploy, and observe with defaults that work and integrations that are already done.

• Treats developer experience as a product

  There’s a roadmap, a support model, clear ownership, and feedback loops, not a pile of scripts nobody owns.

The trap to avoid

• Don’t build a “platform of platforms”

  If your platform needs a platform team to operate it, you’ve recreated the problem with a nicer logo.

• Keep it small, opinionated, and measured by adoption

  Adoption is the score. If teams avoid it, it’s not a platform, it’s a side project.

Fix pattern 3: A lightweight governance loop that prevents relapse

Even with a thin core and a platform, sprawl returns if decisions don’t have a lifecycle. The fix isn’t heavy approvals. It’s a simple loop that keeps visibility and ownership alive.

The Tooling Decision Record (TDR) in one page

Think of this as the smallest artefact that stops “we bought it because reasons”.

Include:

• What problem are we solving?

• Who owns it? (service owner + platform owner)

• What is the exit plan?

• What data and access does it touch?

• What is the success measure? (adoption, incident reduction, cost)

If the TDR can’t be written clearly, that’s usually a signal the tool choice isn’t clear either.

Quarterly rationalisation cadence (30 minutes per domain)

This isn’t a big program. It’s maintenance — like brushing your teeth.

• Keep / consolidate / retire review

• Licence true-up

• Security review refresh

• Decommission plan for “retire”

This matches what actually works in sprawl governance: visibility, ownership, regular review, and renewal control without turning every request into theatre.

Fix pattern 4: Use AI to reduce friction, not to multiply tools

AI can either cut your operational overhead or become the newest category of sprawl. The difference is whether AI is used to simplify workflows or to introduce new platforms with new permissions, new data paths, and new vendors.

Where AI helps immediately

• Draft TDRs from a template (problem statement, risks, owners, exit plan)

• Generate migration runbooks and test checklists (so consolidation doesn’t stall)

• Summarise incidents across Slack + tickets + telemetry (faster shared understanding)

Where AI makes sprawl worse

• “AI tool of the week” procurement

  Every team trialling a different assistant with a different data policy.

• Multiple copilots with different permissions and data paths

  Now you’ve got duplicated tooling and a mess of access, retention, and compliance questions.

Use AI like power steering, not a new engine. If it makes your stack bigger, noisier, or harder to govern, it’s not helping; it’s just moving the burden somewhere else.

A practical 30/60/90-day plan (doable, not heroic)

You don’t fix tool sprawl with a big-bang program and a six-month steering committee. You fix it by stopping new sprawl, consolidating one capability end-to-end, then locking in a lightweight loop so you don’t slide back.

First 30 days: stop the bleeding

Your goal in the first month is simple: no more surprise tooling.

• Freeze new tools in the platform lane unless a TDR exists

  If a tool affects identity, customer data, or incident response, it needs a one-page Tooling Decision Record. No TDR, no new dependency.

• Inventory the top 20 tools by pain, not by popularity

  Rank them by:

  • cost (licence + hidden support effort)

  • access risk (privileged roles, data exposure)

  • incident dependency (do you need it to debug production?)

• Pick two consolidation targets

  Start with the two areas that create the most fragmentation:

  • observability (logs/metrics/traces/alerts)

  • CI/CD (pipelines, releases, rollback patterns)

Keep it focused. Two targets is realistic. Ten targets is theatre.

60 days: consolidate one lane

Now you do one consolidation properly. Not “we chose a tool”. Real consolidation: standards, migration, ownership.

• Choose the standard for one capability

  Example: logging + tracing correlation. Define the required fields, correlation IDs, and the source of truth pipeline.

• Migrate the highest pain services first

  Don’t start with the easiest. Start with the services that:

  • page people most often

  • block incident response

  • have the messiest “where do I look?” story

That’s how you earn trust fast.

• Publish golden path docs and a support model

  One page that answers:

  • how to onboard a service in under an hour

  • what’s supported (and what’s not)

  • who to contact when it breaks

If teams can’t adopt it quickly, they won’t adopt it at all.

90 days: lock in governance

By day 90, you want the system to stay clean without constant heroics from you.

• Run a quarterly rationalisation meeting

  30 minutes per domain: keep, consolidate, retire. Decisions recorded. Owners assigned.

• Require a TDR for renewals

  This is where you win. Tool sprawl often survives because renewals are automatic. Make renewals earn their place.

• Make exceptions expire unless renewed

  Every exception has an end date. If it’s still valuable, renew it with a fresh TDR. If not, it disappears quietly, which is exactly what you want.

The aim isn’t to have fewer tools for the sake of it. It’s to have fewer operational stories your team needs to remember at 4:47 pm on a Friday.

The takeaway

Back to Friday 4:47pm. The payment flow didn’t fail because the team lacked tools. It failed because, in the moment that mattered, nobody could see a single, trusted story. The signals were scattered, the dashboards disagreed, and the “one person who knows the bot” wasn’t online. That’s the real cost of over-tooling: not licences, but minutes and mental load when pressure is high.

Here’s the truth in one line: the fix is less about tools, more about ownership and boundaries. Your best engineers shouldn’t be doing archaeology across dashboards.

If you want architecture playbooks you can run on Monday, subscribe to my newsletter.

Integration decision matrix

Quick “Swiss Army knife” risk check

Tick 4+ and you’re in the danger zone:

• One integration service owns routing and mapping and retries and auth and business rules

• Every new project says: “Just add it to the hub”

• Changes require a central team queue and a lot of coordination

• A single deploy can break multiple unrelated domains

• Teams can’t ship value without waiting on the hub

• The hub keeps adding “optional fields” and “one endpoint for everything”

If you’re a CIO choosing API gateway vs iPaaS/ESB vs event broker, use the matrix above and make the call in 10 minutes. Then hold the line. The fastest way to slow delivery is letting one integration layer turn into the Swiss Army knife that “handles everything”. It feels tidy at first — one team, one platform, one place to plug things in. Then the queue forms. Every change needs a coordination meeting. One deploy breaks three unrelated journeys. Suddenly your integration layer isn’t enabling delivery; it’s rationing it. And the worst part? Domain ownership quietly slips away, because the real business logic ends up living in “the hub” instead of the teams that should own it.

The story: how the “helpful” integration hub became the choke point

It usually starts with good intentions. Two systems need to talk, the timeline is tight, and one team offers a “temporary” integration service to get things moving. It’s a sensible call: one connector, one mapping, one place to manage retries. It ships. People celebrate. Then the next project comes along and someone says, “Just run it through the integration hub; it’s already there.” And then the next one. Before long, the hub isn’t a shortcut; it’s the default.

Six months later, a small change goes out on a Thursday afternoon. It looks harmless. By Friday morning, five domains are dealing with failures they didn’t cause and can’t fix. Nobody wants to deploy without a war room. That’s when the nickname sticks: “The Octopus”, because everything runs through it,  and when it thrashes, everyone gets dragged under.

The moment you realise you’re stuck

The hub becomes a queue, not a platform. Instead of teams owning their integrations, they file tickets and wait. Integration turns into a central dependency, and delivery slows to the speed of the busiest team.

What the Swiss Army knife integration anti-pattern looks like

You can spot it without reading a single line of code. It shows up in day-to-day behaviour, team habits, and the shape of the interfaces.

• Interface bloat: “kitchen sink” endpoints appear in one API that tries to serve every consumer. Schemas grow into mega-objects with endless optional fields because “someone might need it later”.

• Responsibility bloat: the same component starts enforcing security policy, transforming payloads, orchestrating multi-step workflows, and quietly embedding domain rules (“if VIP customer then…”).

• Coupling bloat: every system’s release plan becomes dependent on the hub’s release cycle. Teams stop shipping independently because the integration layer is now the shared choke point.

• Operational bloat: retries, dead-letter handling, monitoring dashboards, data fixes, and one-off scripts all pile into the same codebase. The hub becomes a production support tool as much as a runtime.

The net effect is predictable: changes feel risky, testing becomes expensive, and the blast radius grows. People start avoiding improvements because “touching the hub” is a career-limiting move.

Why it happens in enterprises (not because people are silly)

It’s usually a rational response to pressure. The pitch is simple: a central team will be faster and more consistent. Vendor platforms reinforce it by selling “do-everything” toolkits that make it easy to add one more connector, one more flow, one more rule. And without a clear split between gateway duties (policy and traffic management) and integration runtime duties (bounded orchestration and transformation), everything collapses into one place by default.

The real costs (and why they sneak up on you)

The Swiss Army knife hub doesn’t fail loudly on day one. It fails slowly, in ways that look like “just normal delivery friction” until you add it up.

• Delivery: every change waits for the hub team. Even small tweaks carry a coordination tax: extra ceremonies, extra handovers, extra testing across journeys that don’t belong together. Your best engineers spend time negotiating the queue instead of shipping outcomes.

• Reliability: the blast radius grows. One bad deploy, one misconfigured retry policy, one schema tweak, and suddenly multiple flows across unrelated domains degrade at once. Incidents become harder to isolate because the hub sits in the middle of everything.

• Security and compliance: the hub becomes a privilege magnet. It needs secrets, tokens, elevated network access, and broad permissions “because it integrates with everything”. That’s exactly how you end up with a single component that’s both operationally critical and over-privileged.

• Architecture drift: business rules leak into integration glue. The hub starts deciding things domains should own, and your domain boundaries get fuzzy. Over time, the real system behaviour lives in flows and mappings, not in the services that should be accountable.

A quick smell test

Ask two questions:

• Can a domain ship value without changing the hub?

• Do we have more than one way to integrate, and do we know why?

Root causes in plain English

This anti-pattern isn’t a tooling problem. It’s what happens when a few small decisions stack up and nobody draws a boundary early.

First, integration concerns get mixed with product decisions. Instead of domains owning what their data means and how it should change, the hub starts making those calls in mappings and flows. Second, “reuse” gets pushed too far. Someone introduces a mega canonical model to “standardise everything”, and now every team must contort their reality to fit one schema. That’s not reuse; that’s a shared constraint you’ll pay for forever.

Third, there’s no product thinking. The hub has users (engineering teams), but it rarely has a clear service promise, a catalogue of what it offers, or a roadmap that’s aligned with business priorities. Finally, a governance gap seals the deal: there are no lightweight rules that stop the hub from swallowing the next use case.

That’s the Swiss Army knife in a sentence: one interface trying to serve every use case and becoming worse for all of them.

The fix: split the problem into lanes

The way out is to stop arguing about “the right tool” and start agreeing on lanes. Each lane has a job, a boundary, and a failure mode you actively avoid. When you split the problem this way, you get a clean target state: teams can choose the right pattern for the job, ship independently, and you stop feeding the Octopus.

Lane 1: API gateway is for policy and proxy

Use the gateway for traffic management, not business logic:

• AuthN/AuthZ, rate limits, WAF, routing, versioning, observability hooks

• Avoid turning it into a “brain”. If the gateway is doing payload mapping, workflow branching, or domain decisions, it’s no longer a gateway; it’s a brittle integration service with a shiny badge.

Lane 2: Integration runtime is for bounded orchestration

This is where connectors and workflow steps belong:

• Transformations, protocol translation, retries, and multi-step orchestration

• The key rule: orchestration must have an owner and a domain boundary. If it’s “enterprise-wide glue”, you’re rebuilding the same anti-pattern with a different logo.

Lane 3: Event broker is for decoupling and fan-out

Use events to publish facts and let teams subscribe by need:

• Publish “what happened”, not “how to do the job”

• Keep event contracts lean and versioned, avoid fat events that try to carry the whole world. And be honest: event-driven isn’t magic. It needs discipline around contracts, idempotency, and observability.

Lane 4: Data pipelines are for analytics, not operational flow

Keep reporting and backfills in data plumbing, not runtime integration. Separate them so operational reliability and analytics flexibility don’t sabotage each other.

A practical 30/60/90-day plan to unwind the hub

You don’t fix a Swiss Army knife hub by “rewriting integration”. You fix it by stopping the bleeding, then moving work out in small, safe cuts. The goal in 90 days isn’t perfection, it’s momentum, lower risk, and a clear path where teams can ship without asking permission.

Days 0–30: Stabilise and put fences up

Start with a simple rule: no new “just add it to the hub” work unless it passes the decision matrix. That one move reduces future debt straight away. Next, make the hub visible. Pick the critical flows (the ones that wake people up at 2 am) and create one dashboard per flow. Add basic SLOs so you can say what “good” looks like. Then improve change safety: introduce contract tests for the top integrations and agree on a basic rollback plan. If you can’t roll back quickly, you’ll never move fast safely.

Days 31–60: Split by ownership, not by technology

Identify the top five flows by business criticality and map who should own the behaviour. Then carve out thin adapters at the edge and move domain rules back into the services that own the outcomes. This is the big mindset shift: you’re not “modernising integration”, you’re restoring accountability. Introduce a lightweight integration catalogue: what exists, who owns it, how changes happen, and where the contracts live.

Days 61–90: Migrate, retire, and measure

Replace one end-to-end workflow with either events or bounded orchestration, then retire what it replaced. Decommission at least one hub capability, a connector, a mega mapping, or a reporting job. Finally, track the metrics that prove it’s working: lead time, incident rate, blast radius, and deployment frequency.

Governance that prevents the next Swiss Army knife

Governance only works if it’s light enough to survive contact with delivery. You don’t need a committee for every integration; you need a few clear rules that make the right choice the easy choice.

Start with a one-page integration decision record. It should capture two things: why this pattern (API, runtime, events, or data pipeline) and who owns it end-to-end. No owner, no build. Next, publish simple guardrails: the gateway does policy and proxy, the integration runtime does bounded orchestration, and events are for fan-out. Make these rules visible and repeat them until they become habit.

Then lock in a practical definition of done: contracts are versioned, observability exists at the flow level, and ownership is explicit (including who’s on the hook when it breaks). Finally, use AI where it helps: let it draft mappings, generate contract tests, and propose runbooks, but keep human approval in the loop. That gives you speed without handing control to the tool or the hub.

“The Octopus” wasn’t evil. It was overloaded to be a gateway, an orchestrator, a translator, a rules engine, and a support console all at once. Once you see that, the fix becomes clear: this is less about swapping tools and more about restoring ownership and boundaries so teams can ship safely without a central choke point.

If you want more run-it-on-Monday architecture and governance playbooks (no fluff), subscribe to my newsletter.

If you’re a CIO choosing centralised data clean-up vs distributed data ownership, use the matrix below.

Bad data doesn’t fail loudly. It quietly rewrites decisions.

Most teams only notice when the numbers don’t match in an exec meeting or when a customer asks the awkward question first.

In 7 minutes you’ll have a way to diagnose, contain, and prevent it.

The CIO matrix: “Clean-up squad” vs “Quality by design”

Most leaders don’t choose between these because they love one approach. They choose because something has already gone wrong: a board pack number is challenged, a revenue metric shifts overnight, or three dashboards tell three stories.

This matrix is a quick way to decide what you need first: a fast containment move, or a structural fix that stops repeat outbreaks.

Now the honest bit: most enterprises need both. Option A is what you do when the house is already smoky. It buys you time and restores confidence. Option B is what stops the next fire by making quality part of normal delivery, not an after-hours rescue mission. A contains today’s outbreak. B is the vaccine.

10-point “Bad Data Virus” early warning checklist

If you want the fastest diagnosis, don’t start with tooling. Start with behaviour. When a bad data virus is spreading, you’ll see it in how people act before you see it in logs.

Read this like a quick health check. If you’re nodding along to three or more, you’re not dealing with a one-off defect — you’re dealing with a pattern.

• Same metric, three dashboards, three answers (and everyone has a “reason”)

• Teams can’t name the source of truth, only the dashboard they prefer

• Manual CSV “fixes” happen right before every exec meeting

• No shared definitions for key fields (customer, active, churn)

• Pipelines succeed, but the numbers are wrong, green jobs, red outcomes

• Schema changes ship without notice, and downstream teams find out the hard way

• Data quality checks exist, but nobody watches alerts (or alerts are ignored noise)

• Ownership is unclear (producer vs consumer blame cycle)

• AI/ML outputs drift and nobody can trace which inputs changed

• The data team is stuck doing ad-hoc reconciliations instead of building capability

If this feels familiar, good news: you don’t need a miracle platform. You need a clean decision on containment vs prevention and then a simple operating model that makes quality repeatable.

What the “Bad Data Virus” anti-pattern looks like

The pattern in one sentence

Bad data enters quietly, gets copied everywhere, and becomes “truth” through repetition.

Why “virus” is the right metaphor

It rarely arrives as a big, obvious failure. It slips in as a missing field, a duplicated record, a “temporary” mapping, or a late change to a definition. Then it multiplies. ETL jobs pick it up, extracts ship it to other teams, reverse ETL pushes it back into operational tools, and downstream marts bake it into KPIs. Before long, it’s in spreadsheets, board decks, and AI features — and unwinding it becomes harder than building it correctly in the first place.

The cost isn’t just wrong numbers

The real damage is behavioural. Decision latency creeps in: teams hesitate, double-check, and delay because they stop trusting what they see. Then governance overhead follows: more meetings, more approvals, more “alignment”, and less delivery.

A useful anchor: data quality is simply fitness for use.

How bad data spreads in modern architectures

Three common transmission paths

Bad data doesn’t need a fancy failure mode. It spreads through normal delivery work, especially when speed wins, and nobody owns the “downstream blast radius”.

Path 1: Operational systems → analytics.

Source systems aren’t built for clean reporting. Capture rules vary by team, fields get reused for new meanings, and updates arrive late. Add duplicate keys, merges, and backfills, and you get dashboards that look stable until they suddenly aren’t.

Path 2: “Helpful” transformations.

This is where good intentions turn into long-term pain. Someone patches a logic gap in a pipeline: a mapping table, a filter, a “quick fix” to match finance numbers. If that logic isn’t documented and tested, it becomes invisible business policy, and it quietly diverges from what the business thinks is happening.

Path 3: Self-serve scale.

Self-serve analytics is great, until it isn’t. More consumers means more extracts, more copies, and more versions of “truth”. Two teams can start from the same dataset and still ship conflicting definitions of the same metric.

The silent killer: breaking changes

Schema drift and incompatible changes break consumers even when pipelines are “green”. The jobs run. The tables load. The numbers are just wrong, or worse, wrong in a way that looks plausible.

Root causes CIOs should look for

Ownership gaps

The most common root cause is also the least technical: nobody can clearly say who owns quality for a dataset that matters. “The data team owns quality” sounds tidy, but it becomes a loophole. Producers change fields, tweak definitions, or ship new logic to hit delivery dates. Consumers then discover the impact days later, usually when a KPI shifts and someone starts asking for screenshots. The blast radius lands downstream, and everyone argues about whose job it is to fix it.

No contracts, no tests, no alarms

When there’s no contract, expectations live in people’s heads: what a field means, what “complete” looks like, how fresh the data should be. That’s tribal knowledge, not an engineering system. Without tests, regressions slip through even the boring ones like not-null, uniqueness, and referential integrity. And without observability, you don’t find out early. You find out in the exec meeting, with a graph on screen and zero time to explain it.

Misaligned incentives

Most organisations reward feature shipping. Data correctness is treated as “maintenance” until it becomes a crisis. When incentives don’t match the risk, bad data becomes predictable.

The fix in three moves: contain, treat, vaccinate

1) Contain the outbreak (what to do this month)

When trust is already wobbling, your first job is to stop the spread. Pick the KPI that’s causing the most noise (usually revenue, active customers, churn, or risk exposure) and quarantine the metric. Name one “official” dataset for that KPI and freeze definition changes for a short window. You’re not trying to solve all data quality this month you’re buying stability so people can make decisions again.

Next, create a lightweight data incident loop. Keep it simple: P0 for exec metrics and board reporting, P1 for customer impact, P2 for internal issues. Use one channel and one comms owner, so updates aren’t scattered across Slack threads, email chains, and meetings. If you can’t say who owns comms, you don’t have an incident process; you have chaos with a spreadsheet.

Finally, stop the worst replication. The fastest way bad data becomes permanent is through uncontrolled extracts and “shadow marts” that nobody admits owning. For critical domains, temporarily block or gate ad-hoc exports and duplicate marts until the official source is stable.

2) Treat the source (what to do this quarter)

Containment is triage. Treatment is where you remove the root cause. Start by defining “fitness for use” for each critical dataset in plain language. Don’t overthink it, just be explicit about the basics: accuracy, completeness, timeliness, uniqueness, and consistency.

Then implement automated checks where the data lives, not three layers downstream. Begin with high-signal tests that catch real breakages early: not-null, uniqueness, accepted values, and relationship tests (think referential integrity between key tables). Add richer rules only when you need them, using a validation framework like Great Expectations, especially for complex expectations or anomaly-style checks.

Make quality visible. Track it like a product metric, not a one-off project. A weekly scorecard for the top 10 datasets visible to both producers and consumers changes behaviour fast. When teams see quality trends, they stop treating data issues as “random” and start treating them as engineering.

3) Vaccinate with “quality by design” (what to do over 6–12 months)

Now you prevent recurrence. For critical data products, introduce data contracts and treat them like APIs for data: schema, constraints, freshness expectations, and change rules. This is how you stop “surprise” from becoming normal.

Back it with schema evolution discipline. Backwards compatible changes by default. Breaking changes require explicit versioning and a migration plan. No exceptions for “it’s just analytics”.

Add data observability so you learn early: monitor freshness, volume, distribution shifts, lineage, and failures. If the first time you notice a problem is the monthly exec pack, you’re running blind.

Finally, build governance teams can live with: federated guardrails, not a central bottleneck. Set minimum controls and clear decision rights, then let teams move fast inside the rails.

A practical operating model (so this doesn’t become theatre)

Decision rights (keep it crisp)

Most data programs fail for the same reason: everyone agrees quality matters, then nobody has the pen when a trade-off shows up. The fix is boring, clear decision rights.

• Data Producer owns correctness at the source. They control schema changes and they’re accountable for contract compliance when they publish data.

• Data Product Owner owns definitions, SLAs, and consumer outcomes. They decide what “active customer” means and what “good enough” looks like for freshness and completeness.

• Platform Team provides the paved road: tooling, pipelines, observability, templates, and patterns that make the right thing the easy thing.

• Governance sets minimum controls and arbitrates red lines (the small number of issues where risk or compliance means you can’t “just ship it”).

Two rules that stop 80% of pain

• No breaking changes without a version and a migration plan.

• No tier 1 KPI without tests and a clear alerting path (who gets paged, and what “action” looks like).

30/60/90-day plan (actionable, not heroic)

Days 0–30: Pick three exec KPIs and declare a single source of truth for each. Write the definition in plain English and publish it where teams actually look. Add basic tests (not-null, uniqueness, accepted values) and route alerts to one channel with a named owner, so issues don’t die in silence.

Days 31–60: Publish data contracts for those KPIs: schema, constraints, freshness targets, and change rules. Put a schema change workflow in place (review + versioning) so breaking changes can’t sneak in as “just a small tweak”.

Days 61–90: Expand the approach to the top 10 datasets that drive decisions. Start measuring reliability like an engineering outcome: incidents per month, MTTR, and a simple “trust score” your execs can understand.

Closing

Bad data isn’t a tooling problem first. It’s an ownership and change-management problem that tools can enforce. Containment buys you time. Contracts and tests buy you trust, and trust is what lets teams move fast without weekly reconciliation theatre.

If you want more run-it-on-Monday architecture and governance playbooks, subscribe to the newsletter.

If you’re a CIO choosing between ‘the architecture review board as the gate’ and ‘empowered teams with guardrails’, use the matrix above and pick your default. If decisions keep bouncing between recurring meetings, and every stakeholder feels like they get a vote, you’re living the design-by-committee anti-pattern. The good news is you don’t need a dictatorship to fix it. You need clear decision rights, a fast path for input, and a simple way to record the call so you stop re-arguing the same topics next quarter.

What “design by committee” looks like in real architecture work

You don’t usually see it written on a Jira ticket. You feel it. The calendar fills up, the same diagram gets re-litigated, and the “decision” turns into a series of polite compromises that nobody’s proud to own. If you’ve ever left a meeting thinking “Wait… did we actually decide anything?” this is what you’re dealing with.

The symptoms (you can almost hear them)

• Every decision needs “one more meeting”

  There’s always another stakeholder to “bring along”, another review to “sanity check”, another forum to “socialise the approach”.

• Architecture turns into negotiation, not trade-offs

  Instead of cost, risk, operability, and time-to-value, you’re bartering preferences: “If we add your requirement, can we keep mine?”

• Solutions grow features to satisfy everyone, then satisfy no one

  You end up with the “camel” solution: heavy, awkward, and expensive to run. It technically includes everyone’s request, yet it misses the actual goal.

• People leave meetings unclear on who decided what

  There’s a vague sense of alignment, but no decision owner, no decision record, and no next step that anyone can quote later.

• The system gets complex, inconsistent, and hard to operate

  More moving parts, more exceptions, more bespoke integrations. The on-call experience gets worse, and delivery slows because every change has hidden dependencies.

Why it happens (good intent, bad mechanics)

Most teams don’t choose this on purpose. It’s usually a well-meaning response to pressure.

• Leaders want alignment and risk reduction

  When the blast radius is high (security, compliance, shared platforms), leaders understandably want visibility and confidence.

• Decision rights are unclear, so consensus becomes the fallback

  If nobody can point to a decision owner, the group defaults to agreement-by-exhaustion. It feels safe, but it’s slow, and it avoids accountability.

• The architecture review board (ARB) becomes the place where work goes to slow down

  Instead of a focused escalation path for “red line” decisions, the ARB becomes a queue. Teams start designing for approval, not for outcomes.

The hidden cost: speed, coherence, and accountability

Design by committee feels polite. Everyone gets heard, risk feels “managed”, and nobody walks out upset. Then the bill arrives in delivery time, system quality, and ownership. You don’t notice it in a single sprint. You notice it when the same decisions resurface, the platform drifts, and teams stop taking initiative because initiative gets punished with meetings.

Speed tax

• Lead time balloons because feedback is serial, not parallel

  One review triggers another review, which triggers another stakeholder request. Each loop adds days, sometimes weeks, and none of it shows up cleanly on your delivery dashboard.

• Teams wait for permission instead of shipping evidence

  When the default is “get everyone to agree first”, teams stop running small experiments. They stop bringing options with data. They bring slide decks and hope for a blessing. That’s how architecture governance turns into a queue instead of a capability.

Coherence tax

• “Camel architecture”: stitched compromises, no unifying direction

  You end up with a solution built from negotiated pieces rather than a clear set of trade-offs. The result usually has extra components, inconsistent patterns, and awkward seams. It works… until it has to scale, or be operated at 2am, or be secured properly.

Accountability tax

• When everyone is involved, no one owns the outcome

  A group can create a decision, but it can’t carry responsibility the way a named decision owner can. When the outcome is messy, you get finger-pointing or silence — neither helps the next decision.

• Decisions are hard to revisit because the reasoning was never captured

  Without an Architecture Decision Record (ADR) or similar, you can’t tell whether you’re reversing a bad call or repeating a good one in a new context. So you re-run the debate from scratch, with a slightly different cast, and call it “alignment”.

The fix in one sentence

Separate input from authority, then record the decision so you can move fast without losing control.

Here’s what that looks like in practice: you still invite strong input from security, platforms, data, finance, and delivery, but you don’t pretend it’s a vote. You name a decision owner, timebox the consultation, make the call, and capture the “why” in an Architecture Decision Record (ADR). That’s lightweight governance: fewer meetings, clearer decision rights, and far less déjà vu the next time the topic comes up.

Step-by-step playbook to kill design by committee (without killing collaboration)

You don’t fix this by telling people to “be decisive”. You fix it by changing the operating system: decision types, decision rights, and a simple record of what got decided. Here’s a playbook you can roll out in a week, then tighten over the next month.

1) Define decision types and the escalation line

Start by sorting decisions into three buckets. This stops the ARB (or “governance”) being dragged into everything.

• Team decisions: local, reversible, low blast radius

  Examples: library choice for a service, minor refactors, feature flags, internal API shaping.

• Platform decisions: shared, hard to reverse, multi-team impact

  Examples: standard logging pattern, event contracts, shared CI/CD approach, platform authentication method.

• Enterprise “red line” decisions: security, regulatory, major spend

  Examples: anything touching regulated data, material vendor lock-in, new payment rails, material cost commitments.

One rule that changes everything: if it’s a red line decision, it gets a timeboxed review. Everything else stays with the team. No exceptions “because someone’s curious”.

2) Assign decision rights using DACI or RAPID (pick one)

If you want to stop consensus-by-default, you need a decision model people can remember on a busy Tuesday.

• Use DACI when you want a simple model that most teams can apply without training wheels.

  (Driver, Approver, Contributors, Informed.)

• Use RAPID when decisions span layers and you need clarity on who recommends versus who decides.

  (Recommend, Agree, Perform, Input, Decide.)

Quick callout: RACI often fails for decisions because it’s task-flavoured. It tells you who’s “responsible” for work, not who has the authority to decide when opinions clash.

3) Install a single “decision owner” per decision

This is the moment everything speeds up.

• One person is accountable for the call

  Name them. Put it on the doc. If you can’t name them, you’ve found the real problem.

• Many people can be consulted

  Consultation is encouraged. Chaos isn’t.

• Input is a gift, not a vote

  People should feel heard. They shouldn’t feel entitled to a veto.

A practical line to use: “We’ll take input widely, then the decision owner will make the call and record it.”

4) Use a one-page pre-read so meetings become decisions

Most architecture meetings fail before they start: no pre-read, no options, no trade-offs, no decision needed. Fix that and half your committee problem disappears.

One-page pre-read template

• Context and constraints (what’s true, what’s non-negotiable)

• Options (2–3 max, if you bring 7, you’re not ready)

• Trade-offs (cost, risk, time, operability)

• Recommendation and “what would change my mind?”

• Decision needed today (yes/no plus the selected option)

If the pre-read isn’t ready, don’t hold the meeting. You’re just creating calendar noise.

5) Record the decision with ADRs (lightweight, searchable)

This is how you stop re-arguing decisions every quarter.

• Store ADRs with the code or in a shared repo

  Somewhere searchable, versioned, and easy to link.

• Keep them short: context, decision, consequences

  You’re writing a memory aid, not a novel.

• Link ADRs to principles and standards when relevant

  That way the decision isn’t floating on vibes; it’s connected to the operating model.

The win here is cultural: teams learn that decisions are made once, recorded, and revisited only when assumptions change.

6) Turn the ARB into a service, not a gate

An ARB can be useful. The problem is when it becomes the choke point.

• Office hours for early advice

  Bring rough ideas early and get directional feedback before it becomes a political document.

• Async review with a 48-hour SLA for red line items

  Give teams a predictable path. Timebox the feedback. Move on.

• Publish “approved patterns”

  If you keep re-reviewing the same choices (logging, auth, secrets, networking), publish the patterns and let teams reuse them without re-litigating.

Net result: better architecture governance, less theatre, and teams that can actually deliver.

A simple checklist you can copy

Paste this into your project space and use it at the start of any architecture discussion. It’s a quick way to spot when a healthy consult is turning into committee mode.

“Are we drifting into committee mode?”

• Do we know who decides (a name, not a group)?

• Is the decision reversible? If yes, why is it stuck?

• Are we debating preferences instead of constraints (security, cost, time, operability)?

• Are we missing architecturally significant requirements (security, latency, audit, availability, data retention)?

• Did we timebox consultation (who gets input, by when)?

• Will we publish an ADR within 24 hours of the decision (context, decision, consequences)?

What to say in the room

You don’t need to “win” the meeting. You just need to steer it back to a decision. These lines keep things respectful while still moving forward.

When the meeting starts to spiral

• “Let’s separate concerns from decisions. What input do we still need, and who’s deciding today?”

• “If we can’t name the decision owner, that’s the real problem.”

• “Quick reset: are we here to explore options, or to decide one?”

When someone wants a vote

• “Happy to take your input. We’re not voting, we’re trading off.”

• “Let’s capture your concern as a constraint. Then the decision owner can weigh it with the others.”

• “If this is a veto, say it plainly; otherwise, it’s input.”

When someone raises risk late

• “Great catch. Is this a red line risk? If yes, we escalate. If no, we document and proceed.”

• “What would need to be true for this risk to be acceptable?”

• “Let’s record it in the ADR with a mitigation and an owner, so it doesn’t vanish after this call.”

Closing: your operating model in 3 bullets

• Clear decision rights (DACI or RAPID), with named decision owners

• Lightweight governance (ARB for red lines only, timeboxed so delivery keeps moving)

• ADRs as memory (so you don’t re-litigate the past every quarter)

If you want more patterns like this, follow and subscribe to the newsletter. I share practical architecture operating models you can run on Monday morning.

A team I worked with did everything “right” on paper. We had a clear business goal, a tight deadline, and a talented group of engineers who could ship fast. And we did. The first release landed quickly, stakeholders were happy, and the roadmap looked achievable.

Then the second phase arrived.

Suddenly, every sprint started with a long meeting about “the right” database. Then another about messaging. Then another about observability tools. Decisions dragged because too many people needed to agree, but nobody owned the final call. To buy time, we ran more spikes. To reduce risk, we added more tools. To “future-proof” analytics, we copied more data into more places.

A few months later, the delivery pace slowed to a crawl. The architecture wasn’t broken because the team lacked skill. It broke because a handful of well-meant choices multiplied across the enterprise: decision-making drifted, data spread without ownership, integration layers became overloaded, and tooling started running the teams instead of supporting them.

In this article, you’ll learn four enterprise architecture anti-patterns, how to spot them early using simple signals and metrics, and the practical steps to fix them before they become expensive habits.

What is an anti-pattern in enterprise architecture?

Enterprise architecture is full of “best practice” advice. The catch is that the same idea can be brilliant in one context and painful in another. That’s where patterns and anti-patterns matter.

Patterns vs anti-patterns (plain-English definitions)

• Pattern: a repeatable approach that solves a known problem in a specific context. It has trade-offs, but the benefits are worth it when the conditions fit.

• Anti-pattern: something that looks smart at the start, often because it feels efficient or “safe”, but it creates recurring pain once the organisation scales.

• Quick tell: if teams keep saying “we’ll fix it later”, you’re probably already in anti-pattern territory. “Later” becomes the roadmap, and the architecture starts accruing interest.

A useful mindset shift is this: an anti-pattern is rarely stupidity. It’s usually speed, fear, or unclear ownership showing up as “design”.

A grounded definition of “architecture”

To keep this practical (and avoid word games), anchor on a simple, standards-based view:

Architecture describes the fundamental elements of a system, the relationships between those elements, the environment in which the system operates, and the guiding principles that shape how the system is designed and how it evolves over time.

That last part matters. Architecture is not just a diagram of what exists today. It’s also the set of rules that decide how change happens tomorrow. When those rules are missing or messy, anti-patterns spread fast.

The four layers where EA anti-patterns show up

Enterprise architecture anti-patterns don’t appear in one place. They spread across layers, and each layer has its own style of failure. If you only look at apps, you’ll miss the business decision problem. If you only look at tooling, you’ll miss the data lifecycle problem.

A simple lens: Business, Data, Application, Technology

• Business: decision-making, priorities, operating model

  This is where anti-patterns show up as slow decisions, unclear ownership, competing agendas, and “everyone approves, nobody owns”.

• Data: quality, retention, governance, value

  This is where anti-patterns look like uncontrolled replication, mystery datasets, poor classification, and growing risk wrapped in “just in case”.

• Application: service boundaries, integration, coupling

  This is where anti-patterns appear as messy service responsibilities, overloaded integration layers, brittle dependencies, and change that breaks unrelated teams.

• Technology: platform, tooling, operational practices

  This is where anti-patterns show up as tool sprawl, inconsistent environments, fragile automation, and operational effort that keeps rising even when “everything is automated”.

Same enterprise, different layer, different failure mode.

Anti-pattern 1: Design by committee

“Design by committee” usually starts with good intent: get the right people in the room, reduce risk, and avoid bad calls. The problem is what happens next. Decision-making turns into a recurring meeting series, and architecture becomes a negotiation instead of a discipline.

What it looks like in real teams

• Endless architecture meetings that end with “let’s do another spike”

• No clear decision owner

• Everyone can block, nobody can close

You’ll often see a team shipping early, then stalling as complexity rises. The meeting load goes up while delivery slows down.

Early warning signs

• Too many decision-makers in one room

• Repeated debates on storage, messaging, frameworks

• Increasing tech debt and refactoring churn

• Delivery dates slip because decisions arrive late

A classic symptom is “decision drift”: the team starts coding without a decision, then later discovers a half-written guideline somewhere and tries to retrofit it.

Metrics you can track (even without fancy tooling)

You don’t need a big governance platform to spot this. Track a few simple indicators:

• Number of architecture meetings per decision

• Time from “decision needed” to “decision published”

• Count of spikes raised due to decision ambiguity

• Rework rate: stories reopened due to architectural changes

If those numbers trend up together, you’re paying a “decision tax” every sprint.

Fix: a lightweight decision system, not a heavyweight committee

The goal isn’t less collaboration. It’s clearer ownership and faster closure.

• Define decision roles

  One accountable owner for the decision, plus a small review group. Keep the decision-making circle tight; widen the feedback circle instead.

• Standardise decisions with ADRs and a simple lifecycle

  Use a consistent format and statuses such as proposed, accepted, superseded, rejected. The point is clarity: what we decided, why, what we didn’t choose, and when it changes.

• Set a “decision SLA” for common choices

  Example: “Most decisions close within 5 working days.” If it can’t close, force the next question: what information is missing and who owns getting it?

• Publish a small set of viewpoints and tools

  Pick the minimum that keeps teams aligned (for example C4/UML, draw.io/PlantUML, and one shared repository for diagrams and ADRs). Consistency beats perfection.

Two “hidden traps” to call out (quick and human)

• Ivory tower architect: decisions appear, but nobody can ask questions. The team learns by guessing, and gaps turn into rework.

• Architect plays golf: the architect leaves, and the team inherits a design they can’t evolve. The architecture becomes a relic, not a living guide.

Design by committee is a process smell. Fix the decision system, and the architecture starts behaving like a product again: owned, iterated, and measurable.

Anti-pattern 2: Bad data virus

Bad data rarely arrives with a bang. It spreads quietly. One “temporary” dataset becomes a permanent table. One export becomes a pipeline. One replica becomes a lake. Then suddenly you’re paying for data nobody trusts, nobody owns, and nobody can confidently delete.

What it looks like

• Old, unused data gets replicated into new systems (replicas, lakes, analytics, AI)

• Nobody can explain why certain datasets exist

• Storage and risk grow together

The giveaway is when the enterprise keeps copying the same uncertainty into new platforms. The data looks more “modern”, but the confusion stays.

Why it happens

• Fear of deleting data

• Weak classification and ownership

• Retention handled as an afterthought

Most teams don’t choose this deliberately. They’re trying to stay safe, keep options open, and avoid being blamed for deleting “something important”. Over time, “safe” becomes expensive.

Early warning signs

• Low usage datasets with high storage cost

• Unclear sensitivity classification

• “We might need it later” becomes the default policy

If your data discussions are mostly about where to store it, not why it exists and who uses it, you’re already slipping.

Metrics to watch

You can make this measurable without turning it into a massive governance program:

• Data access frequency (reads/writes per dataset)

• Age distribution of data (how much is stale)

• Percentage classified vs unclassified

• Audit findings tied to data governance gaps

A simple starting point: rank your top datasets by cost, then overlay usage. The scary ones rise to the top fast.

Fix: treat data like a product with a lifecycle

The cure is less about new platforms and more about basic hygiene and accountability.

• Run a data assessment (what exists, who owns it, who uses it)

  Build a lightweight inventory: dataset name, owner, purpose, consumers, retention rule, and sensitivity level.

• Classify data and align retention policies

  Classify by value and risk, then set retention based on actual need (not fear). If you can’t explain the purpose, it’s not ready to spread.

• Introduce deletion and archiving automation

  Manual deletion rarely happens. Automate it with clear approvals, logging, and safety rails (archive first, delete after a defined window).

• Tie dark data reduction to security outcomes

  Less unknown data means fewer places sensitive information can hide, leak, or get copied into tools that were never designed to protect it. Smaller attack surface, cleaner audits, and less time arguing about what’s safe to share.

Bad data virus is the anti-pattern where “just in case” becomes the default architecture. Fix it by making data ownership, lifecycle, and retention normal operational work, like patching or access reviews.

Anti-pattern 3: Swiss Army knife integration

This one is sneaky because it often starts as a rescue mission. Teams move to event-driven patterns to reduce tight coupling, then the integration layer slowly becomes the place where “everything gets solved”. Over time, the broker turns into a Swiss Army knife: handy, overloaded, and impossible to hand to someone new without cutting yourself.

What it looks like in 2025 systems

• The message broker or integration layer starts doing everything: routing, transforms, auth logic, orchestration, even business rules

• A small “core team” becomes a bottleneck because only they understand the glue

It’s the modern version of the old “mega-database with magic stored procedures”. Different tool, same problem: logic hidden in a place that’s hard to test, hard to version, and hard to reason about.

Symptoms you’ll hear out loud

• “We can’t change that, it might break other flows”

• “It’s all in the broker rules”

• “We need the one person who built it”

When those phrases show up, your integration layer has stopped being plumbing and started being a shadow application.

Metrics that reveal it

• Growth in message types and transformations

• Incidents tied to broker changes

• Mean time to recover when messaging breaks

• Percentage of business rules living outside services

A practical check: if a broker change needs the same level of analysis and testing as a service release, you’ve turned the broker into a product without admitting it.

Fix: move intelligence to services, keep pipes simple

The goal isn’t “no integration logic”. The goal is to keep the broker focused on transport and coordination, while services own the domain rules.

• Reduce transformation logic in the broker

  Minimise mapping scripts and embedded decision trees. If transformations must exist, make them simple, visible, and versioned like code.

• Standardise contracts and versioning

  Define event/message schemas, version them explicitly, and treat compatibility as a first-class concern.

• Push business rules back into domain services (“smart endpoints”)

  Keep decision-making close to the domain. Services should validate, decide, and act. The integration layer should pass messages, not “think”.

• Add tracing and clear observability for message flows

  Make every hop visible: correlation IDs, distributed tracing, and meaningful metrics (latency, failures, retries). If you can’t see the flow end-to-end, you can’t manage the risk.

Swiss Army knife integration feels efficient until the day you need to change it quickly. Then it becomes a single point of confusion, delay, and fragility. Keep pipes simple, and your teams get their autonomy back.

Anti-pattern 4: Operational over-tooling

Tools are meant to remove friction. Operational over-tooling does the opposite: it adds layers of dashboards, scanners, pipelines, and platforms until teams spend more time managing the toolchain than improving the product. The result is a noisy, expensive system that still wakes people up at 2am.

What it looks like

• Tool sprawl: overlapping CI/CD, logging, monitoring, security scanners, dashboards

• Teams spend more time operating tools than shipping outcomes

• Automation exists, but the on-call pain stays

A clear sign is when “keeping the platform running” becomes a bigger job than building the thing the platform exists to support.

Common causes

• Tool adoption driven by trends or CV-building

• “DevOps equals automation” thinking

• No exit plan once a tool is in

A lot of over-tooling is fear in disguise: fear of manual work, fear of incidents, fear of being seen as behind. So the response is “add another tool”.

Metrics to track

• Tool count per category (CI, observability, security, IaC)

• Feature usage rate (how much of the tool you actually use)

• Integration effort per tool (time to onboard, maintain, upgrade)

• Training/support load per quarter

If the tool count rises while incident rates and lead time don’t improve, you’re buying complexity, not reliability.

Fix: governance that helps teams move faster

This isn’t about banning tools. It’s about making tool decisions deliberate, visible, and reversible.

• Run a tooling audit and create a simple inventory

  List the tools, licences, owners, purpose, cost, and which teams rely on them. You can’t fix sprawl if nobody can see it.

• Set tool adoption criteria

  For every new tool: define the problem, compare options, write a decision record, run a trial, and set a rollout plan (including success measures).

• Standardise where it pays off, allow exceptions with an ADR

  Standardisation reduces cognitive load and onboarding time. Exceptions are fine, but they should be explicit and justified so they don’t quietly become the new default.

• Use Well-Architected style anti-pattern checks as a review prompt

  Treat reviews as a way to catch operational smells early: duplicated tooling, noisy alerting, brittle pipelines, and automation that creates work instead of removing it.

Operational over-tooling is the moment your tooling becomes the product. The fix is simple governance that keeps choice intentional and keeps teams focused on outcomes, not operating a maze.

A practical cadence to prevent anti-patterns (without slowing delivery)

Most anti-patterns don’t arrive as a single bad decision. They grow when teams are busy, deadlines are real, and “we’ll clean it up later” feels like the only way to move. The fix isn’t heavier governance. It’s a repeatable cadence that keeps decisions small, visible, and testable.

A six-step loop your teams can repeat

Think of this as an architecture “heartbeat” you can run every iteration or every PI, depending on your scale:

• Gather stakeholder inputs

  Short, purposeful conversations: product, delivery, ops, security, data, and the teams building the work. Capture what success looks like and what pain must be avoided.

• Identify ASRs, constraints, risks, assumptions

  Make the hidden stuff explicit. What must be true for this to work? What can’t change? What are we betting on? What could hurt customers or delivery?

• Choose principles and tactics

  Agree on a few guiding rules (security-by-design, minimise coupling, prefer managed services, etc.) and the tactics that support them.

• Compare options, make trade-offs, publish ADRs

  Don’t debate forever. Compare a small set of options, state the trade-offs, and publish the decision so teams can move with confidence.

• Create the few diagrams people will read

  Resist the urge to document everything. Create the minimum set that helps teams build, operate, and change safely.

• Build a delivery roadmap, then iterate

  Translate architecture into delivery slices: sequencing, dependencies, risks, and checkpoints. Then revisit as reality changes (because it will).

This loop keeps architecture close to delivery. It also makes anti-patterns easier to spot early, because you’re repeatedly surfacing decisions, ownership, and trade-offs.

“Fitness functions” as your guardrails

Fitness functions are simple measurable checks that protect the architecture over time. They reduce arguments because the system tells you when you’re drifting.

Keep the list short and tied to outcomes, for example:

• Latency (end-to-end response time targets)

• Cost (unit cost per transaction or per customer)

• Recovery time (RTO/RPO, or time-to-restore for key services)

• Security events (unauthorised access attempts, critical vulnerabilities, failed controls)

• Data retention compliance (datasets with owners, classification, and enforced retention)

If a change improves features but fails the fitness functions, it’s a signal to pause, adjust, and avoid baking in the next anti-pattern.

Simple checklist you can run this week

Anti-patterns rarely start as disasters. They start as shortcuts that quietly become habits. The earlier you notice them, the cheaper they are to fix.

Here’s a quick recap of the four anti-patterns we covered:

• Design by committee: decisions stall, spikes multiply, and delivery slows because nobody owns the call.

• Bad data virus: unused data spreads into replicas, lakes, analytics, and AI, while cost and risk climb together.

• Swiss Army knife integration: the broker/integration layer absorbs routing, transforms, and business rules until one team becomes the bottleneck.

• Operational over-tooling: tool sprawl grows, cognitive load rises, and on-call pain stays even when “everything is automated”.

If you want a practical next step, run this mini-checklist in your next architecture sync:

• Do we have a clear decision owner for each major choice?

• Are we capturing decisions in a consistent way (even a lightweight ADR)?

• Which datasets exist “just in case”, and who owns them?

• Is our integration layer doing transport, or is it doing business logic?

• Which tools do we pay for but barely use, and what problem are they meant to solve?

If you comment your context (team size, delivery model, and where you’re feeling the most pain), I’ll suggest the top two anti-patterns to tackle first and a small, realistic plan to unwind them without slowing delivery.

Part 1, Part 2, Part 3, Part 4

Chapter 6: Final Review & Integrative Challenge

By now, you’ve explored the what, why, and how of PCI DSS from understanding its origins and scope, to learning how every architect, developer, tester, and project manager contributes to compliance.
But understanding the standard isn’t the goal.
Applying it instinctively even under pressure, deadlines, and complexity is.

This final chapter helps you bring all the pieces together through real-world scenarios, reflection, and a closing synthesis of the PCI mindset.

6.1 The Real Meaning of “Compliance”

When most people hear the word compliance, they picture checklists and audits. But in PCI, compliance isn’t a destination, it’s a rhythm.
You don’t “get” compliant; you stay compliant, every day, through a thousand small actions.

It’s like driving safely. You don’t pass the driving test once and forget the road rules. Every journey, every traffic light, every weather change demands awareness.

The same applies to PCI.
The audit report or Attestation of Compliance (AoC) is just the snapshot.
The real protection lives in daily behaviour: encrypting data, reviewing logs, patching systems, and keeping curiosity alive.

6.2 The Integrative Scenario; “The New Checkout Project”

Let’s step into a realistic situation that mirrors what many modern teams face.

Your company, AuroraPay, is launching a new checkout microservice to process payments for digital gift cards. You are part of a cross-functional squad with an architect, developers, testers, and a project manager. The CTO has made one thing clear: the system must be PCI DSS compliant by design, no last-minute clean-ups.

You’ve been given this initial plan:

1. Frontend: A React single-page application (SPA) that collects card details and calls the backend API.

2. Backend: A Node.js microservice running on AWS Fargate that sends card data to an external payment processor (Adyen).

3. Database: A PostgreSQL instance storing transactions, order details, and some user metadata.

4. Logs and Monitoring: CloudWatch for logs, Datadog for metrics.

5. Project Timeline: 10 weeks until production release.

Everything looks neat. But PCI awareness means seeing what others miss.

Let’s test that awareness.

Challenge Part 1: Scoping the CDE

Question: Which components are in scope for PCI DSS?

At first glance, you might think only the backend API is.
But remember Chapter 2: any system that stores, processes, or transmits cardholder data even temporarily, falls into the Cardholder Data Environment (CDE).

That means:

• The React frontend (if it captures raw card numbers)

• The API (since it transmits card data)

• The network segment where the API runs

• The logging and monitoring systems capturing any CHD accidentally

Now imagine the React app is hosted on the same domain as your marketing site. Suddenly, the entire web environment is connected and your PCI scope just exploded.

Challenge Part 2: Designing for Scope Reduction

You propose a different design:

• Use Adyen’s hosted payment page or client-side encryption so that the browser never sends raw card data to your backend.

• The backend receives only a token, which represents the transaction.

• All logs contain order IDs and masked PANs only (e.g. **** **** **** 1234).

• The backend stores transaction metadata, but not card numbers.

• TLS 1.3 enforced across all communication.

• Access to the database restricted by IAM roles and MFA.

Result: The backend is now out of scope for PCI DSS because it never touches CHD or SAD.
Your CDE shrinks to the external payment processor’s domain and the PCI burden moves to them (supported by their AoC).

You’ve achieved the architect’s dream: security through design simplicity.

Challenge Part 3: The Logging Trap

Two sprints later, a developer adds this debug statement:

console.log(”Payment request body:”, JSON.stringify(req.body));


What happens?

That single line, harmless during local testing, writes full card data to CloudWatch logs which sync to Datadog.
In one commit, your observability pipeline becomes part of the CDE.
You’ve turned a one-system scope into a multi-vendor audit nightmare.

Lesson: PCI compliance isn’t about encryption keys or firewalls.
It’s about awareness. Every log, every payload, every variable can either keep you safe or expose your entire environment.

Challenge Part 4: Vendor and People Risks

During testing, the PM signs a contract with an analytics vendor to “track customer purchase behaviour.” The vendor asks for API access to the transaction database.

As an architect, your alarm bells ring:
Analytics systems often aren’t PCI-compliant. If they can access even tokenised data with partial PANs, you may inadvertently expose CHD.

Action Plan:

• Verify the vendor’s PCI Attestation of Compliance.

• Restrict access via a read-only view with masked data.

• Ensure the data export process is logged, encrypted, and approved.

• Document this design decision in your PCI scope register.

Meanwhile, a developer leaves the company.
Offboarding fails to revoke their access to CloudWatch. Two weeks later, auditors find an active user account.

PCI DSS violation: Requirement 8, every user must have unique access and timely revocation upon termination.

Small oversights, big consequences.

Challenge Part 5: The Test Data Dilemma

Your QA environment needs sample transactions to verify refunds and partial authorisations.
A new tester, unaware of PCI, exports a few real production transactions “for realism.”

Suddenly, your test environment now holds live card data and therefore, becomes part of the CDE.
Your scope just tripled.

Correct approach:

• Use synthetic tokens or dummy card numbers provided by Adyen.

• Validate with test-mode APIs only.

• Prohibit real data replication across environments.

• Automate nightly scans for PAN-like patterns in logs and databases.

Testing securely is as important as coding securely.

6.3 The Human Side of Compliance

PCI DSS is a technical standard, but failures are almost always human.
People skip steps when they’re tired, or they make assumptions when documentation lags.

That’s why Requirement 12, maintaining security policy and training is so essential.
Compliance is sustained not through one-off audits but through habits, rituals, and accountability.

Every person in the PCI ecosystem has a small part to play:

• The architect defines safe boundaries.

• The developer guards data at the code level.

• The tester hunts for leaks before they spread.

• The project manager ensures processes don’t drift.

Individually, each role might seem minor. Together, they build resilience.

“PCI isn’t a firewall. It’s a culture of carefulness.”

6.4 Reflection Exercise; The Team Retrospective

Imagine your squad has just completed the AuroraPay project.
During your sprint retrospective, your manager asks three questions:

1. What did we do well in our PCI implementation?

2. Where did we take unnecessary risks or shortcuts?

3. How can we make compliance automatic next time?

Spend a few minutes writing honest answers from your perspective and from another role’s.
For instance:

• If you’re a developer, how can you make life easier for testers?

• If you’re a PM, how can you ensure architects have enough time for design reviews?

• If you’re a tester, how can you share findings that influence coding standards?

Compliance is teamwork under pressure. Reflection keeps the team humble and sharp.

6.5 The “What If?” Game

Let’s test your instincts with short, thought-based scenarios.

These “micro-decisions” are where PCI lives or dies.
Every choice above affects multiple requirements — from access control to vulnerability management.

6.6 Group Discussion Prompts

Use these prompts for a 20-minute discussion:

1. How can your organisation make PCI training less of a compliance exercise and more of a shared culture?

2. Which PCI controls feel most natural to your role? Which feel alien?

3. What would a “PCI by Design” culture look like in your product teams?

4. Should PCI be integrated into sprint reviews, definition of done, or architecture sign-off?

5. How can you collaborate with vendors to share responsibility transparently?

The goal isn’t to find right answers, it’s to surface blind spots.

6.7 The Final Checklist; Can You Explain PCI in Plain English?

By the end of this course, you should be able to explain PCI DSS without jargon.
Try this exercise:

“Explain PCI DSS to a new engineer in two minutes.”

Here’s a model answer:

“PCI DSS is a global security standard that protects payment card data.
It applies to anyone who stores, processes, or transmits cardholder data.
The goal is to minimise where that data exists and secure it through encryption, restricted access, and continuous monitoring.
It has 12 core requirements — things like firewalls, secure coding, and logging.
Compliance isn’t just about passing audits; it’s about building systems that keep customer trust safe every day.”

If you can deliver that confidently, you’ve achieved awareness, the purpose of this entire program.

6.8 From Awareness to Ownership

Take ten minutes and write a brief “PCI Pledge” in your own words.
What habits will you personally maintain after this course?

Here are a few examples:

• I will never store or log unmasked card data, even temporarily.

• I will challenge designs that blur PCI boundaries, no matter who proposes them.

• I will keep learning about new attack patterns and mitigation techniques.

• I will treat compliance as part of engineering excellence, not bureaucracy.

Awareness without ownership fades. Ownership turns rules into reflex.

6.9 Building a PCI Mindset

Let’s close the loop.

PCI DSS isn’t about avoiding fines or impressing auditors. It’s about protecting trust the invisible currency behind every tap, click, and swipe.

When you secure cardholder data, you protect not only your customers but also your team’s integrity and your company’s reputation.

Across these six chapters, you’ve learned to:

1. Understand why PCI DSS exists and what it protects.

2. Identify what data is in scope and how to reduce exposure.

3. Apply the 12 requirements in plain, practical language.

4. See how each role contributes to compliance daily.

5. Learn from real-world breaches where negligence had a cost.

6. Integrate all of this into one coherent mindset: design small, protect deeply, monitor continuously.

If you take nothing else away, remember this truth:

PCI DSS is not a standard for computers, it’s a standard for people who build them responsibly.

6.10 Mini-Final Quiz

1. What is the fastest way to reduce PCI scope in an application design?

2. Why must test environments follow the same rules as production?

3. Which three requirements would be violated by logging raw PANs?

4. What human behaviour caused most major PCI breaches discussed in Chapter 5?

5. What’s the difference between compliance and security in practice?

6. What one action can you personally take tomorrow to strengthen PCI compliance at work?

The Quiet Confidence

True PCI mastery isn’t loud. It doesn’t rely on security slogans or compliance badges.
It’s quiet, the calm confidence that every line of code, every diagram, every decision was made with respect for the people whose data you hold.

You’ll never meet most of them. They’ll never know your name. But their trust is in your hands every time they swipe or click.

And that is what being PCI-aware truly means.

Part 1

Part 2

Part 3

Chapter 4: ROLE-BASED AWARENESS

When people first learn about PCI DSS, it can feel abstract, twelve requirements, dozens of controls, hundreds of acronyms.
But compliance doesn’t happen in the document library; it happens in the choices people make each day.
Every commit, every deployment, every configuration file either strengthens or weakens the protection of cardholder data.

This chapter takes you inside four everyday roles, Solution Architect, Software Developer, Tester, and Project Manager to show how each one keeps the organisation within the PCI guardrails.
You’ll see that PCI isn’t the job of “the security team.” It’s a shared language of safety.

4.1 The Solution Architect, Guardian of Boundaries

The architect’s super-power is design foresight. Long before a single line of code is written, you decide where card data will flow and where it won’t.
That boundary, more than any single control, determines the size of your PCI scope and the effort to keep it secure.

Defining the CDE

Start every payment-related project by drawing the data-flow diagram.
Ask, step by step:

1. Where does card data enter?

2. Where is it transformed, stored, or transmitted?

3. Who or what touches it on the way out?

Every arrow on that diagram is a potential exposure.
Architects who design without mapping data flow are like electricians wiring a house blindfolded.

Example:
An architect at an e-commerce firm noticed that a marketing plug-in was receiving full card numbers via analytics tags. By simply changing the integration point to fire after tokenisation, he removed an entire vendor from scope, saving the company tens of thousands in audit costs.

Building Segmentation and Isolation

Think of segmentation as the moat around your castle.
Your PCI zone should be a small, self-contained island: isolated networks, restricted subnets, minimal connectivity to non-PCI systems.

Use:

• Separate VPCs or network segments for the CDE.

• Firewall rules allowing only required traffic.

• Jump hosts or bastions for administrative access.

Golden rule: If a server doesn’t need to talk to the CDE, it must not be able to.

Designing for Tokenisation and Outsourcing

Every architect faces a pivotal choice: build or delegate?
If a third-party payment gateway can safely process card data, let them.
By externalising the sensitive part, you reduce your internal exposure and shift the compliance burden to a specialist whose entire business is PCI.

However, you must validate the vendor’s Attestation of Compliance (AoC) and ensure contracts specify PCI responsibilities.
Outsourcing does not mean abdication, it means partnership under written assurance.

Architect’s Checklist

• Card data flow mapped and documented

• Network segmentation diagram approved

• Encryption and tokenisation designed end-to-end

• Vendor AoCs reviewed and stored

• Non-functional requirements include PCI controls (IAM, monitoring, DR)

Reflection Pause

If you drew your current system’s boundaries today, could you clearly mark which components are in PCI scope?
If you can’t, that’s your first priority tomorrow.

4.2 The Software Developer, Defender of Data

Developers are closest to the raw material of compliance: code.
A single logging statement can undo a million dollars of architecture.
Yet, developers are also best placed to stop problems early because they control how data is handled at the source.

The Rule of Least Exposure

The simplest way to stay compliant is never handle real card data.
Where possible, use client-side tokenisation or hosted payment pages so the browser sends the PAN directly to the payment provider, not to your API.
Your backend receives a harmless token instead of the real number.

If you must handle CHD, immediately encrypt or tokenise it before any persistence or logging occurs.

Secure Coding Habits

1. Validate inputs strictly. Never trust user data, sanitise, whitelist, and type-check.

2. Use parameterised queries. Prevent SQL injection.

3. Mask logs. Replace sensitive digits with XXXX or omit them entirely.

4. Protect secrets. Store keys in managed services (AWS Secrets Manager, Azure Key Vault).

5. Avoid real data in tests. Use gateway-supplied dummy cards.

Story: The Danger of Debug Logs

During integration testing, a developer left console.log(request.body) active inside a Lambda. It worked fine until real payments began. Overnight, hundreds of PANs appeared in CloudWatch logs.
No breach occurred, but the company’s entire observability stack became in-scope for PCI. It took weeks to cleanse and re-architect.

The fix? Introduce a logging filter middleware that automatically masks any field named card, pan, or cvv before writing logs.
A ten-line utility now protects millions of transactions.

Code Review and Automation

Security reviews shouldn’t depend on human memory. Integrate Static Application Security Testing (SAST) and Dependency Scanning into CI/CD pipelines.
Flag issues early, before merge.
Treat a failed security scan the same way you treat a failed unit test.

Developer’s Checklist

• No CHD/SAD logged or stored

• Encryption libraries validated and tested

• Secrets managed through approved vaults

• Automated scanning in pipeline

• Dummy cards only in non-production

Reflection Pause

Open your latest codebase. Search for the words “card”, “cvv”, “pan”, or “payment”.
Would any of those lines raise a red flag to an auditor?
If yes, fix them today, future-you will thank present-you.

4.3 The Tester, Detective of Exposure

Testers are the quality guardians.
While developers ensure data is handled correctly, testers confirm that nothing slips through the cracks.
They are the ones who can catch data leakage before it becomes a breach.

Testing for Data Safety

When testing payment flows:

• Inspect responses and logs. Ensure no API returns or stores full PANs or CVVs.

• Check error handling. Failed transactions must never echo card details.

• Verify TLS. Capture network traffic and confirm encryption throughout the chain.

• Validate data masking. Reports, dashboards, and exports should display only partial PANs (e.g. **** **** **** 1234).

Negative Testing and Abuse Cases

Attackers don’t follow the happy path, and neither should you.
Try:

• Submitting malformed payloads or very long numbers.

• Attempting to upload files where text is expected.

• Replaying valid tokens twice.

Your goal isn’t to break the system maliciously, but to prove that defences hold even under stress.

Story: The QA Hero

At a Sydney start-up, a tester noticed that refund emails included full card numbers, a feature added “for convenience.”
She raised a ticket, and it turned out the template engine was using raw API responses.
Had those emails been sent to customers, thousands of PANs would have left the CDE.
Her curiosity saved the company from a breach and a fine.
That’s the value of critical testing.

Automating PCI Validation

Use scripts or static analysis tools that search for PAN-like patterns (\b[0-9]{13,19}\b) in logs and databases.
Run them nightly. If they ever match, alert immediately.

Many organisations integrate these scans into CI/CD or SIEM systems. Prevention through automation keeps humans from missing patterns.

Tester’s Checklist

• No card data in responses or logs

• TLS validated end-to-end

• Reports show masked data only

• Abuse and replay scenarios tested

• Automated pattern scans in place

Reflection Pause

When was the last time your QA suite explicitly checked for data masking or encryption?
Testing functional correctness is good; testing data hygiene is better.

4.4 The Project Manager, Coordinator of Compliance

Project Managers may not configure firewalls or write code, but they decide whether PCI tasks are prioritised or postponed.
Their influence determines if compliance stays visible or quietly drifts into “later.”

Making Compliance Part of Delivery

In agile terms, PCI is not a “nice-to-have.” It’s a definition-of-done.
Every user story that touches payments should include acceptance criteria such as:

• “All card data tokenised before storage.”

• “Logs verified for masking.”

• “Security review approved.”

By embedding compliance into the backlog, PMs prevent last-minute scrambles before audits.

Tracking Evidence and Attestations

PCI audits thrive on documentation.
PMs ensure:

• Vendor AoCs are collected and renewed annually.

• Architecture diagrams and DFDs are version-controlled.

• Training records are stored.

• Jira or Confluence pages capture proof of each requirement.

A well-maintained evidence trail turns audit season from panic to paperwork.

Scheduling Security and Training

Requirement 12 mandates regular awareness training.
PMs coordinate these sessions, ensuring new joiners complete induction within 30 days and all staff refresh annually.

They also schedule quarterly vulnerability scans and annual penetration tests in the roadmap so they’re never forgotten when delivery pressure mounts.

Story: The Project That Forgot Security

A mobile wallet project once treated PCI items as “phase 2.” The launch went ahead with tokenisation incomplete. Within weeks, a partner bank refused integration until the system passed PCI validation. The resulting delay cost more than the original sprint budget.

The PM later said, “We learned the hard way that compliance work is delivery work.”

PM’s Checklist

• PCI requirements built into backlog

• AoCs collected and tracked

• Security scans and pen-tests scheduled

• Training compliance reported monthly

• Risk register includes PCI items

Reflection Pause

Open your project board.
Are PCI-related stories visible, with owners and due dates?
If not, they’ll quietly slip behind feature requests and reappear only when auditors call.

4.5 The Shared Responsibility Mindset

PCI DSS works only when everyone pulls together.
Architects limit exposure; developers code securely; testers verify integrity; PMs keep the machine disciplined.
It’s like an orchestra, different instruments, one melody: protect cardholder data.

Cross-Role Collaboration

• Design reviews: Architects and developers discuss data flows with testers present, so everyone agrees on boundaries before a single deployment.

• Security stand-ups: Once a fortnight, each squad surfaces new risks or near-misses.

• Incident simulations: PMs run tabletop exercises, “What if logs leaked CHD?”, so roles are clear when reality strikes.

These rituals turn PCI from a static document into a living culture.

4.6 Mini-Review Quiz

1. What is the architect’s primary goal during PCI design?

2. Why should developers avoid handling real card data whenever possible?

3. Name two ways testers can confirm that card data isn’t leaking.

4. What evidence must project managers collect to support audits?

5. How does embedding compliance tasks in sprints improve outcomes?

4.7 Summary, The Everyday Champions

PCI compliance is not a project milestone; it’s a habit.
Architects draw boundaries, developers guard data, testers catch leaks, and PMs keep the rhythm.

When each role treats security as part of craftsmanship, PCI DSS stops feeling like bureaucracy and starts feeling like pride in doing things properly.

“A compliant system is simply a secure system that was built by people who cared.”

Chapter 5: Real-World Mistakes and Lessons

When you read a PCI DSS control, “encrypt transmission” or “restrict access”, it can sound abstract, even bureaucratic. But behind every clause sits a painful story: a company that learned the hard way what happens when controls fail.

These are not cautionary tales from unknown startups; they’re from global enterprises with entire departments dedicated to security. The mistakes were small, the consequences enormous.

5.1 The Home Depot Breach; The Chain-of-Trust Failure

In 2014, Home Depot, one of the world’s largest home-improvement retailers, suffered a data breach that exposed 56 million customer payment cards.

What Happened

Attackers didn’t storm the main network head-on.
They entered through the credentials of a third-party vendor, a small heating and air-conditioning contractor who had remote VPN access for billing. Once inside, the attackers moved laterally into Home Depot’s point-of-sale (POS) environment and installed malware that captured card data in memory as transactions were processed.

PCI DSS Violations

• Requirement 7 & 8: Access not restricted by business need-to-know; shared credentials between vendor systems.

• Requirement 11: Lack of intrusion detection and log correlation.

• Requirement 1: Weak network segmentation, once the attackers entered, they could move freely.

The Root Cause

The weakest link wasn’t technology, it was trust without verification. The vendor connection bypassed strong access controls, and network segmentation between corporate and POS systems was incomplete.

The Cost

Home Depot paid over US $179 million in settlements and fines, not including brand damage and years of litigation.

The Lesson

For architects: segmentation is sacred. Vendors should connect through tightly scoped APIs or bastion gateways, never directly into sensitive networks.
For project managers: always collect and verify vendor AoCs and monitor their access continuously.
For everyone: your PCI scope includes your partners, whether you like it or not.

5.2 Target; When Monitoring Exists but Nobody Looks

In 2013, Target Corporation experienced one of the most publicised PCI-related breaches in history. Around 40 million cards were compromised, plus 70 million customer records.

What Happened

Just like Home Depot, the attackers came in through a third-party vendor, in this case, an HVAC maintenance company. They used stolen credentials to access Target’s internal network and deploy malware on POS terminals.

The tragedy?
Target’s intrusion detection system (FireEye) actually raised alerts in real time. But those alerts were ignored. The SOC team was overloaded and under-trained.

PCI DSS Violations

• Requirement 10: Logs and alerts must be actively reviewed.

• Requirement 12: Lack of trained personnel and effective incident-response process.

• Requirement 5: Failure to keep endpoint protection signatures updated.

The Cost

More than US $290 million in settlements, legal fees, and remediation plus a CEO resignation and multi-year reputation hit.

The Lesson

Monitoring is meaningless without human vigilance.
PCI doesn’t just ask for logs; it asks for log review.

Architects and PMs must ensure that monitoring alerts flow to trained teams who have authority to act. Testers can help by simulating incidents and confirming alerts trigger correctly.

“Detection without response is decoration.”

5.3 British Airways; The JavaScript Injection Disaster

In 2018, British Airways was fined £20 million (AUD ≈ 40 million) after a cyber-attack redirected customers to a fraudulent payment page.

What Happened

Hackers injected malicious JavaScript into British Airways’ website. When customers entered payment details, the script silently sent card data to an attacker-controlled domain.

The compromise lasted two months and affected about 400,000 cardholders.

PCI DSS Violations

• Requirement 6: Failure to maintain secure web applications and patch vulnerabilities.

• Requirement 11: Insufficient change-detection mechanisms on scripts.

• Requirement 10: Lack of logging around client-side integrity changes.

Root Cause

The attackers exploited outdated third-party libraries and unmonitored front-end changes, a blind spot in most PCI programs that focus on back-end servers.

The Lesson

For developers: PCI applies to client-side code too.
If your JavaScript collects payment data, treat it like part of the CDE. Use sub-resource integrity (SRI) checks, content-security policies (CSPs), and code signing to prevent tampering.

For architects: maintain an inventory of external scripts and libraries. Implement automated integrity checks in CI/CD.

Even the front-end is a door; lock it.

5.4 Marriott International; When Data Lives Too Long

In 2018, Marriott International revealed that attackers had accessed the guest reservation system of Starwood, a hotel chain it had acquired. The intrusion had persisted undetected for four years, exposing data from over 383 million guests, including card numbers, passport details, and addresses.

What Happened

Attackers breached Starwood’s network in 2014, well before the merger. The compromised systems including databases containing encrypted card data, were migrated into Marriott’s infrastructure without thorough re-assessment. The attackers retained access post-migration.

PCI DSS Violations

• Requirement 6 & 11: Inadequate vulnerability testing and failure to re-validate security after major changes.

• Requirement 3: Long-term storage of cardholder data without re-encryption or key rotation.

• Requirement 10: Insufficient monitoring and anomaly detection.

The Cost

Marriott was fined £18.4 million by the UK Information Commissioner’s Office and spent hundreds of millions on remediation and customer support.

The Lesson

Architects: every acquisition or major system migration resets your PCI clock.
Always perform a fresh CDE scoping and validation exercise.
Never assume the inherited environment is compliant, compliance is not transferable.

Project Managers: treat mergers, cloud migrations, and platform rebuilds as PCI-impacting events requiring new risk assessments.

5.5 Equifax; Patch Management and the Cost of Delay

In 2017, Equifax, one of the largest credit-reporting agencies, suffered a breach that exposed personal and financial data of 147 million people worldwide. Although not strictly a PCI merchant, the event demonstrates a perfect storm of PCI DSS violations.

What Happened

A known vulnerability in Apache Struts (CVE-2017-5638) had been publicly disclosed in March 2017. Equifax failed to patch it for months. Attackers exploited the flaw, accessed databases containing card and identity data, and exfiltrated it undetected.

PCI DSS Relevance

• Requirement 6.2: Install critical patches within one month of release.

• Requirement 11: Regularly scan and test for new vulnerabilities.

• Requirement 10: Ensure logging is centralised and alerts are reviewed.

The Cost

Equifax paid over US $1.4 billion in fines, compensation, and upgrades and permanently damaged its brand credibility.

The Lesson

For developers and PMs: treat vulnerability notifications like fire alarms, not calendar reminders.
For architects: build automatic patch pipelines; don’t rely on human tracking.
For testers: verify patch levels in environments as part of regression testing.

A single missed update can undo every encryption key and firewall you’ve deployed.

5.6 NAB (National Australia Bank); The Cloud Misconfiguration Wake-Up Call

In 2019, National Australia Bank (NAB) publicly disclosed that the personal details of about 13,000 customers had been accidentally shared with a third-party data-validation service.

What Happened

During a routine system migration, customer information including names, addresses, and account numbers, was uploaded to a cloud server operated by an external provider without proper redaction or encryption.

Although the exposure was accidental and quickly contained, it prompted intense regulatory scrutiny because NAB is a card issuer and PCI DSS Level 1 entity.

PCI DSS Implications

• Requirement 3: Data not adequately protected before transmission.

• Requirement 7: Data shared beyond business need.

• Requirement 12: Lack of defined data-handling process for external validation.

The Lesson

Even in highly mature institutions, configuration drift and human error are constant risks.
For architects: implement data-loss prevention (DLP) tooling and enforce encryption at upload.
For PMs: every data exchange with a third-party vendor must pass a PCI data-handling checklist before execution.

“It wasn’t a hack, it was a handshake done carelessly.”

5.7 Lessons Across the Board

After studying these incidents, several recurring themes emerge.
Each one maps directly to PCI principles but, more importantly, to human behaviour.

The moral is clear: non-compliance rarely comes from malice.
It comes from small oversights, an unpatched system, a forgotten script, a blind trust in a partner.

5.8 Reflection Pause

Take a quiet moment and consider your own environment.

• Do you know every third-party system that can reach your CDE?

• Who reviews alerts when your monitoring tool screams in the middle of the night?

• How long is payment data retained in your databases or backups?

• Are there front-end scripts on your payment pages that no one “owns”?

Write down three small actions you can take this week to reduce your organisation’s PCI risk.
They might feel trivial but so did those missed patches, unreviewed alerts, and forgotten test logs that triggered global headlines.

5.9 Mini-Review Quiz

1. Which PCI requirements did the Home Depot breach violate, and how?

2. What was the fundamental failure in Target’s monitoring process?

3. Why does client-side JavaScript fall under PCI scope, as shown by the British Airways incident?

4. What compliance lesson can we learn from Marriott’s acquisition of Starwood?

5. How does the Equifax breach illustrate the importance of Requirement 6.2?

6. What practical steps can teams take to prevent accidental data exposure like NAB’s?

5.10 Summary; The Price of Complacency

Every breach you’ve just read about could have been prevented by fulfilling one or two existing PCI controls.
That’s what makes these stories haunting.

They prove that compliance is not paperwork, it’s discipline.
It’s patching on time, reviewing logs, verifying vendors, and deleting what you no longer need.

PCI DSS isn’t a shield you buy once; it’s a reflex you practise daily.

“Security fails when familiarity breeds comfort.
Compliance survives when curiosity never sleeps.”