A systems architect makes the software you already pay for work as one system. That means designing the integration architecture, agreeing a single data model, defining secure API and access boundaries, and planning the migration, so a stack of disconnected tools shares one version of the truth instead of a person copying rows between them.
The symptom is always the same: two departments quote different revenue figures from two systems, and both are technically correct. So a ninth tool gets bought to reconcile them, and eighteen months later there are three versions of the truth instead of two.
Almost no company at this stage has a software problem. They have an agreement problem: nobody has ever decided which system owns which fact.
The first deliverable is the least technical and the most valuable: a written map of every entity the business cares about (customer, order, invoice, policy, lead, property) with exactly one system named as the owner of each.
Everything downstream follows from that. Which system writes and which reads. What happens when two disagree. Which identifier travels between them. It sounds bureaucratic until you have watched a finance team reconcile by hand every month because this conversation never happened.
Point-to-point integrations are quick to build and brutal to own: eight systems wired directly to each other is twenty-eight connections, and replacing any one vendor means rewriting seven.
The architecture is designed so a system can be swapped without touching the others: explicit boundaries, versioned contracts, and a defined failure behaviour for every integration. You will change CRM eventually. The design assumes it.
Role-based access defined against real job functions rather than "admin and everyone else". Credentials that are rotatable. Encrypted exchange with external partners. An audit trail that records who changed what, before an incident makes you wish you had one.
Shared logins are the single most common finding, and the easiest thing to fix while the architecture is being redrawn rather than after.
The design is only half the work. The other half is moving live data without losing history or stopping the business: a sequenced cutover, a reconciliation step that proves nothing was dropped, and a documented rollback.
Nobody migrates a pipeline mid-quarter and enjoys it. Planning for it is what makes it survivable.
Written down and handed over. If you replace me tomorrow, the next person picks it up without an archaeology project.
Two engagements where exactly this was the problem, and what came out of them.
The platform had been half-built on an ageing CodeIgniter 3 codebase with an unoptimised schema, no documentation and pending integrations with external verification partners. We redesigned the data model, rebuilt the application on CodeIgniter 4, and reworked every investor flow behind encrypted APIs.
Invoicing and bookkeeping were manual, error-prone and spread across multiple government portals, with no access control over who could change what. We built an accounting platform with role-based permissions, structured ledgers and GST e-invoice and e-way bill APIs wired in directly.
Written up properly, so you can pressure-test the idea without booking anything.
Anything not answered here, ask me directly on the call.
By mapping which system owns which fact, not by choosing what to remove. Most consolidation decisions become obvious once ownership is written down, and several tools people assumed were redundant turn out to be load-bearing.
Usually not. Most engagements end with the same tools connected properly and one or two removed. Replacing a system is expensive, disruptive and rarely addresses the cause, which is that nothing ever agreed which system was authoritative.
One named system that owns each piece of business data, with every other system reading it rather than keeping its own copy. Without it, two departments can pull two different numbers and both be right, which is where the reconciliation work and the arguments come from.
Four to twelve weeks, depending on how many systems are involved and how much of the data needs migrating. The architecture and data model usually land in the first two to three weeks, and are useful on their own even if implementation is scheduled later.
Either your team, with documentation, monitoring and a named owner, or me under a retained arrangement. What does not happen is an undocumented integration running unowned until it fails silently and somebody notices a month of missing records.
Yes, and that is the common case. I produce the architecture and hold delivery to it, whether the people building are in-house, an agency you already retain, or a mix. One accountable technical owner, however many contracts sit underneath.
We work out which on the first call, including whether you need me at all yet.
Senior technical ownership without a senior technical salary.
Ongoing · 2 to 6 days a monthDecide which AI is worth adopting, and which is only a demo.
Fixed scope · 3 to 6 weeksFind the hours your team is losing, then take them back.
Fixed scope, then retainedThirty minutes, no pitch. Describe what is not working and I will tell you straight whether this is the right shape for you, a different one, or nothing yet.
