An architecture review
You give me the systems you run. I map how they actually fit together, tell you where the seams are, what has no future, and what I would do in your place, and in what order.
Architecture and audits
An architecture review of everything you already run
Once a company runs more than one application, the interesting questions stop being about any single one of them. What talks to what. Where the same customer exists three times and the three disagree. Which step of a process exists only because some system could not do it in 2016. How a change reaches production, and how it comes back. This is the part of the work where I have no reason to sell you a build.
The questionTypical answer
A current diagram of what runs whereRarely exists
The same record, in how many systemsThree, disagreeing
Connections held together by a personAt least one
Systems with no upgrade path leftUsually one
How long a release takesLonger than anyone says
Recognise this
You need this if
- Your business runs on more than one system, and nobody can draw how they fit together.
- The same customer, product or employee exists in three places, and the three do not agree.
- Somebody exports a file out of one system every week and types it into another.
- There is a system nobody wants to touch, and it is still holding something important.
- You are about to buy another application and cannot tell whether it replaces something or adds to it.
- Shipping a change takes days, and undoing one takes longer.
- You have a quote from a supplier and no independent way to judge the price, the scope or the approach.
- A project is running, capable people are busy, and nothing is arriving.
Four ways
What you can ask for
Three of these have a name. The fourth is the one most people actually arrive with.
Someone to run the delivery
You have a supplier or your own team, and the building is not the problem. I run the delivery: scope, order of work, dependencies, what is late and why, and what has to be decided this week.
A technical opinion, on call
You keep making decisions that are hard to undo, and nobody around you is technical enough to argue with. An arrangement where you can bring one, without opening a project each time.
Something not on this list
Most of what I am asked here does not have a name yet. Describe it and I will tell you whether it is something I can do well, or whether you need someone else.
Small, mid-size, or enterprise. The symptoms above do not change with headcount. Only the number of systems does, and a company with four applications has the same conversation as one with forty. I have spent years on both sides of that line, and at enterprise scale I join as a consultant alongside your own teams rather than in place of them.
The landscape
The map everybody assumes exists
Ask five people in a company to draw which systems talk to which, and you get five different drawings and none of them complete. Not because anyone was careless, but because every connection was added on a Tuesday to solve one problem, and nobody was ever asked to hold the whole picture. The first thing an architecture review produces is that picture, and it is usually the first time anyone has seen it.
- Every system that carries business data, including the ones bought without IT
- What flows between them, in which direction, and how often
- Where the same record lives in more than one place, and which copy wins
- Where a person is the integration, doing by hand what nothing connects
- Which systems have no upgrade path left, and what is trapped inside them
What a landscape usually looks like
Financesystem of record
CRMown customer list
Web shopown customer list
Weekly exporta person, by hand
HRown employee list
Internal toolone author, no docs
What the map shows firstFinding
Customer exists in three systemsThree truths
One connection is a personSingle point
One system nobody can changeNo path
A sketch of the shape, not of any real client. Yours is drawn from your systems.
The way the work runs
Half the process exists because the software could not do it
Processes are rarely designed. They accumulate. Somebody adds an approval because a system had no roles, a spreadsheet because a report did not exist, a second entry because two systems never agreed. Years later the constraint is gone and the step survives, and everybody assumes it is policy. Reading the process alongside the systems is the only way to tell which steps are your business and which are scar tissue.
- Which steps exist for a business reason, and which for a technical one that has since expired
- Where the same information is entered twice, and what it costs in hours and in errors
- Approvals that nobody reads, and decisions nobody owns
- Reports built by hand every month that a system could produce on its own
- What would actually change if a system were replaced, and what would not
Efficiency here is not a cost-cutting exercise. The point is not to remove people. It is that the hours spent keeping two systems in agreement are hours nobody chose to spend, and they are usually spent by the people you can least afford to have doing it.
The stepReal reason
Second approval before an order goes outBusiness
Data typed into a second systemNo integration
Monthly report assembled by handMissing report
Shared mailbox as a queueNo roles
Spreadsheet kept beside the systemExpired limit
Releases
How a change reaches production, and how it comes back
Everything above is about what you run. This is about how it changes. A company can have good systems and still be unable to move, because releasing anything means one person, one evening, and a shared hope that nothing breaks. The pipeline, CI/CD if that is the name you use for it, is not a developer concern: it decides how fast the business can respond to anything at all.
- How many environments exist, and whether anything is tested before it is live
- What runs automatically on every change, and what depends on somebody remembering
- How long a release takes, and how many people have to be awake for it
- Whether a bad release can be undone, and whether that has ever been rehearsed
- Who can deploy, and whether there is a record of what went out and when
The measure that matters is not how modern the tooling is. It is how long it takes to get one small, safe change in front of your users, and how confidently you could reverse it. A simple pipeline that answers both beats an elaborate one that answers neither.
The pipeline, read end to end
Changewritten
Checkedautomatically
Stagedsomewhere real
Liveand reversible
Environments before productionOften none
Automated checks on every changeRarely
Time to release something smallDays
Rollback ever rehearsedAlmost never
Record of what went live, and whenPartial
The deliverable
A map, and findings you can hand to somebody else
The point of a review is not to arrive at a proposal from me. It is to leave you knowing something you did not know, in a form you can act on without me. So you get the picture of your landscape and the findings in writing, they are yours, and they do not expire if you decide to work with another person entirely.
- A diagram of your landscape: what runs, what connects, and where the seams are
- Diagrams at the depth you ask for, from one picture of everything down to who does what inside a single process
- For each application: what data it holds, what it connects to, and what security sits on the APIs in between
- What I found, in writing, ordered by what it would cost you to ignore
- What I would do in your place, and in what order
- What is fine, said plainly, so you are not sold work you do not need
- Written for you to read, not for another developer to decode
No proposal is attached to it. An audit that arrives with a quote stapled to the back is a sales document. If it turns out I am the right person to fix what I found, we can talk about that separately, after you have read it.
ItemYours
The landscape diagramTo keep
Findings, ordered by cost of ignoringIn writing
What I would do, and in what orderIn writing
What is already fineSaid plainly
A version another supplier can act onIncluded
A quote for the workNot attached
When the building is not the problem
Somebody has to say what is late, and why
Plenty of projects have capable people on them and still arrive at nothing. Usually because nobody owns the order of work, the dependencies between the parts, or the decisions that everyone is politely waiting for someone else to make. That is a job, and it is a different job from writing the code.
- A scope with an order, so the parts that block others are done first
- One place where the state of the project is written down, and it is current
- Dependencies named, including the ones that are on your side
- Decisions surfaced while they still cost little
- Your suppliers and your own people dealt with directly, so you are not the messenger
I am not competing with your supplier. If you already have someone building, my job is to make their work land, not to replace it. If I think you have the wrong supplier, I will tell you that plainly rather than manage around it.
Who is waiting on whom
Scopeagreed, written
Orderblockers first
Decisionssurfaced early
Deliverystate, current
The parts your supplier cannot startYou
The parts nobody has decidedSurfaced
The parts that are simply lateNamed
How it runs
From a conversation to something you can act on
We talk
Free, and without obligation. You describe the situation. I tell you whether this is a free look or paid work, and whether I am the right person at all.
We agree the scope
Which systems I will read, which I will not, what you get at the end, and what it costs. In writing, before anything starts.
I read it
The systems, the connections, the process around them and the way changes reach production. With whatever access is needed, and nothing more.
You get the map and the findings
The picture of your landscape, what I found, and what I would do in what order. Then a conversation about it, if you want one.
Nothing is agreed until the scope and the price are in writing
What it costs
You find out which one you need before it starts, not after
A conversation, an opinion on a quote you have received, and a view of anything reachable from the outside are things one person can do in an afternoon, so they stay free. Reading source code, systems, pipelines and backups is real work, and pretending otherwise would either make it shallow or make me resent it. Which of the two your situation needs is something I will tell you in the first conversation.
Agreed before it startsA website has a shape you can price before you have seen it. This work does not: what I would be reading is different every time, so a number on this page would be a guess rather than a discount. We agree the scope and the price in writing, and only then does anything begin.
Free stays freeThe first conversation, an honest opinion, and a view of anything reachable from the outside cost nothing, whatever comes afterwards. That does not narrow as your company gets bigger.
- You are told which one applies to you before anything begins
- If the honest answer is that you need neither, you will hear that too
- The map and the findings are yours, whether or not you continue with me
- An honest view of what should not be done, which is usually the more valuable half
- A named person you deal with throughout, and it is me
Where the line falls
From outside, free
A conversation about the situation
An opinion on a quote
Whatever is publicly reachable
Which of the two you need
From inside, paid
The systems, and what connects them
The source code you own
The pipeline and the environments
The data, and who can read it
Questions
Frequently asked questions
What does the first conversation cost?
Nothing, and there is no obligation afterwards. Thirty to forty five minutes is usually enough for both of us to know whether it makes sense to continue.
How many systems is too few for this to be worth it?
Two is enough, if they are supposed to agree with each other and do not. The value is not in the number of systems but in the seams between them, and the second system is where seams start.
Where exactly does free stop?
At the point where I need access. A conversation, an opinion on a quote and anything publicly reachable stay free. Reading source code, systems, pipelines or backups is paid work, and you will be told that before it starts rather than invoiced for it afterwards.
Do you need access to our production systems?
Usually not. Most of a review is documentation, configuration, code and conversations with the people who use the systems. Where live access genuinely helps, it is read-only, agreed in the scope, and limited to what the question needs.
Will the review end with you offering to fix it?
No. The map and the findings arrive on their own. If it turns out I am the right person to do the work, that is a separate conversation you start, after you have read them.
What if you find nothing serious?
Then that is what the findings say, and it is worth knowing. A report that manufactures urgency to justify its own cost is not an audit.
Can you run a project you did not build?
Yes, that is the usual case here. The people building can be your team, your existing supplier, or both.
Do you sign a confidentiality agreement?
Yes, and it is signed before I am given any access, not after. If you do not have one, I can provide a simple one. The order matters: everything free happens from the outside, and the moment anything has to be looked at from the inside, that is in writing first.
Not sure whether you need a review or a build?
Describe the situation. You will be told which one it is, and what it would cost, before anything starts.