IFS-ERP CRIMS customization of IFS Cloud

Apply Federated Computational Governance: Balancing Autonomy and Compliance

Apply Federated Computational Governance. Balancing Autonomy and Compliance

Moving beyond the «Centralized Bottleneck»: How to embed compliance, security, and quality standards directly into your IFS Cloud architecture while empowering domain teams to move at the speed of business.

What Problem Does This Solve?

In traditional ERP implementations, organizations face a «Governance Paradox.»

On one hand, you need strict control over master data (Customers, Parts, Suppliers) to ensure financial reporting is accurate and regulations (GDPR, SOX) are met. On the other hand, business units need agility. If the Supply Chain team wants to onboard a new supplier to fix a shortage, they cannot wait 3 days for a Central Data Team to approve the record.

The symptoms of the old model:

  • Bottlenecks: The Central IT/​Data team becomes a queue where requests go to die.
  • Shadow IT: Frustrated business users start managing critical data in Excel to bypass the bureaucracy.
  • Erosion of Quality: When the «gate» is finally opened to speed things up, manual checks are skipped, and bad data enters the ERP.
The Cost of Inaction

Without Federated Computational Governance, your IFS Cloud upgrade becomes a «Lift and Shift» of legacy chaos, and your data remains a liability rather than an asset.

Risk: High

This article solves this by providing a blueprint for automating the rules (Computational) and distributing the responsibility (Federated), ensuring that «doing the right thing» is the easiest path for your users.

1. The Philosophy: Why «Federated» and Why «Computational»?

To understand how to implement this in IFS Cloud, we must first dismantle the terminology. This concept is a core pillar of Data Mesh, a paradigm shift introduced by Zhamak Dehghani, but its application in the monolithic world of ERP requires translation.

The Failure of Centralized Governance

Historically, governance was a «Control Tower.» A group of data stewards sat in a room, wrote 100-page policy documents, and manually approved changes. In the modern digital enterprise, data moves too fast for this. By the time the stewards approve a new product hierarchy, the market has shifted. Centralization scales linearly (you need more stewards for more data), but data grows exponentially.

Enter Federation

Federation borrows from political science. Think of the United States or the European Union. There is a «Federal» level that sets non-negotiable standards (Currency, Defense, Human Rights), and there are «State» levels that manage local nuances (Education, Zoning, Traffic Laws).

In IFS Cloud:

  • The Center (CoE): Defines global standards. «All entities must have a Global ID.» «All PII data must be masked in test environments.»
  • The Domain (e.g., Finance): Defines local utility. «A Customer must have a VAT code valid for the shipping country.» «Payment terms cannot exceed 60 days.»

This allows the Finance team to change their rules without asking IT, provided they don’t violate the global standards.

Enter Computational Governance

Computational means «Policy as Code.» If a rule is written in a PDF, it is a suggestion. If a rule is written in code, it is law. In IFS Cloud, we stop writing documents telling users not to leave fields blank. Instead, we implement a BPA Workflow that makes the «Save» button physically impossible to click until the data is valid. We embed the governance into the platform itself.

2. The Technical Toolset in IFS Cloud

How do we actually build this? IFS Cloud provides a rich ecosystem of low-code and no-code tools that serve as the engine for computational governance.

Business Process Automation (BPA)

The successor to Custom Events, BPA allows you to model workflows visually (BPMN). You can inject governance «decisions» into standard processes.

Example: When a user tries to change a Supplier’s bank account, BPA triggers a validation workflow that checks the IBAN format and requires a secondary approval (4‑eyes principle) before committing the transaction.

Custom Events & Actions

For hard «Guardrails,» PL/SQL events are unmatched. They sit at the database level, ensuring that no matter how the data enters (UI, API, Migration), the rule is enforced.

Example: A trigger that prevents the status of a Customer Order from moving to «Released» if the Customer’s credit limit is expired.

Data Migration Manager (DMM)

Often mistaken as a one-time tool, DMM is a governance powerhouse. Use its «Validation Rules» and «Legacy Data» containers to continuously audit production data.

Example: Run a nightly DMM job that scans the Part Master for incomplete descriptions or missing weights and flags them for the Engineering Domain.

IFS Lobbies & Analytics

Visibility is a form of soft governance. If users know their data errors are displayed on a public dashboard, they self-correct.

Example: A «Data Quality Health» Lobby for the Procurement Manager showing «Suppliers missing Email Addresses» in bright red.

3. Implementing the Federated Model

Building the structure is harder than building the code. You need to organize your teams around Domains. In IFS Cloud, a «Domain» usually maps to a functional module or a business process area.

Step 1: Define the Global Policies (The «Federal» Law)

The Center of Excellence (CoE) defines the non-negotiables. These are usually security, privacy, and interoperability standards.

  • Security: All users must have Role-Based Access Control (RBAC). No direct database access.
  • Privacy: Fields marked as PII (Personally Identifiable Information) must be audited.
  • Interoperability: All master data keys (Customer ID, Part No) must follow the corporate regex pattern (e.g., «C‑10001«).

Step 2: Empower the Domains (The «State» Law)

The Product Domain (Engineering) knows more about spare parts than the IT team ever will. Empower them to write their own rules.

