Architecture Governance for an HR Master Data Platform
HR Master Data Architecture Governance
1. Background
As part of a wider organizational migration, the HR master-data system moved from a group-wide platform to an Ant-operated platform. After migration, it grew into a data platform serving a large number of callers. Business growth and frequent organizational changes exposed unclear module boundaries, heavy coupling between foundational capabilities and business rules, more than 700 interfaces with duplicated behavior, inconsistent dependency versions, scattered messaging and scheduled jobs, and gaps in monitoring and stability work.
The source notes say a systematic architecture-governance initiative began in CY24.
2. Goals and Scope
The goals were to make the system easier to maintain and evolve, consolidate interfaces around clear capabilities, establish layers and responsibilities, improve reliability and observability, and leave room for organizational separation and possible future multi-tenancy.
The scope covered a DDD-oriented project structure, API consolidation, dependency governance, messaging and job changes, cache and DRM configuration governance, web-layer changes, storage upgrades, and stability work. These are the initiative's areas of work; the list alone does not establish that every item was delivered.
3. Technical Directions
3.1 Project Structure and Layers
The target layers were domain for business rules, application for orchestration, infrastructure for databases, RPC, MQ, and middleware, and facade for external interfaces. Business rules should live in the domain. Facades should adapt parameters and convert inputs and outputs. Infrastructure should not own business decisions. Dependencies should flow in one direction to avoid cycles.
The cleanup plan named historical modules such as zdal, hrworkcore-facade, hrorg-metadata-ext-client, and hrorg-data-gateway, plus model modules that needed splitting or relocation. The aim was to reduce lateral dependencies and the tendency for a central module to become a dependency of everything. Shared capabilities belonged in infrastructure or common modules.
3.2 APIs and the Master-Data Read/Write Model
The governance proposal aimed to consolidate more than 700 interfaces into roughly 200 domain-level capabilities. Similar behavior would have one entry point. Old interfaces would be marked @Deprecated, forward internally to new implementations, and be retired gradually after callers moved.
Writes should pass through the master-data service rather than bypassing it to modify the database. A workbench should forward requests, not host core business logic. This protected consistency, clarified system ownership, and made behavior easier to govern.
3.3 Dependency Management
Versions should be controlled in a parent POM, with child modules avoiding independent declarations. The plan also called for a consistent groupId policy, no facade dependencies on implementation modules, and third-party middleware isolated in infrastructure. The intended effect was fewer dependency conflicts, more controlled upgrades, and fewer hidden transitive dependencies.
3.4 Messaging
Messaging had been scattered and tightly coupled to business code. The proposed structure kept business-event creation in the domain and message delivery in infrastructure, behind a unified service for creating, delivering, and sending messages. It made the write-table, send, and archive stages explicit and included idempotency controls.
The source describes clearer message flows and lower duplicate-send risk as intended benefits, and records an approximately 20-second reduction in service startup time. That number is an effect reported in the original notes, without a benchmark attached here.
3.5 Scheduled Jobs
The plan split jobs with several responsibilities so each did one thing, clarified the distribution model, removed redundant conditional logic, and strengthened idempotency and retries. The goals were more stable jobs, better observability, and lower cognitive cost.
3.6 Cache and DRM Configuration
Cache work included a feature switch, removing local caches such as MapDB, clarifying when caches were active, and unifying their management. DRM configuration work would inventory settings, merge redundant ones, move management into infrastructure, and reduce conflicts from scattered configuration.
3.7 Web and Storage
The web-layer direction separated frontend and backend, decoupled the workbench from master data, separated query from mutation interfaces, and placed page-related logic behind shared backend capabilities.
Storage plans included replacing entSearch with ZSearch, improving Elasticsearch fuzzy search, adding data version control, and supporting rollback of historical data.
3.8 Stability and Platform Knowledge
Monitoring work covered summary logs in dashboards, top-traffic statistics, usage by calling system, slow SQL, and slow interfaces. Data-governance work included version snapshots, query auditing, alert-noise reduction, and consistent log levels and formats.
Platform documentation would include a system white paper, user guide, QA material, and GPT-assisted knowledge Q&A.
4. Main Difficulties
Removing modules was risky because dependency chains and implicit dependencies were numerous. Consolidating APIs for a large caller base had a wide blast radius. During coexistence of old and new systems, data consistency needed careful checks. Messaging and cache behavior was hard to validate through static inspection alone. Frequent organizational changes also introduced new requirements during the initiative.
5. Risks and Responses
| Risk | Proposed response |
|---|---|
| Retiring an interface interrupts callers | Staged rollout, log comparison, and traffic monitoring |
| Module removal breaks an implicit dependency | Map full call chains and use shadow tests |
| Messaging change causes duplicate delivery | Add idempotency checks |
| Splitting jobs changes behavior | Unit tests and data replay |
| Cache change harms performance | Load tests and feature switches |
6. Lessons from the Process
Architecture governance should clarify boundaries rather than merely rearrange code. Excessive abstraction can make business behavior harder to understand. Monitoring should advance alongside functional changes. API consolidation needs replacement capabilities, not abrupt deletion. The value of a master-data platform lies in consistent execution and governance across its domain.
7. Questions the Plan Addressed
Why introduce DDD-style layers? Historical business rules were scattered through functional modules. Clearer boundaries and responsibilities would make change easier to reason about.
How could interfaces be consolidated without disrupting callers? Keep old contracts temporarily, route them to new capabilities, watch traffic and logs during staged rollout, and retire only after adoption.
What was the messaging change meant to achieve? One delivery boundary, less coupling, stronger idempotency, and a clearer observable flow.
What was the broader benefit? Reducing the system's cognitive complexity so that the platform could evolve more safely.