Describing Application Architecture
HOPEX IT Architecture 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.
*For more details on the use of an application architecture, see Modeling Technical and Functional Architectures.
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.
*For more details on exchange contracts, see Describing data exchanges.
Verify that the application architecture covers the functional requirements identified in the business capability maps.
*For more details on the functional analysis, see Analyzing the Functional Coverage of the Architecture Implemented.
Describing application systems 
In an approach where application systems are studied in a unitary manner, it is preferable to create application environments to describe the context in which the systems described are used.
*For more details on application system environments, see Describing an Application System Environment with HOPEX IT Architecture.
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.
*For more details on application systems, see Describing an Application System.
 
The following diagram describes the application system corresponding to purchasing request processing.
Purchase requests are formulated by private users or by companies in different conditions.
The "Purchasing Request Processing" application system offers an Internet purchasing service.
The application subsystems can then be described hierarchically by showing at each level the points of exchange with the outside world.
The "eCommerce purchase” application system, for order management, manages order data in an internal data store and customer data in an external data store.
 
Application system structure diagram of the "Internet Purchasing” sub-system
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.
*For more information on data stores, see Managing Data.
Describing application processes 
HOPEX IT Architecture 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.
*For more details on system processes, see Describing Application Processes.
Application process diagram
Describing flow scenarios 
Structure diagrams use interactions to describe the data exchange capabilities between components. In addition, the flow scenarios make it possible to precisely describe the main use cases and implementation of these data exchanges.
It is possible to define flow scenarios at all levels of the application architecture:
Application
Application System
Application Environment
IT service
Micro-service
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".
*For more details on flow scenarios, see Describing Application Flows.