The difference between an architecture assessment that guides real decisions and one that produces generic recommendations comes down to the first conversation. Most consultants start with technical questions: what platforms are you using, how much data are you processing, what's your current stack?
They're asking the wrong questions.
After conducting dozens of architecture assessments across industries, I've learned that the most critical insights emerge from understanding the business context first. The PRISM methodology structures this intake around five specific questions that frame the entire assessment. Get these right, and the technical deep dive becomes focused and purposeful. Get them wrong, and you'll spend weeks documenting systems that don't matter to the organisation's actual challenges.
Question One: What decision are we trying to enable?
This isn't about the stated reason for the assessment. It's about the underlying decision that's been deferred until "we understand our architecture better".
Every assessment I've inherited that produced shelf-ware started with a vague brief: "We need to understand our data landscape". The assessments that led to real change started with a specific decision point: "Should we consolidate these three reporting platforms or invest in making them work together?"
The decision focus shapes everything that follows. If the organisation is choosing between consolidation and federation, the assessment needs to map data lineage patterns differently than if they're evaluating whether to rebuild their integration layer.
I always push for specificity here. "Better reporting" isn't a decision. "Whether to build executive dashboards in the existing platform or move to a new one" is a decision. The more concrete the decision, the sharper the assessment becomes.
Question Two: Who owns the data that drives this decision?
Data ownership reveals the political landscape that determines whether recommendations get implemented. Technical architecture is straightforward compared to organisational architecture.
This question uncovers the hidden complexity. The CRM system might be owned by Sales, but the customer master data that populates it could be managed by Operations, with Marketing maintaining their own version for campaign purposes. The person commissioning the assessment rarely controls all the relevant data sources.
I map ownership against the PRISM Input zone patterns during intake. Systems where ownership is unclear or contested typically require different integration approaches than systems with clear data stewardship. The assessment needs to account for these organisational realities from the beginning, not discover them during the technical analysis phase.
Question Three: What's the timeline for this decision?
Timeline pressure determines the scope and depth of the assessment. A decision that needs to be made in six weeks requires a different approach than one with a twelve-month horizon.
But timeline isn't just about urgency. It's about understanding what level of change the organisation can absorb. A comprehensive architecture overhaul might be technically optimal, but if the decision needs to be implemented before the next budget cycle, the assessment needs to focus on incremental improvements that can be delivered quickly.
This is where many architecture assessments fail. They recommend the perfect solution for a world where timeline and change management capacity are unlimited. The PRISM methodology explicitly considers implementation constraints as part of the assessment framework, not as an afterthought.
Question Four: What's worked and what hasn't in previous integration efforts?
Every organisation has attempted to solve their data integration challenges before. Understanding these previous attempts reveals patterns of success and failure that the current assessment must account for.
I'm not looking for blame or detailed post-mortems. I'm looking for patterns. Did the last three integration projects fail because of technical complexity, insufficient stakeholder engagement, or inadequate change management? Did the successful projects have common characteristics that can be replicated?
This historical context shapes the assessment recommendations. An organisation that consistently struggles with user adoption needs different solutions than one that excels at change management but struggles with technical implementation.
The PRISM Transform zone patterns are particularly relevant here. Understanding how the organisation has handled data transformation logic in the past - embedded in source systems, centralised in middleware, or distributed across multiple platforms - reveals preferences and capabilities that influence future architecture decisions.
Question Five: How will success be measured?
This question separates assessments that drive action from those that satisfy curiosity. If the organisation can't articulate how they'll know whether the recommended changes were successful, the assessment will lack the focus needed to drive implementation.
Success measures need to be specific and owned by someone in the conversation. "Better data quality" isn't measurable. "Reducing the time to produce monthly financial reports from five days to two days" is measurable, and someone in Finance can confirm whether it was achieved.
The success measures also influence the assessment methodology. If success is defined by user adoption of new reporting tools, the assessment needs to evaluate user experience patterns in the Interface zone. If success is defined by reduced data processing times, the focus shifts to Transform zone performance patterns.
How these questions shape the assessment
These five questions create a framework that makes the technical analysis purposeful. Instead of documenting every system and integration point, the assessment focuses on the architectural elements that influence the specific decision being made.
The questions also establish expectations with stakeholders. By clarifying the decision context upfront, there are fewer surprises when the recommendations don't address every possible improvement opportunity. The assessment stays focused on enabling the identified decision rather than attempting to solve every architectural challenge simultaneously.
When I review assessments that failed to drive change, they almost always suffered from unclear intake. The technical analysis was often competent, but it wasn't connected to a specific organisational need. The recommendations were generic because the framing was generic.
Making the intake process productive
These questions work best in a structured conversation with multiple stakeholders present. The person commissioning the assessment rarely has complete answers to all five questions, and the discussion often reveals assumptions that need to be validated.
I typically schedule two hours for the intake session and insist on having both technical and business stakeholders involved. The conversation reveals disconnects between what different groups expect from the assessment, and it's better to surface these misalignments early.
The intake session also establishes the assessment boundaries. By understanding the specific decision context, timeline constraints, and success measures, both parties have clarity about what the assessment will and won't address.
An architecture assessment that starts with these five questions won't necessarily be easier to conduct, but it will be more likely to drive real organisational change. The technical analysis becomes a means to an end rather than an end in itself, and the recommendations connect to decisions that someone actually needs to make.
Getting the framing right is what separates assessments that gather dust from those that guide action. See how PRISM structures the entire process: scottdudley.com/prism