← VAF·SA Framework
Module 2 teaches you how to get the information you need from people who may not want to give it — without aggression, without authority, and without jargon. It is the most human module in the framework. It is also the most decisive. The architect who cannot gather real intelligence cannot design a real solution.
Using methodology vocabulary to demonstrate expertise is a common mistake. It consistently produces the opposite result — stakeholders disengage, and the information you need stays hidden.
Direct questions get direct answers. A vendor who deflects a complex technical question cannot as easily deflect a simple one. A stakeholder who avoids a formal requirements process will respond to a direct conversation.
The intelligence phase is not the moment to demonstrate expertise. Its purpose is to extract what you need for an accurate design. Ask precisely. Speak less. Listen more.
Pillar One
How to Think
Before you ask anything, know the shape of the answer you expect. You are confirming or exposing — not discovering. Every question is a hypothesis. Every response is evidence. Silence is evidence. Deflection is evidence. Confidence without documentation is evidence.
Know the shape of the answer before you ask the question. You are confirming or exposing — not discovering. That discipline cuts the number of questions in half and doubles what you learn.
Pillar Two
How to Talk
Short sentences. Plain words. No jargon unless it is the only precise term available. Speak to the person, not the room. Ask one question at a time. Wait for the full answer before asking the next one.
Silence after a question is not awkward. It is pressure. Let it work. The person who fills silence first reveals most.
Technical vocabulary as a substitute for substance signals uncertainty, not expertise. Precision and economy of language demonstrate mastery. Terminology does not.
In every room — executive, technical, vendor, operational — plain language wins. Faster. Cannot be deflected with counter-jargon. Signals confidence. Works on every audience simultaneously. No different register for the CFO and the DBA. Speak plainly to both.
Do Not Say This
"We need to align our stakeholder engagement model with the target state architecture and validate the NFRs against the current standard architecture methodology phase before we can progress the solution design."
Nobody knows what action to take next. The jargon performed intelligence without communicating anything. The room disengaged.
Say This Instead
"Before we design the solution we need three things from you. What the system actually does today. What it needs to do. And who signs off on the decision. Can we get those in this meeting?"
Three clear items. One question. Everyone in the room knows exactly what is being asked of them. The meeting has a purpose.
Do Not Say This
"We need to conduct a comprehensive as-is assessment, map the capability gaps against the to-be state, and produce an Architecture Decision Record before progressing to the solution architecture phase."
Sounds thorough. Communicates delay. Nobody outside the architecture practice knows what any of those things mean in practical terms.
Say This Instead
"I need to understand what you have, what you need, and what has been tried before. Give me two weeks. Then I will tell you exactly what the solution looks like and what it will take to deliver it."
Timeline committed. Outcome stated. No jargon. Executive can brief their board with those three sentences. That is the point.
The ten questions constitute a structured intelligence protocol, not an interview script or requirements template. The sequence is designed so that by the final question, the solution architect has established the information base required to proceed to design. The intent behind each question is as important as its wording. Both should be understood before the engagement session begins.
Why you ask this
The stated problem is rarely the real problem. The first answer tells you what they have prepared to say. The second answer — after you wait — tells you what they actually mean. Ask it. Wait. Ask it again differently if needed. The real problem is always simpler than the stated one.
What the answer tells you
A clear answer means they have done some thinking. A long answer full of technical detail means they are hiding the real problem behind complexity. No clear answer means no one has defined it — which means you will define it for them. That is power.
Why you ask this
Not "what is the project plan" — what does the business actually need to see. This surfaces the real success criteria before anyone has written a requirements document. It also reveals whether the business has any clarity about what they want. Often they do not. That is your entry point.
What the answer tells you
Vague answer — no one has defined success. You define it and confirm it back. Specific answer — there is already an expectation set. Find out who set it and whether it is achievable. Conflict in the room on this question — significant stakeholder alignment issue. Note it immediately.
Why you ask this
Every engagement has a history. Most of it will not be volunteered. This question forces it into the room. The answer also tells you who is in the room politically — the person who led the last failed attempt will respond differently to this question than the person who replaced them.
What the answer tells you
"Nothing" when you know something was attempted — deliberate withholding. Partial answer — test against the documents from Module 1. Detailed answer — someone wants you to understand the history. Listen carefully. They may be telling you where the politics sit without naming it directly.
Why you ask this
This is the most revealing question in the set. The stated reason for failure is always sanitised. "Budget" means someone did not prioritise it. "Resource constraints" means no one owned it. "Technical complexity" means the vendor could not deliver and the organisation accepted it. Translate the answer.
What the answer tells you
Confident answer with a clear cause — credible. Uncomfortable silence or a quick deflection to process — political. Multiple different answers from different people in the room — no shared understanding of what went wrong. That is Archetype 3 or 4. Act accordingly.
Why you ask this
Not the project owner. The operational owner. The person who will be accountable for this in twelve months. If no one can answer this, the engagement has no landing zone. A solution without an owner does not get implemented — it gets archived. Establish this before design begins.
What the answer tells you
Clear name given immediately — there is organisational commitment. Hesitation, deflection, or "that is still to be decided" — the politics of ownership have not been resolved. You cannot design a solution for an organisation that has not decided who is responsible for it.
Why you ask this
Not a systems inventory for documentation purposes. A dependency map for risk purposes. Every system that touches the solution is a potential failure point, a constraint, or a political boundary. Get the full picture in the room — not from a document written eighteen months ago.
What the answer tells you
Confident complete list — good technical understanding in the room. Partial list with qualifications — there are systems they do not fully control or understand. "It depends" — integration complexity has not been mapped. Add it to the heat map as amber immediately.
Why you ask this
This is the question that exposes Archetype 1. Data direction is the most frequently obfuscated element in any vendor engagement. Ingress versus egress. Internal versus external. What leaves the organisation and where it goes. This question cannot be answered vaguely. Name the flow. Name the destination.
What the answer tells you
Clear named data flows — credible. "The data stays internal" without documentation — verify independently before accepting. Any answer involving a third-party hosting solution — map it precisely. If the vendor hesitates on data direction, the heat map goes red on data sovereignty immediately.
Why you ask this
Security, compliance, regulatory, and contractual constraints. This question surfaces every hard boundary before design begins. It prevents the single most expensive mistake in solution architecture — designing a solution that cannot be approved. Know the constraints before you draw the first box.
What the answer tells you
Comprehensive answer — mature governance environment. Partial answer — governance gaps that will surface later as blockers. "Nothing that I know of" — go and find out independently. There are always constraints. The absence of a known constraint is not permission. It is a gap.
Why you ask this
Verbal commitments and written documentation are different things. What the vendor said in a meeting and what is in the solution paper are frequently not the same. This question forces the client to distinguish between what they were told and what they can prove. That gap is where risk lives.
What the answer tells you
All verbal, no documentation — the vendor has been managing relationships not producing evidence. Significant gap between verbal commitments and written documentation — the vendor is overcommitting. Go to the vendor's own published documentation independently and compare. That is your verification.
Why you ask this
This question does two things. It establishes the cost of inaction — which belongs in the Customer Impact Statement. And it changes the dynamic in the room. The people who have been comfortable with delay suddenly have to face what delay actually means. It is not aggressive. It is honest. And it accelerates decision-making.
What the answer tells you
Strong answer with real consequences — there is genuine urgency. You have a motivated client. Vague answer — the cost of failure has never been articulated. You are going to articulate it in the CIS. Silence — the room is uncomfortable. That discomfort is the beginning of ownership.
The 10 questions generate responses. Reading those responses — accurately, in real time, without projection — is the skill that separates the practitioner who designs the right solution from the one who designs the stated solution.
Response Type 01
Clear and Direct
The person answers the question asked. They provide specifics. They do not qualify excessively. They do not redirect.
Confirm. Document. Move to the next question. Do not over-interrogate a clear answer — it destroys trust and slows the room down.
Response Type 02
Deflection or Qualification
The person answers a different question. They over-qualify. They reference process or policy instead of substance. They look to someone else in the room.
Do not accept the deflection. Return to the original question. Simpler. More direct. "That is useful context — but what I need to know is..." Wait again.
Response Type 03
Silence or Absence
No answer. The question is skipped. The person defers. "We will need to check on that." The question produces discomfort with no resolution.
Document it as an open item. Assign an owner and a deadline in the room. An unanswered question is a heat map risk. Treat it accordingly.
Economy of speech during intelligence gathering consistently produces better outcomes than elaborated questioning. The interval between a question and a stakeholder's response is not conversational difficulty—it is pressure. The first party to fill that interval typically provides the most informative response.
Vendor engagement should not be treated as a neutral information exchange. Vendors operate from defined commercial interests that may not align with the client's architectural or operational requirements. A structured, methodical approach to vendor intelligence gathering—conducted respectfully but with a clear analytical framework—consistently surfaces a more accurate picture of proposed solutions than open-ended discussion.
Independent technical knowledge of a vendor's platform, documentation, and roadmap provides a significant intelligence advantage. Closed questions with named assumptions—which the vendor must confirm or correct—are structurally more effective than open-ended enquiries. Open questions create room for narrative management. Closed questions with stated assumptions require direct engagement with specific claims.
Read independently before you engage
Go to the vendor's published documentation, roadmap, and release notes before the first vendor meeting. Go through unofficial channels — community forums, third-party reviews, independent assessments. Arrive already knowing what their solution does and does not do.
I have reviewed your published documentation on Option 4. I want to confirm a few specifics with you directly.
Ask closed questions with named assumptions
Open questions give vendors room to navigate. Closed questions with named assumptions remove that room. State what you believe to be true and ask them to confirm or correct. A correction forces them to produce the real answer. A confirmation locks them to a position.
My understanding is that in this configuration, data leaves the client environment and is hosted on your infrastructure. Is that correct?
Name the data flow explicitly
Every vendor engagement involving data must produce a named, directional data flow statement. Ingress or egress. Internal or external. At rest or in transit. Where it goes. Who has access. Under what contractual and regulatory obligation. This is not negotiable and it is not technical detail — it is a business risk question.
I need you to confirm in writing — where does this data sit, who can access it, and under what terms.
Request the solution paper and POC results
If a POC has been completed, the results exist in writing. If a solution paper has been produced, it exists in writing. Ask for both. If they are not provided, note the non-provision formally. Documents that exist and are withheld are evidence. Treat them as such.
I understand a POC was completed. I would like to review the outputs. Can you share those before our next session?
Hold the line in plain language
When the vendor cannot answer a question on the heat map — do not accept a deferral. "We will follow up" is not an answer. Name the cell. Name the risk it represents. Name the deadline for resolution. Everything in writing. The formal record changes the dynamic immediately.
I need that confirmed before we proceed. I will note this as an open item with a response required by Friday. Can you confirm that works for you?
Every gap in the information you collect is a risk, an unresolved decision, or a deliberate withholding. None are neutral. Map each one before synthesis begins. Gaps not named become assumptions. Assumptions not validated become failures.
Gap Type 01
Absent Documentation
Documents that should exist do not. No requirements document. No security assessment. No vendor proposal in writing. No data classification. No architecture history.
Nothing has been done, or what was done has been withheld. Both are risks. Treat them the same way — as open heat map cells requiring a decision before design proceeds.
Gap Type 02
Contradictory Documentation
Two documents covering the same domain contradict each other. The requirements say one thing. The vendor proposal says another. The architecture diagram shows a third configuration.
An unresolved decision. Someone chose not to reconcile these. That choice was political. Find out who owns the contradiction and bring them into the workshop to resolve it.
Gap Type 03
Outdated Documentation
Documentation exists but predates significant changes — a vendor acquisition, a platform migration, a regulatory update, a change in organisational strategy.
A decision was made at some point. The environment changed. The decision was never revisited. It is now being treated as current when it is not. Verify before relying on it.
Gap Type 04
Timeline Voids
A period of the engagement history has no documentation. Six months passed and nothing was recorded. Work may have been done — or may not. There is no evidence either way.
Either nothing happened during that period — which is a cost and accountability question — or something happened that is being concealed. Ask directly about the period. The response is diagnostic.
Research across enterprise environments consistently finds that 30 to 40 per cent of applications running in any given organisation are absent from official records. Integration points are typically two to three times more numerous than teams have tracked. Data flows relevant to compliance obligations are frequently unmonitored — not from negligence, but because they were never visible.
Where automated discovery tools are available, they should be deployed before the first workshop session, not after. The output feeds directly into the strawman diagram and the heat map. What would otherwise take two weeks of document immersion and stakeholder questioning becomes a verified baseline that the workshop validates, corrects, and extends rather than builds from nothing.
The gap map produced by automated discovery tells you what the organisation thinks it has. The workshop tells you what it actually has. The difference between those two pictures is the most diagnostic intelligence available at the start of any engagement.
Where automated discovery is not available, the document immersion protocol and the ten questions serve the same function through human-driven extraction. The principle is the same: establish the real current state before design begins, not after.
ALL ITEMS BELOW MUST BE CONFIRMED OR FORMALLY DOCUMENTED AS OPEN BEFORE PROCEEDING TO MODULE 3
Ten questions asked and documented — responses recorded, response types classified (clear / deflection / absent).
All deflections returned and resolved — or formally noted as unresolved with named owner and deadline.
Vendor engagement completed — closed questions asked, responses documented, outstanding items listed in writing.
Independent verification completed — vendor claims checked against their own published documentation and unofficial sources.
Information gap map complete — all four gap types identified, classified, and added to heat map.
Data flow confirmed — direction, destination, access, and contractual basis documented in writing from vendor.
Constraints documented — security, compliance, regulatory, and contractual constraints named and confirmed.
Cost of inaction established — what failure means in time, money, and risk. Ready for the Customer Impact Statement.
All open items assigned — owner named, deadline confirmed, formal record created.