The Business Challenge
Each of the four systems started as a standalone build, solving one part of the department's operations — a way for enforcement officers to file reports from the field, a counter system to register cases for court mention, an HR platform to track staff, a registry for physical case files. As adoption grew across branches and enforcement stations, so did the seams between them: the same officer needed separate logins for enforcement and administrative systems, granting or revoking access after a staff transfer meant repeating the same change in multiple places, and there was no single source of truth for who currently had access to what across the department's software.
System Overview: A Federation, Not a Monolith
Rather than merging four already-working systems into one fragile rebuild, I connected them around a shared identity core — AdminV2, the staff management system that already held the department's authoritative staff and organizational records. Each satellite application integrates with that core in a way that matches how it's actually used:
- Dakwa and Batching authenticate their users with live cross-database queries against AdminV2's core tables on every login — gated by a per-application access grant registered in a central SSO table, not a copied credential store.
- eLapor draws centrally-managed configuration (such as spam-protection keys) from the same core database, decrypted with an encryption key shared consistently across all four applications.
- A direct server-to-server API call keeps a staff member's email address in sync between Dakwa and AdminV2 whenever it changes in either system.
- Batching's own role and permission matrix can be centrally administered from AdminV2, with a live fallback to the core's copy of that matrix whenever it's reachable.
Worth being precise about scope: each application still owns its day-to-day case data independently today — a report filed in eLapor doesn't yet automatically create a prosecution record in Dakwa. What's unified right now is identity and access governance across the whole ecosystem. Case-to-case data automation between the enforcement, prosecution and records systems is the natural next phase to build on top of that shared identity layer.
The Four Modules
Each module below wasn't designed as a piece of one master plan — it was built to solve one division's specific, immediate problem. What each one grew into afterward follows a similar pattern: once a system is already capturing data as a side effect of doing its job, that data becomes the foundation for something more.
eLapor
Enforcement officers needed a way to file reports from the field — but every report came out however the officer happened to format it, making them inconsistent and hard to file, compare or search afterward.
eLapor was originally built to solve exactly that: a system that generates every enforcement report in one standardized format (PDF/JPG), with photo evidence attached, regardless of who's filing it or from which enforcement station.
Since the system was already capturing every report's data as a side effect of standardizing its output, that data became the foundation for genuine enforcement analytics. What started as a report generator grew into a centralized operational intelligence platform — transforming fragmented, spreadsheet-based reporting into a real-time analytics and decision-support ecosystem that consolidates operational, performance, logistics, geographic and environmental data into a single source of truth, using AI-powered analysis and forecasting to support strategic planning and resource optimization.
- Standardized enforcement report generation (PDF/JPG) with photo evidence
- Automated KPI monitoring for individuals, teams, branches and operational units
- Performance analytics dashboard with drill-down reporting
- Geospatial intelligence and black-spot mapping
- Vehicle readiness, maintenance and logistics monitoring
- Operational trend analysis and benchmarking
- AI-assisted root-cause analysis for performance changes
- Environmental factor correlation analysis
- Resource planning and forecasting models
- Six-month predictive performance projections
Performance Intelligence
Tracks operational KPIs at individual, team, branch and regional levels while identifying top-performing units and emerging trends.
AI Root Cause Analysis
Uses historical and contextual data to explain why operational performance rises or declines, considering weather, seasonal trends, traffic conditions, public holidays and resource availability.
Predictive Forecasting
Generates six-month projections and strategic recommendations to support operational planning, manpower allocation and logistics preparation.
Dakwa (Prosecution System)
The Prosecution Division (Bahagian Pendakwaan) could have a large number of Accused Persons present at court at the same time during trial sessions, with no structured way to manage who's next, what stage a case was at, or how to find a specific person's case quickly at the counter.
Dakwa was built as a queue-management platform: the Accused is registered for a hearing (sebutan kes), given a queue number and a QR code, and counter staff can pull up their case status instantly on a later visit instead of searching manually — a meaningful difference when one session can involve a large flow of Accused Persons through the same court.
Once the queue system was in place and generating records of its own, that data became the basis for AI-assisted pattern analysis — surfacing trends in case volume, court load and processing time that the division couldn't see when the process was still manual.
- Court queue-number management for Accused Persons during trial sessions
- QR-code case lookup at the counter
- Multi-court hearing scheduling & case status tracking
- AI-assisted pattern analysis on queue & case records
- PDPA-aware database backup & restore, hardened after real production incidents on the department's server
AdminV2 (Staff Management System)
Every application built for the department — enforcement, prosecution, records — needed to be accessed by the same pool of Road Transport Department staff, but with no shared way to manage who could log into what.
AdminV2 started as an access-control system — one place to manage which staff member could access which application, closing that gap first before it became the identity core the rest of the ecosystem is now federated around.
Since the staff data needed for access control already lived there, AdminV2 grew into a full staff hub — the foundational workforce management and identity governance platform now powering a growing ecosystem of interconnected business applications: the central source of employee data, authentication, authorization, workforce analytics, training management and certification governance, enabling secure Single Sign-On (SSO) access across multiple independent systems.
- Centralized workforce master data management
- Single Sign-On (SSO) authentication across multiple applications
- Role-based access governance and permission management
- Employee lifecycle and service history tracking
- Branch, station and organizational workforce analytics
- Position, grade and vacancy monitoring
- Training management and compliance tracking
- QR-based attendance validation workflows
- Certificate verification and automated generation
- Centralized integration layer for future applications
Identity & Access Governance
Centralized authentication and authorization ensuring employees only access systems and modules relevant to their roles and responsibilities.
Workforce Intelligence
Provides real-time visibility into workforce demographics, staffing distribution, vacancies, grade composition, service history and organizational trends.
Training & Certification Governance
Manages course administration, attendance validation, certificate approval workflows and annual training KPI compliance monitoring.
Batching (Records System)
The department handled a large volume of physical forms and case documents with no consistent way to search for a specific one later, and no record of where a document had been or who had handled it.
Batching was built to generate a batch number for every document at intake, purpose-built so staff could search for any document quickly and so every movement it made afterward left a traceable record.
- Batch-number generation & search at intake
- Inter-department movement logging with full audit trail
- Shelf/rack storage assignment & lookup
- Scheduled disposal workflow with division-head approval routing
- Role-based access centrally administered from AdminV2
An Unplanned, Comprehensive Architecture
None of these four systems were built as part of one master plan — each solved one division's own tactical problem, on its own timeline. But every one of them ended up capturing structured data as a side effect of doing its job: queue and case records from Dakwa, standardized enforcement reports from eLapor, staff and disciplinary records from AdminV2, document movement trails from Batching.
Put together, that wasn't four separate data sets — it was one comprehensive picture of the department's operations. Compiled into statistics, performance evaluation, and forward-looking projections and forecasts, that data is interrelated in a way that can inform how senior management sees the organization's overall performance and sets its direction: where enforcement resources are falling short, how the Prosecution Division's court load is trending, and where the department should be investing next — none of which was visible when each system's data stayed siloed inside its own division.
Outcomes & Impact
My Role & Technology
I built all four applications independently over time for the Road Transport Department, Pahang, then designed and implemented the shared identity and SSO layer that federates them into one ecosystem — including the cross-database authentication model, the central SSO registry, and the encrypted settings distribution between apps.