You need to align technical priorities, development capacity and vendors across teams or products.
Fractional CTO →OXIAE / TECHNICAL CONSULTING
Software architecture for your application.
Software architecture that fits your product, team and expected usage.
Discuss your projectTechnical leadership, architecture design or assessment?
You need reasoned decisions about an application’s components, data and interfaces.
Software architecture (this service)You first need evidence of the existing system’s risks and limitations.
Software audit →UNDERSTAND THE SERVICE
Which architecture fits your product and your team?
A software architect defines component responsibilities, where data is owned and how components interact and are released. A modular application can be a suitable starting point: clear boundaries within one application without operating every component separately. An independent service needs a concrete reason and an owner. The design supports decisions before and during custom software development; implementation and operation are agreed separately.
When it is a good fit
This fits a new application or a demonstrated constraint in the current design. When modernising legacy software, architecture also needs to cover the transition and temporarily retained components. Start with an important user action and its actual requirements.
When to take a different approach
A new diagram does not repair unknown business rules or poor source data. If current code behaviour is unclear, a codebase audit may be needed first. The number of services is not a quality objective in itself.
PRACTICAL DECISION GUIDE
A software architect makes quality requirements testable
Architecture starts with requirements beyond features: capacity, recoverability, access and ability to change. I turn these into scenarios. What happens when a connected service fails, a customer supplies ten times more data or another developer needs to change a module? [1]
We compare the simplest suitable options and record tradeoffs. Component boundaries follow data ownership, failure behavior and operations. Temporary failures need different handling from invalid input. The architecture therefore includes operating agreements and a way to test important assumptions through a focused trial. [2]
Questions to settle first
- Which failure, growth or change scenario drives the architecture?
- Which complexity can the team responsibly operate?
Make acceptance measurable
- Decision records containing options, tradeoffs and operational consequences.
- A focused trial of the least certain quality or capacity assumptions.
Illustrative architecture decision — not a client case study
Store the enquiry and send its confirmation later
An enquiry needs to remain stored when email is temporarily unavailable. This design example assigns data ownership to an enquiry module and confirmation delivery to a background worker. The worker can remain in the same codebase; asynchronous processing does not by itself require an independent service.
Commit the enquiry and delivery intent together
The enquiry module stores the enquiry and its confirmation-delivery intent in one consistent operation. Only after successful storage does the user see ‘enquiry received’. This is not substantive approval and does not yet mean an email was sent.
Make the background task traceable
The confirmation has a stable task ID linked to the enquiry, with uniqueness enforced in storage. The worker retrieves only the required information. Repeated or concurrent dispatch does not create another confirmation task. A missed dispatch can be recovered from the stored intent.
Distinguish failure from an unknown outcome
A confirmed temporary delivery error follows the agreed bounded retry strategy. After a timeout, the email may already have been accepted: check the available delivery reference. Without a confirmed outcome, route for review rather than promising that retries can never send a second email.
Assign an owner for exceptions
An operator can see pending, failed or uncertain confirmations and follows the agreed manual route. Email failure does not rewrite the enquiry as failed, and receipt is not confused with approval.
What the process delivers
The design separates the committed enquiry from message delivery. It identifies ownership of the module and worker and the failures people handle. An independent service remains a further decision if measurable requirements or ownership make it necessary.
How to test this example
- Failed enquiry storage does not show successful receipt. Email failure after successful storage leaves the enquiry intact with a separate confirmation state.
- Offering the same command repeatedly or concurrently does not create another confirmation task. An uncertain external delivery result receives the agreed check or human review.
- A pending or failed confirmation can be traced to its enquiry, task ID, status and responsible owner; enquiry receipt, message delivery and substantive approval remain distinct.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Modular application | One team can release functions together and maintain clear module boundaries. | A shared release requires coordination and testing. Modules still need explicit data and interface agreements. |
| Independent service | A component has a justified need for its own release, workload profile or responsible team. | Adds network dependencies and independent operation. Ownership, version agreements, monitoring and recovery capacity must be available. |
What I need to start
- Important user scenarios and testable requirements: expected usage, response time, acceptable backlog and recovery time. Agree measurements and boundaries in advance.
- An owner for each business data type, an authorised writer and rules for interfaces, validation and failures. Queuing is a processing choice that can fit either architecture option.
- Available development and operating capacity: who releases changes, investigates incidents and maintains access and dependencies?
- Dependencies and behaviour during partial failure: which action is already committed, what needs offering again and when does a person take over?
- A documented decision with assumptions and review triggers, such as changes in measured wait times, independent release needs or team and data boundaries.
How to assess the result
- The design connects each important requirement to a component, owner and check. Alternatives and excluded scope remain visible.
- Representative processing and agreed failures are checked against the selected response-time, backlog and recovery boundaries.
- Repeated commands have a stable processing identity; partial execution and uncertain external outcomes have explicit recovery rules.
- The team can release the agreed components and investigate failures. Documentation covers data ownership, interfaces, monitoring and triggers for reviewing the decision.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- Business functions, user roles, data flows and existing dependencies included in the design.
- Investigation and design may include a bounded technical trial; implementation, migration and operational introduction have their own scope.
- Independently released services require additional setup and operation. Hosting, external services, monitoring and ongoing maintenance are estimated separately.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
You are building a new platform or reaching the limits of the current architecture.
Architecture describes the relationships between components, data and technical boundaries. When modernising legacy software, that design must also support the transition from existing systems. For priorities and decisions across several teams or products, a fractional CTO can provide wider technical leadership.
THE QUESTION I ASK FIRST
Which requirements determine the architecture, and what growth is actually expected?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
What does a software architect deliver beyond a diagram?
Agreed deliverables can include component and data boundaries, interface contracts, justified decisions and acceptance criteria. Responsibilities, assumptions and review triggers are also documented. A technical trial or implementation belongs in the assignment only when explicitly included.
Do we need microservices to support growth?
Not automatically. We first assess whether a modular application can support the requirements. An independent service is considered when separate releases, workload or ownership justify it and the team can operate it. Expected growth alone does not determine the choice.
Can you work with our existing code and development team?
The current product, working practices and operating capacity are the starting point. We choose a specific design question and required access. Missing evidence about the code may require separately agreed investigation; a design decision does not assume a complete rebuild.
When should we review an architecture decision?
When assumptions change or agreed boundaries are exceeded. Examples include measured backlog, different data ownership or a team needing independent releases. Define review signals in advance; every new feature does not automatically require a new architecture.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- Secure Software Development Framework, SP 800-218NIST
Including security in design and development agreements.
Link and relevance checked: - Retry patternMicrosoft Azure Architecture Center
Pattern and tradeoffs for transient dependency failures.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring Software architecture? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief