The Architect’s Dilemma: Balancing Innovation and Governance in IFS Cloud

Introduction

In the fast-paced world of enterprise resource planning, IFS Cloud stands out for its agility and continuous innovation. However, architects tasked with implementing and maintaining the system face a significant challenge: balancing the need for customization with the imperative of governance. The Evergreen model of IFS Cloud, with its bi-annual updates, forces architects to confront this dilemma head-on. Customizations that once remained untouched for years now face scrutiny every six months, turning technical debt from a theoretical concern into an immediate risk.

The Evergreen Reality: A Double-Edged Sword

IFS Cloud’s Evergreen model is designed to keep organizations at the cutting edge, delivering new features and improvements twice a year. While this ensures businesses can leverage the latest advancements, it also means that every customization — no matter how small — must be re-evaluated with each update. What was once a «set and forget» modification in older versions like IFS Applications 9 or 10 now requires ongoing attention. The consequence of weak governance isn’t just inefficiency; it’s the potential for complete paralysis during upgrades.

The Tiered Governance Model: A Structured Approach

To navigate this challenge, architects must move beyond the traditional «Standard vs. Custom» binary. The Tiered Governance Model provides a framework for managing customizations based on their risk and impact. This model categorizes modifications into three tiers, each with its own governance rules and scrutiny levels:

  • Tier 1: Low-Code/No-Code Configurations – Changes made through Page Designer, Custom Fields, Events, Lobbies, and Automation Workflows. While these modifications are generally «upgrade-safe,» they introduce significant data risks if left unchecked. Every custom attribute must undergo a Data Impact Assessment to determine ownership, regulatory requirements, and inclusion in the Data Warehouse.
  • Tier 2: Extend on the Outside – Extensions built using REST APIs in platforms like Boomi, Azure, or Mendix. These integrations offer high flexibility with low core risk but require governance to ensure API Contract Stability. Only public and supported APIs should be used to avoid disruptions.
  • Tier 3: Extend on the Inside – Modifications to Projections, Logical Units (LUs), or underlying business logic. These high-risk changes should be a last resort and must be developed within the IFS Lifecycle Experience (LE) with mandatory automated test scripts.

Operationalizing Governance: From Theory to Practice

Governance isn’t effective if it’s not enforced. To operationalize the Tiered Governance Model, architects must embed governance into every stage of the development lifecycle:

  • Configuration Change Control Board (CCB) – Evaluates the method of implementation for customizations, ensuring every change aligns with architectural best practices.
  • Lifecycle as the Enforcer – IFS Build Place pipelines should act as the «governance sheriff,» blocking merges that lack associated documentation or fail static code analysis. If governance artifacts are missing, the build fails — no exceptions.
  • Expiration Date Strategy – Every customization should have a review date. Aggressive pruning of outdated customizations is essential to prevent technical debt from accumulating.

The Architect’s Bottom Line: Stewardship Over Speed

The role of an architect in IFS Cloud is not just to enable innovation but to ensure that innovation is sustainable. This requires a shift in mindset: from seeing governance as a barrier to recognizing it as the foundation of a resilient system. By defining ownership, lifecycle, and validation rules before a single line of code is written, architects can transform IFS Cloud from a fragile house of cards into a robust, evolving platform.

Action Plan: What You Can Do Today

  • Audit your customizations and document ownership, purpose, and review dates for each.
  • Enforce Data Impact Assessments for all custom attributes.
  • Lock down APIs to public, supported interfaces only.
  • Automate governance by configuring pipelines to block non-compliant merges.
  • Schedule regular reviews and retire obsolete customizations.
  • Train your team on governance responsibilities to ensure everyone understands the rules.

Conclusion

The next IFS Cloud update is always around the corner. By implementing a Tiered Governance Model and embedding governance into the development lifecycle, architects can ensure their customizations are ready for the future. Governance is not about saying «no» but about saying «do it right.»

Frequently Asked Questions

What is the Evergreen model in IFS Cloud?

The Evergreen model in IFS Cloud refers to the bi-annual updates that deliver new features and improvements. This model ensures organizations stay current with the latest advancements but requires ongoing evaluation of customizations to avoid technical debt and upgrade issues.

What is the Tiered Governance Model?

The Tiered Governance Model is a structured approach to managing customizations in IFS Cloud. It categorizes modifications into three tiers based on risk and impact: Tier 1 (Low-Code/No-Code Configurations), Tier 2 (Extend on the Outside), and Tier 3 (Extend on the Inside). Each tier has specific governance rules to ensure sustainability and compliance.

Why is governance important in IFS Cloud customizations?

Governance is crucial in IFS Cloud customizations to prevent technical debt, ensure compliance, and maintain system integrity. Without proper governance, customizations can become liabilities, hindering upgrades and increasing risks.

What is a Data Impact Assessment?

A Data Impact Assessment is a mandatory evaluation for all custom attributes in IFS Cloud. It determines data ownership, regulatory requirements, and whether the data should be included in the Data Warehouse. This assessment ensures that customizations are documented and compliant.

How can architects enforce governance in IFS Cloud?

Architects can enforce governance by embedding it into the development lifecycle. This includes using a Configuration Change Control Board (CCB) to evaluate implementation methods, automating governance through pipelines, and scheduling regular reviews to retire obsolete customizations.

What is the role of the Configuration Change Control Board (CCB)?

The CCB evaluates the method of implementation for customizations, ensuring they align with architectural best practices. It approves or rejects changes based on their potential risks and compliance with governance rules.

What is the Expiration Date Strategy?

The Expiration Date Strategy involves assigning review dates to all customizations. This ensures that workarounds or temporary solutions are retired when they become obsolete, preventing the accumulation of technical debt.

How can organizations prepare for IFS Cloud updates?

Organizations can prepare for IFS Cloud updates by auditing customizations, enforcing Data Impact Assessments, locking down APIs to public and supported interfaces, automating governance through pipelines, and training teams on governance responsibilities.