Business Problem Structuring and Case Frameworks Questions

A comparison matrix is a simple decision-analysis tool that lists options against evaluation criteria, assigns scores per criterion, applies weights to reflect relative importance, and computes weighted totals to rank options. As a Solutions Architect I use it to make transparent, repeatable trade-offs.

Example (scores 1–5, higher = better). Weights: Cost 0.4, Security 0.4, Implementation time 0.2.

• In-house: Cost 2, Security 5, Time 2
• Vendor A: Cost 4, Security 3, Time 4
• Vendor B: Cost 3, Security 4, Time 3

Weighted scores:

• In-house = 20.4 + 50.4 + 2*0.2 = 0.8 + 2.0 + 0.4 = 3.2
• Vendor A = 40.4 + 30.4 + 4*0.2 = 1.6 + 1.2 + 0.8 = 3.6
• Vendor B = 30.4 + 40.4 + 3*0.2 = 1.2 + 1.6 + 0.6 = 3.4

Interpretation: Vendor A scores highest (3.6)—best fit given these weights (cost and time favored moderately). The matrix makes assumptions explicit: weights reflect stakeholder priorities; scores reflect estimated performance.

Limitations and misleading scenarios:

• Subjectivity: scores and weights can reflect bias or incomplete data.
• Missing factors: omitting critical criteria (e.g., vendor lock‑in, support SLAs, compliance) skews results.
• Interdependent criteria: cost may affect security; independent scoring can misrepresent trade-offs.
• Scale sensitivity: choice of 1–5 vs 1–10 or nonlinear utilities changes outcomes.
• Hidden costs/risks: one-time migration effort or future scaling costs may be undercounted.

Mitigations: run sensitivity analysis (vary weights), add qualitative notes, include TCO models and risk-adjusted scores, and validate with PoC or vendor references before final decision.

Sensitivity analysis tests how the outputs of a decision (e.g., total cost of ownership, NPV) change when you vary uncertain inputs. For a solutions architect recommending a cloud migration, it helps quantify risk and show which assumptions drive the recommendation.

Example:

• Base model: 5‑year TCO comparing on‑prem vs. cloud. Inputs: migration one‑time cost $200k, annual cloud ops $120k, on‑prem ops $180k, discount rate 8%.
• Vary assumptions: migration cost ±30% ($140k–$260k), annual cloud ops ±25% ($90k–$150k), discount rate 4%–12%.
• Outcome: compute NPV/TCO under each combination. You may find that at base values cloud wins by $150k, but if migration cost >$240k or ops savings <$30k/year cloud is no longer favorable.

Which variables to stress:

• High impact/uncertain: migration effort/cost, annual run-rate savings, discount rate, hardware refresh timing, staffing costs, license migrations.
• Secondary: network egress, compliance remediation, training.

How to present findings:

• Start with a clear summary (recommendation and confidence level).
• Tornado chart ranking inputs by impact on NPV/TCO.
• Scenario matrix (best, base, worst) with NPVs.
• Breakout table showing threshold values where decision flips.
• Short narrative explaining key risks, recommended mitigations (phased migration, fixed‑price migration vendor, pilot) and monitoring triggers to re-evaluate.

This approach makes the recommendation data-driven and shows stakeholders where to focus de‑risking efforts.

Sections I would include (one page, skimmable with clear headings):

• Header: Solution name, customer, date, single-line value proposition.
• Customer problem: 2–3 bullets stating business drivers, data sources, pain points (latency, cost, scale).
• Constraints & assumptions: security, compliance, data residency, existing stack, team skills, SLAs.
• Solution options (brief): 2 alternatives (lift-and-shift analytics + BI; cloud-native data platform) with one-line pros/cons.
• Recommended architecture (diagram thumbnail + 3 bullets): core components (ingest, storage, compute, catalog, visualization), integrations, HA/DR pattern.
• Key benefits & KPIs: latency, cost reduction, time-to-insight, scalability.
• Cost estimate & licensing: high-level TCO bands (CapEx/OpEx), major cost drivers.
• Timeline & milestones: 0–3 months (Poc), 3–6 months (MVP), 6–12 months (rollout).
• Risks & mitigations: data quality, security, skill gaps + mitigations.
• Next steps & asks: decision points, pilot scope, stakeholders, budget sign-off.

Level of technical detail by audience:

