Barack Obama said something in a podcast interview that has stayed with me. His message to young people, the ones who assume the top of any field is full of geniuses, was that you should never let anyone make you feel you do not belong. Once you have had some exposure to the rooms where decisions get made, you realise the people in them are mostly ordinary. What sets them apart is rarely brilliance. It is access, exposure, and the confidence that comes from being treated as though they belong. They are not a different species. They were let into the room.

I keep coming back to it because our profession tells architects the reverse. It says you have to prove you are the exception before you are allowed to belong.

Somewhere on the way to the title, many of us absorb a belief about what an architect is meant to be. The smartest person present. The one every hard technical problem routes to, because you are the architect, so surely you hold the deepest answer on every subject. The strongest voice, the one that wins the room by knowing more than anyone else in it. Hold that belief long enough, and it changes how you carry yourself.

I held it for years, and it cost me.

You have probably felt this yourself. You are good at the work, maybe better than some of the people getting promoted ahead of you. And in workplace after workplace, the same message keeps coming back: you are too introverted, you lack presence, you need to be more visible if you want to move up. So you are left wondering whether getting ahead means turning into someone you are not. The answer is no. I spent years getting that wrong before I got it right. So this is about how to grow and lead as the architect you already are, without giving up the parts of yourself that got you here.

The job was never to be the smartest in the room

Gregor Hohpe, who wrote The Software Architect Elevator, puts it about as plainly as anyone in our field. The architect, he argues, should not be the smartest person in the room handing out instructions. The job is to help make everyone else in the room a little smarter. He calls the architect an IQ amplifier for everyone else.

That one reframe takes the weight off you.

An architect who tries to be the cleverest person in the room ends up hoarding decisions and talking down to the specialists who know their own domains far better than he does. The engineers know the code. The security lead knows the threat model. The finance lead knows what the business can afford. Your job is to get those people talking to each other, to spot the trade-offs none of them can see on their own, and to help them reach a decision none of them could have made alone. You build the shared picture everyone can work from. On a good day, everyone walks out sharper than they walked in, and nobody can point to the exact thing you did to make it happen. That is how the best architecture work goes, in my experience. The wins are the kind you can barely see, a decision that turned out right, a risk that never became a problem, complexity that never built up. Those wins are rarely celebrated in the room.

I learned to be that kind of architect on a major transformation at a telecoms operator, building an API platform as the business shifted from primarily selling connectivity to running digital services. The developers were the subject matter experts on the systems in scope. They understood them far better than I did. My part was to let them own the system design, connect the dots across their work, and carry their ideas to the decision makers. I translated those ideas for the commercial and business leaders who held the budget, then secured the buy-in that turned good engineering into a funded programme. I was not the smartest person on that programme. I was the one who made sure the smartest people were heard by the people who paid for it.

That connecting work tends to matter more than the impressive solo acts architects are still rewarded for. And it suits a different kind of architect, the one who connects the work and leads the room, in their own reserved way. That instinct is a strength, even when it gets treated as a shortcoming.

The evidence that being loud is the wrong measure

If that belief has ever held you back, there is an interesting analysis you should check out, linked below. Its author, Nick Malik, suggested that courage is a core trait for architects in his work on personality traits for enterprise architects, and I couldn’t agree more. Courage is about being willing to take a position that is measurably better for your client, even if it means paying a personal price to propose it. A mark of an effective architect is to draw an unpopular but best-fit conclusion, make a difficult decision with integrity, and then have the courage to push it through as a standard for others to follow.

Nick Malik also shared conference slides on the personality traits of effective enterprise architects. In them, he used a personality framework to compare the architects he considered successful with those he did not. In his analysis, he observed that the architects he considered successful tended to sit near the middle of the personality scales rather than at the extremes. In his sample, raw extroversion did not, by itself, predict success, nor did being the most detached. What worked was being able to switch between listening and speaking up, depending on the situation, and I’d add that this takes courage.

Look at the wider leadership research, and you find something every introverted architect already knows. In a widely cited 2006 survey, 65% of senior executives said they saw introversion as a barrier to leadership. Only 6% thought introverts had the people skills to lead a team well. Yet when Adam Grant, Francesca Gino, and David Hofmann ran a field study on this, published in the Harvard Business Review in 2010, they found that introverted leaders produced better results than extroverted leaders when their teams were proactive. They listened, made people feel heard, and let good ideas run their course. The perception is that introverts lose. The evidence is more nuanced, and in the right conditions, the introverted ones come out ahead.

The route to becoming an architect is rarely a straight line

My first degree was in Biochemistry at a university in Nigeria, and I was bad at it. For that university system, a third‑class degree was the lowest passing honours band, and I barely made it. Nothing on that transcript pointed to the architecture career I would go on to build.

A few years before that, my mother bought me my first laptop when I was a teenager. That machine did more for my life than the degree ever did. I taught myself to build websites, HTML and CSS first, then the Zend Framework for PHP in the late 2000s and early 2010s, spending odd hours on Stack Overflow and breaking things until they worked. No one told me to. I did it because I enjoyed it, and I kept building on my own and gaining experience with system design. Before long, it started paying. I picked up clients on Elance, the freelancing site which later merged with oDesk to become Upwork.

The road from there ran through cloud computing. When the cloud boom created a new role, the cloud architect, I earned professional architect certifications from the major cloud service providers and kept climbing. But the technical depth was never what held me back.

The thing holding me back was the room.

In 2016, I was accepted to speak at a conference run by the Software Engineering Institute at Carnegie Mellon. I had taken one of their methods, a structured way of evaluating architectural trade-offs called ATAM, applied it at my work, and was going to stand on their stage and talk about it with the people who created the method sitting in the audience. I was frightened. Every reserved instinct told me to back down and stick to the technical work where I felt safe, rather than communicating it on stage.

I did it anyway. It did not go perfectly, and it did not need to. What I learned that day has held ever since. Confidence did not come first, and then hand me the courage to speak. It ran the other way. I spoke while scared, and the confidence arrived afterwards, built from the doing. You do not talk yourself into it in the mirror. You outwork the self-doubt one uncomfortable room at a time. If that is you, do not wait to feel ready. Pick the smallest room where you can speak up this week, and use it.

The trap of becoming acceptable

There is a second pressure, and it has little to do with how good you are at the work. I was already an architect when I became an immigrant, and I had to find my feet in a new country from scratch. You leave home for a place where the language is new, the unwritten rules are invisible, and in some rooms the assumption is that you must be a diversity hire rather than there on merit. You are asked, in dozens of small ways, to justify a presence that others are simply granted.

For an introvert, that pressure does something specific. It teaches you to make yourself smaller. You start managing yourself down into something easier to supervise. You soften the directness. You temper the ambition so it no longer makes less ambitious people uncomfortable. You take a great deal of advice about becoming warmer, more agreeable, more coachable, and easier to be around.

I tried versions of that for a while. It did not make me a better architect. It made me smaller, slower and easier to overlook.

That does not mean I am always right. I have made my share of mistakes, including chasing approval from people who never mattered to the work. Some of the feedback I got was fair, and I took it. I go looking for it because that is how you grow. But I had to learn to weigh it, because confidence is easy to mistake for competence.

What I hold on to now is the difference between 2 things that look alike on the outside. One is getting better at how you work, which is always worth doing. The other is changing yourself so much to fit in that there is less of you left. The test is simple. When feedback lands, ask which of the 2 it is. If it makes you sharper at work, take it. If it mostly makes it easier for someone else to handle you, hold onto yourself.

Holding onto yourself comes at a price, and it helps to name it. It means some people will not like you for it. Kishimi and Koga built a whole book around this idea, The Courage to Be Disliked, drawing on Alfred Adler’s psychology. Their argument is that trying to be liked by everyone is its own kind of trap, and that freedom begins when you accept that being disliked by some is the cost of living as yourself. This is the personal side of that same courage, the nerve to take the unpopular position even when it costs you. You cannot hold the right architectural line and keep everyone comfortable. At some point, you choose.

Self-leadership comes before leading others

The turn comes from understanding your own wiring before you try to manage anyone else’s. For me, that meant some unglamorous homework on myself.

I have spent time with the instruments people use to map themselves. On the 16Personalities test, I come out as the Architect type, the reserved, strategic, future-focused profile, and in my case, the turbulent version of it, the one most prone to feeling misunderstood, which made me laugh out loud when I first read it. On the Gallup strengths assessment, my top 5 are Futuristic, Learner, Intellection, Focus, and Achiever, a stack that leans toward strategic thinking and steady effort rather than charm and performance. On a third tool, PrinciplesYou, built on Ray Dalio’s work, I come out as a Shaper, someone who fixes on a goal and drives through obstacles, with attributes of the Quiet Leader and the Strategist alongside.

None of these tools is gospel, and I do not treat them as science. What they gave me was a mirror. All 3 said the same thing about me. My contribution was never going to be the warmest presence in the room or the fastest to charm it. It was going to be depth, foresight, structured thinking, and the grit to hold a hard problem until it gives way.

They named my growth areas honestly, too, and I needed to hear those. Sensitivity to how other people feel. Telling people when they have done good work. More patience. Self-leadership meant owning both halves, the strengths to lean into and the edges I genuinely had to work on, rather than swallowing a blanket instruction to become a different person.

There was one line in those results I stopped apologising for. It described a kind of leadership that is as much about listening as speaking, reading the room and holding a position without raising your voice. I had spent years treating that as a flaw to correct. It turned out to be closer to what the job actually needs. If your instinct is to listen before you speak, you do not need to borrow an extrovert’s playbook to lead well. You need to run your own, on purpose.

It comes down to learning to say no. No to the roles that need a different kind of person and would leave you miserable and mediocre. No to the meeting that wants a stage performer when the work needs a thinker. You stop trying to force yourself into the shape of the louder, more charming presence that gets mistaken for strength, and you start building on what you actually do well. You lead other people better once you stop mismanaging yourself. Start by engaging in introspection, using an assessment tool, and better understanding your strengths. PrinciplesYou is a free one you can start with.

The reason this is bigger than your next review

Some time ago, I took my first degree off my LinkedIn profile. The third-class result in Biochemistry embarrassed me, and I had left it out. A former manager noticed and called me about it. He asked why I had taken it down. Then he told me something I had not considered. That degree, and the unlikely road from it to where I am today, was not the weak part of my story. For a young person from a background like mine, someone looking at this profession and wondering if there was any room for them, my strange route was the most useful part of the whole profile. Hiding it did not help that aspiring architect, so I put it back.

That call changed how I think about the whole thing.

I am a Black man, a Nigerian, an immigrant who rebuilt a career in a new country. When people from where I am from, or people who carry some part of my story, see the path laid out honestly, third-class degree and all, something shifts in what they believe is open to them. A bigger life starts to look possible for them. Being among the first in your own world to do a thing is not only a private milestone. It stretches the map for everyone who comes after you.

That is why I serve on The Open Group’s peer-review board that certifies architects. It is why I mentor the ones coming up. It is why I write and speak, even when it still frightens me. Not because I am the smartest person in any of those rooms. I am not, and the job was never to be.

The architect a room actually needs is the one who makes everyone else in it better. You do not have to become the strongest voice there to do that work, and you do not have to file away the parts of yourself that carried you this far. What you have to do is understand your own wiring, protect it, and point it at problems worth solving.

I write The Foresight-Driven Enterprise, a newsletter on enterprise architecture, foresight, and growing as a practitioner. If you want more like this, subscribe.

Further reading

• Gregor Hohpe, The Software Architect Elevator (O’Reilly), and his talk “Thinking Like an Architect,” InfoQ presentation

• Nick Malik, “Personality Traits of Effective Enterprise Architects,” the practitioner analysis. Slides and his companion article

• Adam Grant, Francesca Gino and David Hofmann, “The Hidden Advantages of Quiet Bosses,” Harvard Business Review, 2010, on reserved leaders and proactive teams. PDF

• The 65% and 6% figures come from a 2006 USA Today survey of senior executives, cited across the introverted-leadership literature.

• Barack Obama on belonging and exposure, The Pivot Podcast, 2024. YouTube

Back in the early 1970s, a team at MIT built a computer model to capture how the world behaves over time.

They called that model World3. It pulled together five big things we normally learn in separate subjects- population, food production, industrial output, pollution, and non‑renewable resources- into one connected system.

Donella Meadows, then a young systems scientist and the lead author, explored how those forces pushed and pulled on each other over roughly two centuries of simulated history. The book that emerged from this work, The Limits to Growth, sold millions of copies and sparked a debate that still hasn’t really stopped.

A lot of that debate has revolved around one big question: whether its long‑term projections actually got the future right.

By contrast, far fewer people have asked what might be the more useful question: how that team learned to see the world as one connected system, and why kids still rarely get taught to think that way at school.

That’s the heart of what I’m arguing in this week’s edition. My point is simple: schools should teach systems thinking and give it the same weight as any core skill. Systems thinking prepares young people to make sense of a deeply connected world, where the big problems play out through relationships, feedback loops, and knock‑on effects that no single fact can ever explain on its own. Take AI: it’s made systems thinking much more urgent because a child who learns to see systems now is far better equipped for a future where much routine ‘thinking’ gets handed off to machines.

Facts in isolation are not understanding.

A lot of schools are very good at teaching the pieces: a fact here, a formula there, and things to memorise for a test. That approach works fine when a problem stays put and fits neatly inside one subject. But it starts to fall apart as soon as the problem won’t sit still and spills over into other areas.

Back in 1973, Horst Rittel and Melvin Webber gave these kinds of problems a name. They called them “wicked” because they’re fuzzy at the edges, don’t have a clear finish line, and can’t be solved with a simple true‑or‑false answer. Derek and Laura Cabrera push this further, arguing that wicked problems often show up when there’s a gap between how a real system works and how we think it works. We end up grabbing the wrong fix simply because we’ve misread the system we’re trying to change. A finance chief solves it as a money problem. A technology chief solves it as a tech problem. But the real issue often lies in the space between those perspectives, and no one feels responsible for it.

