I have met TOGAF-certified architects who cannot make a single architectural decision. And senior developers with zero certifications who architect circles around them. This contradiction forced me to ask: what makes a good architect when the certificate on your wall means nothing to the systems you build?
If you have ever wondered whether your certification actually made you an architect, or if you are doing architectural work without the title and wondering if you qualify, this article will help you separate credential from capability. We will explore why execution beats certification every single time, and what enterprise architect skills actually matter when stakeholders need decisions, not documents.
The architecture profession has an identity crisis around credentialing. We have created a false equivalence between "passed the exam" and "can do the job." Meanwhile, experienced engineers who architect daily go unrecognized because they lack the certificate. This needs to change.
The Certification Trap: When Credentials Replace Capability
Let me tell you about a recently TOGAF-certified architect I worked with. On paper, perfectly qualified. Excellent knowledge of ADM phases, artifact types, and governance structures. Could explain the difference between Phase B and Phase C in detail.
When a critical technology decision needed to be made under time pressure - choosing between two integration approaches with imperfect information - this certified architect could not commit. They wanted to complete a full stakeholder analysis, produce a target state architecture, and follow the framework process. The decision needed to happen in days, not months.
I watched as the team worked around the architect, making the decision through informal conversations and developer consensus. The architect continued producing artifacts after the decision had already been made. The certification had provided vocabulary but not judgment.
This is what I call The Certification Trap - the false confidence that comes from confusing credential acquisition with capability development. It happens when you believe that passing an exam qualifies you to practice, rather than seeing it as vocabulary for a practice you need to develop through execution.
Think about it like a driver's license. A license proves you passed a test: you know the rules, you can parallel park in a controlled setting, you understand traffic signs. It does not prove you can navigate a highway in a snowstorm, react to an unexpected obstacle, or judge when to break a rule for safety.
Architecture certification is the license. Architectural capability is the driving skill. Nobody confuses a new driver with a skilled driver just because they have a license. But we routinely confuse a newly certified architect with a capable architect.
Here is what certifications actually give you: vocabulary, not judgment. They teach you the language of architecture. They do not teach you when to skip the process, how to make decisions with incomplete information, or when good enough today beats perfect next quarter. Those instincts come from execution, not exams.
The big tell that someone has fallen into the certification trap? They use only TOGAF as their identity. When you ask what makes them an architect, they point to the certificate. When you ask about their last successful architectural decision, they describe the process they followed, not the outcome they achieved.
What Actually Makes an Architect: Execution Over Credentials
Now let me tell you about a senior developer I worked alongside who had no architecture certifications. Never attended a TOGAF course. Could not tell you the difference between Phase B and Phase C of the ADM.
Despite having no formal architecture credentials, this developer consistently made decisions that held up over time. They naturally decomposed domains, anticipated integration challenges, and communicated trade-offs to stakeholders in language they understood.
I started paying attention to what this developer actually did differently. They asked "what happens when this fails?" before building. They drew boundaries between components based on change frequency, not just function. They spoke to business stakeholders about consequences, not technology.
When I suggested they pursue a certification, they asked: "Would it make me better at what I already do?" Honest answer: probably not.
This taught me that architecture is a practice, not a title. Some of the best architects I have worked with never had the certification. They had something more valuable: the instinct for trade-offs that comes from years of building systems that had to survive real-world conditions.
Think about the difference between a chef and a recipe follower. A recipe follower can produce a meal by following instructions precisely. A chef understands why ingredients work together, can adapt when something is missing, and creates new dishes from principles.
When the recipe does not work - when stakeholders resist, when timelines compress, when requirements contradict - the recipe follower is lost. The chef adapts. Architecture happens in the adaptations, not in the steps.
So what actually makes a good architect? Three core capabilities that no certification can teach:
Trade-off Navigation: Real architects make decisions with incomplete information. They understand that every architectural choice has consequences, and they can articulate those consequences to stakeholders in terms that matter to them. They know when to choose fast over perfect, when to choose simple over elegant, when to choose proven over innovative.
Decision Ownership: Real architects take responsibility for outcomes, not just processes. They do not hide behind frameworks when decisions go wrong. They learn from failures and adjust their approach. They understand that being right about the process means nothing if the system does not work.
Communication Across Levels: Real architects translate between technical teams and business stakeholders. They can explain why a technical constraint matters to a budget discussion. They can explain why a business requirement creates technical complexity. They build bridges between worlds that often do not understand each other.
These solution architect skills and enterprise architect skills come from execution, not examination. They develop through making decisions that have real consequences, not through memorizing frameworks.
The Real Assessment: How to Evaluate Architectural Capability
Whether you are a developer wondering if you already architect, a certified architect questioning your capability, or a manager trying to identify real architects versus certified non-architects, here is how to evaluate what actually matters.
For developers who think they might already be architecting: Look at your last three technical decisions. Did you consider not just how to build something, but what happens when it breaks? Did you think about who else would be affected by your choices? Did you communicate the trade-offs to someone who needed to understand them? If yes, you are already doing architectural work.
For certified architects wondering if your certification matches your capability: Take your last three architectural decisions. For each one, ask: did I make this decision because my certification taught me to, or because my experience told me to? If the answer is always "certification," you may be following recipes instead of cooking.
For managers trying to identify real architectural talent: Do not ask about certifications first. Ask about decisions. What was the last technical decision they made that had business impact? How did they handle stakeholder disagreement? What did they learn from a decision that went wrong? The answers will tell you more than any certificate.
The path to becoming what makes a good architect is not through more certifications. It is through more execution. Take on decisions that matter. Make choices with real consequences. Learn from failures. Build systems that have to survive contact with users.
Your enterprise architect career path should be measured in decisions navigated, not credentials accumulated. Your developer to architect transition happens when you start thinking about consequences, not when you pass an exam.
Conclusion: Choose Execution Over Credentials
The architecture profession needs to stop confusing certification with capability. We need to recognize that what makes a good architect is not the certificate on the wall but the decisions they make under uncertainty.
If you are a developer already thinking architecturally, own that identity. You do not need permission from a certification body to architect. You need experience making decisions that matter.
If you are a certified architect, use your certification as vocabulary, not validation. The real test of your architectural capability happens every time a stakeholder needs a decision and you have to deliver one that works.
If you are building an enterprise architect career path or planning your developer to architect transition, focus on execution opportunities. Seek decisions, not documents. Build systems, not just models. Learn from failures, not just frameworks.
The industry needs architects who can deliver, not just architects who can describe. We need people who understand what does an enterprise architect do in practice, not just in theory. We need the courage to evaluate capability over credentials.
Architecture is too important to be left to the certified. It is too valuable to be gatekept by examinations. The best architects I know earned their expertise through years of decisions that had real consequences. That is the path that actually develops architectural thinking.
Watch the video for the full stories behind this framework and see how these principles apply to specific career situations: https://www.youtube.com/watch?v=fZaY23c5XDE
What is one thing you learned through execution that no certification ever taught you?
Resources
- Related: "Reading the Room: Political Skills They Don't Teach in TOGAF"
- Related: "From Menu Item to Decision Maker: Building Architectural Influence"
- Video: https://www.youtube.com/watch?v=fZaY23c5XDE
Watch the video for the personal stories behind this framework: https://www.youtube.com/watch?v=fZaY23c5XDE
How do you evaluate architectural capability in your organization - through credentials or through execution?