The Project
The project was a major digital infrastructure initiative for the Ministry of Human Resource Development (MHRD), architected, developed, and implemented by a specialist technology team on behalf of the National Informatics Centre (NIC). The system was designed to serve citizens across India at a scale that ran into the hundreds of millions — a requirement that shaped every architectural decision from the outset.
My role was to advise the Architecture Review Board for the project as it moved from pilot to full implementation. The delivery was being executed by a specialist technology team on behalf of NIC. My responsibility was architectural oversight: reviewing the decisions being made by the delivery team, providing technical direction on the approaches being taken, and ensuring that the platform’s architecture was coherent, scalable, and appropriate to the scale of what MHRD was trying to build.
This is a role that is easier to describe than to execute. Architecture oversight on a population-scale government project is a materially different discipline from architecture ownership on a commercial project. The failure modes are different, the stakeholders are different, and the consequences of getting the fundamentals wrong are measured not in revenue loss but in educational access denied to people who have no alternative.
What an Architecture Review Board Actually Does
The ARB is a governance body, not a delivery team. This distinction matters, and it is frequently misunderstood in both directions — by delivery teams who experience it as an obstacle, and by stakeholders who expect it to produce output rather than assurance.
The ARB’s job is to review architectural decisions before they are implemented at a point where changing them is still feasible, identify decisions that are locally reasonable but globally problematic, ensure that non-functional requirements — scalability, security, reliability, maintainability — are designed for rather than retrofitted, and hold the architecture coherent across workstreams that may be moving at different speeds.
In this project’s context, this governance function had specific importance. The delivery structure involved three distinct entities: MHRD as the client and policy owner, NIC as the technical authority and host, and the delivery team as the implementors. Each had a legitimate perspective on what the system should do. The ARB provided the mechanism for ensuring that architectural decisions reflected all three perspectives — and that decisions made by the delivery team in the context of their immediate workstream did not create problems at the integration points that only became visible later.
Advising that process required something beyond technical judgement. It required being credible to engineers who knew their own domain deeply, legible to government stakeholders who needed to understand architectural risk without the technical detail, and independent enough from the delivery team’s schedule pressure to insist on architectural work that didn’t produce visible output on a sprint board.
The Architectural Challenges of Population-Scale Government Systems
The platform’s ambition — hundreds of millions of potential users — is not a number that a conventional three-tier web architecture addresses by default. The architectural philosophy required for that scale is different from what you apply to a system designed for thousands or even millions of users, and the differences start from first principles rather than at the tuning stage.
The connectivity variance alone was significant. India’s user base at the time of the platform’s development spanned everything from broadband-connected urban institutions to rural users accessing it over intermittent, low-bandwidth connections. An architecture optimised for broadband delivery would exclude precisely the users the platform was most intended to reach. Content architecture, delivery mechanisms, page weight standards, and the design of interactive features all had to account for the low-bandwidth case as the baseline, not the exception.
Multi-language support at this scale introduces a different class of architectural decision. India’s linguistic diversity — 22 scheduled languages, hundreds of regional variants — means that content management, character encoding, rendering, and search all require deliberate architectural treatment. Choices made early in the content management architecture determine whether the system can accommodate new languages and content at scale, or whether each addition requires significant re-engineering.
The transactional data modules carried a different kind of architectural weight from the content delivery modules. Unlike content delivery, which degrades gracefully if a page loads slowly, transactional data is consequential — errors or inconsistencies have direct impact on the users who depend on them. The data architecture, integrity controls, and access patterns for these modules required more rigorous design than the content layers, and the ARB’s role was to ensure that distinction was reflected in how the two areas were built.
Security architecture for a government platform of this kind involves constraints that commercial systems rarely encounter in the same form. The combination of citizen data, government authentication requirements, and NIC’s infrastructure standards created a security design space that the delivery team had to navigate carefully, and where the ARB provided independent review of whether the approaches taken were adequate to the context.
The Three-Party Delivery Dynamic
One of the structural realities of government technology projects — and this one illustrated it clearly — is that delivery involves multiple entities with different accountabilities, different timelines, and different definitions of what success looks like.
MHRD’s definition of success was policy delivery: a functioning system that demonstrably served its intended purpose, with the political visibility that reflected the ambition of the project’s launch. NIC’s definition included technical sustainability: a platform that could be maintained and extended within NIC’s operational model over a long horizon. The delivery team’s definition was implementation: a system that met the specified requirements within the agreed timeline.
These definitions are not contradictory, but they are not identical. The tensions between them — particularly between the delivery team’s schedule pressure and the long-term sustainability requirements that NIC and MHRD needed — were exactly the kind of tension that the ARB was positioned to surface and resolve. A decision that satisfied the delivery team’s sprint goal but created a maintenance burden for NIC’s operational team is an architectural decision that needs to be reviewed, not shipped.
Maintaining independence from the delivery team’s schedule pressure is one of the hardest practical aspects of an ARB advisory role. The delivery team has legitimate urgency. The ARB’s job is to ensure that urgency does not result in architectural shortcuts whose cost is paid years later by the people maintaining and operating the system — or, in this case, by the citizens who depend on it.
What Architecture Oversight at This Scale Requires
Three things from this engagement that carry forward into any large-scale government architecture role.
The ARB’s value is realised before delivery, not after. The return on architecture governance is invisible — it is measured in problems that do not occur. Making that value visible to stakeholders who are accustomed to output-based progress metrics requires explicit communication of the risks being managed and the decisions being reviewed. An ARB that cannot articulate the risk it is preventing will eventually lose the organisational support it needs to function.
Population-scale systems require architectural philosophy, not just architectural decisions. The individual technical choices — database design, caching strategy, content delivery approach — matter less than the underlying philosophy that connects them. A system designed to serve hundreds of millions of people with extreme variance in connectivity, language, and device capability needs a coherent philosophy about what that means for every layer of the stack. The ARB’s role is to establish and protect that philosophy as the delivery team makes hundreds of individual decisions in its shadow.
The three-party government delivery structure requires explicit governance of the interfaces. Ministry, implementing agency, delivery partner — each interface between these entities is a point where architectural requirements can be lost, misunderstood, or deprioritised. The ARB needs to be positioned at those interfaces, not inside any one entity, to be effective. Independence is a structural requirement, not a personal virtue.
The platform went live. It served citizens across India at a scale and cost that was not achievable through any conventional channel. The architecture that supported it was not perfect — no system of that complexity and ambition is — but it was coherent, it was designed for the right scale, and it was delivered with the governance that a project of that significance warranted.
That is what an Architecture Review Board is for.