Scenario: The Engineering Domain decides that no spare part can be «Active» unless it has a defined «Commodity Code» and «Weight.»

Action: Instead of asking IT to write a script, the Engineering Data Steward uses the IFS Business Modeler or configures a Custom Field with a mandatory setting. They own the quality of their data product.

Step 3: The «Sidecar» Concept in ERP

In microservices (Kubernetes), a «sidecar» is a process that runs alongside a service to handle logging and security. In IFS Cloud, we simulate this with Projection Configurations.

We wrap standard IFS Projections (APIs) with our governance logic. When a simplified UI (like a mobile scanning app for warehouse workers) calls the «ReceiveShopOrder« projection, our governance layer (BPA) intercepts the call, checks if the worker is certified to handle hazardous materials (if the part is hazardous), and only then allows the transaction to proceed. This is computational governance: the rule is checked at the moment of execution, every single time.

4. A Practical Implementation Roadmap

You cannot implement this overnight. It requires a phased approach.

Identify Domains: Map your IFS modules to business owners. Who owns «Inventory»? Is it Logistics or Finance? (Hint: It’s usually shared, which requires a «Data Contract»).
Classify Data: Tag fields. Which Custom Fields are critical? Which are nice-to-have?
Define Global Standards: Write the «Constitution» of your data.

Platform Setup: Configure IFS DMM for ongoing audits. Set up the BPA environment.
Pilot Domain: Pick one domain (e.g., Procurement). Implement 5 critical «Policy as Code» rules. (e.g., «No PO without a Contract Reference»).
Feedback Loop: Measure if these rules slow down the business or help it.

Enable Self-Service: Give Domain Stewards access to create their own Lobbies and basic Validation Rules.
Data Contracts: Formalize the handovers. If Manufacturing consumes data from Engineering, create a «Contract» that specifies the quality Manufacturing expects. Use Custom Events to alert when this contract is breached.

5. Challenges and Mitigations

The journey to Federated Computational Governance is fraught with cultural and technical traps.

The «Silo» Risk

Challenge: If you give Domains too much autonomy, they might create data definitions that don’t talk to each other (e.g., Finance uses «Client» and Sales uses «Customer»).

Mitigation: The CoE must enforce a «Polyglot» binding. Use the IFS Master Data Management (MDM) capabilities or a shared glossary to map these terms. The Global ID is the unifying thread.

Performance Overhead

Challenge: Too many synchronous checks (Events, Validations) can slow down the system. If saving a Customer Order triggers 50 complex SQL queries, the user experience suffers.

Mitigation: Use Asynchronous validation where possible. Let the user save the order, but put it in a «blocked» state. Let a background job validate it and release it. This keeps the UI snappy.

6. The Role of AI in Computational Governance

We cannot ignore the «AI» in «IFS Cloud». The future of governance is predictive.

Anomaly Detection: Instead of writing hard rules («Price cannot be > 1000»), use IFS AI capabilities to learn the patterns. If a user enters a price that is 3 standard deviations away from the historical average for that part category, the AI flags it. This is «Soft Computational Governance.» It doesn’t block, but it nudges.

Auto-Classification: When a new document is uploaded to Document Management, use AI to scan the text. If it contains credit card numbers, automatically tag it as «Confidential» and apply the relevant Access Control Policy.

Conclusion

Federated Computational Governance is not just a buzzword; it is the only way to scale data management in a complex ERP like IFS Cloud. By shifting from manual gatekeeping to automated guardrails, and by moving responsibility from a central bottleneck to the domain experts, you create an organization that is resilient, compliant, and agile.

Your data is no longer a static record in a database; it is a live product, constantly checked, polished, and served by the platform itself.

Frequently Asked Questions

Roles and Permissions (FNDUSER) control access (Can I see this screen? Can I edit this field?). Computational Governance controls logic and content (Can I save this specific value given the current context?). For example, a user might have permission to edit Supplier Payment Terms, but Governance rules might prevent them from setting terms to «Immediate» for a new supplier without VP approval.

Not necessarily. While external Governance tools are powerful, IFS Cloud has enough native capability (BPA, Custom Events, DMM, Lobbies) to handle 90% of governance needs for data residing within the ERP. External tools are best used when you need to govern data flowing between IFS Cloud, Salesforce, and a Data Lake.

The Domain Owner. In the old model, IT fixed data. In the Federated model, if the Sales data is bad, the Sales team fixes it. The platform (IT) provides the tools (Lobbies, error reports) to help them find and fix it efficiently, but the accountability sits with the business function.

Validation rules are a subset of it. Computational Governance is broader — it includes the automation of the lifecycle. It’s not just «Is this field valid?», but «Does this data trigger the correct downstream processes automatically?», «Is the PII masked automatically?», and «Is the audit log generated automatically?». It is holistic policy enforcement via code.

This is critical. Hard blocks can stop business. The best practice is to build «Override Workflows.» If a user hits a block (e.g., Credit Limit Exceeded), they should be able to click «Request Exception.» This triggers a BPA workflow to a manager. If approved, the system allows the transaction one time while logging the exception for audit. This keeps the business moving while maintaining governance.

Learn More About IFS Cloud BPA

Explore how Business Process Automation serves as the engine for your governance policies.

Watch Tutorial