Describing Application Architecture
HOPEX IT Architecture V2 offers the means to represent different levels of application architectures: from the description of the application environment to the technical components to be implemented.
These representations make it possible to define the software and hardware components and to identify in a consistent way the data exchanged between them.
The description of application systems can be done according to a top-down approach, starting by describing the company's main application systems, or according to a unitary approach by describing only certain application systems.

An application system is an assembly of other application systems, applications and end users interacting with application components to implement one or several functions.
If you use a unitary approach, you will need to describe the application system environment to describe the context in which the application system is used and its interactions with external components.

An application system environment allows presenting the other application systems, applications or micro-services with which this application system can interact.
In addition to a precise description of the application architecture to be implemented, this step covers the following points:
• Identify precisely the exchanges between the different software and hardware components and formalize them through exchange contracts.

An exchange contract is a model of a contract between organizational entities. This contract is described by exchanges between an initiator role and one or several contributor roles.
• Verify that the application architecture covers the functional requirements identified in the business capability maps.
Describing application systems
In an approach where application systems are studied in a unitary manner, it is preferable to create application system environments to describe the context in which the application systems described are used.
In a top-down approach, the main application system structure diagram is the entry point for the description of the existing or planned application system.
The following diagram describes the application system corresponding to purchasing requests processing.
The following diagram describes the application system corresponding to purchasing requests processing.
Purchasing requests can be formulated by external customers via an Internet purchasing application or indirectly via a call center. Internal users have to call a “Sales assistant” who uses the “Office Supplies Purchasing Management” application.
The application subsystems can then be described hierarchically by showing at each level the points of exchange with the outside world.
The data stores are used to represent the data that will be stored in databases.

A data store provides a mechanism to update or consult data that will persist beyond the scope of the current process. It enables storage of input message flows, and their retransmission via one or several output message flows.
Application sub-system structure diagram of “Purchasing Request Management”.
The “Purchase Request Management” application uses two IT Services: “Display purchase request list” and “Assign and handle purchase request”. The “Assign and handle purchase request” IT service invokes Excel micro-service.
Describing application processes
HOPEX IT Architecture V2 offers the possibility to check that the processes performed by the application system are correctly covered by describing Application processes.

A system process is the executable representation of a process. the events of the workflow, the tasks to be carried out during the processing, the algorithmic elements used to specify the way in which the tasks follow each other, the information flows exchanged with the participants.
Application process diagram
Describing flow scenarios
Structure diagrams use interactions to describe the data exchanged between components. However HOPEX IT Architecture V2 offers flow scenario facilities to describe precisely data exchanged.
At each level of the application architecture, it is possible to define flow scenarios between system components in specific contexts.
The objective of flow scenarios is to verify that content is correctly conveyed between components.
The scenario of application system flows below describes the interactions between a client and the eCommerce application.
Example of scenario of application system flows for "Purchasing Requests Processing".