Take a story many economists and policy writers love. In a popular anecdote from British‑ruled India, the government wanted fewer cobras in Delhi and offered a reward for every dead snake. In the tale, people start breeding cobras just to cash in on the reward. When the officials shut down the scheme, the story says the breeders dumped their now‑worthless snakes, and Delhi ended up with more cobras than it had started with. It’s a neat little warning about how a quick fix can end up feeding the very problem it was supposed to solve.

The twist is the part that matters. The breeding part very likely never happened. German economist Horst Siebert popularised the term “cobra effect” in 2001, and the story itself seems to trace back to a hedged 19th‑century newspaper piece that naturalists at the time thought was unlikely. We took a messy, uncertain bit of history and squeezed it into one clean cause, because a simple story is easier to remember than a real system. That storytelling habit is exactly the kind of thing systems thinking teaches you to notice and challenge.

Climate change is both a chemistry problem and an economics problem, with each side feeding into the other over decades. Inequality works the same way, and so does a pandemic or a supply chain that breaks on the far side of the planet. These kinds of problems live in the relationships between the pieces, not in any one piece on its own. A child who’s only taught to break things into parts will often miss what’s really going on in the way those parts connect.

Systems thinking is the habit of looking at those connections first. It gets you asking what influences what, where the delays sit, and what’s likely to happen after that obvious first move. That uses a very different mental muscle from memorising facts, and many schools don’t give that muscle nearly as much of a workout as they could.

This can be taught, and taught early.

The pushback I hear most often is this: systems thinking sounds like something for professors and consultants, not something you’d try with a bunch of nine‑year‑olds.

It’s a fair concern, but there are decades of classroom practice that show kids can handle it. The Waters Foundation has been helping schools teach systems thinking to children since the late ’80s. In the Catalina Foothills district in Arizona, US, systems thinking programs have been run in classrooms since around 1989. In Waters Foundation examples from Tucson, kindergarteners chart how story characters such as the gingerbread man change over time, learning to see change unfold – that’s one way into systems thinking. In the US, the National Research Council’s Framework for K–12 Science Education, under the National Academies, now treats “systems and system models” as core ideas in school science.

This is not only a US story. In 2022, the European Commission published GreenComp, its official sustainability competence framework, and named systems thinking as one of 12 core competences every learner should build. A 2024 European Commission study mapped 39 countries and found that elements of systems thinking are already present in most national curricula. UNESCO goes further, listing systems thinking among the 8 core competences it says every learner should develop. The policy backing is there. The gap is in how evenly schools actually teach it.

None of this needs the jargon. If you give a young child simple language for a loop, you’re handing them a tool they can use for the rest of their life. They start to notice deeper causes instead of just pointing to the closest symptom. They start asking what a decision will do a few steps down the line, not just right now.

We already teach reading and basic arithmetic early on, because people need them almost everywhere in life. Understanding how things connect belongs in that same ‘must‑have’ group, but only some school systems genuinely treat it that way.

AI has raised the stakes faster than most school systems can realistically keep up.

For most of the history of schooling, systems thinking has been treated as a nice‑to‑have, hard to squeeze into the timetable, something for the “next” reform round. AI has pretty much killed off that luxury of taking our time.

An AI model is a system embedded within larger systems: the classroom, the platform, the economy, and the rules that society wraps around it. A young person who just leans on AI risks turning into a passive consumer of whatever it spits out, even the slick, confident answer that happens to be wrong. A young person who can see the system around the tool can do far more with it. They start asking where the answer came from, what’s missing, and who actually gets affected if we act on it. They can check the reasoning instead of just swallowing a plausible‑sounding output whole.

That gap, between passive use and active questioning, is what will end up mattering most. AI is very good at fast, pattern-heavy tasks. The sort of routine cognitive work many jobs used to depend on. What AI still can’t do is decide what really matters, weigh the ugly trade‑offs, or take responsibility for the fallout. Those are still very human skills, and they’re exactly the kind of muscles that systems thinking helps you build. As AI takes over more of the routine work, being able to reason about the whole system stops being a nice extra and becomes what separates the people who steer from the people who get steered.

None of this has to wait for a national curriculum overhaul, and chances are, you don’t run one anyway. What you probably run is something closer to the ground: a team, a department, a hiring plan. The same logic applies just as much in those settings. Instead of only hiring the deepest technical specialist, start valuing the person who can see how all the parts connect. Give more credit to the answer that follows a problem several steps back, rather than the tidy single cause that fits nicely on one slide or the one with the most detail on one piece. You might not be able to rewrite the syllabus, but you can decide what your organisation treats as real intelligence.

So we come back to Donella Meadows and the model she made famous.

For over 50 years, we have argued about whether those curves were accurate. We’ve spent far less of that time teaching the mindset that produced them; the ability to hold a whole system in view and think through how it moves. The next generation is going to inherit more complexity, coming at them faster, with more powerful tools in their hands than any generation before. We can keep throwing facts at them and hope they somehow assemble the bigger picture on their own. Or we can choose to teach them, early and deliberately, how to see the whole system they’re operating in.

One path prepares them for the world they’re really going to live in; the other mostly prepares them for another test.

I write The Foresight-Driven Enterprise for leaders who are building what comes next. If that sounds like you, subscribe, and you’ll get a free copy of Working with Complex Systems, my ebook on systems thinking models worth knowing, including Donella Meadows’ own

In the world of buildings, the title “architect” is protected by law. In business and tech, it’s something you get with a job title change. An experience‑based board certification is how you put real weight behind that word.

In Britain, using the title “architect” in business without being registered can lead to prosecution.

I do not mean business technology roles. I mean architects who design buildings. Their title is protected by law under Section 20 of the Architects Act 1997. In business, only people on the Architects Registration Board’s register may use it. Getting onto that register usually takes years of education, training, and supervised practice. If you put “architect” on your business card or planning drawings without being on the register, the ARB can take you to a magistrates’ court. The ARB brings these cases and publishes the outcomes on its website, partly to warn others.

In business technology, you often become an “architect” when your job title is changed. There is no legal register, no statutory assessment, and no law defending the title. The ARB itself has said that titles like “software architect” and “systems architect” fall outside its remit, and it takes a common‑sense view that leaves the industry alone.

I’ve worked as an architect for over a decade, and I’m convinced that gap has a cost for our profession. If anyone can take a title, it loses its meaning over time. Nowadays, technical and product-focused roles are inflated with the title “architect,” often to signify a senior domain expert or to attract one with the fancy title. When the title is freely given, those who genuinely carry the trade-offs and decisions are mixed in with people who simply put the word on a slide, or capable subject matter experts in their own right who are not architects. Open CA, The Open Group’s architect certification, is one of the strongest experience-based standards we have, and earning it is the clearest way I know to give the title real weight.

This guide is for practising architects preparing for their first Open CA certification. I have earned Open CA myself, and I now sit on the board that assesses other candidates, so I will walk you through the process from the assessor’s side. You are the one doing the hard work. I have already been through it and can point out the steps that get you there.

1. Understand what you are actually applying for

Before you start your application, make sure you understand what Open CA is, because it works differently from most certifications you’re familiar with.

There’s no exam. There’s no “sit this course and you’re done.” Peer review board members assess Open CA based on your real-world project experience and an interview, so it depends on the engagements you have truly led or supported and the decisions you have actually made. You can’t revise your way into this. You earn it by doing the work and talking it through.

The Open Group built the Open CA around you, not your employer. The credential is portable; if you change companies, it goes with you because it certifies your skills, not your position. Thousands of architects in many countries hold Open CA, making it one of the few architectural credentials a hiring manager abroad is likely to recognise immediately.

Open CA has three levels and four disciplines. The levels run Certified at Level 1, Master at Level 2, and Distinguished at Level 3. The disciplines are Business Architecture, Solution (often written Solution/IT), Enterprise Architecture, and the newer Digital Architecture. You apply at either Level 1 or Level 2, depending on your experience. Level 1 Certified indicates that you can work as a contributing architect, with some support, across a broad set of skills. If your experience is deeper, you can go straight to Master without ever holding the Certified designation. There’s one hard rule at the top: you can’t apply for Distinguished until you already hold the Master level. For a first certification, most people start at Level 1, and I have written the rest of this guide for Level 1 candidates. Certify at the level that truly matches your experience.​

2. Pick the discipline that fits the work you actually do

Open CA does not expect you to be a generalist. You certify in one discipline, and you should pick the one that corresponds to the work you already do.

If you design solutions to specific business problems by applying technology, people, and processes to deliver a working system, that is Solution Architecture. If you work at the level of the entire organisation, aligning business and technology across it, and enabling change, that is Enterprise Architecture. If your work focuses on the structure of the business, its capabilities, operating model, and workflows, that is Business Architecture. Digital Architecture is the latest discipline, aimed at architects working in digital‑native, experience‑led contexts.

Be honest when choosing a discipline. The assessment relies on evidence, and you will have to defend what you put down in the interview. A Solution Architect who presents their work as Enterprise Architecture just to seem more senior will struggle as soon as an assessor asks detailed questions about enterprise‑wide trade‑offs. My recommendation is that you should certify at the level and in the discipline where you actually are, not where you would like to be. You can change discipline at the next level when you have truly gathered experience in that discipline.

​

3. Know the 2 routes and the required badges that make up each level

There are two ways in, and the bar is the same either way.

The first route is the Direct Certification, where you apply directly to The Open Group. The direct route is the usual approach for independent practitioners. The second route is via an Accredited Certification Program, where your employer runs an accredited scheme, and you apply through them. If you’re not sure which route you’re on, check The Open Group’s register of accredited programmes. If your employer is listed, you usually go through them; if not, you go direct.

Whichever route you take, Level 1 is made up of four Milestone Badges. You earn them separately, at your own pace, before applying for certification, and then you bring them together in your application.​

• A Professional Communication Milestone Badge, which requires three examples of written work and three examples of spoken work as evidence that you can communicate clearly about your architecture work.

• A Professional Development Milestone Badge, where you show that you keep your knowledge up to date across technology trends, your client’s industry, and your architecture discipline.

• Two Experience Profile Milestone Badges, each a full write‑up of a real engagement you led or supported. At least one of the two must be in the discipline you are certifying in.

Once you have all four badges, you submit your certification application and are then invited to a peer‑review interview. The badges take time, and the Experience Profiles are where most people underestimate the effort, so that is the part I focus on most.

What changes at levels 2 and 3

If your experience qualifies you for a higher level, four things change, and they are worth knowing before you begin.​

• Master (Level 2) requires five badges instead of four. You still earn a Professional Communication and a Professional Development badge, but you submit three Experience Profiles, and at least two of those must be in your discipline.

• Distinguished (Level 3) requires four badges, but the mix is different. There is no Professional Communication badge at this level. You earn a Professional Development badge and submit three Experience Profiles, and you must already hold a Master level before you apply.

• From the Master level and above, the Professional Development badge also expects you to mentor others in their career progression. At Level 1, you are not required to mentor others.

• The interview scales too. At Level 1, a single Master or Distinguished architect interviews you. At Levels 2 and 3, three architects interview you and then meet to agree on a decision.

​

4. Write your Experience Profiles so the work speaks for itself

This is the core of the application, and it is where most people struggle. An Experience Profile is a detailed, structured description of one engagement: the business problem, what you did, the decisions you made, the conflicts you handled, the risks you managed, and what you would do differently. A peer-review board member who has never met you reads it without context and must be convinced that you led genuine architecture work. If the profile is vague, it does not matter how good the work itself was. Work the assessor cannot see might as well not have happened.

That bar has become higher, not lower, in the age of AI. Anyone can now generate a fluent, well‑structured account of work they barely did or never did, so the board leans harder on the live interview to test whether the experience and judgement behind the writing are truly yours. The written profile gets you to the interview. The conversation is where it is proven.

A few habits separate a profile that passes from one that fails.

Describe what you actually did, in the first person, and in clear detail. The application form asks you to describe your skills and competencies, typical of architects, such as gathering requirements, setting or supporting a vision, resolving conflicts, influencing and persuading, using a recognised architecture method, communicating architectural decisions, assessing and managing risk, and validating a solution. At the first level, Certified Architect, you demonstrate the applied skills across these different areas. At the Master Architect level, you also demonstrate applied skills, with an emphasis on leadership rather than support. Bonus points if you can show expert level or mastery of certain skills - you could be recommended to serve on the peer-review board. The competencies are specific to the architecture discipline. For example, Enterprise Architects would be reviewed against enterprise-wide alignment, change enablement, and governance. Business architects are assessed on their ability to design capabilities and value streams, strategies and tactics, amongst other aspects of business architecture. Solution Architects will be assessed against their technical design and delivery of working solutions. So, describe your work to match your chosen discipline. For each competency, fluffy language will fail; a specific recollection of a real situation will pass. When I describe mediating a conflict, I do not write “I facilitated alignment between stakeholders.” I describe the actual conflict.

Some years back, while working for a manufacturing client, two solution architects were going in different directions: one was pushing towards a content management solution with an analytics component, the other towards an in-house built analytics solution, each optimising their own area at the expense of the enterprise architecture. If left unresolved, their designs would have been a technical fit for each capability area but not fit for the enterprise as a whole. I ran an options and trade‑off analysis in front of them, mapped each choice to the business capability it supported, and showed the combined cost of a siloed decision. They agreed on an enterprise‑wide design. This counts as a conflict‑mediation example because it shows a real conflict, real positions, and a real resolution.

Connect every decision you describe to a clear reason. The assessor is not looking for clever technology. They are looking for judgement. On the API platform I built for a pan-African telecoms operator moving from connectivity into digital services, the most important decision was an unglamorous one: building the APIs to the TM Forum industry standard rather than a bespoke design favoured by the development teams. It held up under questioning because the reason behind it was commercial, not technical. Those APIs had to be published, trusted, and paid for by external partners, and a recognised standard was what made that possible. A decision with a clear reason behind it is evidence of an architect. A decision without one is just a preference.

