As Sociotechnical Systems continue to grow and the complexity of software products increases alongside ever-changing market demands, the way we think, design, architect, and develop ecosystems should evolve from past approaches.
Many businesses undergoing software transformation and system design and evolution face challenges such as rigid workflows, inefficient processes, and systems that struggle to adapt to real-world complexities. Traditional modeling techniques often emphasize static workflows, which can fail to capture the true dynamics of day-to-day business operations.
In this article, I’d like to share a new combined approach, Systematic Event Discovery Approach (SEDA), to system design, software transformation, and migration, which is based on the EventStorming workshop methodology.
Purpose & Benefits
The Systematic Event Discovery Approach (SEDA) provides a more effective solution than other methodologies and approaches, by focusing on identifying, analyzing, and optimizing key events within a system, not only Technically but also Organizationally.
Regarding these key elements of system design and transformation, the SEDA provides businesses with the opportunity to evolve their software ecosystem through event-driven, scalable, and adaptable solutions that align seamlessly with their long-term operational needs. Applications of the SEDA in software business would be:
- Software & System Transformation: Facilitates the transition of software eco-systems from both technical and organizational perspectives.
- System Design: Supports the creation of systems from the ground up with a structured and scalable architecture.
- Real-Time Responsiveness: Enables systems to dynamically adapt to real-time business conditions and operational changes.
- Continuous Improvement: Provides insights for ongoing system enhancements and optimization.
- Scalability: Ensures systems can grow efficiently in response to increasing business demands.
- Risk Management: Helps identify and mitigate potential risks through proactive event discovery, feedback loops and emergent behaviour analysis.
- Regulatory Compliance: Supports adherence to industry regulations by identifying compliance gaps and optimizing processes.
Unlike well-known process modelling and conventional solutions that focus on predefined sequences and known as best practices, the SEDA embraces real-world complexity through Domain-Driven Design, Team Topologies, and Systems Thinking.
Key events, such as a customer placing an order, a payment being processed, or a delivery being completed in an e-commerce application, serve as critical building blocks for understanding how a system truly functions.
The 4 Key Steps of SEDA
Software transformation based on SEDA can be defined in four major steps. In this section, we will briefly examine each step, with a detailed explanation provided in separate articles.
Understanding Current State & Identifying Transformation Vision
Before imagining any transformation, it’s important to first understand the system’s current state. The Iceberg Model helps with this by breaking down both the visible and invisible aspects of the system, providing a deeper perspective.
That’s why this section can be represented in 2 parts:
- System Exploration via Iceberg Model
- Principle Vision Investigation
System Exploration via Iceberg Model
As mentioned in the article on systems thinking (see here), the Iceberg Model is one of the most powerful and relevant tools for analyzing systems. It consists of four levels.
The tip of the iceberg, the visible part, represents Events in sociotechnical systems. These are the immediate issues that surface in a system, such as slow development cycles, excessive delays, team misalignment, or software quality problems.
The second layer, beneath events, consists of recurring issues and behaviors known as Patterns & Trends. For example, when teams are constantly waiting for approvals or dealing with dependencies between teams, it can create bottlenecks.
Organizational and technical factors that influence behaviors are found at the third level of the Iceberg Model, which we refer to as System Structure. This level includes elements like team topologies, software architecture, tooling, and processes, all of which shape the patterns we observe above.
For example, a monolithic architecture tends to enforce centralized decision-making and create excessive dependencies.
Deeply rooted beliefs and culture form the core causes in the Iceberg Model, known as the Mental Model. This is the most powerful and influential layer, shaping unspoken assumptions about how work should be done, who makes decisions, and how teams collaborate and communicate.
Principle Vision Investigation
After identifying the system’s current challenges, the next step is to create a transformation vision that directly addresses these issues. This is possible with considering Conway’s Law. It suggests that the design of software mirrors the structure of the organization that builds it. If teams are siloed, the software will likely reflect that by having rigid, disconnected components.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
For example, if the back-end and front-end teams operate separately with little communication, you can expect delays when trying to integrate their work.
For more comprehensive information, please read the Part Two.
Redesigning around Domains & Define New Team Structure
Redesigning an organization’s structure around business domains and redefining team roles is a strategic move in system design and software transformation. The goal is to enhance business agility, improve technical scalability, and boost overall efficiency. Inspired by two concepts:
- Team Topologies (Re)definition
- System Leverage Point Discovery
In the second step of SEDA, we focus on aligning teams more closely with business requirements while improving how system components work together.
Team Topologies (Re)definition
You’re probably wondering, why do we need to redefine our team structure?
The main reason is that traditional team structures often:
- Create high dependencies between teams
- Slow down delivery due to hand-offs
- Lead to a lack of ownership in critical business areas
By aligning teams with business domains, we ensure that the right teams (for example stream-aligned teams) have right autonomy and ownership, ultimately driving better control and efficiency in our core business.
System Leverage Point Discovery
To discover system leverage points, we need to (re)design our system around business domains and adopt a domain-centric approach in our workflow. This helps organizations enhance team autonomy while reducing their cognitive load. It could be done in 4 steps as below:
- Identify Key Domain Events with an EventStorming Workshop: This workshop is a powerful technique for uncovering domain events, user interactions, and system behaviors. It helps teams gain a deeper understanding of business processes and dependencies. This workshop results in a visual map of key domain events, making system boundaries clearer and more defined.
- Define System Boundaries & Bounded Contexts: This helps teams work independently within their own business domains, minimizing dependencies and allowing for smoother, parallel progress.
- Map Command-Event Interactions: This phase focuses on understanding how different parts of the system communicate through commands and events. Commands initiate actions, triggering events that, in turn, affect other system components.
- Point Core Domains as Leverage Points: Since these are the most distinctive aspects of a business, they should receive the highest investment in innovation and strong team ownership, serving as key system leverage points.
Implement Incremental Changes & Cultivate Feedback-Driven Culture
To ensure an effective and reasonable software transformation process and system design, the third step involves defining incremental changes and fostering a feedback-driven culture. This can be achieved through the following two steps:
- Global System Alignment via Fitness Functions
- System Dynamic Adoption with Feedback Loops
In this third step of SEDA, we focus on embracing changes, through software transformation and system design, in an incremental manner to keep the system as flexible as possible.
Global System Alignment via Fitness Functions
Global system alignment involves ensuring that all elements of the system, such as its architecture, processes, and practices, are working together toward shared goals. In software design and transformation, fitness functions are used to:
- Assess System Design Decisions
- Ensuring Architectural Decision Move Toward Desired Outcome
These functions also serve as indicators of system health, helping guide transformation efforts and ensuring alignment across all system components.
System Dynamic Adoption with Feedback Loops
In a sociotechnical system, system dynamics describes how various components interact and adjust in response to feedback from users, performance, and other factors. Feedback loops, in system thinking, are key mechanisms where a change in one part of the system triggers a reaction or adjustment in another part. In software ecosystems, these feedback loops can be either positive, reinforcing a change, or negative, helping to correct or stabilize the system.
You might be wondering, why are feedback loops important at this stage of SEDA?
Feedback loops are essential in system design and software transformation because they enable the system to adapt and evolve in response to changes in user behavior, performance, and environmental factors. They are responsible:
- To make the system more resilient
- To ensure the stays on track and prevents deviations
Addressing Unexpected Outcomes
In the world of software transformation and system design, unexpected outcomes are often unavoidable due to the complexity of sociotechnical systems. As organizations implement new technologies, re-architect their systems, or adopt agile methodologies, they may face unanticipated challenges, such as performance bottlenecks, security vulnerabilities, or user experience issues.
To effectively address these challenges, two key principles provide helpful frameworks:
- Systems Thinking (Nonlinear Thinking)
- Vigilance Over Emergent Behavior
Nonlinear Thinking
Nonlinear thinking recognizes that in complex software ecosystems, small changes don’t always lead to predictable or proportional outcomes. This is different from linear thinking, which assumes a direct and proportional relationship between causes and effects.
This way of thinking can help us reduce unexpected outcomes in the following ways:
- Gaining a better understanding of sociotechnical systems
- Preventing oversimplification
- Modeling different scenarios and use cases
Vigilance Over Emergent Behavior
Emergent behavior refers to complex patterns or phenomena that arise when simpler elements within a system interact. These behaviors are often hard to predict because they emerge from the system as a whole, rather than from individual parts.
Staying vigilant about emerging behaviors helps tackle unexpected outcomes by focusing on:
- Monitoring system behavior in real-time
- Anticipating unpredictable outcomes
- Leveraging monitoring and analytics tools
- Pattern recognition
This approach ensures we are ready to address challenges as they arise and make informed decisions along the way in SEDA process.
