Presentation Structure & Storytelling

Structuring the 45-minute CTA Review Board presentation with storytelling techniques, time management, and a business-first narrative.

Presentation Flow: Structuring the 45 Minutes

The Three-Act Structure

The presentation works as a story with a beginning, middle, and end that judges can recognize and follow.

Figure 1. Three-act presentation structure for the CTA Review Board. The opening establishes context, the architecture act walks through all seven domain artifacts, and the closing reinforces key decisions and risks for judges scoring the final impression.

Act 1: Opening (3-5 minutes) - Set the Stage

Goal: Prove understanding of the scenario and frame the problem like a senior architect briefing a CXO.

1. State the business context - summarize the company, its industry, and the key business drivers in 2-3 sentences
2. Identify the critical requirements - call out the top 3-5 requirements that shaped the architecture (both functional and non-functional)
3. Declare assumptions - any ambiguities resolved with explicit assumptions (judges respect this)
4. Preview the approach - one sentence framing the overall architectural philosophy for this scenario (e.g., “I’ve designed a platform-first solution with selective use of middleware for the high-volume integration requirements”)

Opening formula

“The scenario describes [company type] facing [core challenge]. The critical requirements driving my architecture are [1, 2, 3]. I’ve assumed [key assumption]. My approach prioritizes [architectural philosophy] because [reason].”

Act 2: Middle (25-35 minutes) - Walk Through the Architecture

Goal: Walk through each artifact with a clear narrative, tying every decision to a requirement.

Present artifacts in a logical flow. A proven sequence:

Order	Artifact	Time	What to Cover
1	System Landscape	4-5 min	All systems, their roles, interactions, and protocols
2	Data Model	4-5 min	Key objects, relationships, cardinality, LDV considerations
3	Integration Architecture	4-5 min	Data flows, sync/async, protocols, error handling
4	Security & Identity	3-4 min	Authentication, authorization, sharing model, portal security
5	Actors & Licenses	2-3 min	User types, license recommendations, access patterns
6	Role Hierarchy	2-3 min	Sharing model, territory management if applicable
7	Data Migration	2-3 min	Strategy, tools, sequencing, validation
8	Governance & DevOps	3-4 min	Environments, CI/CD, release strategy, testing
9	Project Risks & Mitigations	2-3 min	Top risks with concrete mitigation strategies

For each artifact, follow this pattern:

1. Identify the requirement - “This addresses the requirement for…”
2. State your recommendation - “I recommend…”
3. Explain why - “Because…”
4. Acknowledge trade-offs - “The trade-off here is…”
5. Note alternatives considered - “I considered X but chose Y because…”

The biggest mistake

Do not do “solution dumps” where the architecture is described without tying it to requirements. If judges do not know what a solution element addresses, they cannot score it. Every solution must tie to a requirement.

Act 3: Closing (2-3 minutes) - Summarize Key Decisions

Goal: Leave judges with a clear mental model of the architecture and its strengths.

1. Recap the top 3 architectural decisions and why they matter
2. Restate key trade-offs and why they were acceptable
3. Acknowledge top risks with mitigation strategies
4. Express confidence - “I believe this architecture addresses the core requirements because…”

The 12-Section Operational Structure

The Three-Act Structure above is a pedagogical framework that teaches HOW to think about presentation flow. The 12-section structure below is an operational checklist that specifies exactly WHAT to cover and WHEN. Both complement each other: the Three-Act guides narrative planning, the 12-section guides execution.

Validated across 13+ mock boards, this structure is used by successful candidates coached by Cloud Johann, FlowRepublic, and CTA Gang of Four.

#	Section	Time	What to Cover	Maps to Three-Act
1	Company Overview	0-2 min	Company background, project goals, timeline, key business drivers	Act 1: Opening
2	Org Strategy	2-4 min	Single vs multi-org decision with justification, multi-currency, translations	Act 1: Opening
3	Risks & Assumptions	4-5 min	Dependency risks, budget assumptions, key constraints, ambiguity resolutions	Act 1: Opening
4	Actors & Licenses	5-8 min	All user types, license types (Sales/Service/Community/Platform), cost implications	Act 2: Architecture
5	Role Hierarchy	8-12 min	Security model foundation - role tree, territory management, access inheritance	Act 2: Architecture
6	System Landscape	12-15 min	All systems, middleware (MuleSoft/ESB), SSO, integration layer with legends	Act 2: Architecture
7	Data Model	15-22 min	Standard/custom objects, relationships, LDV strategy, OWD overlay	Act 2: Architecture
8	Business Requirements	22-30 min	Requirement-to-solution mapping with justification for every key decision	Act 2: Architecture
9	Data Migration	30-35 min	Strategy, phases, tools, what to disable during load, validation criteria	Act 2: Architecture
10	Sharing & Accessibility	35-38 min	OWD settings, sharing rules, Apex managed sharing, FLS, restriction rules	Act 2: Architecture
11	Reporting	38-40 min	Standard reports, trending analytics, off-platform needs, forecasting	Act 2: Architecture
12	Project & Deployment	40-45 min	CI/CD pipeline, branching strategy, testing approach, governance, release plan	Act 3: Close

Why Role Hierarchy comes BEFORE System Landscape

Most candidates put System Landscape first because it feels like the natural starting point. The 12-section order puts Role Hierarchy first because the sharing model is foundational; it constrains every other design decision. Judges who have seen the security model first can evaluate all subsequent sections through that lens.

Section 11 (Reporting) is often forgotten

Many candidates skip reporting entirely or treat it as an afterthought. If the scenario mentions analytics, dashboards, forecasting, or data availability requirements, reporting MUST be addressed explicitly. Even a 2-minute overview shows judges it was considered.

Mapping the Two Structures

The two structures work together:

• Planning phase (180 min): Use the 12-section list as a BUILD checklist. Ensure content exists for every section.
• Presentation phase (45 min): Use the Three-Act narrative flow. Open with context (sections 1-3), walk through architecture (sections 4-11), close with deployment and risks (section 12).
• The 12-section order is not rigid. Adapt the sequence if the scenario demands it (e.g., if integration is the dominant domain, present System Landscape + Integration Architecture together before Data Model).

The 90-Second Diagram Rule

Practice presenting each diagram in under 90 seconds with a clear narrative arc:

“This diagram shows [what it represents]. The key decision here is [decision]. The trade-off is [trade-off]. This connects to [next diagram/requirement] because [reason].”

Time Management During Presentation

Figure 2. Pacing checkpoints for the 45-minute presentation slot. If the System Landscape and Data Model are not complete by minute 15, the candidate is behind and must drop detail on lower-priority artifacts to recover.

Pacing checkpoints

If you are not past the data model by minute 15, you are behind. Skip detail on lower-risk artifacts and summarize. If you are ahead of schedule at minute 30, use the extra time to address trade-offs. Do not pad with filler.

• Do not repeat yourself. Time is finite. Repeating elements wastes precious minutes.
• Be concise. Answers should be CC: correct and concise.
• Keep a mental clock. Know where you should be at the 15-minute and 30-minute marks.
• Do not read slides. Speak to the diagrams. Do not narrate bullet points.

---

Storytelling Techniques

The CTA presentation is not a technical document. It is an architectural narrative: the story of how an architecture solves a business problem.

The Business-First Narrative

Frame every technical decision in terms of business outcomes:

Instead of…	Say…
”I used MuleSoft for integration"	"The high-volume, real-time data requirements between the ERP and Salesforce led me to recommend middleware to ensure reliability and provide circuit-breaking capabilities"
"I chose Community licenses"	"Given the 50,000 external partner users who need limited case and knowledge access, Partner Community licenses provide the right capability at the right cost point"
"I added a CDN"	"To meet the 2-second page load SLA for the 15 global office locations, I’ve introduced a CDN layer to reduce latency for static assets”

The SACV Framework

Every architecture decision can be evaluated and presented through four lenses:

• Simplicity - Is this the simplest approach that meets the requirement?
• Appeal - Does this resonate with the business stakeholders?
• Change - How adaptable is this when requirements evolve?
• Value - What is the cost/benefit trade-off?

Story Arc for Each Decision

Each major decision can be presented as a mini-narrative following this arc:

