How to Design an SDK Business Model Diagram: A Step‑by‑Step Guide

Introduction

This piece originates from the SDK department’s design standards and examines how to construct a business model diagram that belongs to an SDK, focusing on business capabilities rather than just technical architecture.

Everyone is an architect – you have to do the architecture work yourself.

What Is a Business Model Diagram?

A business model diagram is the concrete visual expression of a business model. In other words, it is the equation: diagram = business model + visual representation.

Thus the problem reduces to: business model + expression.

What Is a Business Model?

The essence of a business model is to define the capabilities, responsibilities, and boundaries of a business through abstraction, aggregation, and classification.

The role of a business model is to help developers explain their domain succinctly, especially when communicating with product, R&D, and UI/UX teams or upstream SDK consumers.

Audience and Application Scenarios

R&D: understand capability decomposition and evolution logic, form internal consensus, and aid requirement assessment.

Product: grasp the division of labor among HMI, R&D, and UED, and evaluate requirement rationality and customer value.

How to Express?

After clarifying the content and purpose of a business model, the next question is how to express it visually.

What to Express?

The diagram should convey three core aspects:

Business Core : high‑level abstraction of key modules and future extensibility.

Basic Capabilities : reusable capabilities that ensure performance, quality, and development efficiency.

Integration Mode : SDK‑specific connection patterns that lower integration cost and provide personalized abilities.

Expression Forms

A single diagram should capture the entire architecture. The horizontal dimension selects a layered SDK business architecture, while the vertical dimension reflects capability depth.

The recommended layering (not exhaustive) includes:

HMI layer: SDK components that satisfy human‑machine interface requirements.

Business component layer: domain‑specific business encapsulation for different HMI scenarios.

Pattern/Framework layer: core business processes and capabilities.

Common ability layer: cross‑domain utilities required by the business.

Base library/engine layer: underlying engine or library capabilities.

How to Derive?

Derivation Principles

The derivation combines top‑down and bottom‑up approaches:

Top‑down: low barrier, starts from global requirements, reduces decision complexity.

Bottom‑up: higher barrier, starts from concrete problems, requires deep domain knowledge.

Combined: iteratively validate and adjust to keep the model self‑consistent.

Derivation Steps and Standards

The process consists of six steps:

Requirement collection

Capability decomposition

Capability definition

Capability classification

Capability layering

Data relationship mapping

These steps transform PRD into discrete capability items, then refine, classify, and organize them into a layered model.

Capability Decomposition

Decompose product PRD into atomic capability items by first extracting events, then breaking each event into indivisible capability sub‑items. The resulting list forms the “raw” capability items.

Event definition : an occurrence that significantly changes the domain state, such as “user registration succeeded” or “order paid”.

Capability Definition

Refine raw capability items by removing redundant modifiers, simplifying language, and preserving essential information. Two strategies are shown: minimal removal versus deeper pruning to achieve concise yet complete descriptions.

Capability Classification

After definition, the capability list is chaotic and needs ordering. Classification uses a minimum‑spanning‑tree clustering approach, prioritizing business‑specific rules over generic ones. The table below outlines the principles for business‑specific and generic classification.

Type

Principle

Definition

Business‑specific (high priority)

Business

Group capabilities according to existing business module classification.

Data

Group data capabilities according to module data classification.

Other

Apply module‑defined rules.

Generic (low priority)

Data – same entity

Group capabilities that operate on the same data entity.

Data – same operation

Group capabilities with identical data operation types.

Data – same scenario

Group capabilities used in the same scenario despite different data types.

Business – same attribute

Group capabilities of the same business type.

Business – same scenario

Group capabilities used in similar scenarios.

Capability Layering

After classification, establish hierarchical relationships (parallel, composition, dependency) to build a layered model. The classic SDK layering includes:

Business component layer – abstracts SDK integration capabilities.

Business pattern layer – core business processes.

Base ability layer – connects to engine/base libraries.

Data Relationship Mapping

Define what data flows between layers and how it moves (unidirectional, bidirectional). Identify producers and consumers, and specify data attributes and control types.

Evaluation Criteria for the Business Model Diagram

After the diagram is produced, repeatedly check the following dimensions:

Correctness : high requirement match and traceable change process.

Extensibility : satisfies current needs and adapts to future business changes.

Clarity : aesthetically pleasing, simple structure, and clear classification.