Data is duplicated
The same counterparty, order, project or material is maintained in several systems with different statuses and update rules.
Application architecture can constrain business development when platforms have unclear roles, data sources are undefined and data exchange rules are inconsistent, as well as when systems are ageing.
Business logic has no defined home
It is not always clear where core process logic resides: ERP, an industry system, a spreadsheet, an integration or a manual procedure.
Changes break connections
Updating one system or interface causes errors in undocumented parts of the landscape.
New solutions create a separate layer
Digital products run in isolation and add new data, statuses, and integrations without a shared architectural role.
Why this happens
A counterparty’s details may be maintained in several systems. Orders may move between platforms through file transfers, while project status is recorded in a separate spreadsheet. Updating an accounting system can disrupt an integration that the project team has overlooked.
These symptoms arise when an application landscape lacks common rules. It is unclear where source data is created, who owns business logic, which functions are duplicated, which modifications a critical process depends on and who is responsible for interfaces between platforms.
Systems work, but their roles, data, and exchanges do not form a manageable architecture.
Each new change can reinforce the landscape – or create a new integration gap.
Application architecture defines the roles of systems and rules of exchange.
Platform roles
Where is the business logic placed?
We define which functions are supported by ERP, core accounting, industry systems, portals, analytics and specialist platforms.
System boundaries, function owners, duplication and the target allocation of roles.
Owners of data and interfaces
Who is responsible for the source and the exchange?
For key data and integrations, owners, consumers, rules of change and responsibility for the quality of the exchange are fixed.
Data sources, owners, consumers, exchange contracts and versioning rules.
Landscape life cycle
How can changes avoid creating new gaps?
New systems, modifications, integrations and retirement of functionality follow a shared architecture governance process.
Change rules, exception criteria, dependencies, monitoring and system retirement procedures.
More about the model
A managed architecture defines the source of data for customers, contracts, materials and projects; boundaries between enterprise and specialised platforms; shared group services; system retirement procedures; and how interface changes are agreed with consuming systems.
Integrations are managed in their own right. Each interface has an owner, data contract, version, monitoring and error-handling procedures. Without these, an integration bus adds a technology layer but leaves inconsistent connections unresolved.
How we build target application architecture
We first record the actual roles of systems, their data and dependencies, then define the target model for platforms, integrations and the application landscape lifecycle.
Document actual system roles and dependencies
We look not only at the list of systems, but at what processes, data, modifications, exchanges and manual bypasses really support the business.
More about our work
Starting point
One end-to-end process runs through multiple systems, tables, mail, and manual data transfers.
What we do
We record system roles, duplicated functions, data transfers outside established integrations, critical modifications, and data owners and consumers.
How to check the results
The systems supporting each process are clear, along with duplicated functions, manual transfers and the interfaces on which results depend.
Distinguish the roles of corporate and specialised platforms
Determine which platform is responsible for what and where the business logic should be located.
More about our work
Starting point
ERP, accounting core, industry systems, portals and analytics developed locally, and their roles were determined by individual projects.
What we do
We define the roles of enterprise and local systems, master data sources and shared services, identifying which functions to retain and which to move out of the core.
How to check the results
For each critical function, the target system, business logic owner and modifications to retain or retire are clear.
Set the rules for data, events and exchange
Integrations become a manageable entity: with the owner, data contract, version, monitoring, and error handling.
More about our work
Starting point
Point-to-point exchanges, file transfers, and unaccounted-for interfaces create dependency on individual employees and contractors.
What we do
Set exchange contracts, events, queues, version rules, monitoring, error handling and the procedure for agreeing changes to interfaces.
How to check the results
For each critical interface, the owner, users, data format, version, monitoring, and error response order are defined.
Planning a transition without losing control
Landscape changes are made by business stages, not just by the technical calendar.
More about our work
Starting point
Migrations, system replacements, and new digital products are launched without a common dependency map and lifecycle rules.
What we do
We plan data migration, parallel operation, reconciliation, training, retirement of previous functionality and governance of new initiatives.
How to check the results
Dependencies are identified before work begins, switching risks are known, and new systems are tested for compatibility with the target architecture.
Services within this practice
Engagements and deliverables range from IT landscape assessments to platform architecture, integrations, master data, implementation and support for business systems.
IT landscape assessment
A map of current systems, functions, integrations, data, manual workarounds and duplication, showing where the IT landscape constrains processes, reporting, platform development and control over change.
Platform architecture design
A target allocation of roles across ERP, accounting, industry-specific, enterprise and specialised platforms: what each system is responsible for and where its functional boundaries lie.
Implementing and developing ERP, accounting and industry-specific systems
Working enterprise systems with configured processes, roles, reference data, reports, integrations, user workflows and support rules.
Building integrations and a master data model
A managed framework for data exchange and reference data: sources, consumers, APIs, events, routes, reference lists, data owners, error handling and integration monitoring.
Developing and implementing business applications
Application services, portals, platform extensions and enterprise system enhancements that close gaps between processes, data and the current IT landscape.
Supporting and developing enterprise systems
A post-launch support framework: evolving requirements, enhancements, releases, integration monitoring, user support, documentation and architecture governance for changes.
What the management team receives
Application landscape map
System roles, dependencies, function duplication, critical modifications, data owners and consumers.
Target application architecture
Boundaries of corporate and local systems, master data sources, common services and transition stages.
Model of platform roles
Which system supports each key capability, where the business logic resides, and where the gap remains.
Integration architecture
Exchange contracts, events, queues, versions, monitoring, error handling and interface owners.
Migration and cutover plan
Data migration, parallel operation, reconciliation, training and retirement of previous functionality.
Architecture governance rules
Procedures for introducing new systems, handling exceptions, maintaining documentation, assigning ownership and decommissioning.
What changes in IT landscape management
The result is that every critical function, system, integration, and data has a role, owner, and rule of change.
Roles of systemsEach critical function has a platform, a data source, and a business logic owner.
Starting point
The same functions are implemented in several systems, and the place of the basic business logic is not always obvious.
What's changing
For each critical function, a target platform, data source, and owner are defined.
How to check the results
The role of the platform, the source of the data and the owner of the business logic are recorded in the architectural documentation and allocation of responsibility.
Dependencies before changeThe affected systems, interfaces and data consumers are identified before work begins.
Starting point
Changing one system reveals dependencies after a project or update is launched.
What's changing
Before starting work, the affected systems, interfaces, data consumers and switching risks are known.
How to check the results
For each change, there is a dependency map, interface owners, and a list of data consumers.
Reliable exchangeProcesses rely on managed exchange without manually copying data between platforms.
Starting point
Data is transferred through files, spreadsheets, email or manual exports.
What's changing
Critical exchanges are described through rules, contracts, versions, monitoring, and error handling.
How to check the results
Re-entering and file transfers are reduced, and exchange errors are detected and processed according to the established order.
Control of modificationsCritical logic and dependence on modifications become visible.
Starting point
Significant system modifications support key processes, but their logic and risks are not documented.
What's changing
Critical logic is described, the owner, risks and a plan for further development are defined for it.
How to check the results
Decisions to retain, retire or replace a modification consider its business rationale and architectural implications.
IT costs with a business roleLarge IT initiatives are associated with supported capabilities, processes, and risks.
Starting point
IT costs are discussed across projects and systems, but are not always related to a role for the business.
What's changing
For each major initiative, a supported capability, process, risk, and place in the target architecture are defined.
How to check the results
A portfolio of digital projects can be matched with business capabilities, processes, and architectural gaps.
When this practice is especially useful
Practice is needed when the landscape evolves faster than the company can cement the roles of systems, data, and rules of exchange.
The end-to-end process goes through gaps
One process goes through multiple systems, tables, mail, and manual transmissions.
More details
- the same data is entered several times
- Process status must be collected from different sources
- Employees use tables as an intermediate system
- Errors occur at the joints of platforms
- Ownership of the interface between systems is not defined
Critical logic is hidden in modifications
ERP, accounting core or industry system contain critical logic that is difficult to change.
More details
- Much of the process depends on individual modifications.
- The logic of change is not documented
- The development of the system requires the participation of a narrow group of specialists or contractor
- Updates pose a risk of disruption to the process
- There are no business criteria for retaining or retiring a modification
The group operates on different platforms.
Several companies or sites have the same functions under different rules.
More details
- The same processes are implemented in incompatible systems
- Reference data and statuses differ between sites
- Consolidation requires manual adjustments
- Group service does not have a single owner.
- Transition to a single model is impossible without a dependency map
New digital products are launched in isolation
New solutions create an additional layer of data, statuses, and integrations
More details
- Functional units launch products without architectural verification
- New services duplicate data from existing platforms
- integration is created point by point for a separate project
- Data consumers not accounted for prior to launch
- Maintenance costs are growing faster than landscape controllability
This practice in projects
