A software component is a part of a system, not necessarily a product in its own right. Its size depends on the question being asked: a map of a business needs different granularity from a map of one capability. UI layers and backend APIs are architectural building blocks; unlike a complete product, they do not independently meet a customer need. section 5.2 section 6.4.1
Components become more useful to reason about when their relationships are visible. A Wardley Map builds value chains from components and their dependencies, starting with users and their needs. Because a change to one component can affect its dependents, the map can prompt questions about what else may need to evolve. section 5.2 section 5.4.2
To explore a set of components with colleagues:
- Set the map’s purpose and scope, identify users and needs, then build value chains and place their components along the evolution axis. section 5.2
- For a component whose position is uncertain, compare its characteristics with stages of evolution. Discuss conflicting judgments rather than forcing a supposedly correct answer. section 5.3.2
- Ask what a component knows about another: only a public contract, or details such as private methods and persisted state? More knowledge can make changes riskier. section 12.1
A product made of components
An advertising-campaign product can contain a customer UI and separate applications for creating campaigns, running and tracking them, and configuring rules. Those parts may be owned by different teams without each becoming a separate customer-facing product. Mapping their dependencies can make ownership and change conversations more concrete. section 6.1.6 section 6.4.1
Compare coupling types by integration strength to discuss how much one component knows about another and where changes may cascade. section 12.1
Component boundaries and positions are working judgments, not permanent labels. Revisit them as dependencies and practices evolve. For example, widespread internet access and collaboration tools helped remote working evolve; a change in one part of a value chain can alter what is possible elsewhere. section 5.3.2 section 5.4.2