Include your judgement concerning people as well as systems. The strongest profiles focus as much on human dynamics as on the technical aspects of architecture. On that manufacturing engagement, a technical specialist wanted to focus on a specific product before the business architecture was understood. I redirected the discussion to business capabilities and showed how several products could automate those capabilities, until he changed his position himself. A peer-review board member recognises this approach because it reflects how the work actually happens.

​

Be honest in the retrospective. Every profile ends by asking what you would do differently, and this is where applicants either offer a humble‑brag or tell the truth. Tell the truth. On that same engagement, my honest answer about what I would change was to bring human‑centred design and organisational psychology in earlier, because the technical design is the easier part and moving people towards change is the harder part. An honest weakness, examined properly, appears as seniority. A smooth but empty response would suggest to the peer-review board member that you have not reflected on it. You should think carefully about what you could have done better.

Anonymise with care, and never inflate. Two practical rules sit under all of this. First, protect your clients. You can fully describe a project without naming the company, and strong profiles do exactly that. Second, successful architecting does not always mean delivery was completed, so you do not need to exaggerate your contribution. What the assessment weighs is whether your architecture was sound and accepted, not whether the project survived every subsequent budget decision. For example, you might have an engagement that was validated and signed off by the client, then deferred for reasons unrelated to the architecture. It still counts because the architecture was accepted and could have been built. Claim only what is true. The interview is designed to find any gap between what you wrote and what you can defend.

​

5. Know what the board is listening for

After the badges and the application, the interview comes next. For Level 1 certification, you are interviewed by a single Master or Distinguished architect. At Master and Distinguished, the panel grows because those levels place greater emphasis on architectural leadership. It is easy to imagine the interview as something frightening, but it is not, as long as you have done the earlier steps honestly.

I now sit on this board, so I can tell you clearly what we listen for. We are not trying to trap you with trivia, and there is no secret, pre‑set answer. We focus on three things.

• ​Ownership is arguably the most important thing. Can you prove that the work you described is genuinely yours, and that you can talk about it plainly without notes?

• Next are the honest trade‑offs you are able to articulate. Can you show that you understand why you chose each option and what you had to give up to make that choice?

• Judgement under pressure is another one. How do you respond when we challenge a decision? Can you defend it or explain clearly what you would change, instead of freezing or bluffing?

​

The preparation that matters is not rehearsing scripted answers. It is knowing your own engagements thoroughly, as if they were a story you have lived. Re‑read your Experience Profiles until you can remember the reasoning behind every decision. Then expect to be challenged on the weakest part, because that is likely what we will notice. An architect who can say, “You are right, in hindsight I would have sequenced that differently, and here is why,” will likely pass. An aspiring architect who defends a position they never really thought through will likely not.

Earning it, keeping it, and what it changes

So to recap, this week’s edition was written for the architect pursuing their first Open CA certification. Choose the discipline that fits your actual work. Then earn your four Level 1 badges at your own pace: the Professional Communication badge, the Professional Development badge, and two Experience Profile badges. Write those profiles so that the work is self-explanatory. Submit your certification application, then attend the board interview, knowing your engagements thoroughly. If you enter at a higher level, the pattern changes: five badges at Master and four at Distinguished, and you must hold Master before you can attempt Distinguished.

A practical note on how to keep it. Open CA isn’t a certificate you hang on the wall and forget about. You re‑certify every three years by earning a new Professional Development badge and either signing a declaration that you are still practising or submitting another Experience Profile. It is a relatively light commitment to maintain a qualification that confirms you are still doing the work.

Open CA is not the only route that judges experience rather than exams. In the UK, Chartered IT Professional (CITP) status from BCS is assessed on demonstrated competence and professional practice rather than a test. Like Open CA, it uses the SFIA skills framework that underpins many such assessments. Iasa’s CITA certifications follow the same principle, focusing on real architectural work rather than memorised knowledge. Open CA is the certification I hold and assess, so it is the one I can explain from the inside. If your situation points to one of the other certifications, the habits in this guide still apply.

The reason this matters is simple. When you finish, you hold something that people who were simply given the title never had to earn: a credential validated by practising Enterprise, Business, Solution or Digital Architects who have done the job themselves and earned the same certification. The title “architect” in business is freely used and anyone can claim it. A defended title has to be worked for. In a job market that hands out the title easily, you will have done the harder thing, and your credentials will stand.

If your part of the profession has felt the cost of the title being given out too easily, share in the comments where it showed up: in a project, a hire, or a decision nobody owned.

I write about enterprise design and strategic foresight here in The Foresight‑Driven Enterprise. Subscribe if you want to get more actionable articles like this one.

A TOGAF certificate will not make you a good architect.

If you are trying to become an enterprise architect, or trying to get better at the one job you already have, you have probably been handed bad advice. Someone points you at a framework, or a certificate, and tells you that is the path. It is not.

There are three things behind every great enterprise architect. Knowledge gets you in the door. Practice makes you good. Community makes you great. Leave any of them out and you end up as the architect everyone has met and nobody wants to keep. I have spent several years doing this work, and the same three things keep deciding who gets good, who goes on to become great, and who stalls.

Here is what each one means for you, and how to build it.

1. Knowledge gets you in the door

Start with the craft, because you cannot apply what you have not learned.

The trap is stopping there. The architects who earn the ivory-tower reputation are the ones who gather knowledge and never use it, all framework and no building. They get read as academics and theorists, and that label sticks to the rest of the profession.

​​The mislabelling of the title has not helped either. Recruiters and hiring managers often advertise for an enterprise architect when what they actually want is a consultant or a solution architect, which leaves the person who lands the EA job confused about what they were hired to do. So get clear on what the work really is, then treat knowledge as the foundation under it. The foundation is not the building.

You can lay that foundation more deliberately than architects could in the past. You can study the discipline formally. Penn State University runs a master’s degree built around enterprise architecture, and Antwerp Management School offers one too, which is where I did mine. If you are in Europe, it is worth a serious look. There are other academic institutions that offer similar programmes if you do an internet search. TOGAF is the popular shared language across much of the field, so it is a sensible place to begin, though there are other architecture-related frameworks worth knowing, so do not stop at one.

But one framework, or one specialisation, will not carry you far. Aim for range. The architects who matter are deep in one or two areas and broad across many.

Do not build only an architecture career path. Build a portfolio of disciplines that feed each other. For example, an enterprise architect should understand strategy and change management. A solution architect should understand software engineering and product development. Those pairings are what make your work stronger.

That is the path worth copying. In my own case, it ran from solution architecture, through the Google Cloud and AWS professional architect certifications, into security architecture, and kept widening from there into business architecture, then strategic foresight, risk, and the governance of enterprise IT. Over time, each area became another lens on the same enterprise. Which makes me understand and design enterprises better. You do not need that exact mix. You need the habit of widening on purpose, with attention to your specific strengths.

One warning if you are coming up from solution architecture. Enterprise architecture and solution architecture are different but related disciplines, and they often get conflated. The move from one to the other is a real change of discipline, not a bigger version of the same job. The questions and the concerns are different. If you treat it as a promotion of the same skills, you will struggle.

If you are starting today, AI strategy is the obvious place to extend, built on architecture foundations rather than chased on its own. The architecture questions are the ones that decide whether it works: how it fits with the rest of the enterprise, who is accountable for it, how it is governed.

Knowledge gets you into the room. It will not make you good. For that, you have to use it.

2. Practice makes you good

Look at the word you are chasing.

“Architect” comes from the Greek arkhitéktōn. Arkhi means chief. Téktōn means builder or craftsman, the one who fabricates. Put the two together and an architect is the master builder, the chief craftsman who directs the making of the whole. The two halves were never meant to come apart. Design and construction, thinking and making, were one role. The architect conceived the thing and carried it through to the point where it stood up.

So the title itself tells you what makes an architect good. It is the building. The ivory-tower architect has held on to the “chief” and let go of the “builder”, which is exactly why the title sits awkwardly on them. Practice, the doing, is the part that makes you good, and the part no certificate can hand you.

So apply what you learn, then apply it again. You get good by repetition, under real conditions, with something at stake. On the job, you never stop practising.

People, process and technology. You hear those three words constantly. As an enterprise architect, you have to genuinely understand each one and bring them together in your architecture, and you only learn to do that by doing it.

Here is what that looked like for me in one transformation, helping a pan-African telecoms operator move from selling connectivity to running digital services. I was given a mandate to design the change and then build the platforms that made it work. That meant building a cloud platform to run the small, independent services the new model needed, and connecting those services to the old core systems that were not going anywhere. It also meant building a system to create, publish, and sell access to the operator’s APIs through a developer portal, across areas like product, customer, partner, billing, and payment.

Those APIs mattered because of what they unlocked. Other programmes were built on top of them: the move into fintech, the overhaul of the core business systems, joined-up customer channels, and new digital products. Under all of that sat the basic engineering that lets teams move fast without breaking what already works, a shared code repository, a standard build-and-release pipeline, and the testing and tools that make agile and DevOps real rather than slogans.

Two parts of that work teach more about practice than any exam could.

The first was the pull between standards and good engineering. Every API had to meet the TM Forum standards the telecoms industry runs on, while still being built in the modern way those standards did not always allow for at the time. Holding both at once is judgement you only earn by doing the work, getting it wrong, and doing it again.

The second was the part that gets overlooked. The architecture was shaped as much by the business model as by the technology. Deciding how each API would make money, through revenue-sharing, a flat fee, or a free tier with paid upgrades, changed how that API was designed and built. An architect who could only talk technology would have missed it. The master-builder meaning of the word asks for someone who designs the whole thing, builds it, and stays with it until it works and pays off.

For you, the takeaway is plain. Look for work where you build and own the outcome, not only the diagram. That is where you get good.

You will not always have a transformation that size to cut your teeth on, so make your own reps. In software architecture circles, Ted Neward is known for Architecture Katas, small groups working through made-up scenarios to practise technical architecture, which is also important for an enterprise architect. At the enterprise level you can build the same kind of practice in concrete ways. Take a TOGAF case study and work it end to end, running a business scenario through the full ADM cycle and producing the deliverables for each phase, which is what many advanced TOGAF practice case studies are designed to support. Pick a real company you do not work for, read its annual report, and model it in ArchiMate, building a capability map and a target operating model from the outside in. Or offer your help to a charity or a small business that could never afford an architect, where the stakes are real and the risk is low. Any of these gives you the repetition without waiting for a career-defining programme to land in your lap.

This is also why experience-based proof matters more than just sitting an architecture exam that tests your knowledge, and why it is worth aiming for. Anyone can pass a knowledge test. Far fewer can prove what they have actually delivered. The Open Group’s Open CA is judged by a board against the real outcomes you have led or supported, which is why it carries weight. It is evidence the work happened and the result was earned. In my case that meant Level 1 as a solution architect, after delivering several solutions for multiple clients, then Level 2 as an enterprise architect three years later, after delivering several enterprise-wide transformations for multiple clients. And when you earn one, the industry starts to see you as an architect in your own right. The recognition comes from what you delivered, not from a title an employer handed you. SFIA, CITP through the BCS, and the IASA certifications all put significant weight on demonstrated experience, not just recall of theory. Aim for such qualifications once you have the experience to back them. The pure knowledge exams belong back under the first point.

Practice makes you good. What turns good into great is harder to certify, because it does not happen at your desk.

3. Community makes you great

The jump from good to great runs through other people, so this is the part you must give back by contributing beyond the scope of your role at work.

The early instinct is to join things and stop there. The membership goes on your profile and nothing else happens. What matters is moving from joining to contributing, because contributing is where you get sharper and where other architects challenge your thinking.

Aim to contribute at three levels. Inside the organisation you work for, help run or lead a community of practice, where standards get argued out and newer architects find their feet. Outside it, write articles and speak at industry events, because defending your thinking in front of a sceptical room finds the holes in it faster than working alone or within an organisation ever will. And give time to the bodies that hold the profession together, rather than only holding the membership card. Actively seek out these initiatives and keep practising through them, because that is how the community sharpens your craft and you sharpen it back.

Here is how I have tried to do it: leading communities of practice inside the organisations I have worked for, speaking regularly at conferences, sharing my thinking with my audience regularly on platforms like LinkedIn and Substack like I am doing now, sitting in the Business Architecture Guild’s Organisation Design working group, helping review whitepapers to evolve the business architecture practice, and serving on the Open Group’s certification authority, where I now help certify other architects. The invitation to sit on that board closed a loop I did not expect. I went from sitting the Open CA assessment as a candidate to helping certify aspiring architects.

There is a bigger reason to contribute than your own growth. The field only stays sharp if its practitioners keep shaping it. AI and other new technologies are already changing what architecture has to do, and that change will be steered by the architects who help shape the standards and the thinking around it. Stay out of that, and the practice moves on without you. Your contribution is part of how the discipline keeps pace and stays useful.

Keep the range here too. Alongside the architecture bodies, I judge for a foresight fellowship and belong to the Association of Professional Futurists, because foresight is what helps architecture plan for what is coming instead of just describing what already exists. Find the next field that makes your own work stronger, and get into its rooms.

Where to start

Knowledge, practice, community. Those are the three, and the best architects keep building all of them at once.

None of the three is ever finished. You start with knowledge, and you never stop adding to it, because the technology and the business keep changing under you. Knowledge with no practice is the ivory tower, the architect who has read it all and built nothing. Practice with no knowledge is guesswork that fails the moment a problem gets hard. And either of them with no community leaves you stuck, because you stop being challenged once you are the smartest person in your own small room. The architects who become great are the ones still learning a lot, long after they have the title.

Here is a sign you are getting it right, and it is easy to miss. The strongest architecture teams are often the ones nobody notices, trusted because the enterprise runs well and there is no crisis to point at. They earned that through rigour.

As an enterprise architect, or someone aiming to become one, look honestly at the three and find your weakest point right now. If you are coming up from solution architecture, or from a specific architecture domain, it is usually practice on the enterprise canvas. If you are already deep into your career with a lot of successful projects, it is often community, the contribution you keep meaning to make and never quite get to.

