How to Rigorously Evaluate Technical Solutions: A Leader’s Framework

1

Value Chain Overview

Technology is merely a tool; what we deliver is business capability. When evaluating a solution, the primary focus should be the business value stream from a product perspective, especially in micro‑service architectures where multiple systems integrate to provide services.

Marketing

Identify the target customers, the marketing plan, potential leads, how the product generates leads, and how performance is recorded.

Channel

Determine through which channels the product is delivered, whether the channels provide a consistent experience, if there is a unified user‑management system, and whether the product records channel interactions.

Product

Define the functional requirements needed to achieve business goals.

Risk

Explain how business risks are mitigated, e.g., approval rules for banking financing services, and consider privacy or authorization risks.

Operations

Identify operational channels, role assignments, manual intervention points, and opportunities for full automation.

Data

List the data generated during value realization, decide which data belong to a data‑mid‑platform for further exploitation, and specify key metrics that need quantitative tracking.

2

Business Model, Data Model, Technical Model

Technical leaders often cannot master every technical detail, but if the high‑level models are sound, the solution is controllable.

Business Model

Start with a BPMN diagram to align with business, illustrating coarse‑grained process nodes that later guide domain modeling. The BPMN should focus on business flow, not system integration.

Data Model

After the business model, design a data model without considering implementation details to avoid technical bias. Beware of creating anemic models; further study of DDD may be required.

Technical Model

A robust technical model should include:

Core functional nodes of the business process.

Extension points where each node may change.

Design patterns applied to each node.

Overall non‑functional considerations (see author’s other articles for metrics).

External API interfaces.

With these elements, the solution’s direction and key implementation points become clear and manageable.

3

Data Thinking & Marketing Thinking & Operations Thinking

Completing the modeling steps yields a solid technical design, yet the ultimate delivery is business capability.

Data Thinking

Identify which data can be persisted for later analysis and performance measurement, and which dimensions are needed for reporting to leadership.

Marketing Thinking

Focus not on customer acquisition but on how to market the solution’s value, using the gathered data to showcase benefits to management and business units.

Operations Thinking

After design, ensure developers avoid “snowball” effects where a feature creates ongoing operational burdens. For example, follow the RQN principle in error‑code design, as discussed in the article on self‑operating mindset for developers.

4

Project Management

Once the solution design is complete, timely delivery must be guaranteed. This falls under project management; refer to the PMBOK guide for a detailed framework covering integration, scope, schedule, cost, quality, resources, communication, risk, procurement, and stakeholder management.

When a technical solution addresses all these aspects, it can be considered comprehensive, and technical managers can use this framework both for evaluation and for presenting proposals.