• Sales: High-level value, options, benefits, timeline, asks. Minimal architecture jargon; focus on win criteria and decision points.
• CTO: Detailed architecture thumbnail, integration points, security/compliance, scalability patterns, data model implications, risk mitigations, estimated sizing and cost drivers.
• Procurement: Clear licensing and TCO bands, contract/SLAs required, third-party dependencies, payment/timeline milestones, and any long‑lead procurement items.

This keeps the brief actionable for sales while giving the CTO and procurement the specific technical and commercial details they need to progress.

Start by defining workload and metrics: active users = 10,000 DAU, peak concurrent users (PCU), requests per user per day (RPU), average session length, read/write ratio, payload sizes, and retention/traffic patterns (peak hour factor).

Estimate traffic:

• Use assumptions (documented): RPU = 20, PCU = 5% of DAU = 500, peak hour = 20% of daily traffic, avg request size = 50KB, responses = 100KB.
• Data sources: benchmarks from similar internal services, cloud provider reference architectures (AWS/GCP throughput per instance), open benchmarks (TechEmpower), and historical analogs from past projects.

Compute sizing:

• Calculate requests/sec at peak: (DAU * RPU * peak_hour_fraction) / 3600 → provision instances able to handle that RPS with measured RPS per instance from benchmark.
• Add CPU/RAM headroom: baseline + 30–50% safety margin; use instance types that fit CPU/memory profile and support autoscaling.

Storage sizing:

• Transactional DB: estimate writes/day = DAU * writes per user; retain hot data window (e.g., 90 days) + archival. Include index overhead (20–40%) and backups (snapshot retention).
• Object storage: total bytes = DAU * avg stored bytes per user * retention; account for replication and lifecycle policies.

Networking:

• Egress = peak RPS * avg response size * safety margin; include CDN for static content and caching hit-rate assumptions (e.g., 70% cache hit reduces origin bandwidth).

Safety margins & SLOs:

• Document SLOs (latency, availability). Use 30–50% capacity buffer for first release; plan autoscaling thresholds and cooldowns. Include cost vs. latency trade-offs.

Validation & iteration:

• Before launch: load-test with realistic traffic (k6/JMeter) including spike tests; tune autoscaling and DB sizing; capture telemetry and adjust.
• After launch: monitor real traffic, compare against assumptions, and run capacity experiments (canary scale, scheduled load tests). Feed observed RPU, PCU, and performance into updated estimates and refine autoscaling policies and instance types monthly for first quarter.

Deliverables: calculation sheet, assumptions log, runbook for scaling incidents, and cost projection with sensitivity analysis.

Start by clarifying scope and timeframe (e.g., 5-year TCO, number of users, required SLAs). Then use a scored, quantified framework across dimensions; produce both qualitative notes and numeric totals to aid decision-making.

Framework (columns: Dimension | On‑Prem | SaaS | Metric / Calculation)

• Licensing: one‑time license + maintenance vs. recurring subscription. Metric = present value (PV) of license + annual maintenance over timeframe.
• Maintenance & Ops: FTEs, infra costs, backups, patch windows. Metric = annual personnel + infra + tooling costs.
• Customization: dev hours × rate + upgrade impact. Metric = initial customization cost + annual change backlog cost.
• Upgrade effort: downtime risk, testing, regression. Metric = estimated hours per upgrade × hourly cost + lost-revenue risk.
• Security posture: control over data, encryption, auditability, compliance. Metric = residual risk score (1–10) translated to expected annualized risk cost.
• Support model: vendor SLA, escalation, included vs. premium. Metric = expected support spend + risk-adjusted downtime cost.
• Exit costs: data egress, replatforming, contract penalties. Metric = one‑time exit cost estimate.
• Vendor lock-in (quantify): compute Lock-in Index = PV(contractual dependency costs + custom code dependency + data migration cost + switching opportunity cost) / PV(total spend). Use scenarios: best/likely/worst.

Example (5-year PV): license+maintenance $1.2M, ops $800k, customization $300k, upgrades $150k, security risk $120k, support $60k, exit $200k → PV spend $2.83M; lock‑in numerator (custom+data migration+penalties) $650k → Lock‑in Index = 23%.

Deliverable: spreadsheet with rows for each item, assumptions cells (discount rate, FTE cost, hours), sensitivity analysis (change subscription rate +10%, migration cost ±30%), and a recommendation tying technical risk to business constraints (e.g., choose SaaS if Lock‑in Index <25% and security/compliance requirements met; choose on‑prem if control outweighs incremental TCO and lock‑in >40%).