Nobody can draw the current state.
Most organisations cannot produce an accurate diagram of their own application landscape. Systems were added by department, integrations were built point to point by whoever was available, and the person who understood the whole picture has changed roles.
The cost surfaces at every upgrade and every new system: integrations break, master data conflicts, and no one can say which record is authoritative. Architecture is the work of deciding that deliberately and writing it down.
Where architecture debt shows up.
No authoritative master record
Four systems hold the same customer or item. None is the source of truth, so every report needs a reconciliation.
Integrations break on upgrade
Nobody owns the contract between two systems, so a version change silently breaks a nightly job.
Point-to-point sprawl
Twenty bespoke interfaces where a governed integration layer would have needed five.
Overlapping applications
Three systems do the same job for different departments, each with a licence, an owner and a defender.
Undocumented decisions
A structural choice was made for a reason that is now forgotten, so it cannot be changed without risk.
Architecture written for a vendor
The target state was designed around what the advisor resells rather than what the operation needs.
What the engagement actually includes.
Current-state landscape
A verified diagram of every application, interface and data flow — including the systems nobody mentions in the first workshop.
Target architecture
Where each capability should live, which systems consolidate, what is retired and what stays. Platform-pragmatic: we do not architect around what we resell.
Integration architecture
Interfaces designed as versioned, documented contracts between systems, with an owner and a failure behaviour, rather than scripts.
Data governance
One authoritative record per master data domain, with a named owner, quality rules and a defined path for creating and changing records.
Architecture decision records
Every structural decision written down with the options considered, the reason for the choice and the debt accepted — so it can be revisited in three years.
Transition plan
The sequence from current to target: what moves first, what depends on what, and the point at which each legacy system can actually be switched off.
Document, decide, sequence.
We document what exists before recommending what should. These are the layers the target architecture is expressed across.
Ranges observed on Al Jawad engagements. Your targets are agreed in assessment, before the work starts.
Are you vendor-neutral?
We are an Odoo partner and we say so. We are also platform-pragmatic: where the right answer for a capability is not Odoo, the architecture says that, in writing.
Do we need this before an ERP project?
If the landscape has more than a handful of systems and any of them will remain, yes. Integration and master data decisions taken during implementation under time pressure are the ones most often regretted.
What is an architecture decision record?
A short document per structural decision: the options, the choice, the reason and the technical debt knowingly accepted. It is the single most useful artefact we hand over.
Will you architect lock-in?
No. We build for handover and we are explicit about which technical debt we took on intentionally and which is incidental.
Start a conversation.
Choose the one that fits where you are. None of them is a sales call. Each is an advisory conversation calibrated to a specific question.