Software Should Solve the Business, Not Just the Brief
A brief might say: “We need a CRM.”
But the real problem could be: sales enquiries are arriving from five places, nobody knows who owns them, follow-ups are inconsistent and management cannot see what is happening.
The brief
“We need a CRM.”
Asks for software.
The real problem
Enquiries are lost and invisible.
Asks for a solution.
Those are very different problems. That distinction shapes everything we do.
What Solution Architecture Covers
| We examine | What we are trying to understand |
|---|---|
| Business processes | How work actually happens today |
| Users and roles | Who does what, and where responsibility sits |
| Information | What data exists, where it lives and how it moves |
| Systems | What should connect, remain, change or disappear |
| Workflows | What should happen automatically and what still needs judgement |
| Exceptions | What happens when reality does not follow the happy path |
| Scale | What the solution needs to handle as the business grows |
| Constraints | Budget, infrastructure, connectivity, integrations and operational realities |
| Future change | What should be possible without rebuilding everything |
The result is not a diagram for its own sake. It is a clearer answer to: What should we build, why should we build it, and how should it work?
The Most Expensive Software Decision Can Happen Before Development Starts
It is easy to start building too early. A business sees a competitor's platform and wants something similar. A team starts designing screens. A developer starts setting up the database. Then six months later, everyone discovers that the original assumption was wrong.
The system technically works, but the business has to work around it.
Good architecture reduces that risk before it becomes expensive.
Have us pressure-test the idea before development begins.
Talk to us about your systemWe Do Not Assume Everything Needs Custom Software
Sometimes the right answer is a new application. Sometimes it is an integration. Sometimes it is automation. Sometimes an existing platform is sufficient. Sometimes the current system can be repaired. And sometimes the business has a process problem that software should not be used to hide.
The wrong starting question
“What technology should we use?”
The right starting question
“What needs to become better?”
Then technology follows the decision.
Architecture Is Where Business Rules Become Explicit
A system needs to know more than what happens when everything goes correctly. Consider a property enquiry: someone sees a listing, asks a question and an agent responds. But what happens if…
- The property has already been taken?
- The buyer changes their requirements?
- Several agents are involved?
- The enquiry comes through WhatsApp?
- The customer does not respond?
- The property information changes?
- The same person enquires about several properties?
These are not minor development details. They are part of the architecture. A system that only handles the happy path is not finished.
Propertyzone: Architecture Before Features
Propertyzone is a good example of why the distinction matters. The platform is not simply a collection of property listings. Behind each listing is a set of relationships between properties, locations, agencies, enquiries, users and the information required to help someone move from discovery toward an actual conversation.
The architecture had to account for both sides of the marketplace: what exists, and what someone is looking for. That shaped how the product handles structured property information, discovery, enquiries and the wider journey around a property.
What We Produce
Depending on the project, solution architecture can produce:
Process maps
System and integration architecture
Data models
User and permission models
Workflow definitions
Technical decisions
Product structure
Implementation priorities
MVP boundaries
Future-state architecture
The deliverable is not a document that gets filed away. It becomes the foundation for the engineering work that follows.
The Best Architecture Is Usually Less Complicated Than the First Idea
Complexity can make a proposal sound impressive. It does not necessarily make the system better. We look for opportunities to remove unnecessary steps, duplicated data, disconnected systems and features that do not meaningfully improve the outcome.
Simpler is not always better.
Unnecessary complexity is always expensive.
Bring us the messy process or the ambitious idea. We will help determine what actually needs to exist.
Talk to us about your systemBuilt for the Environment the Business Actually Operates In
Architecture has to survive contact with reality. That includes:
Existing software
Third-party systems
Unreliable or variable connectivity
Operational workarounds
Different user roles
Manual processes
Data quality
Growth
Maintenance
Real customer behaviour
We do not design a theoretical system and leave the implementation team to discover the difficult parts later. The difficult parts are exactly what architecture is supposed to expose.
How We Work
Understand
We map the business problem and how the work happens today.
Challenge
We test assumptions, identify gaps and question whether software is actually the right intervention.
Structure
We define workflows, information, systems, responsibilities and technical boundaries.
Design
We turn those decisions into a practical architecture that engineering can build.
Build with intent
Where Sparkline is responsible for implementation, the architecture becomes the foundation for the engineering work.
When You Should Involve Us
Solution architecture is particularly valuable when:
You are considering building a new business system
Your current systems no longer fit the way the business operates
Several platforms need to work together
You are replacing spreadsheets and manual processes
Different teams need one source of truth
An existing project keeps accumulating features without becoming clearer
You have a product idea but do not know what the first version should contain
You are about to spend significant money on software development
Sometimes a conversation now is cheaper than a rebuild later.
And When We Would Tell You Not to Build
We are comfortable saying no.
The objective is not to create more software. It is to create the right solution.
From Architecture to Engineering
Once the decisions are clear, the next question is execution. That is where Sparkline's systems engineering capability takes over. The architecture defines what needs to exist and how the pieces should work together. Engineering turns that into software that has to survive real users, real data and real exceptions.
Explore Systems EngineeringBuild Less Blindly.
Build what the business actually needs.
Tell us what is happening today, what is not working, and what you are considering building. We will start from there.