background Layer 1

Event-Driven Virtual Office for IT Delivery Transparency

Customer
BAKAI BANK OJSC
Project manager on the customer side
Abbas Fatullaev
CIO
Year of project completion
2026
Project timeline
september, 2026 — october, 2026
Project scope
215 automated workstations
Goals

Give IT leadership of the bank a real-time, verifiable picture of where delivery work is and where it is stuck — without status meetings, manual reports or surveillance.

1. Replace manual status collection across 37 delivery teams with an automatic view built from Jira, GitLab and Slack events.

2. Let every manager see their own team (scoped by the Active Directory management hierarchy) and drill from a person to the exact task, merge request or review behind any status.

3. Link code to business work: connect GitLab activity to Jira issues automatically, so progress on a story is visible without asking developers.

4. Motivate engineers transparently: reward delivered results (closed tasks, merged and reviewed code) with internal BAKAI Coin and an open leaderboard, with anti-fraud rules.

5. Keep trust: make hidden monitoring technically impossible rather than forbidden by policy.

Project Results

Production data, 15.09–22.10.2026:

  • 215 employees, 37 teams, 7 tribes in one live view; 144 users signed in (67% of staff), 70–108 weekly active users.

  • 53 Jira boards and 44 projects, 258 GitLab repositories connected; 14,289 Jira issues and 27,540 GitLab events processed, 96,000+ webhooks.

  • 58% of merged MRs automatically linked to Jira issues; 12,653 status comments posted to Jira with no manual work.

  • 2,949 Jira issues resolved since launch are visible to managers with their code activity.

  • BAKAI Coin: 182 engineers rewarded for closed tasks, testing, merges and reviews.

  • Anti-fraud flagged 4,457 suspicious accruals (self-merges, self-reviews, too-fast closures) and capped 325.

  • Zero storage of message content; no "inactive" status exists in the system.

The uniqueness of the project

Most activity trackers can say "employee is inactive". This system cannot — by design. There is no "idle", "absent" or "not working" value in the database schema, so such a status can never be shown. Absence of events is displayed as "not enough data", never as a judgment about a person.

Every status on the map is derived from a concrete Jira, GitLab or Slack event and shown with a link to that event, so any conclusion can be verified by the manager and by the employee.

Slack message text is discarded before it reaches the database or logs; only metadata is used.

The office is rendered as an interactive 3D floor (three.js) where teams sit in zones and employees' states update live over WebSocket — readable both on a laptop before a stand-up and on a wall TV in the office.

Gamification pays for results, not activity: no rewards for commit counts, messages or "online time"; one task is paid once per task–employee pair, self-merges without a peer approval earn nothing.

Used software

Built in-house, fully on-premise inside the bank perimeter.

Frontend: Angular 18 (standalone components, signals), Angular Material, three.js for the 3D office.

Backend: Python 3.12, FastAPI, Pydantic v2, SQLAlchemy 2, Alembic migrations; Redis 7 + ARQ background workers and schedulers; WebSocket live feed.

Data: PostgreSQL 16.

Integrations: Jira Software Data Center 9.x (webhooks + fallback polling), GitLab Self-Managed 16.x (webhooks), Active Directory over LDAPS (login, org hierarchy), Slack Enterprise Grid (metadata only).

Infrastructure: Docker Compose, nginx with TLS on the bank's internal CA, GitLab CI/CD with mandatory lint, type, API-contract and test gates; Prometheus metrics, health checks, audit log.

Quality: OpenAPI contract, ~460 automated backend tests.

Difficulty of implementation
  • Delivered in-house in a short cycle: production launch on 15.09.2026, stages 0–5 of the plan completed by October 2026.

  • Incomplete org data: AD has a manager attribute for only ~23% of employees; the rest of the hierarchy had to be modelled and maintained manually without breaking visibility rules.

  • Unreliable event delivery: webhooks can be lost or delayed, requiring idempotent processing, polling fallback, stale-task refresh and recovery of stuck deliveries.

  • Heterogeneous Jira setups: different boards, workflows, custom fields (QA, story points, T-shirt sizes) and shared boards — all made configurable in the admin UI rather than code.

  • Fair rewards: designing anti-fraud rules (caps, one payment per task–person, no self-merge rewards, QA double-pay protection) that engineers accept as fair.

  • Trust and security: privacy-by-schema, LDAPS, internal CA, audit log, on-premise only.

Project Description

Initial situation. The bank's IT development division runs 37 delivery teams (215 people) grouped into tribes and blocks. Work lives in Jira, code in GitLab, communication in Slack, people in Active Directory — but nothing connected them. Managers learned the state of work by asking people at stand-ups and in chats; linking a merge request to a business task was manual; there was no shared, fair way to recognise engineers' contribution. Any monitoring tool had to pass a strict trust requirement: no hidden control of employees, no reading of correspondence, everything on-premise.

Implemented solution. BAKAI Virtual Office — an on-premise web platform that shows the IT division as a live 3D office. Each employee's state (working on a task, in review, in communication, no active task, not enough data) is computed every few minutes from Jira, GitLab and Slack events and always shown with links to its sources. Managers see only their subtree of the AD management hierarchy. The platform includes: employee and task catalogues with filters by board and team, task status summaries, a live activity feed, the BAKAI Coin reward system with leaderboards by team, tribe and block, manual grant requests with approval, admin reference data (blocks, tribes, teams, roles, tech stacks, Jira boards and status mappings) changeable without redeploy, integration monitoring, live server logs and a full audit log.

Implementation specifics. GitLab events are linked to Jira issues by extracting issue keys from branches, commits and MR titles, validated against real project keys; the platform posts idempotent comments back to Jira. Jira is ingested through webhooks with fallback polling and targeted refresh of stale issues, so the map stays correct even if a webhook is lost. Coin rules are versioned and the transaction ledger is append-only; anti-fraud caps daily and weekly accruals, blocks double payment when one story is closed by several MRs, and ignores self-merges. Four RBAC roles (sysadmin, tribe lead, HR, employee). The hardest part was the org structure: AD provides a manager for only part of the staff, so the hierarchy is combined from AD and managed reference data and materialised as paths for fast scoped queries.

Changes after implementation. Since launch on 15 September 2026, 144 employees and all tribe leads use the platform; 58% of merged code is linked to business tasks automatically and over 12,000 status comments reached Jira without manual work. Managers open one screen instead of collecting status; every conclusion is traceable to an event; engineers see their own contribution and ranking transparently; team structure changes are made by admins in minutes without developers.

Project geography

Bishkek, Kyrgyzstan — IT development division of the bank (215 people, 37 teams, 7 tribes). On-premise deployment in the bank's data center; designed to scale to 1 500 employees and other divisions.

Additional presentations:
01-virtual-office-zoomed.png
00-virtual-office.jpg
02-leaderboard.jpg
03-tasks.png
04-audit.png
05-integrations.png
We use cookies for analytical purposes and to deliver you the best experience with our website. Continuing to the site, you agree to the Cookie Policy.