Solution
Enterprise systems that integrate, stay consistent and can be audited
We build the internal applications and workflow platforms an organisation runs on, connect them to the systems already in place and modernise legacy estates one bounded piece at a time.
The problem space
Enterprise software is defined less by its features than by its surroundings. A new application arrives into an estate that already contains an ERP, a CRM, an HR system, a data warehouse, several databases nobody fully understands and a set of spreadsheets doing the work those systems do not. Its value depends on how well it exchanges data with all of them and how clearly it establishes which system owns which fact.
The recurring problems are integration and consistency. An order exists in the CRM, the ERP and the warehouse system with three different statuses. A customer record has been edited in two places. A nightly batch job fails silently and the finance team finds out at month end. Adding one more application without addressing ownership and data flow makes this worse, however well the application itself is built.
Modernisation raises the stakes. Legacy systems often encode decades of business rules that exist nowhere else, and replacing them in one programme has a poor record across the industry. We favour incremental change: place a stable interface in front of the legacy system, move one capability at a time behind it, run old and new side by side until the results match, then retire the old path.
Why it is hard
Engineering challenges
Point-to-point integration sprawl
Each new system is wired directly to several others with bespoke scripts, file drops and database links. After a few years no one can say what will break when a field changes. The integrations become the most fragile and least documented part of the estate.
No single owner for shared data
When several systems can edit the same customer, product or price, they diverge. Reports disagree depending on their source, and staff spend time reconciling by hand. The underlying fault is the absence of a declared system of record for each entity.
Updates that span systems
A business operation such as approving a purchase order may need to write to the workflow system, the ERP and a notification service. There is no distributed transaction across them. If the second write fails after the first succeeds, the organisation is left with a state that no system considers valid.
Legacy systems that cannot be paused
The system being replaced is still running the business. It has undocumented behaviour, batch windows, and consumers that read its tables directly. A cutover that assumes a clean switch tends to discover these dependencies in production.
Authorisation that outgrows roles
Access rules start as a few roles and become a matrix of role, department, region, approval limit and delegation. Scattered across application code they are impossible to review. Auditors ask who could approve a transaction on a given date, and nobody can answer with confidence.
Audit trails added afterwards
A changed-by column and an updated-at timestamp do not show what the previous value was, who approved the change or which upstream event caused it. Reconstructing history from application logs is unreliable. Auditability has to be a property of the data model.
How we build it
Architecture
The application is built as a set of services or modules aligned to business domains, connected to the wider estate through an integration layer that isolates each external system behind a stable contract.
- 01
Domain services
Business capabilities such as procurement, approvals or case management are implemented as modules with clear boundaries and their own data. Whether these are deployed as one modular application or as separate services depends on team structure and scaling needs. The boundary matters more than the deployment unit, because it determines what can change independently.
- 02
Integration layer and anti-corruption adapters
Each external system is wrapped by an adapter that translates between its model and the application's own. ERP quirks, legacy field formats and vendor API changes are contained in that adapter. Synchronous calls go through an API gateway with timeouts and circuit breakers; data propagation uses events or change data capture, so a slow downstream system does not block users.
- 03
Workflow engine
Long-running processes with approvals, escalations and timers are modelled explicitly in a workflow engine instead of being spread across status columns and scheduled jobs. The engine persists the state of every instance, so a process survives restarts and its current step is always visible. Process definitions are versioned, and in-flight instances complete on the version they started with.
- 04
Consistency through outbox and sagas
A service writes its state change and the corresponding event in one local transaction using the transactional outbox pattern, and a relay publishes the event reliably. Multi-system operations are coordinated as sagas with defined compensating actions for each step. Consumers are idempotent, so redelivery is safe. Reconciliation jobs compare systems on a schedule and report any drift.
- 05
Identity and authorisation
Users authenticate through the corporate identity provider with single sign-on. Authorisation combines roles with attributes such as organisational unit and approval limit, and is evaluated in a central policy component whose rules are held as reviewable configuration. Segregation-of-duties constraints, for example that a requester cannot approve their own request, are enforced there.
- 06
Audit and history store
Every state change is recorded as an append-only entry with the actor, time, before and after values, and the correlation identifier of the request or event that caused it. The record is written in the same transaction as the change, so it cannot be skipped. This supports audit queries and makes it possible to reconstruct an entity as it stood on any date.
- 07
Strangler facade for modernisation
A routing layer sits in front of the legacy system and directs each function either to the old implementation or to its replacement. Capabilities are moved one at a time, with new and old run in parallel and their outputs compared before traffic is switched. The legacy system shrinks as functions are retired, and at each stage there is a working path to fall back to.
Clients
- Web app
- Mobile apps
- Partner integrations
API Gateway / BFF
- Routing
- Authentication
- Rate limiting
- Response shaping
Domain Services
Each service owns one bounded context
- Orders
- Payments
- Catalogue
- Accounts
- Notifications
Async Messaging
- Kafka topics
- Outbox publisher
- Event consumers
- Dead-letter queues
Data Stores
Database per service, no shared tables
- PostgreSQL per service
- Redis cache
- Search index
- Object storage
Platform
- Tracing and metrics
- Central logging
- CI/CD pipelines
- Service configuration
What an engagement delivers
- Domain model and system-of-record map for shared data
- Application services with documented APIs and event contracts
- Integration adapters for ERP, CRM and legacy systems
- Workflow definitions with approval, escalation and delegation rules
- Role and attribute-based access model with audit history
- Reconciliation jobs and drift reporting between systems
- Incremental migration plan with parallel-run and rollback steps
Before you start
Decisions to make early
- Configure a packaged product or build
- Use a packaged product where the process is standard and you are prepared to adopt its way of working: finance, payroll and core HR are common examples. Build where the process is a source of differentiation or where customising a package would mean fighting it at every upgrade. Heavy customisation of a packaged system often carries the cost of a custom build without the control.
- Synchronous APIs or events between systems
- Use a synchronous call when the caller needs an answer to proceed, such as a credit check during order entry. Use events when other systems only need to know that something happened. Events reduce coupling and absorb outages, at the price of eventual consistency that users and reports must be designed to tolerate.
- Replace the legacy system or wrap it
- Wrap it when the system is stable, its logic is sound and the main problem is access to its data and functions. Replace it incrementally when it blocks change, runs on unsupported technology or depends on skills that are leaving the organisation. A full rewrite in a single release is justified only when the system is small enough to verify exhaustively.
- How strict consistency needs to be
- Decide per operation. Financial postings and inventory decrements generally need to be correct at the moment they occur and belong in one transactional boundary. Search indexes, dashboards and notifications can lag by seconds. Naming these requirements explicitly avoids both over-engineering and silent inconsistency.
FAQ
Common questions
Can you integrate with our ERP or CRM?
Integration depends on what interfaces the system exposes: REST or SOAP APIs, message queues, file exchange or database-level change data capture. We assess those interfaces first and build an adapter around whichever is supported and stable. Vendor names are used descriptively; we do not claim any vendor partnership or certification.
How do you keep the business running during modernisation?
By moving one capability at a time behind a routing layer, running the new implementation alongside the old and comparing results before switching traffic. Each step has a defined rollback. The legacy system remains authoritative for anything not yet migrated.
Do you use low-code platforms?
Where they fit. Low-code tools are effective for simple forms and departmental workflows with modest integration needs. They become limiting when logic is complex, when volumes are high, or when changes need proper version control, testing and review. We recommend based on the process, not on a preference for either approach.
Who operates the system after it goes live?
That is agreed at the outset. The system is delivered with infrastructure as code, monitoring, runbooks and documentation so that your team can run it. Starone can also provide ongoing engineering and operational support under a separate arrangement.
Related
Reference architectures
Have a system that needs to work in production?
Tell us what you are building. An engineer will read it and reply within two working days.