Architecting State Digital Platforms: People-Centered, Iterative Transformation
At the end of every government form and every “Contact Us” click is a person waiting for a clear, fast answer. Too often our attention stays on shiny delivery-cloud lift-and-shifts, flashy dashboards-while the user pain that drove the work remains the metric least measured. Recent leadership moves at the Maryland Department of Information Technology remind us why we must keep that human endpoint at the center of digital modernization.
A quick signal
I recently read about Marcy Katz Jacobs’ departure from her role as deputy secretary and chief digital experience officer at Maryland DoIT. During her brief tenure after Maryland Digital Service was formed in 2023, the team rebuilt hundreds of websites and introduced a state design system while embedding iterative, user‑centred practices across projects. An interim leader has been named to carry forward the work.
Why this matters beyond one resignation
What appears to be a personnel change is actually a useful lens on a deeper, recurring theme in public-sector digital transformation: moving from isolated modernization projects to platform thinking and operationalized user research. The Maryland example surfaces several architectural and organisational lessons that every CTO, chief architect, or state CIO should treat as checklists rather than anecdotes.
Design systems are governance, not decoration
A design system is more than a shared CSS file. It is an organisational contract: accessibility rules, interaction patterns, and performance budgets that bind teams across agencies. When done well, it reduces duplication, reduces front-end tech debt, and speeds delivery; when done poorly, it becomes a brittle dependency that prevents local innovation. The right approach treats the design system as a living product with clear ownership, versioned releases, and a public changelog.
Ship-and-learn beats “big-bang” every time-if you instrument it
Iterative delivery (the “ship-and-learn” mindset) reduces risk, but only if you measure outcomes instead of output. Track task completion rates, call volumes for related services, and time-to-resolution-not just site visits. Canary releases, feature flags and A/B testing should be standard in government rollouts. Observability (logs, traces, real user monitoring) must be in place before you call a release successful.
Platform-first, not portal-first
Rebuilding “hundreds of websites” can be a symptom of two divergent strategies: replicate-and-maintain, or consolidate-and-compose. I advise architects to aim for a composable platform-headless CMS, reusable components, APIs and shared authentication-so each department can present unique content without rebuilding common plumbing. This reduces long-term operational expenditure and makes security and compliance enforceable centrally.
People are the real currency
Public-sector tech succeeds or fails on talent and culture. Recruiting engineers is one thing; retaining people who can operate at the intersection of policy, UX research and systems engineering is another. Secondments from industry, apprenticeships, and clearly mapped career paths inside government teams are investments that pay compounding returns. If the project narrative ends at “we shipped,” you’ve already lost half the value.
Trade-offs worth naming
- Speed vs stability: rapid rollouts expose friction faster but require mature rollback and monitoring practices.
- Centralization vs autonomy: a central design system scales governance; local teams need the flexibility to innovate within guardrails.
- Rebuild vs migrate: a full rebuild can remove legacy constraints but risks reintroducing old assumptions; migration with strangler patterns often achieves better continuity.
A note for Indian states and Northeastern administrations
This model is highly transferrable. Many Indian states manage fragmented departmental sites and face similar user‑journey problems at scale. A focused effort to create a state-level design system, paired with shared platform services (auth, payments, notifications) and rapid‑feedback user research, can dramatically lower the cost of digital public services while improving uptake and trust. Frugal engineering-minimal viable platforms, reusable components, low-cost observability-works particularly well where budgets and connectivity are constrained.
Key takeaways
- Treat design systems as productized governance: version, own, and maintain them.
- Measure user outcomes, not just delivery milestones.
- Build composable platforms (APIs + components) instead of many bespoke portals.
- Invest in retention and cross-sector talent pipelines for public teams.
- Bake observability and rollback strategies into every release.
Closing thought
Modern digital government is less about flawless launches and more about sustainable systems that learn from every interaction-and the architectural choices we make today determine how well those systems learn tomorrow.
About the Author: Sanjeev Sarma is the Founder Director and Chief Software Architect at Webx Technologies. With a core focus on Generative AI integration, Cloud-Native Scalability, and Enterprise Software Architecture, he has spent over two decades driving digital transformation across Northeast India and beyond. Beyond his corporate leadership, Sanjeev is deeply invested in shaping the future of the IT industry. He serves as an Industry Expert on the Board of Studies for Assam Don Bosco University’s School of Technology, advises state technology committees, and actively mentors emerging tech startups at STPI. He brings a unique, dual perspective of high-level enterprise execution and future-ready academic curriculum development.
