The City as a System

Reliability becomes public

That changed the emotional weight of the work. In a factory, if a planning report was wrong, the consequence could be serious while the problem still lived within an operational chain, where people could gather, examine, correct, train, adjust, and recover, and where the users, departments, and responsibilities were known. In a transit system, failure became public immediately. A gate that did not open could create irritation, delay, crowding, and loss of confidence, a slow response during rush hour could disturb the movement of many people, and a payment inconsistency could grow past a technical defect into a question of fairness. The city made reliability public. That was the first lesson.

The second lesson was quieter: public infrastructure must become almost invisible to be trusted. When it works, people barely notice it. A commuter taps and passes through, a bus ride is paid for without ceremony, and a transaction moves through the system into a larger accounting flow, with the visible experience kept simple because the system carries complexity elsewhere. That simplicity is never accidental. It has to be designed.

The automated fare collection system brought together MRT gates, buses, fare cards, transaction records, payment flows, backend systems, and reconciliation processes, each part with its own timing and responsibility. A gate operated in moments, a bus operated across routes and time, a card carried identity, value, and permission, and GIRO card mechanisms connected transit behavior to banking and payment infrastructure, with the network holding all of it together in a way that felt effortless to the public. Underneath that effortlessness was a dense world of decisions. The system had to know enough to open the gate quickly, record the transaction, handle communication delays, store and reconcile usage, deal with cards, devices, accounts, routes, and payment rules, and support operators, administrators, maintenance teams, and customers, with every technical decision carrying an operational consequence.

Strangers in motion

That was a major shift from the factory, where users could be trained, observed, mapped, and adjusted over time, and where everyone belonged to the same institutional world. The city’s users were strangers: a worker, a student, a parent, a tourist, an elderly passenger, a bus rider, a train passenger. They did not share the same knowledge, patience, language, urgency, or confidence with technology, so the system could not ask too much of them. It had to meet them in motion. That was humbling, and it forced a new kind of design discipline. The gate could not become a place where the passenger had to stop and think, the fare card interaction had to be quick enough to preserve flow and clear enough to reduce hesitation, and the system’s complexity had to be absorbed behind the scenes across devices, records, networks, transaction rules, payment systems, and reconciliation. Good infrastructure never asks to be admired. It creates ordinary confidence.

A passenger saw the card as a convenience, while for the system the card was an instrument of access, value, identity, and transaction. When the card met the reader, the system had to read, decide, record, and permit movement, in a sequence fast enough to feel natural and reliable enough to be trusted. There was a kind of institutional trust inside that small moment. A person approached the gate expecting the city to recognize the card and allow passage, and when the gate opened, the system had done its work. When it worked, nothing dramatic happened, and that was the point.

The difficulty was that ordinary confidence requires extraordinary attention, because every hidden failure had the potential to surface in public: a device error becoming a queue, a communication delay becoming confusion, a reconciliation problem becoming a dispute, a slow response becoming congestion, a small design decision multiplied by thousands or millions of encounters. Scale changes the meaning of small things. In the factory, a small data error could travel through production. In the city, a small transaction error could travel through public experience, and I began to see that the size of a system is measured by the number of lives it touches as much as by the number of its components. That awareness made me careful, and it changed how I understood interfaces. In the laboratory, interfaces were often electrical or programmatic, and in the factory they appeared between departments, processes, reports, and people. In Singapore, interfaces multiplied in every direction: card to reader, gate to passenger, device to network, bus system to central system, fare logic to payment logic, transport operation to banking process, public behavior to machine response. Every interface was a place where trust could be strengthened or weakened. A poorly designed interface creates hesitation, a delayed response creates doubt, an unclear error creates frustration, a missing record creates dispute, and a mismatch between operational practice and system logic creates confusion, so the architecture had to attend to what happened between components as much as inside them. That became clearer to me in Singapore than ever before. A gate by itself is not the system, and neither is a fare card, a bus device, or a backend ledger. The system exists in the relationships, in the way each part recognizes, responds to, records, and reconciles the actions of the others.

