How to Earn the Title: A Practising Architect's Guide to Your First Open CA Certification
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.