← VAF·SA Framework
A technically sound solution that cannot be communicated to the people who must act on it has not completed the engagement. The design remains theoretical until it lands in the right room.
Module 5 teaches how to present the artefacts produced in Module 4 to every audience who needs to act on them. It teaches how to raise concerns without losing the room. How to hold a position under pressure without making it personal. How to read a room in real time and adjust without abandoning the position.
The foundation has been established in Module 2. Plain questions get real answers. Plain speech outperforms framework language in every room. The less you say, the more they hear. Module 5 applies those principles to the specific communication contexts an SA will encounter — the executive presentation, the technical deep-dive, the vendor negotiation, the project manager update, and the governance escalation.
The artefact should be presented before commentary is offered. Placing the Customer Impact Statement and allowing stakeholders to read it before elaboration consistently produces more substantive engagement than presenting it alongside explanation. You present the Architecture on a Page and let the room read it before you explain it. If the artefact is doing its job, the first sixty seconds of silence after you place it on the table is not awkward. It is working.
The same solution. The same artefacts. Five different rooms. In each room, the same plain language applies — but the entry point changes. The executive needs the outcome first. The technical lead needs the constraint first. The vendor needs the named assumption first. The project manager needs the dependency first. The governance body needs the decision first. Get the entry point wrong and the room closes before the artefact is placed on the table.
What They Care About
Cost. Risk. Timeline. Whether this will actually work this time. They have been promised solutions before. They have seen money spent and nothing delivered. Your credibility starts at zero and is built only through precise, honest, unhedged communication.
How to Enter the Room
Lead with outcome. Never lead with technology. State the problem in their language. State the solution in terms of what it fixes. State the risk in terms of what it costs to ignore. Place the CIS. Let them read it. Then speak.
Here is what we know, here is what we are recommending, and here is the decision we need from you by Friday. Everything is on this one page.
What Loses the Room
Any technical detail in the first five minutes. Framework references. Acronyms without definitions. Hedging language — "it depends", "we will need to investigate", "there are a number of factors." Executives are time-poor and have learned to filter noise. Noise is anything that is not the answer.
What They Care About
What exists. What must be preserved. What can change. What cannot. They have deep knowledge of the current state and they are protective of it — because they are the ones who will be called at 2am when something breaks. Respect the depth before introducing the change.
How to Enter the Room
Lead with constraints. Show the current state first. Speak in system boundaries and integration patterns, not in product names. Place the Architecture on a Page — middle zone first. Invite challenge. A technical lead who pushes back is engaged. One who goes quiet has disconnected.
I want to show you what we think the current state looks like and where we are proposing to change it. Tell me where we have got it wrong.
What Loses the Room
Presenting a target state without acknowledging the current state. Dismissing technical concerns as business decisions. Using vendor marketing language for technical decisions. Any sign that you have not understood the actual system before proposing to change it.
What They Care About
Closing the deal. Protecting the existing relationship. Avoiding technical scrutiny that might expose gaps between what was sold and what was delivered. Vendors are not neutral. Engage them as motivated parties — respectfully, professionally, and with full awareness that their interest and your client's interest are not always aligned.
How to Enter the Room
Lead with what you already know. You have read their documentation. You have independently verified their claims. You ask closed questions with named assumptions they must confirm or deny. Place the heat map. Name the cells that are red. Ask for written confirmation before the meeting ends.
My understanding from your published documentation is that data in this configuration exits the client environment to your infrastructure. Can you confirm that is correct, and if not, show me where the documentation is incorrect.
What Loses the Room
Open questions. Asking the vendor to explain their solution from scratch gives them room to navigate. Accepting verbal commitments without written confirmation. Allowing "we will follow up on that" to close a red cell. A red cell is never closed by a promise. It is closed by documentation.
What They Care About
Dates. Dependencies. Who is blocking what. What decision is needed to unblock delivery. They are managing a timeline and they need the architect to give them precise inputs — not architecture theory, not framework references, but: what is the next decision, who needs to make it, and what happens if they do not.
How to Enter the Room
Lead with the blocking dependency. What cannot proceed until what decision is made. One action owner per risk. One deadline per open item. Place the AoaP roadmap zone. Point to the phase where the dependency sits. Name the consequence of missing the decision deadline.
We cannot start Phase 2 until the data sovereignty question is answered. That decision belongs to the CISO. It needs to happen by the 15th or Phase 2 slips three weeks. I need you to get that meeting in the calendar today.
What Loses the Room
Architecture theory. Framework references. Design discussions that belong in a different forum. Any communication that does not give the PM a named action, a named owner, and a named deadline. The PM cannot do anything with "it depends." Give them the specific thing they need to move.
What They Care About
What changes for them. What breaks. What they will need to support that they have never supported before. What the rollback position is. They will live with this solution long after the architect has left the engagement. Their concerns are not obstructions — they are the operational reality the design must survive.
How to Enter the Room
Lead with what changes. What they do differently from next Monday. What breaks during the transition and what the fallback is. What training or documentation they need. Place the AoaP — bottom zone for the rollout sequence, right margin for operational risks. Ask what they are worried about and document every answer.
Here is what changes for your team from go-live. Here is what we have put in place to protect you during the transition. Here is who to call if something breaks. What have I missed?
What Loses the Room
Architecture diagrams without operational context. A solution that has not considered the support model. Any implication that operational concerns are less important than design decisions. Operations teams that do not trust the architect will create a hostile go-live environment. Earn the trust by taking their concerns seriously before deployment.
A concern raised verbally in a meeting is a concern that disappears when the meeting ends. A concern raised in writing, with a named owner and a named deadline, is a concern that stays visible until it is resolved or escalated. The architect who raises concerns verbally and accepts verbal reassurance is not protecting the engagement — they are protecting the relationship at the expense of the outcome.
Raising concerns is not confrontational. It is the job. Identifying risks and requiring decisions before those risks materialise is what separates effective practitioners from those who defer to social comfort.
1
Name the concern precisely
Not "there are some security concerns." Name the specific concern: the domain, the system, the risk, and the consequence if unresolved. A vague concern cannot be owned or actioned. A precise concern can.
The data sovereignty question for Domain 02 of the heat map is currently red. If data egress to the vendor's infrastructure proceeds without resolution, we are in breach of the agency's data classification policy.
2
Name the owner
A concern without an owner is not a concern — it is a floating anxiety. One person. Named. Responsible for resolving or escalating. Not "the security team." The CISO. Not "the vendor." The account executive by name.
This needs a decision from the CISO. I am assigning this to [name] as of today's meeting.
3
Name the consequence of inaction
What happens if this is not resolved by the deadline. Not hypothetically — specifically. The phase that slips. The risk that materialises. The approval that cannot be granted. The consequence must be real and specific or it will be ignored.
If this is not resolved by the 15th, Phase 2 cannot proceed and the project delivery date moves by at least three weeks.
4
Set the deadline
A specific date. Not "as soon as possible." Not "before Phase 2." A calendar date. Confirmed in the room. Written in the meeting record immediately. The deadline is what converts the concern from a discussion into an action.
I need written confirmation from [vendor name] that this cell can be closed by Friday the 15th. Can you confirm that works for you?
5
Put it in writing before you leave the room
A concern raised verbally and not documented is a concern that never happened. Email, meeting notes, or a formal risk register entry — but in writing, same day, sent to all relevant parties. The written record changes the dynamic. It removes the ability to claim the concern was not raised.
Following today's meeting, I am documenting the following open item: [concern, owner, deadline, consequence]. This will remain on the risk register until closed.
You never need to raise your voice to raise a concern. The concern is in the document. The document is the pressure. Your job is to place it precisely, assign it correctly, and follow up at the deadline. The volume of the conversation is irrelevant. The written record is everything.
Holding the line is not stubbornness. It is the discipline of maintaining a position that is supported by evidence under pressure from parties who have a vested interest in that position not being maintained. The vendor who needs the contract signed. The project manager who needs the phase to start. The executive who does not want to hear the timeline has moved. Holding the line protects the engagement from the interests of the room.
Abandoning a correct position under social or political pressure is not collaboration. It is a failure of the engagement. Agreement that contradicts evidence is not consensus. It is capitulation.
Do Not Do This
Arguing the Position
Repeating the concern louder. Adding more detail to convince. Debating the framework or the methodology. Appealing to authority. Getting defensive when challenged. These all signal uncertainty. The room reads defensiveness as doubt.
But as I said, the standard architecture methodology requires us to complete phase C before we can proceed, and the security implications here are significant because if you look at the diagram you will see that...
Do This Instead
Placing the Evidence
State the position once. Name the evidence. Offer to document the disagreement formally. Then stop. The formal record changes the dynamic. The person who wants to proceed over the architect's documented objection is now assuming personal accountability for that choice.
I understand the urgency. My position remains that Domain 02 needs to be resolved before we proceed. I am happy to document that we are proceeding over my architectural objection if that is the decision being made.
Do Not Do This
Making It Personal
Attributing the resistance to the person rather than the problem. Expressing frustration. Implying bad faith. Taking pushback as a personal affront. Any of these moves the conversation from the professional to the personal — and on that ground, the architect always loses.
We have been through this three times already. I cannot keep explaining the same risk to people who are not listening. This is exactly why the last attempt failed.
Do This Instead
Staying on the Problem
The problem is the problem. Not the person. Not the history. Not the politics. Return to the artefact. Return to the evidence. Name the specific risk. Name the specific consequence. Stay factual. Stay calm. Let the evidence carry the weight.
The risk is documented in ADR-003 and Domain 07 of the heat map. Both are available for review. The consequence of proceeding without resolution is [specific outcome]. That is the position.
The Power of Professional Silence
After placing a concern or holding a position — stop talking.
The practitioner who fills silence after stating a position undermines it. Silence signals that the position has been stated and does not require defence. It places the pressure on the other party to respond. It is not awkward. It is working.
The person who speaks first after the position is stated reveals their level of discomfort with it. That is useful information. Read it. Respond only to what is said — not to the discomfort behind it.
Decision Altitude collapse happens in meetings. An executive begins specifying technical implementation. A technical team negotiates business requirements. A vendor attempts to close a commercial commitment in an architecture review. The practitioner who allows these moments to pass without redirection owns the consequences — the business decision that got made without business authority, or the technical decision that locked out options the delivery team needed.
Redirection is not confrontation. It is a structural observation delivered in plain language. The goal is to move the decision to the correct room — not to win the argument about where it belongs.
The redirection is always about the decision, not the person. "This decision belongs in a different room" is a structural observation. "You shouldn't be deciding this" is a personal one. The first is professional. The second creates resistance. Use the first. Always.
Scenario 01
Executive making a technical decision
The executive sponsor has begun specifying which cloud services to use, which integration pattern to adopt, or which vendor product to select. This is a technical decision. It belongs at solution architecture altitude, not business altitude.
Say This
"That is exactly the right question — and I want to make sure it gets the right answer. The technical decision on [specific item] is one I need to take back to the architecture session with the technical team. What I need from this room is your confirmation on [the business outcome] — which gives us the authority to make that technical call with your intent clearly understood. Can we confirm that first?"
The executive's input is acknowledged. The decision is moved without being dismissed. The business outcome — which is theirs to decide — is kept in the room.
Scenario 02
Technical team negotiating business requirements
The technical lead or platform team is making scope decisions, re-interpreting business requirements, or accepting constraints that affect business outcomes — without business authority to do so.
Say This
"I want to make sure we are clear on what this room can decide. The technical approach to [item] is absolutely ours to resolve here. The question of whether [business requirement or constraint] still stands is a business decision — it belongs with [named business stakeholder]. I'll take that question back to them before we finalise this. Can we proceed with the technical design on the assumption it holds, and flag it for confirmation?"
The technical work continues. The business decision is not made without authority. The gap is named and assigned — not left open and unaddressed.
Scenario 03
Vendor attempting to close a commitment at the wrong level
The vendor is seeking sign-off on a commercial position, a scope commitment, or a delivery timeline in an architecture session — where no one present has commercial authority.
Say This
"I want to be direct with you. The people in this room can confirm the technical approach. The commercial commitment you are seeking belongs to a different conversation — with [named commercial authority]. I will make sure that conversation happens. In the meantime, I need you to confirm [the specific technical question] so we can continue the design work."
The vendor's request is heard. The authority boundary is named clearly. The technical work continues. The commercial question does not get answered by someone without the authority to answer it.
Scenario 04
Mixed-altitude room producing no decision
A room containing executives, architects, technical leads, and vendors is attempting to reach agreement on a decision that requires clarity about which altitude it belongs to before anyone can decide anything.
Say This
"Before we go further, I want to clarify what we are deciding in this session. There are two things on the table: [business outcome decision] and [technical approach decision]. The first belongs to [executive names]. The second belongs to [technical names]. I suggest we confirm the first in the next fifteen minutes, then the technical team takes the second from there. That way we do not have one conversation trying to make two decisions at once."
The room is structured. Both decisions get the right audience. The meeting becomes two focused conversations instead of one unfocused one.
In engagements involving a team of specialist architects — security, data, integration, infrastructure — the greatest communication risk is not what happens in the client room. It is what happens when two specialists from the same team offer contradictory positions in that room without realising they are doing so.
A security architect who raises a concern already resolved in the heat map. A data architect who challenges an integration pattern the solution architect has already confirmed with the technical lead. An infrastructure specialist who volunteers a constraint that contradicts the roadmap. None of these represent incompetence. They represent the absence of a pre-presentation alignment session. Internal misalignment becomes public misalignment. That costs more credibility than any technical error.
The client room is not the place to discover that your team has different positions on the same question. The pre-presentation session is. Run it. Every time. Even when the team is experienced. Especially when the engagement is complex.
Session Structure
The Pre-Presentation Session
Thirty minutes. Same day as the client session where possible. Every specialist who will be in the room. Four agenda items only:
1. Confirm the current state of each heat map domain — specialist by domain. Any change from the last agreed position is named before the client room.
2. Agree the narrative for the audience. What leads. What follows. What stays technical and what gets translated.
3. Name the designated voice per domain. When a question on security comes up — who answers it. When a question on data architecture comes up — who answers it. One voice per domain. No interruptions, no corrections, no additions from others unless invited.
4. Protocol for unanticipated questions. If a question arrives that nobody prepared for — one response only: "Let me confirm that and come back to you before end of day." Not a guess. Not a debate. A commitment and a timeline.
What Alignment Produces
One Position. One Room.
The client room receives a single consistent position from a team that has already resolved its internal disagreements. Questions go to named specialists who are prepared for them. Contradictions are eliminated before they occur rather than managed after they surface.
The session does not eliminate disagreement within the team. It ensures disagreement is resolved at the correct altitude — internally — rather than performed in front of the client.
Where genuine disagreement cannot be resolved before the client session, it is not taken into the room unresolved. It is converted into an open item with a named internal owner and a resolution timeline — and presented as such if it surfaces.
Presenting the CIS
Place. Pause. Listen.
Hand or display the CIS. Say: "This is the one-page summary of where we are and what we need." Then stop. Give the room sixty seconds to read it silently. The first question or comment tells you where the resistance is. Do not pre-empt it by explaining before it is read.
If no questions come after sixty seconds: "Is the decision required on page two clear?" That is the only prompt you need.
Presenting the AoaP
Zone by Zone. Audience by Audience.
Display the AoaP. Begin at the top zone for the executive audience: "The business objective is here." Move to the middle for the technical audience: "The solution structure is here." Move to the bottom for the delivery team: "The roadmap is here."
Ask each audience to confirm their zone is accurate before moving on. The disagreement that surfaces in this process is the most valuable information in the room.
Presenting the Heat Map
Name Every Red Cell Aloud.
Display the heat map. Read every red cell aloud, by domain name. For each one: "Domain 02 — data sovereignty. This is red. The owner is [name]. The deadline for resolution is [date]."
Do not allow the room to move past a red cell with a vague response. If the owner is unknown — name that too. An unowned red cell becomes a formal escalation item before the meeting ends.
In every one of the four engagement archetypes, the practitioner operated in an environment that was not set up for their success. The vendor was misleading. The organisation was withholding. The EA practice was absent. The practice manager was not engaged. The pressure was real and consistent.
The operating principle across all four cases was the same: never air dirty laundry. Never fight back. Discharge the work. This is not passivity. It is decision altitude applied to personal conduct. The practitioner who stays above the noise and does the job produces the artefact that speaks for them when the noise has stopped.
The practitioner who complains about the environment is asking the environment to change before they can work. The environment will not change. The practitioner who works anyway — who reads every document, runs every workshop, produces every artefact, and holds every line — changes the outcome without changing the environment. That is the VAF·SA operating posture.
Professional conduct is not about being liked. It is about being effective. The architect who maintains professional conduct in an adversarial engagement protects their position, preserves their credibility, and produces a record that outlasts the engagement. The architect who retaliates protects nothing and produces nothing.
Three rules. No exceptions:
I
Never complain about the engagement to parties inside the engagement
Complaining to the client about their own dysfunction signals that you cannot operate in dysfunction. Every SA engagement involves some level of dysfunction. If you cannot operate in it, you cannot operate. Raise concerns formally through the artefact. Never raise them informally through relationship.
II
Never fight the political environment directly
The political environment is the operating condition, not the problem to solve. Navigate it. The artefact navigates it better than any direct confrontation. A concern documented formally and unanswered is a political problem for the party who chose not to answer it — not for the architect who documented it.
III
Discharge the work and let the record speak
The artefact set is the evidence. The CIS, the AoaP, the heat map, and the ADRs collectively tell the story of the engagement — what was known, what was decided, what was raised as a concern, and what was left unresolved. That record survives the engagement. The politics do not.
ALL ARTEFACTS MUST HAVE BEEN FORMALLY PRESENTED AND ALL CONCERNS DOCUMENTED BEFORE MODULE 5 IS CLOSED
CIS presented to executive audience — placed, read silently, decision question confirmed. Response documented.
AoaP presented zone by zone — business zone confirmed by executive, architecture zone confirmed by technical lead, roadmap confirmed by PM. Disagreements documented.
Heat map presented with all red cells named aloud — owner assigned, deadline confirmed, formal record created for each red cell.
Vendor engagement completed under interrogation protocol — closed questions asked, written confirmations received or formally noted as outstanding.
All concerns raised in writing — named concern, named owner, named consequence, named deadline. Sent before end of day.
All positions held under pressure documented — any instance where the architect maintained a position over pushback is recorded in the risk register or meeting notes.
Operations and support audience briefed — what changes, what the rollback position is, what training or documentation is required. Their concerns documented.
Professional conduct maintained throughout — no complaints, no direct confrontations, all concerns channelled through artefacts and formal records.
Decision required from each audience confirmed — every party who needs to decide something has been told what that decision is, by when, and what happens if they do not make it.