EDA: What does it mean

EDA: What does it mean

EDA, also known as Event Driven architecture, is gaining significant attention in the industry. The question arises: “what exactly is an event driven architecture?”.

When conducting an internet search, various definitions emerge, all of which share the following key aspects:

• It’s an architectural style that provides a specific approach to building and architecting systems or business solutions.
• It utilizes events to trigger communication between different components within a system. An event is something that informs others that a specific occurrence has taken place.
• It consists of three characteristic components:
  • Something that creates events.
  • Something that makes these events available to others.
  • Something that has an interest in these events.

However, using this definition alone can lead to the identification of many technical solutions as EDA. For example, the Java GUI framework SWING can be considered an EDA. This presents a challenge because, in the current context, we are not referring to these types of systems when discussing EDA. Therefore, the definition alone is insufficient. We need additional elements to clearly pinpoint the specific systems we are referring to. This is where positioning comes into play.

Setting the scene

To establish the positioning of EDA, we need a context. The following paragraphs will provide the necessary context and assumptions needed for positioning.

In our reality, our enterprise interacts with other enterprises. These interactions between our enterprise and others are referred to as Level 0 interactions.

Within our company, the team of enterprise architects has analyzed and decomposed the enterprise into different capabilities. A capability represents a fundamental building block that enables our enterprise to perform its functions. These capabilities also interact with one another, which are called Level 1 interactions.

Furthermore, the capabilities of our enterprise can be further decomposed into architectural building blocks and these blocks also have interactions with each other. These interactions are called Level 2 interactions.

This decomposition process of capabilities and building blocks can continue depending on the requirements and complexity of the enterprise. However, for the purpose of positioning, the described levels are sufficient.

Based on the provided model, the following assumptions can be made:

• A typical business solution (avoiding the term “application”) typically remains within the boundaries of a capability (Level 1).
• Workflows or business processes also operate within the confines of a capability.
• We use the term “value chains” for processes that span multiple capabilities. These value chains involve business processes from different capabilities, reflecting the end-to-end flow of value creation.
• Each business process within the organization has a clear and distinct owner. This individual is responsible for ensuring the correct execution and performance of the process.
• In contrast, a value chain does not have a specific business owner. It is often a shared responsibility among multiple stakeholders or teams within the organization.

Let’s consider a brief example to illustrate these assumptions within the context of a supermarket company. In the supermarket company, we can identify four capabilities:

• Product Management: this capability is responsible for managing the entire product portfolio. It manages the process of adding and removing products from the assortment, storing nutritional information etc…
• Pricing: the pricing capability contains the functionality that determines the prices for the products sold in the supermarket. It considers factors such cost price, profit margins, promotions, and other relevant information to calculate the final prices for items on the shelves.
• Label printing: the label printing capability provides the functionality to generate and print labels that will be places on the shelves in the store. It uses the pricing information and other product details to ensure accurate and up-to-date labels are available for customers.
• Store Management: the store management capability contains all the necessary functions to efficiently run the supermarket. This includes tasks like scheduling employees, managing inventory etc.

Let’s illustrate the assumptions with the following examples:

• Any applications or solutions related to product management, will not cross the capability’s boundaries. Although integration points might be required with other capabilities. For example, the application product information, will display the price of a product (integration point). The ownership of the application, however, clearly belongs to the product management capability.
• This also holds true for processes within a specific capability. For example, the process of introducing a new product into the catalogue, will be entirely handled within that capability. The Product Management capability takes complete ownership of this process, ensuring all necessary steps and activities are carried out without spilling over into other capabilities. Typically, the definition of capabilities is based on existing processes, or processes are designed in a way that aligns them with specific capabilities.
• Value chains span multiple capabilities together. For instance, the value chain responsible for ensuring the correct price is presented for every product in the store will involve several capabilities. The Product Management capability ensures that all new products are registered with accurate information. The Pricing capability determines and provides the correct price information. The Label Printing capability uses the pricing and product information to generate accurate labels. Finally, the Store Management capability ensures the appropriate personnel are assigned to post the labels on the shelves before the store opens. Each capability contributes its specific expertise and functions to the value chain, collectively ensuring the desired outcome.

Positioning

Interactions between Enterprises (Level 0):

The main objective for these interactions is sharing information between enterprises, traditionally resolved through managed file transfers, sFTP, Webservice interfaces (EDI), or storage devices (tapes). The use of events is just a “new” way for exchanging information, but the focus remains on data exchange. This is a classical integration problem. Using an event approach is one way of solving this problem.

In my view this use case should not be categorized as EDA – Event driven architecture– but as EDI –Event Driven Integration. The events in this context serve as intermediaries for transferring information, not controlling processes or workflows.

Events used for data integration do not directly control business processes. In the “Sending Enterprise” the process (if relevant) probably ends because the “last component” generates an outgoing event. Similarly, in the receiving enterprise, the component receiving the event will process the data and may create an internal event to initiate a new process or workflow if needed. It is crucial to understand that the events between the enterprises serves as an intermediary for transferring information rather than controlling a process or workflow.

Interaction between capabilities (Level 1): Sharing Data

In many enterprises, data sharing between capabilities is common. Typically, one capability is considered the master of certain data, but that data is “copied” to other capabilities. This pattern helps prevent excessive dependency among different capabilities. By copying the data, these capabilities can continue functioning even if the capability “hosting” the master data becomes unavailable.

In this use case, the primary focus is on data integration. While events are one approach to address this challenge, there are other options available such as ETL tools, propriety database tools etc… We also qualify this scenario as Event Driven Integration.

Interaction between capabilities (Level 1): Value chain

In certain organizations, events are utilized to signal significant occurrences. These occurrences are picked up by other capabilities to drive processes forward.

For instance, in our supermarket example, the product capability might generate an event to signal the registration of a new product. This event can then be picked up by the pricing department to initiate the calculation of a new price for that specific product.

The intent of such events is different and goes beyond data propagation. They serve as signals for important “business events” that have taken place. When events are used in this context, we consider it as “Event Driven Architecture”. It involves using events as a mechanism to coordinate and synchronize processes across capabilities, ensuring that important business events are appropriately handled and executed within the value chain.

Interactions within a capability Level 2

Like the interactions at Level 1, interactions between capabilities also exist at Level 2. Particularly in enterprises that adopt a Microservice Architecture. To enhance the resilience of these solutions, data is frequently copied between microservices. However, in this scenario, we classify it as Event Driven Integration since the primary focus is on data exchange and integration among the microservices.

Within a capability, events also play a role in automating business processes and workflows. This goes beyond the scope of simple data integration and is more closely linked to the overall architecture of a business solution or application. As a result, we classify this as Event Driven Architecture.