Capability Mapping FAQ: Naming, Granularity, and Edge Cases

Definitive answers to the 27 questions every business architect encounters when building capability models

This FAQ addresses the practical challenges that surface when you're actually building capability maps — not the theory, but the real decisions you face when staring at a whiteboard or Capstera workspace. Assumes familiarity with basic business architecture concepts.

Capability Naming and Taxonomy

Should I name capabilities as nouns or verbs?: Always use nouns — capabilities represent what the organization can do, not activities it performs. 'Customer Onboarding' not 'Onboard Customers,' 'Risk Assessment' not 'Assess Risk.' This keeps capabilities distinct from processes and functions. The noun form also makes decomposition clearer — 'Customer Onboarding' naturally breaks down into 'Identity Verification,' 'Account Setup,' and 'Product Enrollment.' Avoid gerunds (-ing words) as they blur the line between capability and process.
How do I handle capabilities that span multiple business domains?: Place cross-cutting capabilities in the domain where they're most operationally controlled, then document dependencies through cross-mapping. For example, 'Customer Data Management' belongs in the Data domain even though Marketing and Sales depend on it heavily. Use your platform's relationship modeling to show these dependencies rather than duplicating the capability. If a capability truly has split ownership, consider whether you're actually looking at multiple related capabilities that should be decomposed.
When should I include 'Management' in capability names?: Include 'Management' only when the capability specifically involves governance, oversight, or strategic direction of something else. 'Portfolio Management' and 'Risk Management' are legitimate because they're about managing portfolios and risks. But 'Customer Management' is usually just 'Customer Service' or 'Customer Relationship Development.' The word 'management' should indicate a meta-capability that governs other capabilities, not just operational work involving that domain.
How specific should capability names be to my industry?: Use industry-standard terminology where it exists — 'Underwriting' in insurance, 'Claims Processing' in healthcare, 'Trade Settlement' in financial services. Generic names like 'Risk Assessment' lose meaning when practitioners need to map processes or identify gaps. However, avoid company-specific product names or internal acronyms. 'Mortgage Origination' works across banks; 'SuperLoan Processing' doesn't. Start with Capstera's industry capability maps to leverage proven taxonomies, then customize naming to match your organization's language.
What's the difference between 'Customer Service' and 'Customer Support'?: This depends on your organization's operational model, but generally 'Customer Service' encompasses the full spectrum of customer interaction capabilities, while 'Customer Support' focuses specifically on problem resolution and technical assistance. If your organization treats these as distinct functions with different systems and teams, model them separately. If they're organizationally integrated, use 'Customer Service' as the broader capability and decompose into 'Issue Resolution,' 'Account Management,' and 'Customer Communication.' The key is consistency with how your business actually operates.
Should I create separate capabilities for digital vs. traditional channels?: No — capabilities should be channel-agnostic. 'Customer Onboarding' remains the same capability whether it happens online, in-branch, or via mobile app. The channel variation appears in your operating model and process maps, not the capability model. Creating 'Digital Customer Onboarding' and 'Branch Customer Onboarding' as separate capabilities fragments your architecture and makes it harder to identify redundancies or gaps. Instead, use your capability-to-application mapping to show which channels for each capability.

Granularity and Decomposition Rules

How do I know when I've decomposed capabilities too far?: Stop decomposing when further breakdown would create capabilities that map to single applications or individual job roles. If your Level 3 capability can only be performed by one system or one type of employee, you've gone too far. Good Level 3 capabilities still have enough complexity to require multiple process steps or involve coordination between teams. For example, 'Invoice Generation' is appropriate granularity; 'PDF Creation' within invoice generation is too granular for most business architecture purposes.
Should all capabilities have the same number of decomposition levels?: No — decomposition depth should reflect business complexity, not organizational symmetry. 'Product Development' in a software company might need 4 levels, while 'Facility Maintenance' only needs 2. The goal is to reach a level where you can meaningfully assess maturity, identify gaps, and map to applications without over-engineering. Some domains are inherently more complex than others. Focus on making each level useful for decision-making rather than achieving visual balance.
How do I handle capabilities that seem to belong at multiple levels?: This usually indicates you're confusing scope with hierarchy. 'Data Analytics' might feel like both a Level 2 capability (enterprise-wide) and a Level 3 sub-capability of 'Marketing Intelligence.' Resolve this by creating 'Data Analytics' as a Level 2 capability, then using cross-mapping to show how 'Marketing Intelligence' depends on it. Don't duplicate capabilities at multiple levels — instead, model the relationships between capabilities that operate at different scopes.
What's the right granularity for mapping applications to capabilities?: Aim for Level 3 capabilities when mapping to applications — specific enough to be meaningful, broad enough to avoid one-to-one mapping. If every application maps to exactly one capability, your capabilities are too granular. If applications map to Level 1 capabilities only, you're too high-level for useful analysis. The sweet spot is where one capability might be supported by 2-4 applications, and one enterprise application might support 3-8 capabilities. This gives you the resolution needed for rationalization and investment decisions.
How do I decompose capabilities when my organization is still defining its operating model?: Start with a proven industry framework from Capstera's Store, then adapt based on your strategic priorities rather than current organizational structure. Don't let today's org chart drive your capability decomposition — you want a model that can survive reorganizations