Part of the series: Getting it organized properly. Notes from a field still finding its shape.
The layer that does not exist
In the Netherlands, a generation of engineers was trained at institutions called the Hogere Technische School, or HTS. The HTS occupied a specific and deliberate position in the educational landscape: it combined rigorous theoretical grounding with hands-on practical training, at the highest vocational level. Graduates left with both the ability to reason about systems and the ability to build them.
Then society decided the HTS was not prestigious enough. It was absorbed into the broader Hoger Beroeps Onderwijs framework and over time the distinctive character that made it valuable was diluted. What replaced it was a cleaner hierarchy: theoretical education at the top, practical education below it. The Technical University on one side, vocational training on the other. The bridge was removed.
This article argues that removing that bridge was a mistake with consequences that extend well beyond the labor market. In IT security specifically, the absence of people who can operate across both layers is not an inconvenience. It is a structural vulnerability.
The construction metaphor and where it breaks
The construction industry offers a useful analogy for thinking about professional roles and the IT industry has borrowed it heavily. There are bricklayers and there are architects. The bricklayer executes. The architect designs. The two roles are cleanly separated and that separation works because the domain allows it. A bricklayer does not need to understand load distribution across an entire structure. An architect does not need to know how to lay a course of brick. The complexity of each layer is real but bounded.
IT does not work this way. The complexity of software systems is not bounded within layers. It crosses them.
A software engineer implementing a security control needs to understand the architectural intent behind that control. Without that understanding, a subtly incorrect implementation can satisfy the letter of a design document while violating its purpose entirely. Conversely, a security architect who has never implemented the systems they design will produce specifications that are coherent on paper and unworkable in practice. The interface between design and implementation is not a handoff point. It is a shared space that requires shared understanding.
What the gap looks like in practice
Three things go wrong simultaneously.
First, the architect cannot fully inspect the implementation. This is not a failure of process. It is a consequence of specialization. An architect who has not written deployment configurations recently is not equipped to assess whether a Terraform template faithfully realizes a security design. The review becomes a formality.
Second, the engineer cannot fully interpret the design. A security engineer who has not worked at the architectural level will fill gaps in a specification with reasonable-sounding local decisions, made without visibility into the broader threat model the architect had in mind.
Third, and most consequentially, the space between the two roles is ungoverned. Threats that live in the gap between design and implementation have no natural owner. Neither role is poorly defined. Both roles are doing exactly what they were hired to do. The problem is that the system as a whole assumes a layer of bridging competence that is not formally recognized and increasingly not trained for.
This is where incidents happen. Not because the architecture was wrong. Not because the engineers were careless. But because the translation between the two was imperfect in ways that neither side had the vantage point to see.
The educational root
The HTS produced people who could occupy that bridging layer. Not because the curriculum was designed with cybersecurity governance in mind, but because combining theoretical and practical education at the highest level produces a particular kind of professional fluency. Graduates understood systems from the inside and from above at the same time.
The tension between HTS and Technical University graduates was well documented. Organizations that recruited both consistently found that the practical differences in capability were smaller than the difference in perceived status. When the HTS was absorbed and parents began steering children toward the theoretical track regardless of aptitude or inclination, the supply of people with that bridging capability declined. In the Netherlands, the labor shortage that followed is visible and widely discussed. The security consequence is less visible and more serious.
A different way to think about roles
Frameworks like TOGAF get the structure right on paper. The Solution Architect sits between the business and technology domains, and that horizontal axis works reasonably well in practice. Solution Architects own the translation between business requirements and technical specialists.
What is less clearly owned is the vertical axis: the connection between enterprise architecture above and engineering below. TOGAF assumes the Solution Architect bridges both. In practice, Solution Architects arrive from one of two directions. Those who came up through engineering are strong on the link to implementation and less fluent in the language of enterprise architecture. Those who came from the academic or consulting side are comfortable with EA frameworks and less grounded in what implementation actually requires. The horizontal bridge is held. The vertical one is not.
This is not a flaw in TOGAF. It is a skills deficit that makes a sound design unworkable. The role at the center of the vertical axis requires a formation that combines theoretical fluency with practical depth.
Gregor Hohpe recognized the same structural tension and proposed the elevator: the architect who can ride between the penthouse and the engine room, fluent on every floor. The elevator is a behavioral solution. It depends on individuals with unusual range finding their own way to the floors that process does not connect.
The pyramid has no bracket for the bridge
Most people do not ride the elevator. The pyramid explains why.
The distribution of roles in IT organizations is not arbitrary. Many engineers at the base, few architects at the top: that structure reflects a real distribution of scope and responsibility. But it also creates gravity. It rewards staying in your layer. Engineers at the base have little organizational incentive to develop upward fluency. The architectural floor feels remote and its language unfamiliar. Architects at the top have little pressure to maintain downward fluency. The implementation floor pushes back with its own skepticism. The elevator has no designated stop for the floor that does not exist.
The people who do develop bridging fluency find themselves structurally homeless. Too practical for the architect title. Too architectural for the engineer salary band. Practical skill is undervalued by default, so the path of least resistance leads upward: take the academic credential, accept the enterprise title, leave the implementation fluency behind. The pyramid absorbs them into the nearest recognized layer and the bridging capability quietly disappears from the org chart.
This is not sustainable and the evidence is accumulating. In IT security the gap between design and implementation is where incidents happen, and those incidents are now visible at a scale that is difficult to ignore. The pattern is not unique to IT. The Netherlands is confronting long waiting lists in mental health care, a domain where the undervaluation of practical clinical skill has produced a supply collapse with patients waiting months for care that is not available. The domains differ. The dynamic is the same: when society frames practical skill as a lesser credential, the supply of people willing to carry it declines and the costs appear elsewhere.
Knowing both layers is a skill. It is not a compromise between theory and practice. It is a distinct and demanding capability that requires formation, recognition and appropriate reward. Society is beginning to acknowledge this, partly because the cost of not acknowledging it is becoming visible in too many places at once. Security is one of them.
The HTS understood this before the rest of the system caught up. Building the bracket that the pyramid is missing, in career frameworks, in education and in organizational design, is the work ahead.
A closing thought on AI. What happens to the ungoverned space when AI moves in? The engineer has a code generation tool. The architect has a diagramming assistant. The gap now has a resident. It still has no owner. Whether AI makes the missing layer more visible or simply more crowded is a question the field has not yet answered. The technology is not done arriving.
Organizing this is harder than naming it. The work is collective and slow. The field gets organized by many people writing carefully about what they can see clearly. This article is one small contribution to that work.
Sources cited
- Cybrary. Distinguishing Between the Security Architect and Security Engineer. cybrary.it
- Hohpe, G. (2020). The Software Architect Elevator. O'Reilly Media.
- Kienzle, D.M. et al. (2009). Security by Design: Secure Design Patterns. Carnegie Mellon Software Engineering Institute.
- Lappalainen, E. et al. (2023). Analysis of Software Engineering Skills Gap in the Industry. ACM Transactions on Computing Education.