This was also where I learned a different kind of leadership. The project required working closely with the customer, understanding expectations clearly, adapting to a different operating culture, and staying focused on the mission, and technical confidence was insufficient. I had to listen carefully, communicate across context, and understand what reliability meant in that environment. Singapore had its own rhythm. The pace, expectations, institutional discipline, and operating culture were different from what I had known, infrastructure was treated seriously, execution mattered, and public systems were expected to perform consistently rather than occasionally. That shaped the way I approached the work. A builder cannot simply carry one set of assumptions into every environment, because systems are local even when engineering principles are universal. Reliability matters everywhere, while the way people experience it depends on context. Trust matters everywhere, while expectations of public institutions differ. Efficiency matters everywhere, while tolerance for delay, ambiguity, and workaround changes from place to place. Singapore taught me to pay attention to place. The architecture had to belong to the city rather than only to the design document, fitting movement patterns, institutional expectations, operational routines, and public habits.

At the time, I was simply learning by being there. I remember watching people move through transit infrastructure and realizing that their experience depended on many hidden acts of engineering, and that most of them would never know who built the system or how it worked. That anonymity never diminished the work. It deepened it. There is a form of service in building what others never have to think about, and that humility was good for me. It softened the young engineer’s desire to be seen as clever, taught me to care more about whether the system held, and showed me that some of the most important work hides inside ordinary reliability.

The edge and the center

The project also forced me to think about movement differently. The morning rush had its own character, with people moving with purpose, stations carrying currents, pauses, surges, and bottlenecks, and buses keeping their own cadence, different from trains and connected to the same urban rhythm, while the fare system had to support all of it without becoming the center of attention. That was the discipline. The system had to be accurate, and it also had to be graceful. Grace is not a word engineers use often, and public systems need it. A graceful system handles ordinary use smoothly, handles exceptions without unnecessary drama, refuses to punish the user for every minor disturbance, avoids exposing complexity too quickly, gives operators enough control without overwhelming them, and protects the integrity of the whole while preserving the experience of the individual. Designing for that kind of grace requires empathy. You have to imagine the tired commuter, the person in a hurry, the child learning to use the card, the elder moving slowly, the bus operator managing a route, the maintenance person diagnosing a device, and the administrator reconciling transactions, because each person meets the system differently, and an architecture that serves only one perspective will fail another.

The edge-and-center relationship fascinated me. The two places asked for different things.

Designing between those needs was anything other than trivial. If the edge depended too much on the center, the system could become slow or fragile. If the edge acted too independently, the center could lose control or accuracy. The architecture had to balance local action with central integrity. At the time, I would not have described it in grand language, since we were dealing with concrete design questions, practical constraints, device behavior, communication patterns, and operational requirements, and I could feel the importance of the balance. The system had to move and remember at the same time. That phrase captures much of what public transaction infrastructure demands: allowing movement without forgetting what happened, staying fast without becoming careless, handling exceptions without turning each one into a crisis, and remaining strict enough to protect value while staying flexible enough to preserve service.

Payment made the work more serious, because money changes the emotional temperature of a technical problem. If a gate delays and no value is involved, frustration is one thing. If a fare is deducted incorrectly, frustration becomes distrust, since people are sensitive to fairness, value, and accountability. A payment-related system cannot be casual about records. It must know what happened, when, where, and under what conditions, support reconciliation, allow disputes to be resolved, and preserve confidence. In that environment, the transaction became a kind of truth. Each transaction said: this card, this device, this time, this fare event. If that truth was captured correctly, the system could proceed with confidence, and if it was not, uncertainty entered the network. I became fascinated by that. A transaction is small, and it is also a promise of memory, allowing a system to remember an event consistently enough that others can act on it later. In public infrastructure, that memory must be trustworthy, and the city depends on millions of such memories, financial, operational, logistical, and civic, which together allow the city to function as if it knows itself.

