Our smart waterway AI DT project has weak organization and a non-IT leader. We decided to use a high-level architecture map (like SGAM) purely as a visual Common Language to bridge the civil and IT domains. How do we introduce this map without overwhelming the team with technical jargon?

GPT-5.4

Vote: Agile slices: Map one single use-case to start.

I maintain vote C. The strongest opposing case is A: a sticky-note workshop can indeed reduce intimidation and create buy-in. But that is a facilitation format, not the best sequencing strategy. In a weakly organized team with a non-IT leader, asking people to co-create the map too early still risks confusion, drift, and jargon-by-accident. C is the safer introduction because it constrains scope before introducing method. One concrete use-case gives everyone a shared reference point: one workflow, one data flow, one operational outcome. That keeps the architecture visual practical instead of abstract. This directly fits the stated goal: use the map as a visual common language, not as an architecture lesson. A single slice lets you label everything in civil/business terms first, then reveal only the minimum IT concepts needed to explain that use-case. B and D remain clearly weaker. Hiding IT turns the map into a tracker rather than a bridge between domains, and hiding the map for contracts avoids the communication problem instead of solving it. So my final case is: start with one high-value use-case, map only that slice, keep the language non-technical, and expand later. If desired, you can run workshop-style sessions after that first slice exists. In other words, A is a useful tactic later, but C is the right introduction strategy now.

GLM 5 (changed mind)

Vote: Agile slices: Map one single use-case to start.

The arguments for Option C have convinced me. Starting with a single use-case provides a concrete, tangible example that anchors the abstract architecture framework in reality. A non-IT leader and weakly organized team can grasp 'how does sensor data flow to the dashboard' far more easily than navigating a blank-slate workshop with unfamiliar concepts. The critical insight is that a workshop (Option A) requires participants to already understand what they're building together. With weak organization and no IT background, the team cannot meaningfully co-create something they don't yet comprehend. The 'show-don't-tell first' approach respects their current capability. Once the team successfully maps one use-case in business/civil terms, they build confidence and familiarity with the visual language. The workshop can then follow as an expansion activity, with participants now equipped to contribute meaningfully. This incremental approach reduces cognitive overload while maintaining the core purpose of bridging domains.

Gemini 3.1 Pro (changed mind)

Vote: Agile slices: Map one single use-case to start.

Claude Opus 4.6 correctly highlighted a critical vulnerability in Option A: running an open-ended sticky-note workshop with a weakly organized team and a non-IT leader is a recipe for chaos, not clarity. Without a foundational understanding of the visual language, a blank-slate collaborative approach will likely increase confusion and frustration. Option C is the most pragmatic way to introduce a complex architectural framework under these specific constraints. By anchoring the high-level map to a single, concrete use-case, we provide immediate, tangible value. The non-IT leader and civil experts can relate to a specific, familiar workflow (e.g., a water level sensor triggering a flood warning) rather than getting lost in abstract architectural layers. This incremental "show, don't tell" approach respects the team's current maturity level. It reduces cognitive overload, safely establishes the visual common language, and builds the structural discipline the team currently lacks before attempting to scale up or map the entire system.

Sonar Reasoning Pro

Vote: Agile slices: Map one single use-case to start.

The workshop advocates (GLM 5 and Gemini 3.1 Pro) make an emotionally compelling case about ownership and tactile co-creation. However, they underestimate the organizational risk. A blank-slate sticky-note workshop with a weakly organized team and a non-IT leader risks chaos masquerading as collaboration—the team co-creates something they don't yet understand, and sticky notes alone don't teach SGAM structure. The search results reinforce why Option C is methodologically sound. SGAM itself is use-case-driven: decomposing High-Level Use Cases (HLUCs) into Primary Use Cases (PUCs) is the core SGAM methodology[1][2]. The framework is explicitly designed to enable 'structured analysis of Smart Grid use cases'[2] by mapping functions, data flows, and components incrementally. For a weakly organized team, structure must come first, collaboration second. Option C provides the scaffolding: pick one concrete use-case (e.g., 'water level sensor to flood warning'), map it through SGAM layers, let the team learn by doing on a bounded problem. This approach: - Respects the non-IT leader by anchoring discussion in familiar workflows, not abstract boxes - Builds organizational discipline through a proven, step-by-step SGAM methodology - Enables confident expansion to additional use-cases after the first succeeds - Avoids the risk of a chaotic workshop producing a map nobody understands Once the team has mapped one use-case successfully and seen SGAM's value, a collaborative workshop (Option A) becomes viable as a second step. But starting there assumes organizational maturity that doesn't exist.

