Everyone who works with systems integration in 2024 has seen some variant of this reference architecture image.
The reference architecture represents a vision of a platform where all of our digital assets are readily available to build more specialized solutions on top quickly and predictably. The platform should also not bind a lot of human and financial capital to allow us to target our investments to provide more value to the business and not just keep the lights on.
Even though the reference architecture diagram is common, cases where these effects have been achieved are not.
From the reference architecture blueprint, it is easy to draw the wrong conclusions, which leads to the belief that choosing the correct technical components is the only challenge. That just by putting Logic Apps and Service Bus there will make it agile and cheap.
The Tools Are Right, but the Results Aren’t: What’s Missing?
We often treat our systems integrations as expanding foam, something shapeless that we can fill any crack left between systems to be integrated.
Why Integrity Is the Key to Agility and Low Costs
A reference architecture is not just a bunch of cloud components organized neatly in a diagram. It is a system with a goal and a set of principles and values.
The system also needs integrity, which refers to its internal consistency, coherence, and alignment with these values and goals. Without integrity, other, more short-term goals will take precedence, like quickly making a temporary solution to solve an immediate demand. Over time, these ad hoc decisions erode the platform’s overarching purpose.
Suppose stakeholders want to register customers directly in the ERP system, but it lacks APIs or event-driven capabilities. Instead of addressing this with proper ERP development, they propose using its built-in database export functionality. The integration must then pull changes from this export. Over time, this creates a fragile system: delays in updates cause confusion, database changes can break the integration, and failures in the export process may appear as integration issues. This short-term workaround undermines the platform’s integrity and increases complexity and maintenance costs.
Implementing the integration under these conditions is an example of low integrity. When multiple “easy” solutions accumulate over time, the cost of ownership will rise considerably, and our agility will decrease.
This scenario reflects a lack of enabling constraints. Without clear rules and principles guiding how systems should interact, ad hoc solutions undermine the integrity of the platform.
We must understand the role of constraints in shaping our systems to avoid the trap of low integrity.
Constraints are rules, conditions, or structures intentionally or unintentionally applied to the system.
Constraints come in three forms:
No constraints: The Cost of Operating Without Constraints
No constraints refer to the absence of rules, conditions, or structures governing a system, process, or team. This is similar to shapeless expanding foam. While no constraints might foster creativity and exploration when we experiment, we will eventually see high maintenance costs and reduced agility.
Restrictive constraints: When Rules Stifle Progress
Restrictive constraints refer to the rules, conditions, or structures that limit a system, process, or team’s freedom to act or adapt. Consultancy firms often implement restrictive constraints, which prioritize adherence to their process or “model” over the system’s goals and values. However, the customer can also impose restrictive constraints, such as extensive Jira tracking, to create a sense of control.
Restrictive constraints can stifle innovation and adaptability, forcing teams to prioritize compliance over meaningful progress.
Enabling constraints: The Key to Agility and Efficiency
Enabling constraints refer to the rules, conditions, or structures intentionally put in place to allow a system, process, or team to perform effectively and achieve its desired outcomes.
Enabling constraints might include rules like mandating API-driven integrations or requiring event-driven notifications for data changes. These constraints guide teams to build solutions that align with the platform’s goals, fostering agility and minimizing long-term costs.
Ownership
Maintaining the integrity of the integration platform requires clear ownership. That might sound easier than it is. In a classical integration delivery model, where an organization hires a consultancy company to build and maintain its integrations, it might seem obvious that the consultancy company should be responsible. After all, they’re building the integrations.
The problem is that the consultancy company doesn’t own the integration platform. Ownership usually rests with the customer, who controls the cloud (or on-prem) environment, owns the backlog, and has the final say on how things are done.
However, many organizations lack the internal expertise to maintain an integration platform effectively—that’s why they rely on consultants in the first place.
This disconnect often results in a misaligned approach: consultants focus on delivering specific integrations as quickly as possible, while the customer’s lack of platform expertise leads to ad hoc decisions that compromise integrity. Over time, this undermines the platform’s ability to scale and adapt to future needs.
Final thoughts
To build a platform that gives us high agility and low maintenance cost, we must first find our Enabling constraints, which allow us to maintain the integrity of our integration platform.