As explained in Part One, the SEDA framework consists of four steps, each of which was briefly discussed. The first step, “Understanding the Current State of Eco-system & Identifying Software Transformation Vision,” is what we’ll explore in detail in this article.
Precisely speaking, this section will focus on system exploration using the Iceberg Model and investigating transformation principles through Conway’s Law and Brooks’ Law.
Understanding the Current State of the Sociotechnical System
Before making any transformation, we first need to understand the current state of our sociotechnical system. This means deeply exploring both its technical aspects, such as software architecture, workflows, and tooling, as well as its organizational dynamics, including team interactions, decision-making processes, and culture.
To truly grasp the complexity of the ecosystem, we must adopt a systemic way of thinking. This means recognizing interconnected patterns rather than focusing on isolated issues and making decisions with a holistic, long-term perspective.
The Iceberg Model offers a valuable framework for this analysis, allowing us to look beyond surface-level problems and uncover deeper, underlying systemic challenges.
Iceberg Model for System Exploration
The Iceberg Model breaks a system into four layers, each offering deeper insights into the root causes of inefficiencies in software development and delivery. If you’d like a deeper understanding of the model, feel free to check out my article on the topic.
Here at SEDA, we’re exploring how to apply it effectively as a first step in software transformation and modernization.
Visible Symptoms – Transforming Events into Actionable Insights
Have you ever found yourself dealing with slow software delivery in your daily work? Or maybe you’ve noticed signs of poor communication between teams or frequent production failures?
These are the surface-level challenges and observable indicators that teams encounter in their daily work, which we refer to as Events in the Iceberg model. Identifying events as visible symptoms in a complex software ecosystem takes a structured approach, one that uncovers inefficiencies, bottlenecks, and recurring challenges across both technical and organizational point of view.
Because sociotechnical systems intertwine people, processes, and technology, misalignment in these areas often gives rise to critical events. To systematically identify these issues, the SEDA framework provides a strategy. Here’s the steps:
1) Monitor and Analyze Development and Delivery Metrics
One of the most effective ways to identify events is by analyzing operational data. Software ecosystems, whether complex or simple, generate large amounts of quantitative metrics, but only if developers and architects consider them during development. These metrics that help highlight inefficiencies, would be as below:
- Code Quality Metrics such as code coverage
- Development Process Metrics like lead time (time from a feature request to deployment) and cycle time
- Performance Metrics like response, throughput, latency and mean time to recovery (MTTR)
- Security Metrics like penetration test success rate
- Project Management Metrics like budget variance
- Customer Satisfaction Metrics such as net promoter score (NPS)
For instance, when lead times (Development Process Metric) are too long because of approval delays, it usually means too much bureaucracy, oversight, or red tape is getting in the way and slowing things down.
2) Conduct Systematic Team Interviews & Shadowing
Communication is key. Inefficiencies in sociotechnical systems often aren’t immediately obvious, so the best way to catch them is by talking directly with engineers, product managers, operations teams, and anyone involved in the production workflow.
When a back-end team keeps facing project delays because they’re waiting on other teams, it can slow everything down and make deadlines harder to meet. Clear and structured communication helps identify these bottlenecks early.
3) Map Out Hand-offs and Identify Dependencies
Most bottlenecks in software development often happen because of too many hand-offs and dependencies between teams and other components of software eco-system. You can identify these by mapping out workflows and noticing where work tends to get stuck.
Here are some key questions to consider:
- How many approvals are required before a change goes live?
- Which teams depend on each other to release a feature?
- Where do delays and escalations happen most often?
Recurring Issues – What Keeps Happening?
Patterns in a sociotechnical system show recurring problems that keep happening over time, even when we try to fix them. By spotting and understanding these patterns, we can better understand the underlying issues that hold us back and improve our ability to tackle the root causes.
SEDA outlines the following steps to identify patterns in the software ecosystem based on events that occur in the layer above.
1 ) Consolidating and Analyzing Event Data Across Teams and Operational Processes
To identify patterns, gather event data from different teams, systems, and workflows. Look for issues that keep happening over time. Even if events seem unrelated at first, you might notice that they’re part of a bigger issue once you look across teams.
This process involves using tools like Jira, GitOps, CI/CD pipeline logs, and incident reports to track how often these events occur and what causes them.
For example, if you notice that new features are always delayed when they’re released, it could be a sign of recurring problems. These might include:
- Too many manual approval
- Poor teamwork between developers and operations
- Outdated infrastructure
- Lack of proper automation
2) Performing Root Cause Analysis on Recurring Issues
Once you’ve spotted recurring issues, the next step is to dig into the root cause analysis (RCA) to understand what’s really driving them. Some Events might reveal deeper issues, like:
- Flaws in the software architecture
- Unclear team responsibilities
- Process gaps, such as bugs slipping in during integration or frequent production outages
Other Events, on the other hand, like delays in production releases can highlight bigger trends. By analyzing these repeated failures, you can uncover:
- Inefficiencies in workflow hand-offs
- Decision-making bottlenecks
- Issues and flaws that might not be obvious at first glance
Systemic Forces – Why Is This Happening?
The structural layer of the Iceberg Model helps explain why certain patterns and events keep repeating in a sociotechnical system. In a complex software ecosystem, this structure includes:
- Team Topologies
- How decisions are made
- Company policies
- Workflows
- Technical architecture
To understand how structure influences surface-level occurrences, we must connect visible Events and Patterns to the deeper forces that sustain them. For this reason, SEDA recommends the following works to explore system structure as the foundation of events and patterns.
1) Structure as the Root Cause of Recurring Events & Patterns
To begin analyzing and exploring the system structure and finding root causes of recurring issues, start by addressing the following questions:
- Why do these failures persist?
- What structural factors contribute to these inefficiencies?
We ask these questions because events often point to deeper patterns. By exploring them, we can uncover recurring issues like:
- Bottlenecks in deployment
- Slow cross-team collaboration
- Limited decision-making autonomy
2) Finding Decision-Making Structures and Bureaucratic Inefficiencies
The structures which require multiple levels of executive approval or lack of autonomy on architectural choices creates rigid hierarchies that slow down Software Transformation and encourage risk avoidance instead of ongoing improvement. Over time, it results in too many handoffs, frequent context switching, and delayed feedback, making it harder for the system to adapt to change.
That’s why, the next step in this level of Iceberg Model analysis is to identify decision-making bottlenecks and inefficiencies by asking the following questions:
- What is the decision-making process within the organization?
- Who is responsible for making key decisions in the company?
- How does the company ensure transparency and collaboration in decision-making?
3) Investigate System Architecture and Technical Debt
Beyond organizational design and decision-making, the software architecture itself plays a crucial role in shaping a system. In large-scale software ecosystems, tightly coupled architectures create rigid dependencies between teams and services. This often leads to integration failures, deployment conflicts, and scalability challenges.
Additionally, when modernizing software, we must avoid falling into the Distributed Big Ball of Mud anti-pattern, which can lead to chaos rather than true modernization.
Hidden Cultural Norms – What Unspoken Beliefs Shape This?
In a complex software ecosystem (Sociotechnical Systems), mental models help define how people understand and interact with both the technology and the organization itself.
The mental models of engineers, product managers, executives, and other team members play a big role in how problems show up and how ongoing issues unfold. They also influence the systems that either keep things running smoothly or contribute to inefficiencies.
To effectively navigate mental models in a complex software ecosystem, organizations must first identify and question the deep-rooted beliefs that influence behavior, decision-making, and system design. SEDA recommends the following steps:
1) Encourage Critical Reflection and Discussion
Start by creating opportunities for your team to think about their assumptions and share their perspectives. Workshops and retrospectives are great ways to do this. Encourage team members to talk about:
- How they believe things work
- Why they think certain processes are necessary
- What challenges they see in getting things done
By putting these thoughts into words, it becomes easier to spot misunderstandings, outdated ideas, or misalignments that might be slowing things down.
2) Shift Towards Systems Thinking
Shifting from optimizing individual tasks to thinking about the entire system is a big mindset shift. People should be encouraged to look at the full workflow, from idea to launch, and understand how their actions affect other teams and the overall process.
3) Provide Training and Provide for New Mental Models
Changing the way people think doesn’t happen overnight. Organizations need to invest in training and mentorship to help new ideas take root.
To make these shifts stick, companies should use the right tools, clear communication, and strong leadership support. This creates a culture where learning and improvement become part of everyday work.
Identifying Principle Transformation Vision
For a Software Transformation to succeed, it’s not just about upgrading technology. It’s about reshaping the architecture, processes, and decision-making to make everything more scalable, flexible, and efficient.
To get there, you need to tackle both organizational and technical roadblocks that slow down software delivery. When defining our transformation vision, SEDA suggest to focus on these three key areas:
- Examining Structure with Conway’s Law
- Analyzing Excessive Handoffs
- Identifying Decision-Making Bottlenecks
Examining Structure with Conway’s Law
A key challenge in software transformation is recognizing how a company’s structure shapes its software architecture. Conway’s Law puts it simply:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. — Melvin Conway
In other words, if a company is divided into rigid silos, its software will likely have tightly connected components that depend on constant coordination between teams. This creates inflexible systems that make software migration slow, costly, and risky.
Analyzing Excessive Handoffs
Too many handoffs in software development cause delays, miscommunication, and inefficiencies. They happen when teams have to wait for approvals, pass work between departments, or depend on specialists for every step. Some common signs of excessive handoffs include:
- Slow deployments because teams rely on external QA or operations.
- Frequent misunderstandings between business, development, and operations due to lack of shared ownership.
- Overly complicated ticketing systems that create bottlenecks and slow things down.
Identifying Decision Making Bottlenecks
In many organizations, decision-making is too centralized, making approvals slow and rigid, which holds back software development. Some common bottlenecks include:
- Architectural decisions needing sign-off from a central team, which slows down innovation.
- Security and compliance reviews being manual and disconnected from day-to-day engineering work.
- Teams lacking the freedom to make even small technical choices without senior leadership approval.
These issues don’t just slow things down—they create frustration and inefficiency, making it harder for teams to improve and adapt during Software Transformation journey.
