Architectural Challenge #3 - DSQ to deal with complexity under pressure
Welcome to this week's Architectural Challenge.
In last week's challenge you learned how to use Collect, Connect and Conclude to make rock solid decisions with detailed but ambiguous requirements.
But what if requirements complex and not very detailed, like during a whiteboard session or the CTA exam? When complexity hits and stress rises, most architects jump to "safe" technical solutions.
Today’s challenge only 10% of architects and CTA candidates nailed this during a recent workshop, because they committed one of the deadly sins of architecture and stayed locked in a surface-level technical perspective.
40% said Salesforce. 50% gave the textbook answer. Only 10% got it right.
The difference? They used DSQ—a method for dealing with complexity under pressure.
Distill business needs to their essence, simulate the solution, and quantify the real impact
DSQ-Method
Here's how to systematically work through complex requirements - top down.
- Distill - Cut through the noise and find the essence
- Simulate - Decompose the problem and map the flow end to end
- Quantify - Reveal real impact
The Challenge
PUB, a property development company, intends to implement Salesforce and consolidate seven legacy monitoring systems for smart fire and security devices into the system.
Given enough time and not being under pressure, the most obvious answer is: buy a product, don’t build.
But watch how the Distill-Simulate-Quantify systematically gets you there - instantly.
Step 1 - Distill - Cut Through the Noise
When faced with complexity, many miss the mark or get lost in details. So here's to counter it.
Condense the requirements into a single sentence that describes in simple terms your mental model of what the business needs.
This step is essential for you to gain clarity for what comes next.
“Seven different monitoring systems, disconnected, with no logic built into them. [...] hosted on-premises with publicly accessible web services that receive signals directly from the different sensors installed in the managed properties. PUB finds little value in these systems and would like to replace them with the new system, which will act as a unified platform to receive, interpret, and react to the different signals received [...]”
Replace seven legacy on-prem systems with a unified system to receive, interpret and react to signals from different fire and devices via web services. (System)
[...] data gathered from the sensors in the managed properties could reveal valuable business trends that can help PUB deliver a better and more efficient service. [...] analyze this data for the past 5 years to come up with valuable market trends.
Analyze past 5 years of sensor data to identify valuable business trends. (Reporting)
Notice how 100+ words became two clear needs. This clarity is the clarity you need for the next step.
Looks straightforward for Salesforce and Tableau CRM, right? This is where 40% of architects stopped and missed the mark. So let's keep going.
Step 2 - Simulate - Uncover the implications and components
Equipped with our simple high-level mental model of what the business is asking for, let's apply second-order thinking - simulating the full process step by step to uncover hidden implications and solution components.
This simulation step is what transforms a surface-level understanding into architectural clarity.
Key principle: Simplify ruthlessly. If you can't model it simply, you don't understand it fully.
- Sensor sends signal to monitoring API 24/7 -> Integration with high availability
- Sensor must be authenticated or at least verified -> Device storage & authentication
- Signal must be processed based to signal type and payload -> Automation with rules engine
- Certain signals might require alerts -> Notifications
- Trend analysis for past 5 years of signals -> Large data store & analytics engine
Assets, APIs, Authentication, Automation, Analytics—nothing Salesforce can't handle. Until you quantify.
Step 3 - Quantify - Ground the problem
Now that you have a conceptual understanding of what the business needs actually entail, you ground it in reality with facts (what would it take to build and operate):
“PUB manages around 100,000 properties worldwide. Each property has an average of 10 smart fire monitoring devices and security devices and sensors. [...] sends a status message at least every 30 seconds. PUB expects its portfolio of managed properties to grow by 10% every year over the next 5 years.”
Compliance:
Fire & security will require high availability and governance.
Volumne:
- 100,000 properties × 10 devices = 1 million devices
- Each device sends a signal every 30 seconds
- 10% annual growth over 5 years
The napkin math: 1 million devices -> 4.8 billion signals per day (yes, nine zeros).
Salesforce is out. 50% of the architects stop here and conclude: Heroku or AWS, because it seems obvious in the context of Salesforce.
And that's the trap - solving the technical problem without considering the impact for the business.
So what’s the impact?
Look at the sheer scale: 1M devices, 4.8B signals a day, no margin for error due to fire and security. This is no simple application. It requires:
- A dedicated team of IoT and hyperscale specialists
- 24/7 monitoring availability due to fire and safety sensor
- A massive infrastructure and staff investment to support this
Consider these second-order effects and the answer becomes obvious: building and maintaining a monitoring platform for security devices with a massive data store doesn't sound like a core competency of a property developer. It's a solved problem with existing products.
The story would be different if PUB's core business was security monitoring - but they build properties.
Wrap-Up
Yes, this ended up being a classic buy-vs-build decision. But without DSQ, 90% of architects missed it entirely because they were so locked in the technical perspective, because you could technically build it.
This systematic thinking - Distill, Simulate, Quantify - is what enables CTAs to evaluate complex technical decisions rapidly and get it right.
Want to be among the 10% who can think systematically under pressure and own any board - even the CTA Review Board?