Academy › SA Accelerator › Module 04

Communication & Governance

The best architecture that nobody understands or trusts doesn't get implemented. Solution architects in insurance IT operate across a wide audience — CTOs who need the strategic view, developers who need the technical detail, PMs who need the delivery implications, regulators who need the compliance evidence. AI helps produce the different translations. The SA ensures every version is accurate and consistent.

⏱ 30–35 min 3 knowledge checks Stakeholder communication, ARB, technical authority

SA Module

Your progress

Translating architecture decisions for different audiences

A Guidewire integration architecture has to be communicated to at least four different audiences who need fundamentally different things from the same content. The CTO needs the strategic implication and the risk profile. The development team needs the technical specification. The PM needs the delivery dependencies and timeline impact. The steering committee needs the business case and the go/no-go signal. AI can draft versions adapted for each audience efficiently — the SA must ensure every version is accurate and consistent with the others.

Audience

What they need from the architecture

What to avoid

CTO / VP Technology

Strategic fit, risk profile, technical debt implications, vendor and platform decisions, cost trajectory, and what they're committing the organisation to long-term

Implementation detail that doesn't translate to strategic decision — message queue depth, API timeout values, transformation layer technology choices

Development team

Interface specifications, data contracts, error handling expectations, component boundaries, what they're responsible for building, and every constraint that affects their implementation choices

Strategic framing that doesn't help them build — business rationale without technical specification, high-level diagrams without interface contracts

Project manager

Delivery dependencies, what must be completed before what, external team dependencies, timeline impact of architecture decisions, and what needs to be in scope vs. deferred

Technical depth that doesn't translate to schedule or resource implications — the PM needs delivery consequences, not architectural rationale

Steering committee

What's being approved, what it commits the organisation to, what the risk is, what the alternative was, and what the SA's recommendation is — in one page

Any technical detail. One-page executive summary with clear recommendation, risk level, and business implication

Regulator / auditor

Evidence of compliance with relevant standards — data handling, access controls, audit trail, data residency — with the specific regulatory reference attached to each control

Architectural rationale that doesn't speak to regulatory requirements — compliance evidence needs to map directly to the regulatory obligation

Prompt — audience-adapted architecture communication

Task I have a completed integration architecture for a Guidewire PolicyCenter-to-legacy-claims MQ integration. I need to communicate it to three audiences: the client CTO (strategic view), the development team (technical specification summary), and the steering committee (one-page approval summary). Generate a version for each audience from my architecture notes.

Architecture notes [Paste your architecture summary — pattern chosen, key components, constraints, tradeoffs, key risks, timeline dependencies]

Format Three separate documents. CTO version: one page, strategic framing, risk level, what we're committing to. Development team version: technical summary with interface contracts, error handling requirements, and implementation constraints — this can be longer. Steering committee version: half page, plain language, what's being approved, what it costs (time and resources), what the risk is, SA recommendation. I will verify all three versions for accuracy and consistency before distributing.

Knowledge Check

AI generates the CTO version of your architecture communication. It describes the MQ integration as "a low-risk, proven approach that reuses existing infrastructure." Your architecture documentation includes a known constraint: the 512KB message size limit that requires payload chunking for complex commercial policies, and a noted risk that the legacy system's MQ interface documentation is from 2019 and hasn't been validated against the current deployment. Should the CTO version mention these?

Correct — and the distinction between what to include and exclude is important. The 512KB constraint is an implementation detail that the development team must know and the CTO doesn't need to act on. The legacy system documentation risk is different: it means the SA is making a design commitment on a partially unvalidated assumption. The CTO is being asked to approve an architecture. If that architecture rests on an unvalidated interface assumption, the CTO needs to know — so they can understand the actual risk level and what the SA is doing to resolve it. "Low risk" without that caveat is inaccurate. "Well-established approach with one open validation item being resolved" is accurate and still appropriately reassuring.

