FastMBO - Internal Goal-Setting and Bonus Calculation System — architecture review¶

This page assembles sections relevant to architecture review: goals, requirements, and constraints; system model; architecture and integrations; security, quality, and operations; and decisions, trade-offs, and risks.

Summary¶

Status¶

historical internal project / reconstructed case study

Role¶

initiator, systems analyst, concept author, prototype developer

Stack¶

Type: Internal automation / MBO system / lightweight internal ERP; Scale: internal use in an organization of up to 350 employees; Period: early transition stage from IT administration to systems analysis and internal systems development

Project value¶

FastMBO is an internal system for automating goal-setting, evaluation sheet collection, achievement approval, and bonus calculation based on the MBO model.

What this demonstrates¶

FastMBO demonstrates an early stage of my professional evolution: from an infrastructure-focused role to systems analysis, internal automation, and architectural thinking.

The project demonstrates:

ability to identify an operational problem and propose automation;
transition from a manual process to a digital workflow;
work with roles, statuses, periods, calculations, and approvals;
understanding of the economic effect of automation;
early experience designing an internal ERP-like system;
transition from “writing a utility” to “designing a system”.

Goals, Requirements, and Constraints¶

Goals and Non-Goals¶

Create an internal system that moves the MBO process from manual document flow to a controlled digital workflow.

Requirements¶

The system was intended to support:

creation and configuration of evaluation periods;
management of metrics and achievement templates;
generation of evaluation sheets for employees;
online data entry;
approval of achievements and metrics;
automatic calculation of total scores, point value, and bonus amount;
manual corrections where required;
publication of results in a personal account;
export of final results for further processing.

Constraints¶

System Model¶

Domain Model¶

User Roles (Actors)¶

Employee - fills in the evaluation sheet, adds achievements, views results.
Manager - approves achievements and metrics of direct reports.
Responsible user - controls the period and checks data completeness and correctness.
Director - approves final results and controls the bonus fund.
System administrator - manages settings, users, periods, and audit.

Data Model¶

ERD¶

API Contracts¶

Architecture and Integrations¶

Architecture¶

Architectural Approach¶

The system was designed as a monolithic web application for internal use.

The target architecture included:

web interface for employees and managers;
authentication and authorization;
service layer for business logic;
relational storage;
reporting and export module;
action logging;
file storage for attachments.

Architecture Artifacts¶

BPMN Business Processes¶

AS-IS¶

TO-BE¶

C4 Context¶

C4 Container¶

C4 Component¶

Integration Flows¶

Target TO-BE Process¶

The target process assumed a transition to a controlled digital cycle:

Preparation of the evaluation period.
Approval of metrics and achievement templates.
Generation of evaluation sheets and assignment to job positions.
Period launch and input unlocking.
Online entry of metrics and achievements by employees.
Parallel validation by managers.
Period closure and input locking.
Automatic calculation of scores, point value, and bonuses.
Manual corrections where required.
Final approval.
Publication of bonuses in the personal account.
Export of final results to 1C via CSV or connector.

Security, Quality, and Operations¶

Security and Access Model¶

User Roles¶

Employee - fills in the evaluation sheet, adds achievements, views results.
Manager - approves achievements and metrics of direct reports.
Responsible user - controls the period and checks data completeness and correctness.
Director - approves final results and controls the bonus fund.
System administrator - manages settings, users, periods, and audit.

Non-Functional Requirements¶

Failure Modes¶

Sizing and Cost Notes¶

Economic Effect¶

The project was justified through the reduction of manual work during preparation, checking, recalculation, and data transfer.

The estimate showed time savings of more than 300,000 RUB per year for an annual evaluation cycle. With a monthly or more frequent cycle, the effect scaled significantly due to process repetition.

Additional effect:

less manual data transfer;
fewer repeated approvals caused by corrections;
higher status transparency;
faster preparation of final results;
easier audit of the evaluation period.

Decisions, Trade-offs, and Risks¶

Key Decisions¶

Trade-offs¶

Monolith vs distributed architecture¶

A monolith was justified by the context:

limited user base;
internal deployment;
one main business process;
no need for distributed architecture;
limited maintenance resources.

Project Limitations¶

The project was not brought to the maturity level of a production system with a full delivery lifecycle, testing process, release process, and ongoing support.

The original documentation was incomplete and insufficiently formalized. Part of the current architecture materials was reconstructed later as a portfolio case study.