3 Crucial Things Every Aspiring Enterprise Architect Should Know
Knowledge gets you in the door. Practice makes you good. Community makes you great.
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.