A business application architecture
Keep deployment separate from logical structure
A modular application does not need a separate service for every capability. Begin with clear responsibilities and split deployment where the workload justifies it.
Document the exceptional route
Show how identity fails, where a request waits and how an operator recovers work. A diagram containing only the successful path is an incomplete reference.
Show responsibility as well as components
A diagram should explain where identity, responsibility and data change hands. Show users, applications, authoritative stores and external services. Identify boundaries that require authentication and operations that cross into another organisation's systems. A collection of product icons does not explain who can perform a business action.
Add a narrative following one request from the user's action through validation and data access to the result. State which steps are synchronous and which finish later. If the interface displays a pending state, explain what changes it and how failure becomes visible. Readers should be able to connect each part of the diagram to an observable part of the workflow.
Include paths that do not succeed
Review the architecture with an unavailable dependency, an expired credential and a repeated request. For AI, add an inaccessible source, an unsupported answer and a tool call requiring approval. Mark where each failure is detected, what evidence is recorded and which component decides the next action.
Consider a document application that stores a file, extracts proposed fields and sends approved information to finance. Account for an extraction timeout, a reviewer changing a value and an uncertain response from the finance system. These events should not all restart the whole workflow. Show the checkpoints needed to recover a stage without repeating a completed business action.
Adapt the reference before adopting it
Record assumptions about scale, availability, data location and team capability. Explain which controls are essential and which components are interchangeable. A managed queue may be convenient, while duplicate handling remains necessary regardless of the product selected.
Map the reference to existing identity, monitoring and deployment practices. Confirm that someone can operate every introduced dependency. Create an updated diagram with agreed differences and keep it beside the implementation. Use a small validation exercise to test the most uncertain boundary before committing to a large build. A reference architecture is a starting point for a reviewable design, not a universal stack that every organisation should install.
It needs to be adapted to the business rules, workload, team capacity and existing systems. Record the assumptions that do not apply.