Connect existing tools or build a central core?
Connected tools are fast, while a central core ensures consistent data and rules. Process criticism, change rates, and duplicate data maintenance are the deciding factors.
For management and product owners, "Connecting Tools or Building a Core System" highlights the difference between "Clear System Leadership" and "Stable Handover." A "Synchronization Loop" is the typical warning sign.
Published: 3 min read · Author: Sebastian Geier
When are connected tools sufficient, and when does the organization need a central core system?
Existing tools can remain connected if their responsibilities are separate and handovers are based on stable, rarely modified contracts. A central core becomes advisable when multiple tools maintain the same identities, states, or rules inconsistently. It then assumes this shared system leadership, while specialized functions can remain outside.
Synchronization Circle
Synchronization Circle – Multiple systems are allowed to modify the same field and overwrite each other in an unpredictable sequence.
Core as a New Monopoly – Increasingly, business logic is migrating to a central location, until every local change depends on the core team.
Integration as Remote Control – A tool is technically separate but cannot complete a process without synchronous detailed calls from other systems.
Demarcation Case: “Synchronization Circle”
Marketing, support, and billing use their own systems but require the same customer ID. Instead of migrating all functions to a suite, a small core manages identity and mapping. The tools retain their core functions and only synchronize events whose ownership is clearly defined.
Unambiguous system leadership
Test criterion
Unambiguous system leadership
For each shared data object and rule, exactly one responsible origin is identified.
Test criterion
Stable transfer
Tools exchange clearly defined events or data without remotely controlling each other's internal processes.
Limited core scope The central core contains only capabilities that multiple systems genuinely require consistently.
Limited core scope
Number of conflicting values for shared data objects across the connected tools.
Proportion of business changes that can be delivered without coordinated adjustments to the central core.
Stable transfer
Map shared data objects, rules, and current modification rights across all participating tools.
Assign conflicts to a leading source and design a minimal core or stable handover agreement.
Restructure a critical data flow and verify consistency and local modifiability before further centralization.
Which perspectives complement "Connecting Tools or Building a Core System"?
Monolithic or modular architecture for growing web systems Expands on the checkpoint "Clear System Leadership." The guiding question is: When should a growing web system remain monolithic and when should it become modular?
A complementary perspective is offered Define content governance for decentralized country teams.Answers the question: "What governance keeps both central brand and local content responsibility operational?"
If you want to put "Connecting Tools or Building a Core System" into practice, you can refer to Robust Website Systems This section focuses on "Architectural Boundaries and Scaling" and "Clear System Leadership."
Conclusion: Connecting Tools or Building a Core System
The right core centralizes truth, not necessarily functions. Good system boundaries allow specialized tools to remain independent while still ensuring clear common rules.
Sources and Further Information
The classification of "connecting tools or building a core system" is based on the following official documentation and standards.
Choosing Technology: An Introduction – GOV.UK Service ManualOfficial guidance on prototyping integrations, carefully cutting components, and evolving via open standards.
14. Operate a reliable service – GOV.UK Service ManualOfficial standard for the operation, availability, recovery, and continuous improvement of reliable services.
OpenAPI SpecificationPrimary specification for machine-readable HTTP API contracts, including operations, data models, and error responses.
Key Thesis
Integrations are sufficient for clearly separated tasks and stable handovers. A core system becomes necessary when shared data, rules, and processes would otherwise be maintained multiple times.
What This Is Not About
This question is not a blanket argument for a suite or against specialized tools. A central dashboard alone does not create a common core, nor does a large number of interfaces.
What it's about
The crucial factor is where data and rules must be maintained in a binding manner and where separate tools can perform their tasks autonomously. The core should define the boundaries of shared truth, not take over every function.
Platform strategy & build vs. buy
When does integration become more expensive than developing from scratch?
A separate evaluation step for "connecting tools or building a core system" is: At what point does integration become less economically viable than developing a new system?
Platform strategy & build vs. buy
Plan platform roadmaps based on dependencies instead of wish lists
Adds a separate decision to the "Connect tools or build a core system" dilemma: How do we transform a wish list into a robust platform roadmap with dependencies?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Limited core scope: next implementation stage
Before a suite migration or a new integration round, the current system leadership should be identified. A data and capability mapping can determine the smallest viable core.