Capability 04
From an unclear problem to a plan you can build.
Discovery, problem definition, technical and data architecture, integration strategy and delivery planning — the work that decides whether the software that follows is worth building at all.
- Discovery
- Solution design
- Technical architecture
- Data architecture
- Build vs buy
- Delivery planning
Most failed software projects were decided before the first sprint.
The costly mistakes are architectural, and they are made early: the wrong system boundary, a data model that cannot represent the business, a build where a product would have done, a product where the process genuinely needed a build, or a plan that assumed an integration would be straightforward.
By the time those surface, they look like delivery problems — late releases, mounting change requests, a team that keeps rewriting the same component. They are not. They are the consequence of a decision nobody was asked to justify.
This is the capability that most clearly separates us from a development shop. We are comfortable being handed a business problem rather than a specification, and returning something you can act on: a defined problem, a shape for the solution, an honest build-versus-buy position, and a delivery plan with the risks named.
What you get
What an architecture engagement produces.
Deliverables are documents and decisions, not slideware. Every one of them should still be useful to whoever builds the system, including if that is not us.
Problem definition
A clear statement of what the business actually needs to change, separated from the solution someone has already assumed.
Requirements
What the system must do, what it must integrate with, what it must never do, and what would make it a success in operational terms.
Technical architecture
Components, system boundaries, interfaces, hosting and the technology choices — each with the reasoning recorded alongside it.
Data architecture
The core entities, the source of truth for each, how records relate, and how data moves and is kept consistent across systems.
Build vs buy
An honest assessment of whether a commercial product covers this, where it would not, and what the workaround would cost over time.
Delivery plan
Sequencing, dependencies, what can be proven early, the realistic shape of the effort, and where the genuine risks sit.
How we approach it
Understand, then decide, then commit.
Discover
Talk to the people doing the work and the people accountable for the outcome. Establish what really happens, not what the process document says.
Define
Write the problem down precisely enough that a solution can be judged against it — including what is out of scope.
Design
Set the system boundaries, the data model and the integration strategy, and choose technology to fit the requirement rather than the fashion.
Validate
Pressure-test the risky assumptions early — the integration nobody has tried, the volume nobody has measured — before they are baked in.
Plan
Sequence the delivery so the uncertain parts are proven first and something useful reaches production early.
When this is the right fit
When to start with architecture.
If more than one of these is true, this is usually where a conversation should start.
- You know the outcome you want but not what needs to be built to get it.
- Two credible internal views disagree on the approach and neither can settle it.
- You are about to commit real budget to a build and want it challenged first.
- A vendor has proposed a solution and you want an independent read on it.
- A previous attempt stalled and you need to know whether the design was the problem.
- The system will need to integrate with platforms nobody has integrated with before.
Related
Where this connects.
Custom Software Development
Where architecture usually leads — building the system that was designed, with the same people accountable.
Modernization & Rescue
When the question is what to do with software that already exists and no longer holds up.
Engineering & Delivery
How the plan becomes working software, and who stays answerable once it is live.
Have a problem that has not become a plan yet?
Describe the business situation rather than the technology. Turning that into a defined problem, an architecture and a delivery plan is exactly the work.