You've watched it happen from the outside. Someone presents a capability model, the room nods, and six months later nothing about the decision has changed. You've wondered whether the missing piece is a credential, something that would make people take an analysis seriously enough to act on it.
So you go looking for the credential that closes that gap, and the search leads to a question that resurfaces in the practitioner forums every few weeks: CBA, the Business Architecture Guild's Certified Business Architect credential, or Open CA, The Open Group's certified-architect track? The thread fills up with real, useful detail: exam formats, renewal fees, which acronym a recruiter will recognise faster.
None of it answers the actual question, which was never which certification. It's whether either one is what actually gets a room to listen.
What the exam actually tests
A business architecture certification tests vocabulary and method. Can you name the layers of a capability model. Can you distinguish a value stream from a process. Can you produce a stakeholder map, a capability heat map, an architecture artifact that would survive a review board. These are real, gradable skills, and the exam is honest about testing exactly them and nothing more.
What it cannot test, because no exam format can, is whether you can sit in a steering committee meeting where two directors disagree about where the next twelve months of funding goes, and change the outcome. That skill isn't on the syllabus. It gets built the way every applied skill gets built: badly, the first several times, on a real problem, in front of a real person who has to live with what you recommend.
Two architects, same credential
Picture two people six months after certifying. Both hold the same credential. Both can build a competent capability heat map. Both can trace a value stream end to end. On paper, there's nothing to choose between them.
The first produces exactly what the syllabus trained them to produce: a technically correct assessment that goes into a governance pack, gets a nod from the review board, and quietly stops mattering the moment the delivery team starts building something else instead. The heat map was accurate. The gaps it identified were real. Eighteen months later, the same gaps show up in a different slide deck, because nobody with the authority to close them ever felt the pressure to.
The second walks into the same kind of meeting and asks a different question first, not "what does the model say" but "what decision is actually on the table here, and what would change someone's mind." Sometimes that means presenting the heat map differently. Sometimes it means not presenting the heat map at all, and instead asking the one director who's actually blocking the resourcing decision what they'd need to see before they'd change their vote. The artifact is the same. What differs is what happens to it after it leaves their hands, and that difference was never on the exam.
What the credential is actually for
None of this is an argument against certification, or even against a formal credential at all. Understanding the concepts, the vocabulary, the core principles of business architecture, whether that comes from a certification or not, is necessary. It is also not sufficient, and the distance between those two words is the entire argument.
Necessary, because a hiring manager scanning fifty resumes needs some way to know you can speak the language before they'll spend an hour finding out whether you can use it. An applicant tracking system doesn't know you're capable of changing a director's mind. It knows whether "CBA" or "Open CA" appears on the document it's scanning. That's worth something.
Not sufficient, because the credential certifies that your work is technically right. It says nothing about whether it will matter to the people who have to act on it. Those are different questions, and the gap between them has a name: the practice layer, sitting between your architecture and the decisions it's supposed to shape. No framework and no exam was ever built to teach it, because it isn't a modelling skill. It's what you do with the model once it's in the room.
What to actually do with it
The certification tells the room what you know. It was never going to tell you who you're becoming as a practitioner, and that was never its job. Building the practice is the part that comes after, and it doesn't come from a second exam. It comes from doing the work: taking a real, unglamorous problem, one small enough that nobody is paying close attention to it yet, and using it to find out what actually changes a decision-maker's mind, not what the textbook says should. Notice which version of your analysis gets acted on and which gets filed. Do that enough times and a pattern emerges that no exam ever tests, because it can't be graded on paper.
The vocabulary gets you in the door. What happens after you're through it, whether the room starts listening, is the practice you're only just starting to build, and no syllabus was ever going to build it for you.
Part of the Business Architecture Framework, which names this exact ceiling for practitioners further along: the credential-based training you've completed teaches you to document the architecture, not to change what happens in the room where decisions get made. If you're earlier in that arc, Closing the Strategy-Execution Gap is built around applied practice from the start, not exam preparation.