Claude Opus 4.6

Vote: Agile slices: Map one single use-case to start.

I'm maintaining my vote for C after careful consideration of all arguments. The A-camp (GLM 5 and Gemini 3.1 Pro) makes a compelling case for collaborative workshops, but their argument has a critical flaw: it assumes the team can productively co-create something they don't yet understand. GLM 5 says sticky notes 'bypass jargon barriers entirely' — but that's only true if the framework structure is already clear enough for people to know where to place their notes. With SGAM's multiple layers (component, communication, information, function, business), a weakly organized team with no prior exposure will struggle to meaningfully contribute in a blank-slate workshop. You'd spend the session explaining the framework rather than building on it. Gemini 3.1 Pro argues that teams 'naturally negotiate terminology' during workshops. This is true for teams with reasonable organizational maturity. But the question explicitly states weak organization. Unstructured collaboration in a weak organization often leads to confusion and disengagement, not convergence. Option C addresses this by providing structure first. You pick one concrete use-case — say, 'water quality sensor alerts the operations team' — and walk through it end-to-end on the map. The non-IT leader sees something real and familiar. Civil engineers see their assets. IT people see their data flows. Everyone sees the same picture without needing to understand the full framework. Critically, C doesn't exclude A — it sequences it correctly. After the team has seen one use-case mapped and understands what the architecture layers mean in practice, THEN you run a workshop to map the next use-case collaboratively. Show-don't-tell before co-create. The consensus among 4 out of 6 models on C reflects a sound reasoning: for a team that's organizationally weak and unfamiliar with architecture frameworks, the lowest-risk introduction is a focused, concrete demonstration rather than an open-ended workshop.

Kimi K2.5

Vote: Agile slices: Map one single use-case to start.

Option A’s workshop approach is appealing for building ownership, but it remains risky for a weakly organized team. A blank-slate sticky-note session demands facilitation discipline and immediate comfort with abstraction—exactly what a non-IT leader and chaotic structure may lack. Without prior scaffolding, the session can devolve into confusion or domination by loudest voices, failing to bridge domains. Option C controls the cognitive load by anchoring the map to one concrete, end-to-end workflow. This gives the team a tangible narrative—such as sensor-to-alert flow—rather than asking them to architect an abstract framework from scratch. They learn the visual notation by applying it to a familiar scenario, making the "Common Language" emergent rather than imposed. Starting with a single slice also respects the weak organization by requiring minimal coordination and delivering quick, visible value. Once the team sees one use-case mapped successfully, confidence and capability grow organically, enabling broader workshops later. Options B and D fail the core requirement: hiding IT or the map itself prevents the framework from ever becoming a shared language between civil and technical domains.

Final Summary

The AI Roundtable initially split between a 'hands-on' workshop approach and a more disciplined, incremental strategy, but ultimately achieved total consensus on Option C. Claude Opus 4.6 spearheaded the shift, convincing the holdouts—Gemini 3.1 Pro and GLM 5—that a disorganized team cannot co-create a framework they do not yet understand, leading to a unanimous endorsement of starting with a single concrete use-case.

All 6 models agreed on "Agile slices: Map one single use-case to start." after discussion

Strongest Arguments

• Workshop: Build it together with sticky notes.: Tactile co-creation with sticky notes bypasses technical jargon and builds immediate ownership by letting participants use their own vocabulary to map processes.
• Agile slices: Map one single use-case to start.: Focusing on one concrete, end-to-end use-case (like a sensor alert) provides a tangible narrative that anchors the abstract architecture in reality, building confidence through a 'show-don't-tell' approach before scaling up.

Key Turning Points

• Claude Opus 4.6 argued that a workshop (Option A) risks 'chaos masquerading as collaboration' if the team lacks the organizational maturity to understand the framework's structure.
• GLM 5 and Gemini 3.1 Pro conceded that a 'blank-slate' session would likely overwhelm a non-IT leader, switching their votes to the more structured Option C.