Value Stream and Event-Driven Architecture are two distinct concepts that are often used in the context of software design and system architecture. While they share some similarities, they have different focuses and purposes. Let’s explore each one:
Value Stream:
Value Stream is a concept derived from Lean thinking and Lean software development. It is widely used in Business Architecture to define the value stages necessary to design a target solution (theoretically, from a baseline). Once the first level of the Value Stream has been agreed on, the Domain Architects (DA) start decomposing (levelling) each value stage into substages until the problem is resolved from a logical perspective. Value stages also allow the DAs to map the capabilities and critical information relevant to the project and even heatmap such relationships to ensure that the necessary changes identified via gap analysis are addressed, as well as interoperability and dependency issues that could arise. This is also useful to identify and mitigate emergent risks as they get discovered through the levelling process. Value streaming therefore refers to the sequence of activities and processes that are required to deliver value to the end-user or customer. The emphasis is on identifying and optimising the flow of value through the entire architecture design development and eventually its delivery lifecycle. In the context of software architecture, a Value Stream approach aims to align all the activities and processes involved in delivering value, such as requirements gathering, development, testing, deployment, and maintenance. The goal of Value Streaming in LEAN environments can also be to eliminate waste MUDA), reduce handoffs, and improve the overall efficiency and effectiveness of the value delivery process. Value Stream Mapping (VSM) is a technique often used to visualise and analyse the current state of the value stream and identify opportunities for improvement. By identifying bottlenecks, delays, and non-value-added activities, organisations can streamline their processes and achieve faster delivery of software solutions.
Event-Driven Architecture (EDA):
Event-Driven Architecture is an architectural pattern that focuses on the communication and interaction between software components based on the occurrence of events. Using EDA with Micro Service Architecture (MSA) is also a way to combine building blocks of functionality in a Value Stream like process chain which allows DAs to achieve the target result by, where possible, reusing existing building blocks of functionality (from a service catalogue for instance). Such rapid design can be viewed also as Agile Architecture, and it gives feedback to a solution driven EA team (context 1 in DPBoK) to continuously improve their collection of reusable building blocks or microservices offering. An event can be any meaningful occurrence or change in the system, such as a user action, a sensor reading, or a system state change. The components in an event-driven system are decoupled and react to events asynchronously. In an event-driven system, components generate events and publish them to an event bus or message broker. Other components can subscribe to these events and react accordingly. This decoupled nature allows for loose coupling, scalability, and flexibility in building complex systems. Event-Driven Architecture is often associated with real-time, event-intensive domains where responsiveness and scalability are crucial. It enables systems to handle a large volume of events and provides a mechanism for reacting to changes or triggering actions based on those events.
In summary, while Value Stream is often seen as focussing on the optimisation of the flow of value through the software development and delivery lifecycle, Event-Driven Architecture is an architectural pattern that enables loose coupling and responsiveness by leveraging events as a means of communication between software components. These days the concept of Value Streaming in an architecture design, allows for high visibility, communication and the detailing (decomposition/levelling) of the necessary value adding changes to occur. Both approaches have their own merits and can be used together in designing and implementing effective software systems.
If this advanced content interests you, please check out our TOGAF EA, TOGAF Practitioner Bridge, TOGAF Business Architecture Foundation, SIRF and EA Practical Workshop courses, where such subject is treated.