Isabella of Castile did not sail anywhere. She funded the expedition, weighed the risk, allocated the resources, and waited for a return. She was excellent at investment planning. Columbus, on the other hand, was in a boat with the wrong maps, heading somewhere he could not quite name, making design decisions under conditions that changed daily. He had to innovate because there was no alternative.
One of them had an executive (management) job. One of them discovered a continent.
This is a rough analogy for two kinds of architects working in organizations right now. And the rough part is not the management job.
The Optimization Architect
You know this role. It probably has a sign-off in your delivery process somewhere. The optimization architect owns the review. They sit at the end of the pipeline, check whether what teams built meets standards, ask pointed questions about cost, and send things back when something looks wrong. They are measured on how many reviews they completed, how many findings they raised, and whether the architecture is technically compliant with what was decided by someone else, earlier, in a meeting they were not in.
This is not useless work. Standards exist for reasons. Runaway costs are real. But this is also, to be direct about it, the Isabella model. Someone made the strategic decision. Someone did the design. The optimization architect checked the receipt.
The BTABoK is fairly blunt on what architecture actually is: the art and science of designing and delivering valuable technology strategy. Not reviewing it. Not auditing it after delivery.
Architects are Governed, They are not Governing
Designing and delivering it. That definition came from thousands of practitioner interviews. The profession agreed on it. Then a large number of organizations went and built the opposite.
The Innovation Architect
The innovation architect owns the problem before it has a budget line. They are in the room when the organization is trying to figure out what it is actually trying to do. They shape the roadmap, which in the BTABoK is not a Gantt chart with good fonts. The Strategic Roadmap canvas exists to prioritize, assign, and connect multiple initiatives within a value stream. That requires knowing what the value stream is, which requires being present before someone else defines it.
They also own design. And design, the BTABoK is careful to say, is not pattern adoption. Design is a business technical innovation problem. Every design decision needs to trace back to a requirement, a principle, or an objective. A decision that cannot be traced is not architecture. It is an assumption, and assumptions accumulate into technical debt. The architect who arrived after the assumptions were made is managing someone else’s debt.
Columbus made design decisions with incomplete maps in open water. That is not an ideal working condition. But it is considerably closer to what the BTABoK describes as the architect’s job than approving someone else’s cloud migration after the vendor contract is signed.
Why Specialization Changes Everything (and What It Does Not Change)
The BTABoK recognizes five specializations: Business, Information, Infrastructure, Software, and Solution. This is where people tend to misread the model, so it is worth being precise.
These are not different professions. They are not different philosophies. Every one of them designs and delivers valuable technology strategy. Every one of them operates across the same five competency pillars: Business Technology, Design, Human Dynamics, IT Environment, and Quality Attributes. Every one of them owns strategy and execution within their domain. A Software Architect who only does design without owning outcomes is not a complete Software Architect. A Business Architect who shapes strategy but hands off at the threshold of delivery is not doing the full job. This is EXACTLY like every other profession. Doctors do not include some lawyers and accountants.
What specialization gives you is depth and a natural place to stand on a large transformation. When an organization is running a genuinely complex change program, including new capabilities, new platforms, new integrations, new data governance, new interfaces, you need people who have gone deep enough in each domain to make the hard calls without spending three weeks getting up to speed on the basics. The specializations work together because they each bring real expertise to the table, not because they divide up the job and stay in their lane.
Think of it this way. Columbus needed navigators, engineers, physicians, and someone who could negotiate on arrival. On a short trip to the coast, one good generalist probably handles it. On a transatlantic voyage into unknown territory, you want people who are genuinely excellent at their specific job and who know how to hand off to each other at the right moment.
Seniority Is Depth, Not Scope
Here is the part that tends to surprise people and of course it angers those who will be left out of the profession, and who are more marketing hype than substance. In the BTABoK career path model, you advance by going deeper, not wider. Each specialization has four levels: Associate, Professional, Distinguished, and Chief Architect. A Chief Software Architect is more senior because they engage with harder design problems in software architecture, not because they have accumulated a portfolio of unrelated domains. And also they still have a distinguished architects business skills. A Distinguished Business Architect is distinguished because of where they can operate within business strategy and capability, not because of how many review gates they own and they still have a distinguished architects technical skills.
This progression exists for every specialization. A Chief Information Architect is as senior a role as a Chief Infrastructure Architect. Neither outranks the other. On a major transformation, you may need both, and you need them to be peers who respect each other’s depth rather than generalists arguing about whose scope is bigger.
This is a structural break from how IT careers traditionally worked. In the old model, scope equals seniority. More domains, more reports, bigger oversight equals bigger title. Enterprise is the worse. An enterprise cannot be designed or innovated. The result is senior architects who are mediocre at six things rather than excellent at one, and who have quietly become optimization architects because reviewing across many domains is the only way to maintain the illusion of coverage. This scope problem is why many senior IT managers with the title architect cannot actually deliver a solution today. They stopped innovating, they tried to manage innovators.
The BTABoK model says no. A mature career path includes well-defined roles, clear expectations, and transparent alignment with business value. The mechanism for advancement is developing the depth to engage at higher levels of complexity within your specialization. A Software Architect who has spent ten years going deeper on design quality, structured decisions, and pattern tradeoffs is more valuable than one who expanded into enterprise governance five years in and now does neither particularly well.
What Gets Left Behind Is a Choice
The optimization model will not disappear. Organizations will always need standards, and someone has to enforce them. But governance is a shared IT responsibility and an IT managers duty. But when a practice is organized around enforcement as its primary purpose, the architects in it end up at the back of every conversation that matters. The BTABoK lists what it is trying to fix: massive failures in modern organizations, a profound identity disorder in the profession, dangerous technology spending, and a complete lack of quality decision-making. None of those are solved by a tighter review gate.
They are solved by architects who are in the room when strategy forms, who design under real constraints toward real outcomes, who own accountability from roadmap to delivery, and who go deep enough in their specialization to actually know what they are doing.
Isabella funded a lot of voyages. Some came back. Columbus had to be good at the job in real time, or he did not come back at all.
The profession needs more Columbuses. We have enough people checking the receipt.