In architecture discussions, implicit assumptions often go unspoken but influence design choices. These assumptions—whether based on past experiences, unchallenged norms, or personal biases—can drive decisions in ways that aren’t always aligned with the system’s needs or the team’s best interests. The danger is that these assumptions, if not made explicit, can lead to suboptimal or misaligned design outcomes.
To surface these assumptions, architects and facilitators can use a few effective strategies:
1. Encourage Open Dialogue
One of the most effective ways to reveal implicit assumptions is to create an environment where open dialogue is encouraged. In this type of setting, participants feel safe to share their thoughts, even when those thoughts challenge the status quo or reveal assumptions they may not have fully examined.
For example, if a team member mentions a solution based on “what we’ve always done,” it’s important to ask why this approach is preferred and what assumptions underlie it. This opens a door to exploring whether these assumptions are still valid or need to be reevaluated.
2. Facilitate Questions that Probe Deeper
Rather than just accepting statements at face value, facilitators can ask probing questions that challenge assumptions. Questions like:
-
“What are we assuming about this user?”
-
“What if this assumption turned out to be wrong?”
-
“How does this decision align with our long-term goals?”
These types of questions can help bring to the surface assumptions that might otherwise go unchallenged. Probing assumptions allows teams to confront potential gaps in their reasoning or misunderstandings about the system’s needs.
3. Use Real-world Scenarios
Sometimes, implicit assumptions are easier to spot when they are framed in the context of real-world scenarios. By imagining how the system will behave in specific use cases or under particular conditions, teams are forced to confront the assumptions they have about how users, processes, and technologies will interact.
For example, asking “What happens when X occurs?” or “How would this approach handle failure in this situation?” can help uncover assumptions about system performance, reliability, or scalability that may not have been explicitly stated.
4. Leverage Diagramming and Mapping Techniques
Architecture diagrams, user journey maps, or systems maps can be incredibly helpful in surfacing implicit assumptions. These visual tools make complex systems and processes tangible, making it easier for the team to see where certain assumptions might be hiding.
By collaboratively creating diagrams, the team can highlight areas where there may be gaps in understanding or where assumptions need to be tested further. For example, a flowchart that maps out a system’s behavior may reveal unspoken assumptions about user paths, data flow, or the sequence of operations.
5. Create a Safe Space for Challenge
Implicit assumptions are often tied to the fear of challenging ideas, especially when senior team members or stakeholders are involved. To surface assumptions, it’s critical to create a space where it’s safe to ask questions, even if those questions challenge authority or the current design direction.
This can be accomplished through “red teaming,” where a team intentionally plays the role of the challenger to push assumptions to the forefront. It also means encouraging junior team members or stakeholders to ask “naive” questions—questions that force the team to reconsider assumptions.
6. Regularly Revisit Assumptions
Even after surfacing assumptions in a conversation, it’s important to periodically revisit them. The context around the system evolves, so assumptions that once seemed reasonable may no longer hold true. By making assumption-checking a regular part of the design process, teams are less likely to fall into the trap of designing based on outdated or unverified assumptions.
Teams can set aside time in their architecture review cycles to evaluate whether the assumptions made in early stages still hold true, given new information or changes in the business or technical environment.
7. Make the Implicit Explicit
A key part of facilitating these dialogues is the ability to translate implicit assumptions into explicit ones. Once identified, these assumptions should be documented, discussed, and tested. This documentation can be a shared reference point for future decisions, helping everyone involved stay aligned on what assumptions are at play and how they might impact future design choices.
For example, in a system redesign, documenting the assumption that “users will always have internet access” may lead to a discussion about the need for offline functionality or resilience planning.
8. Promote Cross-disciplinary Conversations
Architecture dialogues often involve a mix of technical and non-technical team members. Implicit assumptions can arise from different disciplinary perspectives, whether it’s a developer’s assumption about the infrastructure, a designer’s assumption about user behavior, or a product manager’s assumption about business goals.
Encouraging cross-disciplinary conversations ensures that assumptions from all areas are heard and scrutinized. A developer may assume that a new feature can be built with existing infrastructure, while a product manager may assume that customers are willing to pay for the feature. Bringing these diverse perspectives together makes it easier to identify and address the assumptions each group is operating under.
9. Scenario Testing and Prototyping
To validate assumptions, creating prototypes or conducting scenario tests is invaluable. Prototypes allow teams to quickly test assumptions about system functionality and usability. Similarly, scenario testing can reveal whether design decisions hold up under real-world conditions.
This is a powerful way to uncover incorrect or risky assumptions, and it allows teams to pivot or adjust before committing to a full-scale implementation.
10. Document and Share Assumptions
Finally, documenting assumptions and sharing them across the team can help to keep everyone aligned. When assumptions are written down and tracked, it becomes easier to identify when they change or when new information challenges them. This documentation should be seen as a living document, updated regularly as the system design evolves.
This also ensures that everyone has a clear understanding of the rationale behind design choices and allows new team members to quickly get up to speed on the current assumptions that are guiding the architecture.
Conclusion
Surfacing implicit assumptions during architecture dialogues is not just about improving the current design. It’s about fostering a culture of critical thinking, encouraging open discussions, and ensuring that decisions are based on facts and well-validated insights rather than unchecked biases or outdated beliefs. By systematically identifying and challenging these assumptions, teams can create more robust, flexible, and future-proof architectures that better meet user needs and business objectives.