Learn: Central Tools


Find answers to...

  • Trade offs between going Infrastructure-as-a-Service, Platform-as-a-Service, Software-as-a-Service
  • Mainstays in WOG networks, especially the endpoint device, network, and backend infrastructure
  • AI tools through Pair, Launchpad, AI Bots
  • Variants of M365 that GovTech deploys, across M365, SG-Teams, Sharepoint Online, ServiceNow ITSM
  • GovTech's common applications for resource, visitor, asset, workflow management
  • HR administration through HRPS, Workpal


  • Don't dump money recreating stuff already developed
  • See how far we are behind everyone else
  • Rid ourselves of misguided sense of superiority and uniqueness

My Observations

If we think about the public sector as a single organization, it makes sense to use the same tech stack for efficiency, cost savings, knowledge management.
Too many people want to build their platforms/systems/tools without considering the long tail that comes with their own development. The ROI would be stacked in favor of central tools given the cost and effort advantages.
People don't know enough or don't bother to find out about the central tools on offer (or perhaps sometimes it's still work in progress). So they go do their own stuff, which then duplicates development work and wastes resources at the aggregate level.
Or sometimes people just think they've a superior product than what is already being offered centrally.
People in organizations think they have very unique requirements and processes that cannot fit off-the-shelf or central products, but these often are because of inflexibility (i.e. no process reengineering or thinking out of the box) or human stubbornness.
On the other hand, inefficiency and mismanagement at the central level will snowball, as every additional/unnecessary thing that's provisioned gets multiplied by every officer


Sorry, nothing here

Watch on Youtube