From Buildings to Data Systems
What remained constant
I trained and practiced as an architect. Today, my work involves data systems, infrastructure, and long-running technical programs. These are often described as separate fields, distinguished by tools, materials, and professional labels.
That separation has never reflected how I experience the work.
What has remained constant is the practice itself: understanding complex needs, working across interacting systems, and aligning decisions over long time horizons so that what is built continues to function once it is in use. Over time, the medium has changed. The practice has not. This became clear only in hindsight, by looking across work that now spans different domains and long-running initiatives, where responsibility is sustained over years despite being fragmented across short funding cycles, institutions, and geographies.
This is not an account of departure or reinvention. It is a reflection on architectural practice—understood as abstraction, coordination, and responsibility over time—and on how that practice has shaped the work I have done across different contexts.
⸻
1. The thread that runs through
Long before I worked with data systems or infrastructure, I was already operating at a level of abstraction removed from the object itself.
As a student, and later as a tutor, I spent years working with Geometria Descritiva. Its purpose is not representation for its own sake, but translation: projecting three-dimensional structures into different coordinate systems, reasoning through constraints, and moving between views without mistaking any single projection for the thing itself. What mattered was not the drawing, but the structure it encoded.
That way of thinking carried naturally into geographic information systems, which I began teaching before graduating. GIS made explicit something architecture often leaves implicit: that space can be formalized, queried, transformed, and reasoned about independently of any single building or site. Objects receded; relationships and constraints came to the foreground.
During my doctoral work in Space Syntax, this separation became central. Buildings and cities were treated as graphs: networks whose properties are often non-local. What happens in one place is frequently determined by its position within a wider system. Outcomes emerge from topology rather than isolated decisions. That insight proved durable.
At the time, my work remained firmly situated within architecture. I taught, practiced, and worked in architectural research environments. What shifted was not disciplinary affiliation, but attention: away from form and style, toward structure, interaction, and the consequences of decisions once systems are inhabited and used.
There was no moment where one field ended and another began. Instead, there was a steady movement away from objects and toward systems, away from components and toward the relationships that bind them. The practice remained the same; only its focus sharpened.
⸻
2. What architecture actually teaches
Architecture is often described through its visible outputs: buildings, drawings, cities. That emphasis obscures what the discipline trains you to do.
At its core, architecture is about designing systems that must operate under real constraints. A building is never a single object. It is an assembly of structural, mechanical, electrical, environmental, social, regulatory, and economic systems, each governed by different rules, timescales, and failure modes. None can be designed in isolation, and none can be treated as optional.
There is no universal solution. Every project begins from first principles: understanding what is needed, what is possible, what is constrained, and what must be prioritized. Decisions are made early, often with incomplete information, yet their consequences persist long after they are difficult to change. Much of the work lies in anticipating those consequences before they become visible.
Design, in practice, is not about eliminating constraints, but about deciding which ones are allowed to dominate. Time, cost, performance, safety, usability, maintainability, and regulation cannot all be optimized simultaneously. Architectural work consists of making these trade-offs explicit, choosing where compromise is acceptable, and ensuring that those choices remain coherent as the system is built and used.
Equally important is the relationship between design and operation. Buildings are inhabited, regulated, maintained, adapted, and repurposed over decades. Many failures are not caused by faulty components, but by how those components are integrated, and by misalignment between design assumptions and real-world use. The gap between intent and operation is where problems accumulate.
Architectural practice therefore places unusual emphasis on coordination. It requires working across disciplines with incompatible vocabularies, incentives, and criteria for success, and translating between them without collapsing complexity into oversimplification. The work is less about producing answers than about structuring decisions so that systems can coexist without undermining one another.
This training does not produce specialists in individual components. It produces responsibility for coherence: for understanding interactions, identifying fragile interfaces, and tracing how local decisions propagate through a system over time.
⸻
3. A sharpening of focus
From the outside, my work today can resemble a decisive career change. From within the work itself, it did not register as one.
For a long period, my professional life remained recognizably architectural. I taught, practiced, and worked in academic and professional settings grounded in the discipline. What changed gradually were the questions I was drawn to. I became less concerned with individual objects and more with the structures that shape how systems behave once they are in use.
During my doctoral work, this shift was already evident. Space Syntax introduced formal models and computational tools without making computation the focus. Software represented buildings and cities as graphs, but the emphasis remained on what those representations revealed: structure, accessibility, and non-local effects.
After the doctorate, I co-founded a startup to translate that knowledge into tools practitioners could use. My role was not development, but mediation: clarifying requirements, shaping workflows, and aligning theoretical models with professional and technical constraints. Software functioned as a medium through which architectural thinking could be made operational.
The move into coding came later, driven by practical needs. While working as a professor in Bahrain, I needed reproducible research and accessible outputs. Programming became a way to support that work. Over time, analysis extended into full applications, and then into a public-facing platform that I designed, built, deployed, and maintained over several years. The work involved users, institutions, iteration, and long-term responsibility. It was architectural in all the ways that mattered.
This meant making choices about data models, interfaces, performance limits, and maintenance trade-offs—decisions that were less visible than architectural ones, but no less consequential.
By the time my work was formally framed as data science and infrastructure, little felt conceptually new. The materials were different, and the scale had changed, but the practice was familiar. There was no conversion point, only a gradual sharpening of focus as the same way of working found expression in more abstract systems.
⸻
4. What remained constant
Career narratives often assume that progress requires unlearning: abandoning earlier habits to make room for new ones. That was not my experience.
Nothing central to my architectural training became obsolete as the context of my work changed. Comfort with complexity, awareness of uncertainty, and a habit of questioning assumptions rather than optimizing prematurely became more valuable, not less.
Architecture trains you to work without complete information. Requirements shift, constraints evolve, and many influential factors are qualitative or political rather than technical. Assumptions must be surfaced, treated as provisional, and revisited as systems encounter real use. That discipline carried over intact.
Equally important was learning to listen. Architectural practice depends on engagement with engineers, planners, regulators, operators, and users, none of whom share the same priorities or vocabulary. Progress depends on knowing where expertise resides, when to defer, and how to integrate partial perspectives into a coherent whole. This is not a soft skill. It is a design skill.
As the work moved toward data, software, and infrastructure, these traits remained central. First-principles reasoning mattered more than familiarity with tools. Problem framing mattered more than immediate solutions. Responsibility for behavior over time mattered more than the elegance of individual components.
These priorities proved durable across contexts.
⸻
5. Same practice, different constraints
The differences between buildings and digital systems are obvious. One is physical, slow to change, and bound to a site. The other is abstract, fast-moving, and often treated as malleable. Those differences can obscure what they share.
Both are designed for use by others. Both operate within regulatory, economic, and organizational contexts. Both depend on the coordination of multiple subsystems with distinct failure modes. And in both cases, early decisions constrain what remains possible long after those decisions are made.
This became clear in work on data infrastructure. Faced with Earth observation workloads, the default approach would have been to replicate a conventional data centre design or rely on generic cloud services. Those solutions were well understood and widely deployed. They were also poorly aligned with the actual requirements of the work.
The system instead had to be designed from first principles: around data flows, storage patterns, performance constraints, and operational realities. The objective was not formal correctness, but long-term reliability for real users. Integration mattered more than individual components. Alignment mattered more than adherence to templates.
This is a familiar architectural problem. Buildings fail when they are designed according to generic models rather than the conditions they are meant to support. Success depends less on novelty than on coherence: on many small, disciplined decisions reinforcing one another over time.
Decisions about storage architecture, data locality, and operational complexity mattered more than maximizing theoretical flexibility.
Over time, a pattern became visible. The context shifted, the systems grew more abstract, and the constraints changed. What remained stable was the practice: working from first principles, making trade-offs explicit, and taking responsibility for how systems behave once decisions can no longer be revised. The materials changed. The work did not.