Figure 3. Six-stage story arc for presenting each architectural decision. Applying this structure to every major decision ensures judges hear both the rationale and the trade-off, which are the two elements scored most heavily.

Connecting the Dots

The architecture should feel like an interconnected narrative, not isolated slides:

• “This data model decision connects directly to the integration pattern I showed earlier…”
• “The sharing model I designed here is driven by the multi-tenant portal requirement we discussed…”
• “This deployment strategy accounts for the phased rollout risk I identified in the governance section…”

---

Communication Domain Tips (Domain 7)

Domain 7 is independently scored and covers three objectives. It is assessed throughout both the presentation and Q&A; there is no separate “communication section.”

Objective 7.1: Articulate Benefits, Limitations, and Design Choices

• State the “why” before the “what” every time
• Use the format: “I recommend [X] because [business reason]. The limitation is [Y], which I mitigate by [Z]”
• Handle objections by first acknowledging the valid point, then providing reasoning
• Switch between languages: translate between business terms and technical terms naturally

Objective 7.2: Use Visualization and Documentation Tools

• Diagrams must be readable, not just correct, but clear to judges
• Use consistent notation: legends, color coding, and standardized shapes (the Salesforce Shape Library in Lucidchart)
• Label everything: every arrow, every system, every data flow
• Layer diagrams: start with the high-level context and drill down for technical audiences

Objective 7.3: Handle Unexpected Roadblocks

• When a judge introduces a new constraint, pause and assess the impact across the entire architecture, not just the immediate area
• When a mistake becomes apparent, correct it openly: “On reflection, a better approach would be…”
• When requirements conflict, identify the conflict explicitly and propose how to drive a decision with stakeholders

Communication Scoring Indicators

Judges assess communication as a whole. What separates pass from fail in practice:

Passing Communication	Failing Communication
Ties every solution to a requirement	Describes solutions without context
Proactively identifies trade-offs	Only mentions trade-offs when asked
Adapts when challenged with new info	Rigidly defends everything
Speaks concisely and stays on time	Rambles, repeats, or runs out of time
Diagrams are clear and well-labeled	Diagrams are cluttered or unreadable
Acknowledges gaps honestly	Bluffs or gives vague answers
Balances business and technical language	Speaks only in technical jargon

---

Body Language and Confidence

Non-verbal communication matters even in a virtual format. Judges can see the candidate on camera.

Virtual Presentation Best Practices

• Camera on, well-lit: position the camera at eye level with good lighting so judges can see facial expressions clearly
• Look at the camera when speaking, not at the slides. This creates eye contact with the panel
• Sit upright with open posture: leaning slightly forward conveys engagement
• Keep arms visible and open: crossing arms over the chest reads as closed off
• Gesture purposefully: use hand movements to emphasize points, but do not fidget
• Manage vocal delivery: speak at a measured pace, vary tone, project confidence
• Smile when appropriate, especially during the opening and when handling challenges calmly

Confidence Signals

• Pause before answering: deliberate pauses signal thoughtfulness, not ignorance
• Use definitive language: “I recommend” not “I think maybe we could”
• Own decisions: “I chose this approach because” not “This approach was chosen”
• Stay calm under pressure: if a judge pushes back hard, take a breath, restate the challenge, then respond
• Minimize filler words: “um,” “uh,” “like,” “you know”

Confidence Killers to Avoid

• Apologizing for your solution before presenting it
• Reading directly from slides or notes
• Speaking too fast when nervous (practice pacing)
• Avoiding the question and talking around it
• Defensive body language when challenged

The confidence formula

A good architect is confident and self-assured but honest about the limits of their knowledge. Confidence in delivery is half the battle.

Related Topics

• Q&A Strategies: defending decisions and handling judge challenges after the presentation
• Common Mistakes & Mock Boards: why candidates fail and how to practice
• The Big 3 Diagrams: the core artifacts you walk through during the presentation
• Artifact Process & Quality Standards: time allocation and diagram standards that support presentation flow
• Data Trade-offs: trade-off articulation patterns directly applicable to presentation storytelling
• Sharing Model: sharing is the most commonly failed domain; prepare extra depth here