The more I worked on the project, the more I saw the city differently. A city is often experienced through surfaces, roads, stations, vehicles, buildings, and crowds, while beneath the surface run systems of coordination: schedules, payments, permissions, maintenance, signaling, staffing, safety procedures, and transaction records. The visible city moves because the invisible city holds. That captured my imagination in a practical way. I wanted to understand what made public systems dependable, how design decisions at one layer affected behavior at another, and why some systems gave people confidence while others created friction and doubt. Singapore was a serious place to learn this. The city cared about execution, infrastructure was never treated casually, standards mattered, and you could feel that the system was expected to perform consistently. That expectation raised the bar, and it shaped me. Routine is the real test of infrastructure. Many systems can perform during special attention, and fewer can perform once they become ordinary. A fare collection system must succeed during ordinary use, thousands and thousands of times, without ceremony, and that kind of success never looks dramatic. It looks like nothing going wrong. I learned to admire that kind of success.

A system’s character is revealed by its exceptions

The project also forced me to think about exception handling in a new way. In small systems, exceptions can sometimes be handled manually. In large public systems, exceptions must be designed, because cards fail, readers fail, communication gets interrupted, balances run insufficient, transactions need later reconciliation, crowds form, operators need overrides, and devices need maintenance. The question was never whether exceptions would occur. They will. The question is how the system behaves when normal flow is disturbed, and this became one of the deepest lessons of that period. A system’s character is revealed by its exceptions. Normal operation shows whether the design can function, while exception handling shows whether the design is mature. The way a system treats them tells you what kind of system it is.

In Singapore, resilience was never an abstract word. It meant people could keep moving when the system encountered imperfection, operators could intervene when needed, records could be reconciled, failures could be diagnosed, and the public experience did not collapse at the first disturbance. That required foresight. You had to imagine the intended path alongside the broken paths: the card that did not read, the gate that did not respond, the transaction that could not be immediately transmitted, the device that needed maintenance, the passenger who was confused, and the account that required review. This changed the way I approached architecture. The happy path is only the beginning, because real systems live in their exceptions, and public systems most of all.

Building the capability to keep building

As I moved through that project, my sense of responsibility widened. The factory had taught me to respect operations, and Singapore taught me to respect the public. It also taught me that successful delivery depends on more than engineering: you have to understand the customer’s mission, respect the local context, coordinate across boundaries, and stay with the work until the system performs in the environment it was built for. That was a different kind of leadership from the factory, where the users were people I could meet and understand through their roles. The city’s users were mostly unseen. A commuter passing through a gate would never know who designed the transaction flow, tested the device behavior, worked through the payment logic, or made sure the system could recover from exceptions, and that anonymity made the responsibility larger rather than the work less meaningful. A gate opens, a passenger passes, and nothing happens. That nothing is the success. I carried that lesson deeply.

Singapore also taught me something about scale that would matter in the next stage of my ITC journey. A public infrastructure system is never built by one clever engineer working alone. It requires teams, coordination, standards, communication, testing discipline, customer trust, and the ability to work across technical and institutional boundaries, and by then I was beginning to see that the challenge reached past building better systems into building the capability to keep building them. That realization became important when my ITC journey moved into its third stage, the Software Technology Park, where the question changed again: how do you take a small team and create the talent, process, culture, delivery discipline, and ambition needed to serve serious customers? I did not yet have the answers, and the factory and the city had prepared me for the question. The factory taught me that software must serve real work, the city taught me that infrastructure must earn public trust, and the Software Technology Park would teach me that technology scale depends on people scale.

The highest achievement of the fare collection system was not being noticed. Behind the ordinary moment was engineering, transaction logic, communication, reconciliation, payment discipline, operational care, and close collaboration across teams and institutions, while to the person passing through it was something simpler and more important. A person taps the card, the gate opens, and the city keeps moving, and inside that ordinary movement, trust has done its work.