SIMPEG

SIMPEG is the personnel information system of the City Government of South Tangerang: one system for the records, careers and services of every civil servant across the city's agencies. Employees keep their own data up to date and follow their salary steps, promotions and retirement; administrators in each agency and the city's personnel office work on exactly their part of the organisation; and every rule the system applies is taken from the regulation that sets it. It is an internal application, used by the city's staff rather than the public.

I have led its development since 2023, and the current generation — a new Laravel core and a new Vue interface — is entirely my own work, from the data model to the screens.

At a glance

Client	Diskominfo Kota Tangerang Selatan (the city's communication and informatics office), which manages the city's applications; operated by the city's personnel office, BKPSDM
Role	Solution architect since 2023, leading the team — quality assurance, backend developers, a UI developer, DevOps and DevSecOps — and the lead backend developer, writing the main API myself
Period	Since 2023
Version	2
Status	In development — an internal application without a public address
Stack	Laravel and PHP, Vue and TypeScript, Rust, Python; PostgreSQL, Redis, S3-compatible storage; OpenTelemetry, Elasticsearch and Kibana; Docker

My role as the solution architect

On SIMPEG I work first as the solution architect. The domain master for personnel is the city's personnel agency, BKPSDM, so that is where the work begins: I learn how personnel administration runs and the regulations behind it, listen to what the agency needs and to what goes wrong for its staff today, and translate that into an architecture.

• Choosing the technologies the system is built on.
• Designing a modular architecture and breaking its functions into separate modules.
• Designing how it is deployed and operated.
• Dividing the work across the team: quality assurance, backend developers, a UI developer, DevOps and DevSecOps.
• Reviewing what quality assurance and DevSecOps find, and feeding the fixes back into the architecture and into the team's workflow.

Alongside that I am part of the team as a backend engineer, on the module where a mistake would cost the most: the main API that every other part of the system depends on.

The challenge

A city government employs thousands of civil servants across dozens of agencies, and almost everything about them is governed by regulation: their pay, their salary steps, their promotions, their retirement age, the structure of the agency they work in. The city already had a personnel system, built by another team, but its data had never been held to a standard and many of its rules had been written into code years earlier and had quietly gone out of date.

The new system had to bring that data across without losing it, apply the rules as they stand on any given date rather than as they stood when someone last edited the code, and serve three very different groups at once — employees looking after their own records, administrators in each agency, and the personnel office that oversees them all — each seeing only their own part of the organisation.

What it does

A. Lets employees look after their own records

Every employee has a portal on the phone and the desktop: their profile, family, career and competence history, and what needs their attention. They change their data by proposing a change with its supporting documents, follow each proposal until it is approved or returned, and open salary-step, promotion and retirement services with the documents each one requires.

B. Gives administrators the complete record

Administrators keep personal data, placements, families and more than twenty kinds of career history, review employees' proposals, take salary-step, promotion and retirement cases through their decisions, and receive a draft decree whose every figure comes from the records.

C. Keeps the organisation as it was on any date

Each agency's structure and position map belongs to the regulation that set it and takes effect on its own date. The whole government can be drawn as it stood on any day, and the number of people in each position is calculated from their appointments.

D. Applies rules taken from regulations

Salary tables are kept per regulation with their effective dates, retirement age comes from the position held, and a person's legal status changes automatically when the events the regulations define begin and end.

E. Scopes every piece of access

Access is granted as a role at a scope — the whole city, one agency, or one unit such as a school — requested and approved by different people, limited in time, and following the national civil-service agency's circular on managing access to personnel systems.

F. Reports, reminds and invites

Reports cover the employee list, the seniority list, recapitulations, staffing and more, each filtered by the reader's scope. Reminders of upcoming due dates go out by e-mail, and invitations to create an account are sent in daily batches.

G. Verifies identities and has documents signed

An account holder's identity is verified with their identity card and a live face challenge. Documents that need a signature are signed on Aurograf, the city's digital signature platform, with SIMPEG as one of its external clients.

H. Brings the old data across

Records from the previous system are imported phase by phase from a read-only copy, repeatably, with a report of every problem found and no personal data in that report.

Standards it follows

Standard	What it guarantees here	Where it lives
OAuth 2.0 and OpenID Connect, with PKCE	sign-in through an external single sign-on without a client secret in the browser	Core API, Web App
JSON Web Tokens	one token format every service can verify on its own	Core API
TOTP (RFC 6238)	two-factor authentication with any authenticator app	Core API, Web App
Presigned URLs, AWS Signature Version 4	files move between browsers and storage without passing through the core	OSW
W3C Trace Context and OpenTelemetry	one trace from the user's request through every service	every module
ISO 8583 and ISO 4217	every amount is an integer in the currency's minor unit	Core API, Web App
National civil-service circular on access management	access requested and approved, the verifier is not the approver, grants last at most two years	Core API
Civil-service regulations on pay, rank, retirement and allowances	each rule applied is the one in force on the date in question	Core API
WAI-ARIA	navigation that announces the current page and has touch targets large enough for a phone	Web App

How it is built

SIMPEG is a core API and a web application surrounded by specialised services, each with its own version and release cycle. The core holds the personnel rules and data; storage, regional data, the face challenge and document previews are reusable modules I also use in other projects; and signing is handed to the city's signing platform.

The core API: employee records and histories, proposals, services and decisions, rules from regulations, the organisation chart and scoped access.

The web application employees and administrators work in.

The storage service every document and attachment passes through.

The regional data service behind every address.

The live face challenge used during identity verification.

The renderer that gives every uploaded document its preview.

The city's signing platform, on which SIMPEG's documents are signed.

How it is delivered and operated

Every module runs as its own container stack with a versioned image, so the core, the interface and each service can be released on their own schedule. The trace of every request is collected in one place together with the logs, so a question about any record or any slow screen can be answered from evidence. The move from the old system is itself part of operations: the import runs in phases that can be repeated safely as the old system keeps changing until the switch.

Where every trace and log of the platform ends up.

Key decisions

Reuse what already exists. Storage, regional data, the face challenge and document previews are modules I built to be shared between projects, so SIMPEG uses them as they are rather than growing its own copies. The personnel system only contains what is truly about personnel.

Signing belongs to the signing platform. The city already runs a digital signature platform with its own chain of trust. SIMPEG does not hold certificates or sign anything itself: it registers each signing stage with that platform as an external client, and receives the signed document back.

The old data comes across in phases. The previous system's database is read without ever being written to, each phase can be run again safely, and every problem is reported rather than silently fixed or allowed to stop the import.

Rules come from the regulations themselves. I read the regulations rather than copy the old system's behaviour; what a regulation changes is stored as data with its effective date, and the code that applies it names the regulation it implements.

Money has one convention. Every amount, from a salary table to a decree, is an integer in hundredths of a rupiah, the same convention I use in every system I build.

The organisation chart stays relational and versioned. The chart is master data for employees, positions and access, so it lives in the same relational database, in versions that each agency adopts on its own date.

Access follows the organisation and the national guidance. Each grant names its scope, is requested and approved by different people, and ends on its own.

Employees change their own data, and a reviewer approves it. Rather than administrators typing every change, employees propose corrections with their documents, through the same validation an administrator's edit goes through, and a reviewer decides. The people who know the facts best enter them, and nothing reaches the record unchecked.

History

SIMPEG replaces an older personnel system built by another team, which now serves only as the source of the data being brought across. My work on the new system began in 2023, and its current generation — a new Laravel core and a new Vue interface — was rebuilt by the team to my design, with the core API written by me.

Status

SIMPEG is in development and the work is ongoing. This page will grow with it as new parts of the system are released.

Terms

Agency

A department of the city government, such as an education or health office, with its own structure and employees.

Personnel office

The city's office that oversees civil servants across every agency and operates the system day to day.

Salary step

The periodic increase in a civil servant's basic salary that follows from their years of service in a rank.

Decree

The official document that records a decision about an employee, such as a new salary step.

Single sign-on

One account that lets a person sign in to many applications without a separate password for each.