EA - IT Architecture V2 > Architecture Specification > Modeling application architectures > Describing the structure and services of an application > Describing a microservice with HOPEX IT Architecture
Describing a microservice with HOPEX IT Architecture
*A microservice is a software component that can be deployed autonomously, but which does not directly provide an end user service. It can interact with other application services, applications or application systems. This is a deployable software component that uses software technologies. For example: an authentication service, a PDF file printing service.
Microservice diagrams 
A microservice is described by several types of diagram:
• A microservice structure diagram is used to represent the interactions between microservice components based on service interfaces formalism.
• A microservice flow scenario presents the flows exchanged between the microservice elements in a given context.
• A microservice deployment architecture used to represent technical elements that support the microservice.
Accessing the list of microservices  
To access the list of microservices from the Inventories navigation menu:
*Select Software > MicroServices.
The list of microservices appears in the edit area.
Microservice properties with HOPEX IT Architecture 
A Microservice can be described from its properties pages.
The Characteristics property page of a microservice provides access to:
• Its Owner which is the current library by default,
• its Name,
• the Review Status,
• the text of its Description
• The Functional scope section is used to describe:
• The Business capabilities covered by the microservice,
*A business capability is a set of features that can be made available by a system (an enterprise or an automated system).
*For more details on business capabilities, see Describing Business Capabilities with HOPEX IT Architecture.
• The Implemented Functionalities that are fulfilled by the microservice.
*A functionality is a service required to perform a work. This functionality is generally necessary within an activity in order to execute a specific operation. If it is a software functionality, it can be provided by an application.
*For more details on functionalities, see Describing a Functionality Map with HOPEX IT Architecture.
*For more details on fulfillments, see Using fulfillment mechanisms.
• the Use Cases section, see Creating an application Use Case Diagram.
• The Responsibility section relates the person(s) responsible for the IT service
• Software Designer
• Local Application Owner
*For more details on these roles, see Business Roles of HOPEX IT Architecture..
• The Technologies section provides access to the list of Software Technologies used by the microservices.
*A software technology is a basic component necessary for operation of business applications. Software technologies include all basic software such as: application server, electronic mail server, software components for presentation, data entry, storage, business information sharing, operating systems, middleware, navigators, etc.
*For more details on software technologies, see Describing a Software Technology.
• the Risks section presents the risks associated with the application, see Describing an Application Environment with HOPEX IT Architecture.
With HOPEX IT Architecture a microservice is described by other property pages, see HOPEX IT Architecture properties pages content
Using a Microservice Structure Diagram 
*For more details on use of a structure diagram, see Application structure diagram
With HOPEX IT Architecture, the components of a microservice can be described by a microservice structure diagram.
A Microservice Structure Diagram includes:
• IT services,
•  
• Physical data stores; see Managing Data.
• access, request and service points; Creating a Service Point or a Request Point.
• Service interactions between components
*A Service Interaction represents an interaction for service purpose between entities in a specific context inside or outside a company. These entities can be enterprise org-units, applications, activities or processes, as well as external org-units. The content of this interaction is described in a service interface.