When formalizing the architecture of the system it is important that you understand not only the value behind what the architecture will bring to the table, but also to understand and appreciate what it should be.
The primary goals of Software or Technical Architecture is to identify the Non-Functional requirements that are realized by the Quality Attributes that will drive the System Architecture.
On Non-Functional Requirements:
A non-functional requirement is a requirement that specifies criteria
that can be used to judge the operation of a system, rather than
specific behaviors. They are contrasted with functional requirements
that define specific behavior or functions. The plan for implementing
functional requirements is detailed in the system design. The plan for
implementing non-functional requirements is detailed in the system
Broadly, functional requirements define what a system is supposed to
do and non-functional requirements define how a system is supposed to
be. ... Non-functional requirements are often called "quality attributes" of a system. Other terms for non-functional requirements are "qualities", "quality goals", "quality of service requirements", "constraints" and "non-behavioral requirements"
Of course identifying the architecturally significant requirements makes sense when on a greenfield project, however when working with existing software, it is best to be as disciplined as possible. You will not want your software architecture to be influenced by the existing system.
Software architecture to be authoritative really needs to be 3 things.
This is the part of the documentation where you declare NOT WHAT IS, but how things SHOULD BE. We do this through the use of various Architectural Views of the system. We define the components that should be, how they interact, and then we optionally drill down into each component for more granular views that declare how the system should be designed.
This is an important distinction. The System Design should be constrained by the System Architecture, they are in fact separate but related things.
The Rationale of your Software Architecture is what provides legitimacy and authority to the architecture decisions that were made. Perhaps the decision was made to utilize a Pub/Sub event listener over MQ for triggering a batch job and you diagram it?
Why was this decision made? We explain why in the Rationale section and link back our explanation to Non-Functional Requirements, Quality Attribute Goals, or Architecturally Significant Requirements. (Eg. Jobs must be asynchronous and repeatable, Maintainability as a quality attribute drives that in the event of a batch job failure that jobs can be re-initiated via an MQ message, The System must have Zero Message Loss with asynchronous communication, etc...)
Now that you have declared how architecture should be and proved it with your Rationale, you can now identify Risks on the current state of the system to where this doesn't abide.
Your Risks can also diagram where current state is currently deviating from Architecture. These Risks can be addressed by the development team now, either through their project plan or by adding this into the backlog.