Begin with the workflows that must operate
| Workflow | Boundary to identify |
|---|---|
| Client access | Client connection path and the platform components it depends on. |
| Pricing | Source instrument, transformations and distribution into the environment. |
| Execution | Request route, external destination and response evidence. |
| Administration | Approved access path, role and change authority. |
| Integration | Connected system, permitted interface and failed-flow handling. |
MetaQuotes describes MT5 as distributed and provides several integration APIs. Use that as a reason to identify boundaries carefully, not as permission to invent a component topology or undocumented interface.
Annotate dependencies with operational facts
For each flow, record the provider, environment, connection direction, configuration owner and monitoring location. Keep secrets out of the diagram. Mark assumptions and unknowns so the drawing distinguishes verified configuration from a proposed future state.
Add failure domains: what remains available when a component or connection fails, which records remain usable and which team must act. A line connecting two boxes should lead to a testable dependency, not imply automatic recovery.
Walk an operator through the diagram
Pick a normal account workflow and an interruption scenario. Ask the responsible team to trace both using the available records and runbooks. If the operator cannot identify where to investigate a failure, revise the drawing and the handover material.
Deliver the architecture together with a version inventory and a list of unresolved decisions. Use the MT5 architecture review scope to turn those decisions into a project. Review the drawing when new instruments, regions or integrations change the dependency model.