Describing a Micro-Service with HOPEX IT Architecture
A micro-service 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.Micro-service diagrams
A Micro-Service is described by several types of diagram:
• an micro-service structure diagram, is used to represent the interactions between the micro-service components based on exchange contract formalism.
For more details, see Using a Micro-Service Structure Diagram.• a micro-service flow scenario presents the flows exchanged between the micro-service elements in a given context.
For more details, see Using a Scenario of Application Flows Diagram.• a scenario of sequences of flows presents the flows exchanged between the micro-service elements.
For more details, see Using a flow scenario sequence diagram.• an micro-service deployment architecture used to represent technical elements that support the micro-service.
For more details, see Describing an Application Deployment Architecture.Accessing the list of micro-services
To access the list of micro-services using the Inventories navigation pane:
Select Software > Micro-services.The list of micro-services appears in the edit area.
Micro-Service properties with HOPEX IT Architecture
The complete description of a micro-service is accessed from its properties pages.
The Characteristics properties page for a micro-service provides access to:
• its Owner, by default, during creation of the micro service, the current library.
• its Name,
• the Review Status,
• the text of its Description.
• The Functional scope section is used to describe:
• The business capabilities covered by the micro-service,
.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 micro-service.
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 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 micro-services.
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 Specifying the Risks Associated with an Application.
With HOPEX IT Architecture a micro-service is described by other property pages. See HOPEX IT Architecture properties pages content.
Using a Micro-Service Structure Diagram
For more details on use of a structure diagram, see Application structure diagramWith HOPEX IT Architecture, the components of a micro-service can be described by a micro-service structure diagram.
A Micro-Service Structure Diagram includes:
• IT services,
• Physical data stores; see Managing Data.
• access, request and service points; Creating a Service Point or a Request Point.
• interactions between the components
An interaction represents a contract established in a specific context between autonomous entities that are internal or external to an enterprise. These entities can be enterprise org-units, applications, activities or processes, as well as external org-units. The content of this contract is described by an exchange contract.