Option 2 makes the right distinction. Excluding the documentation risk entirely (option 1) means the CTO approves an architecture with a risk characterisation that isn't accurate. Including everything including the 512KB constraint (option 3) over-informs the CTO with implementation detail that doesn't affect their decision. Waiting to present until all risks are closed (option 4) may be the right approach in some cases, but the legacy system interface validation may take time, and the CTO may need to make a decision. Presenting with accurate risk characterisation and clear resolution status is the right approach.

Architecture review governance — running and preparing for ARBs

Architecture Review Boards exist to provide independent scrutiny of significant design decisions before they're committed to implementation. For an SA presenting to an ARB, thorough preparation is the difference between a productive review and a difficult one. AI can help prepare comprehensively — generating the questions the ARB is likely to ask, identifying the weakest parts of the design that reviewers will probe, and structuring the presentation for a technical review audience.

Prompt — ARB preparation

Task I'm presenting a Guidewire integration architecture to the client's Architecture Review Board next week. Help me prepare. The ARB consists of the client's enterprise architect, a security architect, and two senior developers who review all major integration decisions.

Architecture summary [Paste your architecture summary]

Format 1) The 8-10 hardest questions this ARB is likely to ask about this architecture — from each reviewer's perspective (enterprise architect, security architect, senior developer). 2) The 3 weakest points in the current design that will draw the most scrutiny. 3) For each weak point: what I should prepare to defend, what I should concede if pressed, and what mitigation I should propose. 4) Any architecture standard or principle this design may appear to violate — even if I have a good reason — that I should address proactively.

Knowledge Check

AI's ARB preparation identifies that your architecture doesn't implement a circuit breaker for the MQ integration — it assumes the MQ connection is reliable. The ARB preparation notes this as a weak point: "The security architect is likely to ask about failure handling and recovery." You haven't implemented a circuit breaker because the client's legacy system team told you their MQ infrastructure has 99.9% uptime. How should you handle this in the ARB?

Correct — proactive acknowledgment is stronger than reactive defence for two reasons. First, it demonstrates that you've done the thorough review the ARB is expecting. Second, it reframes the conversation from "the SA missed this" to "the SA identified this and here's the position." The circuit breaker question is also a legitimate architecture question: what happens to integration messages when the MQ connection fails? If the 99.9% claim isn't backed by an SLA, you may not want to commit to the design without the circuit breaker. Raising it proactively lets the ARB help you make that decision rather than discovering a gap you didn't address.

Option 3 is the strongest approach. Waiting to be asked (option 1) means the ARB discovers a gap you didn't address — which is the worst outcome in a review. Adding the circuit breaker without understanding whether it's necessary (option 2) may add unnecessary complexity. Preparing a defensive response (option 4) positions you as defending a decision rather than collaborating on the right one. An ARB is a review process, not an adversarial one — proactive identification of gaps you're aware of, with clear reasoning about your current position, is what makes the review productive.

Maintaining technical authority — when design gets challenged

The SA's technical authority is established and maintained through the quality of their reasoning, not their title. When a senior developer challenges a design decision, when a client's internal architect proposes a different approach, or when a vendor's technical team advocates for their preferred pattern — the SA who can articulate the reasoning behind their design clearly and acknowledge the merit in the challenge holds their authority. The SA who defends positions without engaging the challenge loses it.

🤝

Engaging challenges professionally

When a design decision is challenged, the first response should be to understand the challenge fully — what specifically is the challenger's concern, what alternative are they proposing, what constraint or consideration is driving their position? AI can help you prepare responses to anticipated challenges before they arise, framing your position and identifying where you should be open to adjustment.

📊

Evidence-based position holding

The SA holds a position when it's supported by the constraint set and the requirements. "I've chosen this approach because of these specific constraints — if any of those constraints don't apply in your view, I'd like to understand that" is a position that invites productive dialogue. "This is the standard pattern" is a position that invites its own challenge and doesn't actually defend the choice.

🔄

Knowing when to update the design

Technical authority includes the willingness to update a design when a better argument is made. The SA who says "that's a constraint I hadn't accounted for — let me revise the design to reflect it" demonstrates more competence than the one who defends a design against a valid constraint challenge. Authority isn't defending every decision; it's making and updating decisions with good reasoning.