Pick the weak one and start there.

I write here about enterprise design and foresight, and how architects and the leaders they work with can decide well when the future is unclear. If becoming a better architect is on your mind, subscribe and the next pieces will come straight to you.

Futurists do not predict the future. That is lesson one for technologists.

In 1876, Alexander Graham Bell’s financial backers offered his telephone patent to Western Union, the telegraph giant that then ran the dominant long‑distance communications network. The asking price was a reported price of $100,000. Western Union’s president, William Orton, turned it down. By one account he asked what use the company could possibly make of an electrical toy. Within a few years that patent became one of the most valuable ever granted, and the company that owned the wires had handed the future to a competitor.

The people closest to the technology were the worst placed to see where it would go. That distance, between knowing how something works today and seeing where it travels next, is what foresight is built to close. I spent 5 weeks learning how to close it, across 5 weekly sessions, on the University of Houston Professional Certificate in Foresight. I went in as a working enterprise architect with over 15 years in technology behind me, not a futurist by trade, and I came out with a different way of making the decisions that matter most in my work.

What follows are 7 of those moves. None of them needs a crystal ball. All of them change how a technologist decides, and they matter most on exactly the decisions technologists are trained for least: the long-horizon ones, where being wrong is expensive and slow to show up.

1. Foresight runs on evidence, not just imagination

The first thing that surprised me was how little of the work involved imagination.

Foresight is a research pipeline. On the Houston Framework Foresight method, a project starts by collecting hundreds of signals of change from the real world, narrows them into a smaller set of trends, then clusters those into several forces driving the domain, and only then builds around 4 scenarios on top of them. The modern scenario method was developed at the RAND Corporation in the 1950s by Herman Kahn, a physicist and systems theorist who used it to think through nuclear strategy. The discipline grew out of hard analysis, with no crystal ball anywhere in sight.

That matters for technologists because most of us dismiss futures work as guesswork and never adopt it. Treat it instead the way you would treat any evidence pipeline you already trust. The signals are sourced and dated. The drivers are defended. The scenarios trace back to the data that produced them. Once you see the method as research, the objection that it is fluffy stops holding.

2. Stop predicting 1 future. Build for 4.

The biggest shift the course asked of me was to stop backing a single story about what comes next.

Many technologists are trained to produce a single target state. We draw the 2030 architecture, write the roadmap that reaches it, and treat that as the plan. The Houston method builds 4 futures instead: a baseline where today’s trajectory continues, and 3 alternatives where the rules change, settle into a new balance, or break down entirely. My class project looked at the impact of automation on the workforce in Canada out to 2035. The same domain produced very different worlds. In the baseline, which we called The Augmented Workforce, AI mostly augments people and the friction is about reskilling and access. In the transformation scenario, The Intelligent Society, integration becomes irreversible and work shifts from routine tasks to creativity and judgment.

Building the 4 worlds taught me something a single forecast would have hidden. In every version, the force that decided how the world turned out was the same. Trust in the AI mattered more than how advanced the AI became. We had been calling it a technology question. The futures showed it was a trust question. That is the value of the exercise. It shows you what your roadmap is quietly betting on, before you commit.

3. Match your time horizon to how fast your field changes

Before you forecast anything, the course makes you decide how far out to look, and the answer depends on the thing itself.

A computer chip generation turns over in around 18 months. A car platform typically runs 5 to 7 years, with major updates about every 3 to 5. An oil platform lasts 30 years or more. Set the same time horizon for all 3 and you will plan badly for at least 2 of them. Foresight forces you to pick the horizon deliberately, then split it into 3 stages: the near term you can largely see, the middle-to-long term where most of the change happens, and the long term you are steering towards. For the automation project we set the present to 2030 as the near term, 2030 to 2035 as the middle, and 2035 onward as the horizon we were really designing for.

Most technology roadmaps skip this step. They default to a 3-year window because that is how the budget cycle runs, then apply it to decisions that live on a completely different clock. A 3-year horizon is wrong for a data platform you expect to run for 15 years, and it is wrong for an AI capability that may be unrecognisable in 18 months. Choose the horizon from the lifespan of what you are building. The planning calendar is the wrong place to start.

4. See the whole system, not the parts

Peter Bishop, one of the programme’s founders, has called systems thinking the lens through which futurists see the world. It became the most useful habit I took away.

Engineers are trained to break a problem into parts, fix each part, and assume the whole improves. Systems thinking works the other way. It looks at the whole first, at how the parts connect, and at the loops where one thing feeds another. Donella Meadows described a system as a set of things connected so they produce their own behaviour over time. The behaviour comes from the structure. As the quality-improvement pioneer Paul Batalden put it, every system is perfectly designed to get the results it gets. When you map the automation domain as a system, you stop seeing a list of technologies and start seeing why the outcomes keep happening: the feedback between reskilling, trust, and adoption that no single component controls.

For a technologist this is a direct warning. Optimise a single service, platform, or team in isolation and you can easily make the whole worse, because the parts are connected in ways the component view cannot see. Map the system and its loops before you redesign any piece of it. The map is what tells you which change actually moves the outcome and which one just moves the problem somewhere else.

5. Your expertise is hiding the future from you

The hardest discipline in the course was scanning for weak signals, and the hardest part of that was getting out of my own way.

A weak signal is an early, faint sign of change, and the course is blunt about where these come from. They almost always start outside mainstream expertise, in the work of people who are not the recognised authorities and not publishing in the respected journals. The instinct of an expert is to filter those out. The futurist’s discipline is to hold space for them. The signal that stayed with me from my own scanning came from outside enterprise architecture entirely: a product-management writer, Marty Cagan, describing how AI tools could act like a kind of personal coach for product teams. What made it sharp was that Cagan, long a champion of human mentoring, was openly reconsidering how far AI could go as a coaching tool. Even the expert was loosening his grip on his expertise.

There is a long history here. When Bell filed his telephone patent, his rival Elisha Gray lost the race partly because, as historian David Hounshell has argued, Gray’s deep expertise in telegraphy became a disadvantage. He was so deep in the telegraph business that he could not see what the telephone would become. The more you know about your field, the more your knowledge filters what you let yourself take seriously. Build your scanning to reach deliberately outside your discipline, because the signal that matters will rarely be wearing your job title.

6. Separate the adaptive problem from the technical one before you build

Late in the course we drew a line I now use on every brief: the line between a technical problem and an adaptive one.

Ron Heifetz and Marty Linsky set out the distinction. A technical problem can be solved with knowledge you already have, even when it is hard. An adaptive problem needs new learning, a change in how people think or behave, and no existing expertise will crack it. Their warning is that organisations have a strong bias to treat adaptive problems as technical ones, because technical problems are more comfortable to work on. Automation is the clearest example I came across in the whole course. Governments keep responding to it as a technical problem, mostly by funding reskilling platforms and tools. The harder, adaptive truth underneath is that automation forces a society to renegotiate what work is for, and how people find purpose and security in it. No platform solves that.

The same trap catches technologists constantly. We reach for a tool, a platform, or a re-architecture when the real challenge is that people need to learn something new or let something go. Diagnose the nature of the problem first. If it is technical, your expertise will handle it. If it is adaptive, the tool will not, and the work is to help people through the change instead. Spending a fortune building the wrong kind of solution is what happens when you skip the diagnosis.

7. Decide now what will tell you which future is arriving

The final move turns foresight from a one-off workshop into something that keeps earning its place. You decide in advance what would tell you which future is coming true.

For each scenario you built, you name a small set of indicators, the events or numbers that would signal this particular world is materialising. Then you watch them. If you built a future where trust in AI collapses, you decide today what the early evidence of that would look like, so you are not guessing about it in 2 years’ time. This is what stops a foresight exercise from going stale on a shelf. The scenarios stay live because you are tracking the signals that tell you which one is winning.

Technologists already understand this instinct from monitoring and alerting in production systems. The same idea applies to strategy. Attach indicators and trigger conditions to your big architecture bets, and review them on a regular cadence. When an indicator fires, you do not have to start the analysis from scratch, because you decided what it meant before the pressure was on. That is the difference between a roadmap you defend out of habit and one you can change on evidence.

What this adds up to

Put these together and foresight gives a technologist something our training mostly leaves out: a disciplined way to decide when you cannot be certain. We are taught to engineer answers where the requirements are known. Foresight is the method for the decisions where they are not, and those are the decisions that shape an enterprise for a decade and cost the most to get wrong.

William Orton had the better technology and the larger company. He ran the network the whole country depended on. He still handed the future to a competitor, because he had no method for seeing past the present, and he judged the telephone by what it was on the day rather than what it was becoming. The 7 moves above are, in the end, a method for not being Orton.

If you are making a long-horizon technology decision right now, which of the 7 is your team weakest at: treating foresight as guesswork, backing a single future, setting the wrong horizon, optimising in isolation, scanning only your own field, mistaking an adaptive problem for a technical one, or never deciding what would tell you the plan is wrong?

I write about foresight and enterprise design in my newsletter, The Foresight-Driven Enterprise. If this was useful, that is where I go deeper.

Further Reading

• Casson, Herbert N. 1910. The History of the Telephone. Chicago: A. C. McClurg & Co. (Open‑access text via Project Gutenberg: https://www.gutenberg.org/files/819/819-h/819-h.htm).

• “American Heritage Editors.” 1985. “Hindsight, Foresight, and No Sight.” American Heritage. https://www.americanheritage.com/hindsight-foresight-and-no-sight.

• Ericsson, “Bell, Gray and the invention of the telephone”: https://www.ericsson.com/en/about-us/history/communication/early-developments/bell-gray-and-the-invention-of-the-telephone

• “Herman Kahn.” Wikipedia. https://en.wikipedia.org/wiki/Herman_Kahn.

• “Thinking the Unthinkable: The Nuclear Strategy of Herman Kahn.” Royal United Services Institute (RUSI), 2022. https://my.rusi.org/resource/episode-8-thinking-the-unthinkable-the-nuclear-strategy-of-herman-kahn.html.

• Kahn, Herman. 1960. On Thermonuclear War. Princeton, NJ: Princeton University Press.

• Kahn, Herman. 1962. Thinking About the Unthinkable. New York: Horizon Press.

• Heifetz, Ronald A., and Marty Linsky. 2002. Leadership on the Line: Staying Alive Through the Dangers of Leading. Boston: Harvard Business School Press.

• Donella Meadows, Thinking in Systems: A Primer (Chelsea Green, 2008), via the Donella Meadows Project bibliography: https://donellameadows.org/archives/donella-h-meadows-bibliography/

• Institute for Healthcare Improvement, on the Batalden attribution: https://www.ihi.org/library/blog/magic-every-system-perfectly-designed

• Bishop, Hines and Collins, “The current state of scenario development,” foresight 9(1), 2007, DOI: https://doi.org/10.1108/14636680710727516

• University of Houston, Foresight Graduate Program. “Foresight (M.S.) and Professional Certificate.” https://www.uh.edu/technology/programs/graduate/foresight/.

• Hines, Andy. “Framework Foresight.” Andy Hinesight. https://www.andyhinesight.com/foresight-2/framework-foresight/.

• Cagan, Marty. 2026. “Product Coaching and AI.” Silicon Valley Product Group, February 2026. https://www.svpg.com/product-coaching-and-ai/.

The title of this piece is almost embarrassingly common. Search “how to build an EA practice” and you will find hundreds of articles and frameworks, most of them written by people who have read the right things but know how difficult it is to implement in practice. This one is written from having actually done it, with resistance at every level and no room for the practice to fail.

Almost a decade ago, I joined a data management company to build something that did not exist yet. The engineering culture was strong. A talented CTO had built something real, and the engineers were good at their jobs and knew it. What was missing was any structured way of making architectural decisions at the enterprise level. The engineers were shipping code, but nobody had designed how the technology connected to what the business needed to protect legally, financially, and operationally. There were no principles to guide trade-offs, no governance over how changes got made, and no shared picture of the enterprise that anyone could reason from.

At this company, the reason for establishing the EA practice was not abstract, and that mattered more than I understood at the time. The trigger was a compliance deadline. ISO 27001 and several other regulatory requirements had to be implemented and enforced across the whole enterprise, not just IT but finance, marketing, operations, and legal. GDPR had landed in Europe the year before, and customers everywhere, not only the European ones, were insisting their vendors held proper certifications. No certification, no deal. The CTO hired me to build the architecture practice, and I reported directly to him, a structural detail that turned out to matter more than I expected.

What a Real Practice Needs

Across that engagement and several since, I have come to believe a working EA practice needs twelve things. It is less a checklist than a system, where each element holds up the ones around it and the order matters as much as the content.

Here they are, roughly in order of priority, with the first three being non-negotiable

1. Purpose and business objectives

2. Executive sponsorship

3. The organisation’s risk appetite

4. Vision and principles

5. A structured model of the enterprise

6. Reference architectures

7. Alignment with other frameworks

8. The engagement model

9. Implementation and architecture governance

10. Architecture change management

11. Skills, competencies, and team

12. Measuring and communicating value

Most people building a practice pour their energy into the middle of that list: the reference architectures, the information models, the governance. The failures I have seen, and the near-misses I have navigated myself, almost always trace back to the top: a purpose that was never made explicit, sponsorship that was assumed rather than secured, and a risk appetite nobody surfaced until a decision went sideways. Get the top three right and the rest becomes easier to establish. Get them wrong, and no framework, and no amount of hiring, will ensure a successful practice.

1. Purpose and business objectives

The first thing to do is understanding the enterprise and defining what the EA capability is actually for.

“To improve architecture quality” and “to align IT and business” are aspirations, not concrete objectives. They are what gets written when nobody has done the harder work of sitting with a sponsor and pulling out an honest, specific and measurable objective. For us, the objective was concrete: build a capability that could achieve ISO 27001 certification by the next fiscal year, connect technology risk to enterprise risk, and create a governance model the whole enterprise could actually operate within. That specificity shaped every decision that followed, including how I explained to a sceptical engineer why any of it mattered. The answer was tied directly to customer retention and the company’s ability to keep operating.

2. Executive sponsorship

This is the element most practitioners assume is already in place, then discover too late was never actually secured.

Sponsorship is not a nod in a meeting or a supportive email from someone senior. It is a named, visible, resourced commitment from someone with real authority who will back the practice publicly when resistance comes, and resistance always comes, because change asks people to give up something familiar. Mine was the CTO, and the fact that I reported directly to him was not an administrative detail. It was the mechanism that made the practice legitimate in the eyes of the organisation. Without a sponsor, you have no authority to see anything through, no matter how good or influential an architect you are. That is simply the fact. Teams align to what leadership visibly prioritises, so when engineers pushed back on governance, the signal from the top stayed consistent. Had the CTO been ambivalent, the engineers would have treated architecture as something to work around rather than work within. Before you write a single principle or craft the architecture vision for your practice, get your sponsor on record with an explicit, resourced mandate.

3. The organisation’s risk appetite

Every architectural decision is, underneath it all, a risk decision, and you cannot make good ones without knowing where the organisation actually sits on the risk curve.

Some organisations are conservative by design: heavily regulated industries, public bodies, critical infrastructure. Their tolerance for ambiguity is low and their governance reflects it. Others are built for speed and will carry technical debt in exchange for market velocity. A practice designed for one will likely fail in the other. For us, the compliance deadline made the risk appetite unusually explicit. There was a hard line, a date, and a clear set of consequences if it was missed, which gave every trade-off a reference point everyone could reason from. In most engagements you are not handed that. You have to surface it yourself, through deliberate conversations with the CFO, the risk owner, legal, and the CEO, and you need to do it before you design anything.

4. Vision and principles

Principles come after purpose and risk appetite, because they are derived from both.

They are decision rules. When two credible options are on the table, a good principle tells you which way to lean, based on what the organisation actually values, not what looks good on a slide or suits the loudest voice in the room. A strong set of principles does four things: it enables decisions, aligns the enterprise on shared priorities, supports governance, and reflects the real culture of the organisation. Principles lifted from a template, without being tested against those four, read well and settle nothing. The first real disagreement is where you find that out.

5. A Structured Model of the Enterprise

This is the element many architects find satisfying and everyone else usually treats as optional, until something breaks and nobody can explain why.

The structured model is your comprehensive picture of the enterprise: what the business does, how it does it, which systems support which capabilities, where data flows, and who is accountable for what. It is the foundation that gives every other element something concrete to stand on. Without it, you usually cannot make sense of the enterprise as information is scattered all over the place; some in the heads of people, some in wiki pages and PowerPoint documents.

Defining that structured model explicitly was what let me have genuinely useful conversations with the CFO. I could not just tell the finance team that certain controls were necessary. I had to show them, through abstract architecture views, how a specific gap in the information flow created a specific financial and regulatory exposure. The moment I could connect a technology risk to a financial implication in language the CFO could verify and act on, the conversation changed completely. That is what a structured model buys you: a shared language with the people who do not speak architecture but who hold the decisions you need.

6. Reference architectures

Reference architectures are reusable models, and their value is plain: they save time, create consistency, and give teams something to work from rather than reinvent. For us, they gave the engineering and operational teams a starting point for implementing the 114 controls required under ISO 27001. Instead of each team inventing its own approach to access control or data classification, they had a pattern to follow, which cut variation and review time and made the whole implementation more manageable.

A word on their role. Reference architectures are tools. The moment one becomes a rule that cannot be questioned, it stops being an architectural asset and turns into bureaucracy. Used well, they make delivery faster and more coherent. Used badly, they become the thing teams point to when they say architecture slows everything down, and they are not entirely wrong.

7. Alignment with other frameworks

No practice operates in isolation. Most enterprises already run established frameworks for sales, project management, risk, operations, and compliance, and your EA practice has to fit into that landscape rather than set itself up as a competing authority. The practice does not own a domain the way sales or finance does. It manages and evolves the architecture of the whole enterprise, and every other function is part of that architecture.

The practical question is not which framework is theoretically superior. It is where the enterprise already has planning, change management, and benefits realisation covered, and where the real gaps are that the EA practice needs to fill. For us, that meant working out carefully where the ISO 27001 control framework ended and where architectural governance began, then designing that boundary on purpose. Where existing frameworks did the job, I aligned to them. Where there was a genuine gap, the practice stepped in.

8. The engagement model

Establishing an EA practice is hard and the most common reason is not the poor quality of architecture artefacts. It is that the architecture leader builds a practice that is technically sound but the organisation never truly adopts.

The engagement model defines how the practice connects to the rest of the organisation: who comes to you, when and why, how you show up for different groups, and where architecture sits in decision-making. It is fundamentally a question of organisational psychology, because different parts of an organisation carry entirely different concerns and entirely different reasons to embrace or resist what you are building.

For us, the resistance came from two directions. The engineers and product teams worried that standardisation and governance would slow delivery, and from where they stood that was not unreasonable. They had spent years building something, and here was someone arriving to put structure around it. The business heads in marketing, finance, and operations were not hostile so much as indifferent, which is the harder problem, because indifference is harder to move than opposition. Sponsorship gets you into the room. Moving people who do not report to you, and who feel no urgency, takes influence you earn rather than authority you can invoke.

The way through was not a presentation or a strategy document. It was late evenings working through specific concerns with specific executives. It was architecture views built around each person’s actual problem rather than a generic overview of what EA could offer. Every conversation started with their concern and worked towards how the practice could address it, and that repeated engagement is what built the legitimacy the practice needed to operate.

9. Implementation and architecture governance

Governance has a reputation problem. In most organisations it means committees that exist to slow things down, and that reputation is not always unearned. Think of the architecture review boards that meet mainly to slow things down, or the ivory-tower architects who theorise without grasping what their decisions mean in practice. Done well, governance is a lightweight, embedded process that gets the right decisions in front of the right people at the right time.

For us, governance could not stay inside the IT organisation alone, because delivery involved external partners who had to work within the same controls. The model had to reach into third-party delivery, which added complexity but clarified something useful: governance is not a gate at the end of a process. It shapes how the target architecture is developed, how it directs change as things get built, and how it evolves as conditions shift. It is a continuous engagement. For example, we used Architecture Decision Records to capture the decisions we made, and a review board to grant exceptions. Every exception granted was linked to an entry in the risk register and tracked by the risk team until it was closed.

10. Architecture change management

The architecture you design on day one will not be the architecture the organisation needs in two years. If you have not designed for that from the start, you spend those two years watching carefully built decisions slowly go stale.

Architecture change management governs how the target architecture evolves: when a decision needs revisiting, who is involved, and how the impact of a proposed change is assessed before it is made. This is what gives a practice staying power beyond its first purpose. Without it, even a well-built practice tends to drift. An EA practice exists to support change, innovation, and agility, but that value rarely shows up early. It surfaces later, which is exactly why the twelfth element, measuring and communicating value, is what keeps the budget flowing to evolve the capability.

11. Skills, competencies, and team

No architect builds an EA capability alone. I certainly did not, and I want to be direct about why that matters. Too many architects try to carry a capability as a solo effort, become the bottleneck every decision passes through, and eventually burn out, leaving nothing sustainable behind. The practice has to be built into a team.

The team I assembled spanned cloud engineering, security architecture, and technical programme management: different domains, different strengths, and one shared understanding of what we were trying to achieve. Building it was the hardest part of the whole effort, harder than the compliance work and harder than the governance design. The difficulty was not only finding the right people. It was that the engineers who became the most committed contributors to the practice were, at the start, among its loudest critics. They believed architecture would slow delivery, and they said so. What changed their minds was experience. They watched enough good decisions get made well that they began driving the processes themselves, running the agile disciplines and holding others to the standards they had once resisted.

12. Measuring and communicating value

Practices rarely fail on architectural quality. They fail because the value they create stays invisible to the people who control the budget.

Architecture work produces outcomes that are hard to point to: better decisions, risks avoided, complexity kept from compounding. None of those show up on a dashboard, and in organisations where budget decisions run on visible evidence, invisible value gets cut. For us, putting architecture into financial terms was what opened the serious conversations. Showing the CFO how a specific information gap created a specific regulatory exposure, in terms he could verify and act on, was a different conversation from anything a standard architecture review could produce. Building that rhythm, tying architectural outcomes to the planning cycles and financial metrics executives actually use, is what decides whether the practice is successful.

How You Know the Practice Is Working

The clearest signal came when the CEO started requesting time with me directly. I had not lobbied for it. He had simply found that having architectural thinking – trade-off visibility, dependency mapping, capability gaps as strategic risk – in his decisions was useful, and he wanted more of it. When the people running the business seek out the practice rather than tolerate it, something real has changed.

The other signal was the engineers and operational staff – the builders. The ones who had argued hardest that architecture would slow them down became the ones holding others to the standards and running the processes they had once resisted, without being asked. That does not come from a mandate. It comes from enough experience of good decisions, made well, to shift what people believe is worth caring about.

That is what a successful practice looks like. Not the volume of artefacts it produces, but the shift in how the organisation reasons about the decisions that shape it.

What to Take Away

• Start with purpose: a specific, explicit answer to what this is for, tied to business outcomes rather than aspirations.

• Secure your sponsor before building anything: named, resourced, and publicly visible. Everything else depends on it.

• Surface the risk appetite early: it shapes every decision you will make before you have made any of them.

• Let principles follow purpose: they have to reflect the enterprise you are actually in, not a template.

• Build your engagement model before your governance model: the architecture of stakeholder relationships carries more than the architecture artefacts.

• Invest in your team as seriously as your frameworks, and work to embed architectural thinking across functions: the practice that outlasts you is built with people.

• Measure and communicate value constantly, tying deliverables to outcomes the business already tracks: invisible value gets cut.

Frameworks are useful. The experience of studying and leading change is more useful. Use both.

If you are building or rebuilding a practice right now, which is your weakest link today: the sponsor, the value you can prove, or the people you need to bring with you?

I write about the intersection of strategic foresight and enterprise design, and how executives can make better-informed decisions there. If this was useful, share it with a leader who would benefit.

Many enterprise architects first meet “the future” as a date on a slide: “2027 Target Architecture.”

That “future-state architecture” usually means someone higher up took a single strategy narrative, treated it as a prediction, and asked you, as an enterprise architect, to design everything around it and translate it into execution. When that future doesn’t materialise, your carefully crafted roadmap becomes an artefact of a world that never happened.

You’ve probably seen it at work: a new leadership team, bold digital ambitions, a new AI strategy, maybe a consulting deck full of market forecasts and whatever the trendy buzzwords are that quarter. The organisation picks one path – cloud‑only, platform business, Agentic‑AI‑only play – and the architecture team is told to “make it real.” Three years later, regulation shifts, macro conditions change, the strategy pivots, and now your architecture is optimised for a future the company no longer believes in.

Strategic foresight, as a practice, exists because this pattern keeps repeating — and it starts from a simple premise: in complex environments, you cannot reliably predict a single “right” future, no matter how much data you collect. What you can do is explore several plausible futures, see how each one stresses your organisation differently, and design capabilities and options that keep you effective across that range.

This is where scenario planning should matter to architects. Not as a storytelling exercise bolted onto strategy, but as a disciplined way to move from “multiple futures” to “capabilities” and then to actionable roadmaps.

Before we get into how enterprise architects can apply scenarios in practice, we need to clear up some persistent confusion about what foresight and scenarios are – and what they are not. That confusion is a big part of why many architects dismiss foresight as vague or fluffy, even though the underlying methods are anything but.

Common Foresight Misconceptions

Foresight vs prediction

In many organisations, “thinking about the future” defaults to prediction: a single number, a single curve, a single story extended into the future. It looks precise, but decades of work on scenarios and judgment under uncertainty argue that overconfidence in single‑point predictions is a major reason strategies and big programmes fail when conditions change [1].

Strategic foresight takes a different stance. Practitioners assume uncertainty is structural rather than a temporary data problem [2]. The goal is not to be “right once,” but to improve decisions across a range of plausible futures [1, 2]. That means deliberately broadening the space of possibilities and then designing responses that are resilient or adaptable, rather than optimised for a single forecast. For architects, the key shift is from “what will 2027 look like?” to “what must we be able to do across several versions of 2027?”

Foresight vs forecasting

Forecasting still matters. You need demand curves, adoption rates, cost trajectories and budget projections. Forecasting and foresight are complementary, not interchangeable. Forecasting narrows uncertainty around a baseline; foresight keeps multiple structurally different futures on the table, including ones that would break your existing models [2].

When forecasting dominates, organisations tend to lock architectures around the most “probable” scenario and under‑invest in adaptability. When foresight is present, forecasts remain, but you also use scenarios to expose blind spots, test strategies, and surface capabilities you’d need if the world takes a different turn. For an enterprise architect, that is the difference between drawing a single rigid target state and designing a capability‑led roadmap that can flex as drivers of change and signals emerge.

“Scenarios are soft, architecture is hard”

Another misconception is that scenarios are soft, qualitative fluff, while enterprise architecture is hard, quantitative, and closer to engineering in its rigour. In reality, much of EA is already driven by qualitative assumptions: which markets matter, how regulators might act, which partnerships will hold, which technologies will mature. Scenarios don’t introduce fuzziness; they make those underlying assumptions explicit and testable instead of letting them lurk, unexamined, behind “hard” diagrams and models.

A long line of research and practitioner experience with scenario practice argues that the real risk is letting implicit future assumptions drive large, irreversible commitments [1, 2]. For enterprise architects, scenarios are a way to surface and confront those assumptions early before they are baked into platforms, integrations, and operating models.

“Scenarios are a one-off workshop”

Many people also believe scenarios are something you do once at an offsite, producing some colourful narratives that never touch day‑to‑day decisions. Corporate foresight research and public‑sector guidance stress the opposite: scenarios are most valuable when they are revisited, updated, and connected to regular decision cycles [2].

For EA, that means tying scenarios to existing rhythms: annual strategy and portfolio cycles, roadmap refreshes, and major principle or standard reviews. Instead of a one‑time exercise, they become a standing input into how you shape your capability map and architecture over time. That is the foundation we’ll build on when we move from scenarios to capabilities, but first, let’s define scenarios.

What Scenarios and Scenario Planning Actually Are

When people say “scenario”, they often mean “plan B” or “a worse forecast”. That’s not how the field of futures and foresight uses the term. In strategic foresight, scenarios are structured “what‑if” stories about how the future might unfold, each built from different combinations of drivers and uncertainties. They are not strategies or predictions; they are alternative environments in which your strategies and designs must survive.

A standard definition from the literature describes scenarios as several informed, plausible, and imagined alternative future environments in which decisions may be played out [3, 4]. The emphasis is on plausible and alternative: plausible, so they are grounded in real drivers of change; alternative, so they stretch beyond a single extrapolated trend line. For enterprise architects, you can think of scenarios as different “operating contexts” for your organisation: different patterns of regulation, competition, technology, behaviour and shocks that will shape what your architecture needs to enable.

Scenario planning is the method for building and using those scenarios in a disciplined way [3]. The classic intuitive‑logics process, made famous by Shell’s planners in the 1970s, can be applied lightly or deeply depending on how much driver analysis you invest in — the full method runs to eight stages [1]; this article condenses it to three:

1. Define the focal issue and time horizon: e.g. “How does our business model and architecture need to evolve by 2030?”

2. Identify key drivers and critical uncertainties: scan political, economic, social, technological, legal and environmental forces; then separate relatively predetermined trends from genuinely uncertain, high‑impact factors.

3. Develop scenario frameworks and narratives: combine critical uncertainties into 2–4 distinct futures and write coherent, memorable stories that bring each to life.

Well‑run scenario work doesn’t stop at stories. The method is explicitly intended to support strategy and decision‑making under uncertainty, including testing strategies against different futures and identifying resilient options [1, 2]. That’s the bridge we’re going to walk across into architecture.

Scenarios as a Foresight Method (and Why Enterprise Architects Should Care)

Scenarios are one of the core methods in strategic foresight because they do three things traditional planning struggles with. First, they help organisations handle deep uncertainty by rehearsing multiple structurally different futures rather than betting everything on a single forecast. Second, they surface hidden assumptions: when you write parallel stories and ask “what would we actually do here?”, you discover what you’ve been taking for granted about markets, technology and institutions. Third, they widen the option set by forcing teams to explore responses they would never consider if they only planned around a baseline [1, 2].

Practitioner case work — most notably at Shell and in public sector foresight programmes — suggests that scenario‑informed organisations tend to make more robust decisions [2], but systematic empirical research on these effects remains limited [1]. The point of scenario planning, put plainly, is to build an organisation that can adapt when the future is unknown, which is about as clear a mandate as enterprise architects can get.

For enterprise architects, scenarios start to matter when they change what you build and in what order. The real value is not the narratives themselves, but the way they change your view of which capabilities you need, how those capabilities might differ across futures, and how you structure your roadmaps and platforms so you have options rather than one brittle line to a single “2027 Target Architecture.”

EA “Scenarios” vs Foresight Scenarios

If you’ve worked with TOGAF, you already know one use of the word “scenario”. TOGAF business scenarios are complete descriptions of a business problem, both in business and architectural terms, that enable individual requirements to be viewed in relation to one another in the context of the overall problem [5]. They are close to projects and programmes: one situation, one set of actors, one set of performance targets, leading to one set of requirements — and from those, a justified architecture response. Even when the scope extends beyond IT, the horizon remains fixed on a specific, bounded problem . This is a useful requirements technique, but it has almost nothing in common with how the foresight field uses the term “scenario”

TOGAF is not alone in this. BIZBOK uses scenarios to provide situational context for applying business architecture to specific business needs and for analysing capability gaps within a known strategic direction. ITABoK and SAFe both plan from a stated strategic direction rather than across alternative ones. Defence frameworks such as DoDAF and NAF go further in formalising scenario‑based descriptions: their operational viewpoints use explicit, deterministic execution scenarios — actors, activities, states and exchanges — as a primary mechanism for deriving and verifying capability and system behaviour. These are, therefore, highly specific operational use‑cases inside a fixed concept of operations, not scenarios in the foresight sense of multiple plausible futures.

Scenarios in the foresight context sit at a different level entirely. Instead of describing one problem in one expected environment, they describe several informed, plausible and imagined alternative future environments in which decisions may be played out. They reach further in time, combine multiple drivers and uncertainties, and are not tied to a single initiative. Where a TOGAF business scenario says “here is how our claims process should work in the next release”, a foresight scenario says “here are four very different worlds for insurance over the next decade — now let’s see what that does to our business model and capabilities.” That is the layer that no mainstream EA framework covers on its own — and the layer this article is concerned with.

How Foresight Scenarios Are Built

Foresight doesn’t just deal in different stories about the future; it also distinguishes different ways of constructing those stories. The distinction that actually matters for enterprise architects is the split between explorative and normative scenarios [4].

Explorative scenarios focus on the external environment and examine past and present trends that shape likely futures. Because they are treated as independent of your organisation’s specific values or desires, they assume the environment changes first, and that your organisation responds. Your architecture needs to be able to cope with a range of futures you don’t control. Note: Classic scenario planners (like those from the Shell school) heavily favour this approach, arguing that external scenarios should remain value-neutral testbeds to stretch executives’ mental models and avoid bias.

Normative scenarios, on the other hand, put the organisation’s choices and values at the centre. They are constructed from alternative images of the future that may be highly desired (or feared) and are conceived in a retro-projective—or backcasting—way. Their purpose is not just to brace for the future but to help create it, which is where most transformational ambition sits [4].

For EA, explorative scenarios help you understand the range of external conditions your architecture needs to cope with; normative scenarios help anchor the capabilities you deliberately want to build to achieve a desired end-state, even when the environment is messy.

Method‑wise, explorative scenarios pair naturally with testing and resilience work; normative scenarios pair with design and backcasting. Explorative scenarios are the obvious input to wind‑tunnelling: you treat each one as an external test environment and ask how resilient your current strategies and big architecture bets are if the world moves that way. Normative scenarios are the obvious input to backcasting: you start from a deliberately chosen future state and work backwards to the capabilities, architectures and decisions you’d need to help create it. In practice, wind‑tunnelling is most naturally introduced through explorative scenarios, but you can apply the same underlying logic to normative ones too; the question simply shifts from “Does this survive?” to “Does this move us towards the future we say we want to create?”

The intuitive‑logics process is primarily explorative — it first builds scenarios of the external environment, then uses them to stress-test and develop a strategy. If you are working in a more normative mode — designing the future you want to create — you will supplement the intuitive-logics steps with backcasting and vision-led techniques rather than relying on them alone. Whichever mode you are working in, you still need to decide how to structure the scenario content itself – and two approaches are worth knowing:

1. A 4‑archetypes method – Dator’s four archetypes (continued growth, collapse, disciplined society, and transformation) map onto capability patterns as follows: continued growth tends to map to scaling and optimisation; collapse to resilience and recovery; disciplined society to compliance and cost‑control; and transformation to innovation [6]. This helps you avoid four “growth” stories in different outfits.

2. The familiar 2×2 matrix – two critical uncertainties on the axes, four quadrants as scenarios [1, 2]. It is simple and widely used, but often overused; on its own, it doesn’t guarantee variety unless you choose genuinely different uncertainties.

You don’t need to be a connoisseur of scenario methods to get value as an enterprise architect. In practice, it is rarely either/or — most organisations need both. The useful question is: where does your organisation sit on the control spectrum? If you have limited influence over your environment, lean toward explorative; build scenarios of external futures and use them to stress-test your architecture bets. If you have significant market or regulatory influence, lean toward the normative; design the future you intend to help create, and backcast from it. Most foresight-informed enterprise architects will do some of each, which is exactly why the distinction matters: it tells you which mode you are in at any given point, and therefore which techniques to reach for.

Testing Strategies with Scenarios

Once you have built a small set of scenarios — whether explorative, normative, or both — the next useful move is simple: take what you’re already planning to do and ask, “How does this hold up in each of these scenarios?” That is what wind‑tunnelling does. It treats each scenario as a test environment and runs your strategies and architectural bets through it, the way a physical wind tunnel tests a design’s behaviour under different conditions [2].

In “prepare” mode, you usually start with explorative scenarios. You line up your big bets – “single‑vendor ERP”, “API‑first modular core”, “data mesh”, “agentic‑AI‑first customer service”, major sourcing or platform choices – and, for each scenario, you ask three blunt questions:

1. Does this still make sense here at all?

2. If yes, what extra risks, costs or constraints show up in this future?

3. What additional capabilities would we need to make this viable rather than fragile?

You can do this with nothing more than a matrix: scenarios on one axis, strategies and architecture themes on the other, and a short qualitative judgement in each cell. The goal is not a beautiful heatmap; the goal is clarity on which directions are robust or resilient across many futures, which are narrow bets that only work in a few, and where you need options instead of irreversible commitments. The wind‑tunnelling step is where scenario planning turns into scenario analysis: you systematically assess how each strategy or architecture pattern behaves across your futures, and let that evidence shape your capability and roadmap choices.

In “shape” mode, you can run the same exercise on normative scenarios as well, this time checking whether your initiatives genuinely support the future you say you want, rather than just coping with whatever happens. That’s often where you discover that some cherished initiatives are, at best, neutral to your stated long‑term intent – or that you’re missing key enabling capabilities entirely.

Testing your strategies with scenarios on their own doesn’t redesign anything; it shows you where your current strategies and architecture patterns are brittle, over‑fitted or under‑powered. The constructive next question is: In each scenario, what must we actually be able to do that we cannot do today? That’s the move from scenarios to capabilities.

From Scenarios to Capabilities

The outputs of wind‑tunnelling – the gaps, brittleness, and missing capabilities you identified – become the direct input to the capability mapping workshop. You’re not starting fresh; you’re taking the “we’d need this” notes from your wind‑tunnel matrix and turning them into a structured capability map. That’s the bridge from scenarios to capabilities, and it aligns with how scenario‑based strategic planning and capability‑driven planning are described in the literature: use scenarios to surface strategic implications, then translate them into required organisational abilities [2, 7].

You can run this as a simple, structured workshop sequence. Scenario‑based planning work often recommends dedicated “implications” or “from scenarios to action” sessions rather than stopping at narratives [2]. This is where you make that explicit for EA.

1. Start in the scenario, not in today’s org chart.

For each scenario, briefly “step into” that future with the group:

• What does a typical day look like for key customers, regulators, and partners?

• What major events or constraints are present (e.g. strict AI regulation, supply shocks, new platforms dominating your market)?

Foresight practice emphasises this kind of immersion and concreteness to avoid getting stuck in abstract slogans; people reason better about implications when the future context feels real. Keep it concise but concrete enough that people can reason about actions, not just adjectives.

2. Ask the critical question: “What must we be able to do?” — and capture it.

Still in that scenario, ask:

• “In this world, what must our organisation be able to do to remain relevant, successful, or compliant?”

• “What would we need to be able to do faster, cheaper, at scale, or with more reliability than today?”

Scenario‑based strategy work recommends translating scenarios into strategic options and requirements [1, 2, 7]. Frame those requirements as capability statements, not systems or projects: “detect emerging risks in near‑real‑time”, “reconfigure our partner ecosystem in weeks, not years”, “settle 80% of simple claims straight‑through”, “spin up and shut down new products with minimal IT involvement.”

As you capture them, group closely related items under a provisional working label — for example, “monitor regulation continuously”, “simulate impact of new rules”, and “rapidly adapt controls” might sit under “regulatory sensing and response.” Keep the labels technology‑agnostic and treat them as working drafts, not final definitions. You are not building the capability map yet; you are making the raw material scannable and ready for cross-scenario comparison.

3. Repeat across scenarios, then consolidate into stable capabilities.

Run steps 1–2 for each scenario. Only once you have the full cross-scenario picture do you finalise your capability map. Then:

• Merge identical or very similar items across scenarios into a single stable, technology‑agnostic capability label (e.g. if three scenarios each produced a variant of “regulatory sensing and response”, that becomes one capability on your map).

• Mark which scenarios each capability appears in and with what intensity (e.g. “must‑have”, “important”, “only in scenario 3”).

• Note where the maturity requirement changes: a capability might exist today but needs a very different scale, speed, or quality in certain futures.

Clustering after consolidation — rather than within each scenario — ensures your capability labels are stable and comparable across futures, as capability‑based planning guidance describes the process [5]. Scenario‑based strategic planning and scenario‑driven roadmapping both recommend identifying robust elements (common across scenarios), scenario‑specific elements, and timing/maturity differences as inputs to strategy and roadmaps [1, 2, 7]. You’re doing the same, but through the lens of capabilities.

4. Make the patterns explicit

At this point, you can step back and look for patterns:

• Which capabilities show up as “must‑have” across all scenarios? These are your resilient bets.

• Which are only critical in a subset of scenarios? These are candidates for more option‑like, staged investments.

• Which archetypes (continued growth, collapse, disciplined society, or transformation) are driving which capability clusters? This can reveal whether your portfolio is over‑weighted towards one type of future — a pattern that the four archetypes make visible in a way a standard capability map does not.

Taken together, these three questions give you a prioritised, scenario-weighted capability map — and capabilities become the shared language connecting futures, strategy, and architecture.

5. Translate into EA artefacts

Only after you have a scenario‑annotated capability map do you start mapping into more familiar EA artefacts:

• Link capabilities to business services, processes, value streams, applications and platforms.

• Identify where existing architectures already support a needed capability, and where there are gaps or bottlenecks.

• Flag capabilities that require new principles, standards or reference architectures.

Scenario‑driven roadmapping work explicitly combines environment‑oriented scenarios with company‑oriented roadmaps, using capabilities as the connecting layer [7, 8]. Enterprise and business architecture practice already treats capabilities as the key link between strategy and portfolios; here, you’re simply ensuring those capabilities are futures‑informed and foresight-driven.

If, after doing these steps, your capability map looks more or less like your “business as usual” view, something went wrong. Either the scenarios stayed too close to today, or the group never really left current constraints. A simple litmus test, consistent with scenario‑to‑strategy guidance, is this: can you point to specific capabilities and honestly say, “we only saw the need for this when we looked at that scenario”? If not, you’ve probably done an interesting storytelling exercise, not yet foresight‑driven enterprise design work.

From Capabilities to Roadmaps

By this point, you have something most architects never get: a capability map annotated by scenarios. The point is not to freeze this into a one‑off roadmap, but to use it as the core of a foresight‑driven enterprise design capability – a cycle you can run repeatedly, not a workshop you do once [2].

In that cycle, roadmapping is the sequencing and learning step. You take the scenario‑annotated capability map and decide what to move forward with now, what to hold as an option, and where to place decision points as the environment evolves [7]. The roadmap becomes a living artefact that you revisit as you refresh your scanning and scenarios, rather than a static “2027 Target Architecture” picture you defend for three years.

Start with prioritisation, not boxes and arrows. Look at your capability map and ask: which capabilities are must-haves across all scenarios (resilient bets), which are only critical in specific futures (scenario‑specific bets), and which exist today but need a major jump in maturity (speed, scale, quality) under certain scenarios. Use this to cluster capabilities into a handful of roadmap themes – for example: “data‑driven risk sensing”, “partner ecosystem integration”, “automation and straight‑through processing”, “resilience and recovery”.

Next, define increments and decision points rather than a single end‑state. For each capability theme, identify a small number of maturity steps over time, decide what the next concrete increment is, and mark explicit decision points where you can double‑down, pivot or pause depending on how the real world evolves. Robust capabilities can move earlier and harder; scenario‑specific ones might start as small, option‑like investments that you scale if the corresponding future starts to materialise [7, 8].

Only then worry about how you visualise it. Whether you use a classic time‑based swimlane, a layered EA roadmap, or something more visual is secondary. If you like radial visuals, a sun‑ray roadmap works well here: put your long‑term intent or focal issue in the centre, use rays for capability streams, and rings for horizons. The key is the logic – capabilities, increments and decision points driven by scenarios – not the specific diagram template.

In other words, the value here is not another static target architecture, but a reusable way of thinking – a foresight‑driven enterprise design capability that treats scenario planning as an ongoing method to sense change, re‑imagine your enterprise, and adjust your capability roadmap before the future forces your hand.

References

1. Wright, G., Bradfield, R., & Cairns, G. (2013). Does the intuitive logics method – and its recent enhancements – produce “effective” scenarios? Technological Forecasting and Social Change, 80(4), 631–642.

2. van der Heijden, K. (2005). Scenarios: The art of strategic conversation (2nd ed.). Wiley.

3. Chermack, T. J., & Lynham, S. A. (2002). Definitions and outcome variables of scenario planning. Human Resource Development Review, 1(3), 366–383.

4. Spaniol, M. J., & Rowland, N. J. (2018). Defining scenario. Futures & Foresight Science, 1(1), e3. https://doi.org/10.1002/ffo2.3

5. The Open Group. (2018). TOGAF® standard, version 9.2. The Open Group.

6. Dator, J. (2009). Alternative futures at the Manoa School. Journal of Futures Studies, 14(2), 1–8.

7. Hussain, M., Tapinos, E., & Knight, L. (2017). Scenario-driven roadmapping for technology foresight. Technological Forecasting and Social Change, 124, 160–177.

8. Cheng, M. N., Wong, J. W. K., Cheung, C. F., & Leung, K. H. (2016). A scenario-based roadmapping method for strategic planning. Technological Forecasting and Social Change, 110, 164–176.

Most organisations are designed for stability. They optimise for a known world, stripping out redundancy to maximise efficiency. The problem, as we discussed in the last edition, is that the environment they operate in today is more chaotic than ever. What used to be a VUCA world is now more brittle (fragile), anxious, non-linear, and incomprehensible. While there are different acronyms used to describe our environment, VUCA, TUNA, BANI, this article focuses on what leaders need to think about to ensure that their organisations can not just survive, but thrive in such environments.

In Part 1, we explored the concept of antifragility (systems that gain capability from stress) using the Titanic and the human immune system as analogies. But a critical question remains: how do we actually build such systems?

Before we move to the principles, I want to address a thoughtful comment I received from a reader on LinkedIn who works in maritime regulation:

This comment strikes at the heart of the practitioner’s dilemma, and it deserves a careful answer.

The reader is right; the maritime system, which I highlighted in Part 1, improved via reactive learning after the Titanic sank (learning from failure). But the deeper insight is that in safety-critical domains, we cannot rely on “real-world” trial-and-error because the cost of failure is existential. You cannot sink a ship to learn how to build a better one. You cannot crash an aircraft to refine flight dynamics.

This is where the distinction between learning from catastrophe and learning from design becomes critical.

In high-reliability organisations (including aircraft carrier decks, nuclear plants, and trauma centres), teams practice what researchers call “trials without errors¹.” They simulate stress through drills and near-miss reporting. They learn without paying the price in lives.

Antifragility in a business context does not mean betting the company on wild experiments. It means designing a portfolio with a robust core and antifragile edges, being able to exploit and explore, and actively seeking out stressors that make your business stronger.

The maritime system improved after the catastrophe because it forced investment in new safety processes while maintaining proven operational practices. A catastrophe-driven change is expensive, but a designed antifragile system achieves the same result proactively.

Analysis of high-performing companies suggests that they allocate approximately 70% to core improvements, 20% to adjacent opportunities, and 10% to transformational initiatives². This portfolio approach is supported by evidence on organisational ambidexterity: firms that balance exploitation (efficiency in core operations) with exploration (experimentation at the edges) significantly outperform those that do only one of the two³. These experimental edges become antifragile when they’re designed to fail fast, cheaply, and informatively; each failure teaches the organisation without threatening the core. More on this shortly.

The key is many small, reversible experiments that enable data-driven, decisive action. Empirical evidence from 35,000 startups shows this approach accelerates learning and performance; A/B testing enables startups to introduce new products 9–18% faster, rapidly scaling winners while abandoning underperforming initiatives⁴.

This design separates robust core operations from experimental edges. In portfolio terms (the 70% core, 20% adjacent, 10% transformational allocation noted above), this model reflects real options theory; the core operations generate predictable returns, while the experimental portfolio functions as embedded real options that preserve strategic flexibility by limiting downside losses if experiments fail, while capturing upside potential if they succeed. This enables organisations to balance immediate operational performance with long-term adaptive capability⁵

Before I continue, it is important to acknowledge the fundamental limitation that the research landscape on antifragile organisational design is conceptually rich but empirically thin.

There is substantial, validated research on the component principles I discuss below: psychological safety, organisational ambidexterity, high-reliability organising, slack resources, and learning from small failures. Each has decades of empirical support linking it to organisational performance. However, research that explicitly demonstrates how these principles, when combined as an integrated system, produce measurable antifragile outcomes (capability gain from stress, not just resilience) remains limited. Most empirical research stops at resilience. But as we established in Part 1, resilience and antifragility are not the same thing.

In the principles that follow, I share five fundamental truths that are grounded in a synthesis of organisational research, Taleb’s concept of antifragility⁶, and Edzo Botjes’ work on its application to organisational design⁷ (from Part 1), distilled into actionable principles to ponder. They highlight how organisations learn, adapt, and perform in the face of uncertainty. Consider these as design heuristics; evidence-informed guidelines that require adaptation to your context, not rigid prescriptions guaranteed to produce antifragility. Whether these principles, when enacted together, create true antifragility (gain from disorder) versus superior resilience (robust recovery) remains an empirical question that practitioners and researchers must explore together.

Five Principles for Antifragile Design

Principle 1 - Instruct Learning, Not Just Performance

Picture a pharmaceutical company discovering a fatal flaw in a drug three months before launch. A manufacturing defect. An engineer spotted it during a routine test and reported it immediately. The natural response would be to celebrate the catch, investigate the root cause, fix it, and document the lesson.

Now, picture the same company with a different culture. The engineer sees the same flaw. But the manufacturing division is under pressure to hit timeline targets. The engineer’s manager has a bonus tied to “no delays.” The engineer knows that reporting the issue will trigger a three-month investigation. So they do not report it. The drug launches. Two years later, regulators discover the flaw. The company faces fines, reputational damage, and lawsuits. The flaw could have been caught; it was not because the incentive structure punished bad news. This is the opposite of antifragile. The organisation is teaching its people, the ones closest to the truth, to hide information. Put another way, it is converting weak signals into silence.

Research on team learning found that when members believe their team is psychologically safe (i.e., they trust that admitting errors or asking for help will not damage their reputation), they engage in what researchers call “learning behaviour”: seeking feedback, discussing errors, and proposing experiments⁸. And critically, teams with high psychological safety perform better, not worse, than those with high “compliance culture.” The effect flows through a simple mechanism: safety leads to speaking up, which, in turn, enables early problem detection, which, in turn, leads to better outcomes. The mechanism is straightforward. If you hide errors, you get unpleasant surprises. If you surface errors early, you get problems you can fix.

You can operationalise this by decoupling error reporting from performance evaluation. If your performance review system penalises the person who discovers a flaw, or the person who made the mistake, you have built a system that prizes ignorance. Instead, institute blameless post-mortems that focus on systemic causes rather than individual culpability. Amazon institutionalises this through their Correction of Error (COE) process⁹, a blameless post-incident analysis framework that focuses on systemic causes rather than individual fault. The process explicitly asks, ‘Why did our systems allow it?’ rather than ‘Who did it?’ In practice, this philosophy means focusing on documenting systems and processes, identifying how teams and organisational structures enabled the problem, rather than on individual accountability. This protects the engineer while scrutinising the process, creating a culture where surfacing errors transparently enables the entire organisation to build stronger systems by learning from individual mistakes.

Finally, make the invisible visible by measuring “near-miss reporting” as a leading indicator of safety culture. In aviation, airlines measure this religiously. A sharp drop in reported near-misses is treated as a warning sign, not a success (it suggests people are hiding problems again). A unit reporting zero near-misses is not safer; it is blind.

Principle 2 - Embrace Chaos and The Strategy of Small Losses

Antifragile systems gain from disorder and require stressors⁶. Your immune system does not become stronger without encountering threats. Your team does not become more adaptive without facing challenges. But, as we noted in Part 1 with the immune system, dose matters. Existential stress kills the system, but bounded stress strengthens.

The “strategy of small losses,” articulated by Sitkin¹⁰, emphasises deliberately conducting modest-scale, thoughtfully planned experiments with uncertain outcomes to foster organisational learning. Small failures teach organisations how their systems break by exposing weak links when the stakes are low. This creates what Sitkin calls “learning readiness,” a recognition of risk and motivation for change, which keeps organisations vigilant rather than complacent¹⁰

Netflix exemplifies this through “Chaos Monkey,” a tool that randomly disables servers in production. Why deliberately break your system? Because if you never test your resilience, you may discover it fails catastrophically when a real outage hits. By injecting controlled chaos, Netflix’s engineers build systems that degrade gracefully rather than collapsing entirely. This is engineering for resilience through controlled stress; the system learns to withstand failure, not necessarily gain new capabilities from it, but the practice demonstrates the principle of bounded experimentation.

The same logic applies to strategy. A startup that launches ten small pilots, expecting six to fail, is safer than one that bets everything on a single “perfect” product. The failed pilots cost less and teach faster. The winners fund themselves. The portfolio survives through diversity, not perfection. This is not recklessness. It is bounded experimentation. The losses are capped, but the learning is unbounded.

You can start this bounded experimentation through practices like Chaos Engineering. If you operate critical systems, regularly run “what-if-this-fails” scenarios. Can you survive a key supplier exit? A 40% talent loss in engineering? A regulatory crackdown on your core market? Document the answers and fix the vulnerabilities.

You could also implement Red Teaming, where an independent team simulates adversarial attacks on your organisation to test whether your cybersecurity, crisis response, or strategic assumptions can withstand hostile pressure.

For new initiatives, use reversible experiments rather than betting on one massive transformation. Run many small pilots with explicit kill criteria and rapid iteration. Most value comes from discovering what NOT to do.

Amazon’s “two-way door” decision framework operationalises this principle: reversible decisions with limited consequences that can be easily undone, enabling teams to “act with only about 70% of the data” rather than waiting for certainty. This approach recognises that rapid, reversible experiments that limit downside while preserving upside are how modern organisations drive innovation.

Principle 3 - Build Variety Where It Matters

Imagine two hospitals. Hospital A has standardised everything: one supplier for all surgical instruments, one protocol for all procedures, one training curriculum for all nurses. It is efficient. Costs are down 15%. Hospital B is messier. They have three suppliers for critical instruments (which are more expensive). They allow surgeons discretion in which protocol to follow, depending on patient complexity. Nurses get training in multiple specialities. It costs 8% more overall. But they have a range of options (requisite variety)

During a pandemic, supplier A gets hit. A factory closes. Hospital A cannot operate. All their instruments come from a single source that is now overwhelmed or shut down. Hospital B seamlessly switches to Supplier B. Their nurses, cross-trained in multiple areas, fill gaps when intensive care overflows into other units. Their surgeons, used to adapting protocols, manage novel patient presentations.

Hospital A is more cost-efficient in terms of stability, while Hospital B is antifragile.

This principle is grounded in W. Ross Ashby’s foundational law of requisite variety, which holds that a control system must possess equal or greater complexity than the system being controlled. Ashby proved that “only variety can destroy variety¹¹.” Applied to the pandemic example above, we see that Hospital B’s internal organisational variety, i.e., multiple suppliers, cross-trained staff, flexible protocols, enabled it to absorb disturbances that overwhelmed Hospital A’s homogeneous structure.

The strategic question is not whether to increase variety, but where. You want options where it matters (suppliers, critical skills, decision pathways). Conversely, you want standardisation where it matters (compliance protocols, safety interfaces, core governance).

Applying this involves designing a modular architecture. Build your systems where components can be swapped or updated without redesigning the whole. A monolithic system is efficient until it breaks; a modular system trades initial complexity for resilience but is vastly more adaptable.

It also requires cognitive diversity. Hire for disagreement but bias for action; diversity creates value only when teams can convert debate into timely decisions. A leadership team of people who all think similarly will all be blindsided by the same black swan. Diversity of background, function, experience, and worldview increases the variety of scenarios your organisation can see and respond to.

Finally, reframe “redundancy” as strategic optionality, not waste, but the price of preserving future choices. Having a second supplier costs more today. But it is the price of the option to survive if Supplier 1 fails. In volatile times, options are precious. The same logic applies to skills, partnerships, and revenue streams.

Principle 4 - Decentralise Sensing and Decision Rights

In a stable world, information flows predictably upward to decision-makers. The top makes the call, and the organisation executes. This works if the environment changes slowly and evenly. In a more chaotic world, the organisation’s frontline sees threats first, as we already established. Your frontline customer success team knows your product is degrading before metrics show it. Your plant operator sees the equipment behaving oddly before an alarm fires. Your engineer spots the anomaly before it becomes a scandal.

If these people have to ask permission to act, you will respond too late.

Research into organisations operating under extreme uncertainty (such as aircraft carriers, nuclear power plants, and emergency departments) reveals a striking pattern. During a crisis, authority does not follow the org chart. It migrates to the person with the most expertise on the specific problem, regardless of rank. High-reliability organisations structure themselves so that those who know what to do in a specific situation can take the lead, rather than hewing to a set hierarchy. The concept is called “deference to expertise¹².” It is the opposite of “command and control.” It is “intent and discretion” (leaders communicate the outcome that needs to happen and the constraints that apply; teams decide how to achieve it). The result is often agility in times of crisis.

To achieve this agility, you must push decision rights to the edge. Define a set of guardrails (spend limits, duration limits, risk tolerances) and give frontline teams authority to act within them without escalation. This requires trust, but it also removes delays. When your support team can spend up to €1,000 to retain a customer without approval, they respond in minutes, not weeks.

This works nicely when coupled with what military doctrine calls Commander’s Intent. When your CEO communicates strategy, they should answer three questions: What needs to happen? Why is it important? What constraints apply? Then trust teams to figure out how. It creates ownership and adaptation as teams learn what works in their local context.

The structural change here is to design more escalation paths rather than approval paths. The default should be “go ahead”; escalation happens only if you hit a guardrail. This flips the incentive from “ask permission (and hide risks)” to “act and flag problems.” High-reliability manufacturing plants often track “time from signal detection to decision” (the time it takes frontline signals to reach decision-makers). In high-reliability operations, this is measured in hours or minutes, not days.

Principle 5 - Hold Governed Slack

For a long time, “lean” has been the gospel. Strip out waste. Optimise every process. Utilise every asset to 95%+. If your team is not busy, you are leaving money on the table.

This makes sense when the environment is stable. But in a more chaotic environment, “lean” means “brittle.” There is no cushion to absorb a shock. There is no capacity to experiment. There is no bandwidth to respond to an opportunity.

A meta-analysis of 66 studies examining the relationship between slack and firm performance found a positive relationship across all three slack types the researchers identified (available, recoverable, and potential slack)¹³. Slack is what allows you to explore things. Without slack, every hour is allocated to today’s work. You cannot explore; you can only exploit.

An important caveat, though, is that the relationship between slack and performance is contingent. It works best in dynamic environments. In stable, less dynamic industries, excessive slack can reduce efficiency without creating corresponding adaptive gains. The key is governed slack (strategic reserves you deliberately protect, not passive inefficiency).

This is where organisational ambidexterity becomes practical. As stated in the introduction, research on firms that balance exploration (innovation, new markets, new capabilities) with exploitation (efficiency, known markets, proven operations) shows that they outperform those that do only one of the two³. The ones that do both are “ambidextrous.” But you cannot be ambidextrous if you are utilised at 100%. Hence, you need slack to explore.

When I was working on a digital transformation initiative at a multinational telco in 2018, we structured it explicitly: one team focused on exploring new revenue streams and digital services (measured by learning velocity and new capability-building), and separate operational teams focused on the core operational backbone (measured by efficiency and reliability). Exploration and exploitation require different metrics, different time horizons, and different team compositions.

To make this work, you must explicitly reserve capacity. While Google has since evolved its policy, its famous “20% time” was an example of governed slack. Build reserved capacity into your planning. Protect it in your budget. Do not let operational urgency consume it.

It also requires a commitment to true ambidexterity, not “innovation theatre.” You cannot meaningfully explore while running core operations at 100% utilisation. You need different teams (or at least separate project time), different metrics, and different time horizons. Exploration is measured by learning velocity and capability gains; exploitation is measured by efficiency and reliability. Both matter. Neither should dominate.

On Regulation: From Risk-Based to Uncertainty-Aware

To return to my reader’s question: “How do regulatory frameworks enable or constrain antifragility?”

I believe it hinges on a distinction between two concepts: Risk and Knightian Uncertainty¹⁴.

Risk is when you know (or can estimate) the odds: a casino’s roulette wheel, an insurer’s actuarial model, an engineer’s failure rate calculation. These domains work well with prescriptive regulation: “lifeboats must accommodate 100% of passengers; radio watches must be 24/7; Pharmaceutical Good Manufacturing Practice (GMP) standards require X, Y, Z.” The hazards are known, the solutions proven.

Uncertainty (in the Knightian sense) is when outcomes are imaginable, but probabilities cannot be assigned. Which geopolitical event will disrupt your supply chain? Which AI interaction will behave unexpectedly? The future is not just unknown; it is unknowable probabilistically.

Prescriptive regulation fails in the face of uncertainty because it ossifies systems around yesterday’s best practices. Goals-based regulation (setting outcomes like “your AI system must be explainable,” but leaving means open) allows regulated entities to innovate in compliance¹⁵. This creates variety within the regulatory ecosystem where different firms experiment with solutions, surfacing innovations that inform evolving best practices.

The EU AI Act uses this approach for high-risk AI systems (goals-based for emerging challenges, prescriptive bans for unacceptable risks). Pharmaceutical GMP uses prescriptive rules for well-understood hazards where failure modes are known and catastrophic.

The Antifragile Design Checklist

We are a week into 2026, and as you review your strategy for the year, ask these five questions:

1. On Learning: Does “bad news” travel faster than “good news” in our organisation? Are we measuring near-miss reporting and psychological safety, or just output metrics?

2. On Stress: Are we protecting our system from all stress, or are we deliberately injecting safe-to-fail stressors to learn? Do we run chaos engineering, red team exercises, or similar processes?

3. On Variety: Do we have a portfolio of options (multiple suppliers, modular systems, diverse skills), or are we betting on a single “efficient” path?

4. On Decentralisation and Decision Rights: Who has the authority to stop the line if they see a problem? Can a frontline person act within guardrails, or do they need approval from three levels up?

5. On Slack: Do we have the capacity (cash, talent, time) to pounce on a sudden opportunity, or are we running at 100% utilisation? Can we explore, or only exploit?

Applying antifragility comes at a cost; efficiency in the short term to buy survival and capability in the long term. But as the Titanic story taught us, and as every resilient organisation has learned, the cost of building in options is far lower than the cost of discovering too late that you have none.

These five principles are grounded in decades of validated research on how organisations learn, adapt, and perform under uncertainty. Whether they combine to create true antifragility (gain from disorder) or superior resilience (robust recovery and adaptation) will depend on how you apply them in your context and on the evidence you gather as you experiment.

I hope you enjoyed this two-part series on applying antifragility. Thank you for reading, and thank you to my reader in maritime regulation for pushing the thinking deeper. This is how we learn.

Share

References

1. LaPorte, T. R., & Consolini, P. M. (1991). Working in Practice But Not in Theory: Theoretical Challenges of “High-Reliability Organizations.” Journal of Public Administration Research and Theory, Vol. 1, No. 1, pp. 19–47.

2. Nagji, B., & Tuff, G. (2012). Managing Your Innovation Portfolio. Harvard Business Review, 90(5), 66–74. https://hbr.org/2012/05/managing-your-innovation-portfolio

3. He, Z. L., & Wong, P. K. (2004). Exploration vs. Exploitation: An Empirical Test of the Ambidexterity Hypothesis. Organization Science, 15(4), 481–494.

4. Koning, R., Hasan, S., & Chatterji, A. (2019). Experimentation and Startup Performance: Evidence from A/B Testing. NBER Working Paper No. 26278. (Published in Management Science, 68(9), 6434–6453, 2022.)

5. Trigeorgis, L., & Reuer, J. J. (2017). Real options theory in strategic management. Strategic Management Journal, 38(1), 42–63.

6. Taleb, N. N. (2012). Antifragile: Things That Gain from Disorder. Random House.

7. Botjes, E. A. (2020). Defining Antifragility and the application on Organisation Design. Antwerp Management School. https://zenodo.org/records/3719389

8. Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, Vol. 44, No. 2, pp. 350–383.

9. AWS Blog. (2022). Why You Should Develop a Correction of Error (COE). Retrieved from https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/

10. Sitkin, S. B. (1992). Learning through failure: The strategy of small losses. Research in Organizational Behavior, Vol. 14, pp. 231–266.

11. Ashby, W. R. (1956). An Introduction to Cybernetics. Chapman & Hall.

12. Weick, K. E., & Sutcliffe, K. M. (2001). Managing the Unexpected: Assuring High Performance in an Age of Complexity. Jossey-Bass.

13. Daniel, F., Lohrke, F. T., Fornaciari, C. J., & Turner, R. A. (2004). Slack resources and firm performance: a meta-analysis. Journal of Business Research, Vol. 57, No. 6, pp. 565–574.

14. Braun, C., et al. (2024). Knightian uncertainty in the regulatory context. Behavioural Public Policy. https://doi.org/10.1017/bpp.2024.59

15. Decker, C. (2018). Goals-based and rules-based approaches to regulation. BEIS Research Paper Number 8, Department for Business, Energy and Industrial Strategy.

Antifragility is quickly becoming a common term, but meaningful application remains rare. Last week, a keynote on antifragility and organisational design prompted a deeper question: what does it actually take to build systems that get stronger from stress?

This edition synthesises Taleb’s philosophy of antifragility with recent empirical research. We’ll …

Read more

October was eventful. Four themes topped my list—and should be on every leader’s agenda for 2026:

1. Getting serious about the practice of foresight

2. Disciplined execution in the age of AI

3. Bu…

Read more

Tired of Enterprise Architecture feeling like an abstract theory? This episode of The Abstract Interviews provides a practical blueprint to make it a reality. I'm joined by fellow Master Enterprise Architect, Eric Jager, who unveils his powerful four-stage model: The Enterprise Architecture Wheel.

Eric breaks down his approach to Document, Define, Execute, and Control your architecture from start to finish. We explore the crucial difference between architectural thinking and doing architecture, dive into a real-world case study, and discuss how to measure EA maturity.

Whether you're starting from scratch or looking to refine your existing practice, this conversation provides the clarity and one approach you can use to succeed.

Pilots do not trust a single safeguard. Aircraft have recovery procedures, redundant systems, and instruments that warn of turbulence before it shakes the cabin. Enterprises need the same logic. Recovery matters, but the ability to “read the sky” early and adjust course is what keeps you out of trouble.

Business continuity provides security, but sources …

Read more

“The future is already here; it’s just not evenly distributed.” — William Gibson.

We have long been conditioned to think of the future as a continuation of the present. Childhood questions like “What do you want to be when you grow up?” suggest that life moves in a straight line. We internalise this early on, thinking, “I want to be a doctor when I grow …

Read more

Dave Snowden developed the Cynefin framework over 25 years ago,¹ and it remains highly relevant given the complexity and sense-making required in today’s AI-driven environments. In the next three minutes, I will explain the framework and its significance as concisely as possible, so let’s get started.

Read more

In turbulent times, managers cannot assume that tomorrow will be an extension of today - Peter Drucker

While successful businesses have always adapted, today's unprecedented pace of change renders periodic reinvention insufficient; constant sensing and adaptation are now essential for survival, demanding new organisational capabilities.

Studies show that …

Read more

Is your strategy built to last, or just built for today?

Leaders often develop strategies assuming a stable, predictable future. Traditional risk management looks backwards, relying on past data. Planning cycles favour continuity. But we operate in a volatile, interconnected world where disruption is the norm. This reality exposes a critical gap: many le…

Read more

In an era of constant transformation, having an intentional enterprise architecture (EA) practice is no longer optional. EA is a strategic capability that enables organisations to align business and IT, enhance agility, improve decision-making, and reduce waste¹. But for many, the question remains:

→ What is the business case for EA?

The answer requires c…

Read more

Enterprise Architecture (EA) charters are foundational for aligning enterprise initiatives with business strategy. Yet, many organisations either overlook them or produce documents disconnected from reality. A well-crafted EA charter typically defines the architecture function's purpose, scope, and authority, potentially playing a significant role in di…

Read more

In 2008, Netflix made a pivotal architectural decision following a major database corruption that caused a three-day service outage. This incident exposed the limitations of its single data centre architecture and pushed the company to rethink its infrastructure strategy. Instead of attempting incremental improvements, Netflix transitioned to a cloud-na…

Read more

In the early 2000s, Starbucks faced a growing challenge. The company’s reputation as a premium coffee brand was closely tied to the quality of its beans. Yet, the global coffee supply chain was riddled with instability, fluctuating prices, environmental concerns, and ethical sourcing controversies. Consumers were becoming more conscious of sustainabilit…

Read more