Application Communication Diagram and UML/BPMN EAP Profile Overview
The article explains the purpose and structure of application communication diagrams, describes SOA‑oriented component layering, outlines the UML/BPMN EAP profile and Archimate concepts, and provides a detailed list of component types used in enterprise architecture modeling.
The purpose of the Application Communication Diagram is to describe all models and mappings related to communication between applications in the meta‑model entities. It shows the interfaces between application components and between components; where appropriate, interfaces can be associated with data entities, and applications can be linked to business services. Communication should be logical and display only the intermediary technologies relevant to the architecture.
Tip: Use application components to present a Service‑Oriented Architecture (SOA) as much as possible. Different types of application components allow layering; the main components are GUI (interaction), process, and entity. Legacy systems or external applications may result in a hybrid architecture, where "Application" or "Database" components can be mixed with SOA service components. Application components are connected via required or provided services, which are linked by connectors. Provided/required services are typically typed elsewhere as IS service types.
The Application Communication Diagram can represent an existing application map or a logical architecture of a future scenario. An SOA‑type architecture is encouraged, based on service‑oriented application components. In hybrid architectures, a combination of non‑SOA applications, repositories, and new SOA parts can be displayed.
In an SOA‑oriented architecture, it is recommended to structure components according to the nature and level of service application components: interaction‑focused components (GUI, WEB), process‑execution components, and the most stable entity components.
Components interconnect through their required and provided services, which are linked by connectors. These services are typed by IS service definitions modeled elsewhere. Service operations transfer data (parameters), whose types are also modeled as "messages".
UML/BPMN EAP Profile
Interaction Application Component : Represents a top‑level component that manages interaction with external elements, typically a GUI such as a web interface.
Entity Application Component : Derived from business entities, responsible for managing access to and integrity of those entities.
Process Application Component : Handles business process execution and orchestrates process tasks.
System Federation : A coarse‑grained application component that assembles systems together, e.g., for inter‑company collaboration.
Utility Component : Frequently reused components, often off‑the‑shelf.
Database Application Component : Represents a repository; in pure SOA it should not appear, but it is useful for legacy analysis or technical architecture.
Application : Corresponds to legacy applications, commercial products, or assembled groups of application components.
Provided Service : Accesses an application component via a provided service.
Required Service : A service that an application component needs to be connected to a provided service of another component.
Connector : Links provided or required services with one or more instances of application components.
Information Flow : Defines any type of flow of information (business entities, events, products, informal data, etc.) between enterprise activity entities.
Flow Link : Links data (e.g., business entities, events, products) with activity elements (e.g., business processes, services).
External Participant : Participants outside the enterprise.
Consumption Link : Represents an external participant consuming an element of the IS (service, operation, application component).
Architecture is layered: interaction components (site) at the top, process components in the middle, and entity components at the bottom.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architects Research Society
A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