📝

Documenting design challenges

Significant challenges to architecture decisions — and the outcome of those challenges — should be documented in the ADR. If the client's internal architect challenged your integration pattern and you updated the design, that exchange belongs in the ADR's context section. Future architects need to know the design was challenged, what the challenge was, and what the resolution was.

When architecture is overruled — the professional response

SAs working in insurance IT will, at some point, have an architecture recommendation overruled. The project timeline doesn't allow for the approach the SA recommended. The business has a vendor relationship that constrains the technology choice. The client's CTO has a strong preference that overrides the technical recommendation. How the SA responds to this situation defines their professional standing for the rest of the engagement.

The professional response when overruled

Make the recommendation clearly and document the reasoning. When the decision goes a different way, document that too — what the SA recommended, what was decided instead, and what the architectural implications of the alternative approach are. This is not passive-aggressive record-keeping. It's professional documentation that protects the client (they have the information they need to make an informed decision) and the SA (their professional advice is on record). The SA then implements the decided approach to the best of their ability — with the documented implications visible to anyone who reviews the ADR.

Knowledge Check

You recommend a phased data migration approach for the Guidewire implementation — personal auto first, commercial auto after data remediation is complete. The project sponsor overrules the recommendation and insists on a big-bang migration of all policies on the go-live date, citing the regulatory deadline and the cost of running two systems in parallel. You believe this creates significant production risk from the 8,700 policies with incomplete vehicle schedules. What is the professional response?

Correct — and the sequence matters. One more clear statement of the recommendation with the risk quantified is appropriate; repeated escalation after the decision is made is not. Documentation of the recommendation and the decision is professional practice, not record-keeping for blame. Designing the best possible implementation of the decided approach — including the validation and remediation plan — is the SA's obligation once the decision is made. Refusing to sign off is rarely the right professional response unless the approach creates genuine regulatory non-compliance that the SA cannot be party to. Disagreeing with a risk tolerance decision made by a sponsor with the authority to make it is not the same as being asked to do something unethical.

Option 3 describes the complete professional response. Accepting silently (option 1) without documenting the recommendation and the risk means the information the sponsor needed to make an informed decision isn't on record. Escalating to the steering committee (option 2) over the sponsor's head, after the sponsor has made the call, is a relationship-damaging move that should be reserved for genuine regulatory non-compliance, not risk tolerance disagreements. Refusing to sign off (option 4) is a high-stakes action appropriate for cases of genuine non-compliance, not for architecture recommendations that were overruled by an authorised decision-maker. Make the case clearly, document it, then execute the decision with full professional commitment.

Module summary

✅

Different audiences need different translations

AI adapts architecture content for CTO, development team, PM, steering committee, and regulators efficiently. The SA verifies accuracy and consistency across all versions. Strategic risks belong in every version appropriate to the decision being made — not filtered out for non-technical audiences.

✅

Proactive gap acknowledgment beats reactive defence

In ARB presentations, raising known weak points proactively with your reasoning is stronger than waiting to be challenged. It demonstrates thorough review and positions you as a collaborator in the review rather than a defender of a fixed position.

✅

Authority through reasoning, not position

Technical authority is maintained by engaging challenges with clear reasoning, holding positions that are constraint-backed, and updating designs when better arguments are made. Defending positions without engaging the challenge loses authority faster than conceding a valid point.

✅

When overruled: document, then execute

Make the recommendation clearly and quantify the risk. Document both the recommendation and the decision. Then execute the decided approach as well as possible. Professional obligation is to make risk visible and documented — not to block decisions made by authorised decision-makers.

One module left

Module 05 — Your AI-Augmented SA Practice — brings the pathway together. Daily habits for Guidewire implementation and enterprise architecture engagements, positioning for senior SA rates, and a readiness self-assessment across all five modules.

✓

Module 04 Complete

Communication & Governance is done. Continue to Module 05: Your AI-Augmented SA Practice.

Back to Pathway Continue to Module 05 →