We're going though the 62304 learning curve right now.
As the previous answer suggests it is just the high-level view of your medical device software.
According to the standard you should at minimum list the various modules/components. Components are defined as being made of software items. However, how you define components and items is entirely up to you.
In our case, products often have one component and rarely more than three.
In the case of a engineer-workstation-based GUI project, we have four component. The GUI, the product logic, and an existing DLL we are required to integrate, and the underlying mathematical modelling engine that the whole system is based upon.
The architecture consists of
- description of the GUI,
- basically a list of screens and their associated workflow
- a description of the objects(software items) associated with each screen
- a description of the product logic
- a description of the state machine, and how it interacts with the GUI workflow
- a description of the state machine class (a software item)
- a description of the mathematical-modelling operations being performed for the client. (broken down into stages - each stage is a software item)
- a description of a required DLL, its SOUP status, etc. (one software item)
- a reference to another software component developed under 62304
One thing to bear in mind is that (despite the heavy implication of the way the 62304 standard is written) you don't have to create the architecture diagram up front and then fix it in stone in a waterfall coding model. The FDA have encouraged the use of more agile approaches, allowing you to develop the architecture along with the code, so long as your validate the final architecture against the final design. So start with a simple architecture that allows you to make progress, and keep it up to date as you develop the code. See the AAMI's TIR45 publication for some documented justification.