Job-Level Split and Role-System Changes

1. Existing Model

The job system had three tables:

• A job-role table, for example Java developer
• A level table, for example P5 or P6
• A position table combining role and level

It represented one system, had no concept of tenants, and downstream business systems used the levels directly in their rules.

2. Requested Level Split

The existing levels P5, P6, and P7 were to become levels 10 through 16. For example, P5 would split into 10 and 11.

At first glance, implementation could mean adding a new level field, creating a mapping, and asking upstream systems to switch to it.

3. Sources of Complexity

Range-Based Rules

An upstream rule might say “level >= P6.” After the split, should that become “>= 11” or “>= 12”? Every range rule needs clarification when a broad level maps to several finer levels. A shared numeric scale was proposed so callers could compare values without depending on level names.

Future Level Systems

This change was a single split, but future requirements might involve several companies, multiple level systems, or another split. The design question was whether every upstream system should be changed each time, or whether the model should support tenants and multiple schemes from the start.

4. Possible Directions

1. Numeric scale plus a new level field: Lower migration cost, but no solution for multiple tenants.
2. Host business rules in the master-data service: Move range-based rules to the data platform as a transitional approach.
3. Tenant and scheme-aware model: Give each tenant an independent role, level, and position system. This has the highest migration cost.

The key decision was whether to solve only the immediate level split or use the opportunity for a broader model change.