Architecture is too slow. This is something I think most of us Architects have heard. Not because architects are slow, per se, I think it is because every architect describes things differently.
You can’t compare implementations if they’re described in incompatible languages. You can’t identify patterns if everyone uses different terms. Its a lot harder to build reusable technical components if requirements are written differently every time.
I needed a standardized way to specify what technology needs to DO. Independent of vendor or solution. Independent of architect. I couldn’t find one that worked, so I built one.
Full disclosure: I haven’t read every enterprise architecture book. Frankly, it is enough to keep up with the Business Architecture field and others that interest me. This might exist in TOGAF, ArchiMate, or some framework I haven’t encountered. If it does, tell me. I’d genuinely like to see it. But in my career, I haven’t found it in practice.
What follows is what I built because I needed it. It’s evolving. Not final. But useful.
The Problem: What vs How Gets Mixed Up
Business Capability Models describe what the business does – Order Management, Customer Service, Financial Reporting. But they don’t describe what technology needs to DO to enable those capabilities.
In my experience, what happens is that people want to add technical capabilities to the Business capability model. They putting “Document Generation” as well as “Risk Assessment” into the Business Capability model causing confusion.
Additionally, what I have observed is that technology requirements are written differently every time with no reuse, no patterns, just reinvention. They specify vendors instead of capabilities – “System shall use AWS” locks you in before you’ve evaluated alternatives.
It made me realise technical capabilities needed their own model. Separate from business capabilities.
What Technical Capabilities Actually Are
A technical capability describes what technology can do, independent of vendor.
Not “We use AWS.” Instead: “We need Cloud Storage capability.”
Not “We implement Azure API Management.” Instead: “We require API Management capability.”
The capability stays stable. The vendor can change. Think specification, not solution.
This isn’t developer requirements. Developers need user stories, API contracts, data models, test cases. Those come from business analysts and solution architects. Technical capabilities answer a different question: “What must the platform be able to do?” Not “What should the system do for this user story?”
Different layers. Both necessary. Not mixed together.
The Framework: 12 Core Domains
I’ve been developing a Technical Capability Model that organizes capabilities into 12 core domains, spanning everything from Data & Analytics through Emerging Technologies. Each domain breaks down into capability groups. Each group contains specific capabilities.
Three levels:
- Level 1: Domain (Data & Analytics)
- Level 2: Capability Group (Data Quality Management)
- Level 3: Specific Capability (Data Quality Rules Engine)
Each capability includes what it does and why it matters. Approximately 300 technical capabilities total.
[LINK: Technical Capability Model download]
The framework is freely available. Standardized specifications help everyone. If you find it useful, tell me how you’re applying it.
After I developed the model, for identifying what a system needed to be able to do, I realised the Technical Capability Model I had developed could be used for other things.
Domain-Specific Extensions
Standard technical capabilities apply everywhere – API Management, Data Storage, Workflow Orchestration. But some domains need specialized capabilities.
Banking needs SWIFT message processing. Healthcare needs HL7 message processing. Manufacturing needs supply chain integration capabilities. The framework extends with domain-specific capability groups while maintaining core structure.
Take the 12 core domains. Add your industry-specific extensions. Remove capabilities you’ll never use. The aim is standardization within a domain, without forcing every industry into the same mold.
Requirements vs Capabilities: The Distinction That Changes Everything
Here’s the problem with most requirements: they describe what the system needs to DO for this specific use case.
“System shall calculate price and applicable taxes for customer orders.” “System shall validate customer address against postal database.” “System shall generate contracts in PDF format.”
Those are use-case requirements. Specific to this project. Not reusable. Worse: they mix business logic with technical capabilities.
“Calculate price and taxes” is business logic. What technical capabilities could that potentially require?
- Business Rules Management (TC-8.2) – to apply pricing rules and tax calculations
- Data Processing & Preparation (TC-1.4) – to transform input data
- Data Aggregation (TC-1.4.3) – to sum price components
- API Management (TC-3.1) – if calling external tax calculation services
The Technical Capability Model forces clarity. You can’t write “System shall calculate price.” You have to specify which technical capabilities the system needs to be able to do that calculation.
Instead of: “System shall validate customer address” Write: “System requires: Data Quality Management (TC-1.5), API Management (TC-3.1) for postal validation service integration”
Instead of: “System shall generate contracts” Write: “System requires: Document Generation (TC-11.2), Template Management (TC-11.2.1), Multi-Format Output (TC-11.2.3)”
Now those technical capabilities are reusable. Next project needs document generation? Same capabilities, different templates, different use case.
The capabilities don’t change. The business application of them does.
Why This Matters: The Reuse Advantage
Traditional procurement:
Project A writes requirements: “System shall calculate prices with promotional discounts.”
Project B writes requirements: “System shall calculate shipping costs with volume discounts.”
Project C writes requirements: “System shall calculate subscription prices with tiered pricing.”
All three procurements specify rules engines. All three write requirements from scratch. No one realizes they’re buying the same capability three times.
Capability-based procurement:
All three projects identify: Business Rules Management (TC-8.2) required. Enterprise architecture says: “We’re procuring rules engine capability once.” Platform team evaluates vendors against standard capability requirements. Three projects use the same rules engine for different business logic. Specify once. Procure once. Reuse everywhere.
That’s not constraint. That’s clarity enabling efficiency.
Technical capabilities don’t constrain business logic. They enable it. “Calculate price and taxes” is business logic – different for every organization, often different for every product line. But the technical capability, Business Rules Management, is the same. Authoring rules, testing rules, versioning rules, deploying rules – that’s what technology needs to be able to DO.
WHAT rules you write? Business logic.
WHERE you write those rules? Technical capability.
Business teams define logic. Architecture teams specify technical capabilities needed to execute that logic. Procurement teams find vendors who provide those capabilities. Different responsibilities. Clear boundaries.
The Objections (Let’s Address Them Now)
If you’re an architect, you’re already thinking of problems with this approach. Let’s address them directly.
Objection 1: “You’re constraining how vendors solve problems”
No. We’re forcing clarity about what needs solving.
Without capability specifications: RFP says “System shall handle pricing and taxes.” Five vendors interpret that five different ways. One has no rules engine, hard-codes logic. One has sophisticated rules engine you’ll never use. Three have different rules engines with incompatible capabilities.
With capability specifications: RFP says “System requires Business Rules Management (TC-8.2) including Rules Authoring, Version Control, Rule Testing.” All vendors know exactly what’s required. They propose solutions that provide those capabilities. You evaluate HOW they provide them. Vendors compete on implementation quality, not interpretation.
You’re not constraining solutions. You’re clarifying requirements. Vendors still choose how to implement. You just specified what must work when they’re done.
Objection 2: “This is just another framework to maintain”
Fair. But you’re already maintaining something.
Either you’re maintaining inconsistent architecture documentation where every architect describes things differently, or you’re maintaining consistent documentation using a standard catalog. One enables comparison and reuse. One doesn’t.
Pick your maintenance burden.
Objection 3: “What if I need a capability that’s not in your catalog?”
Add it.
This is V0.5. It’s not complete. It’s not final. If you need a capability that doesn’t exist in the framework, that’s useful information. Either I missed something obvious (tell me, I’ll add it), you’ve found a domain-specific capability (extend the framework), or you’re confusing business logic with technical capability (happens often).
The catalog evolves through use. That’s the point of sharing it.
How You Might Use This
Vendor evaluation: List required technical capabilities. Evaluate which vendors provide them. Identify gaps before concluding the procurement. No more “we discovered this limitation after contract signing.”
Functional requirements: Specify capabilities, not solutions. Then choose solutions that provide those capabilities.
Current state documentation: Document which technical capabilities exist today. Identify gaps. Identify redundancies. Compare systems using common language. No more “we have three different things that do basically the same job but we can’t tell because they’re described differently.”
Platform design: Specify which technical capabilities the platform must provide. Teams build on platform capabilities. Clear boundaries between platform and applications.
Pattern recognition: If every architecture uses the same capability catalog, patterns become visible. “This type of module consistently requires these capabilities.” Patterns become reusable specifications.
Different architects still have different opinions. But now they’re disagreeing about the same things, using the same language. That’s progress.
What This Enables
Architecture reviews: Faster. Common language.
Vendor comparisons: Clearer. Same evaluation criteria.
Current state documentation: Comparable. Standard format.
Requirements: Portable. Capability-based, not solution-based.
Patterns: Reusable. Described consistently.
Architecture accelerates. Not by working faster, but by working with standardized, reusable specifications.
Get the Framework
The complete Technical Capability Model includes all 12 domains, approximately 300 capabilities, with descriptions and example technologies.
[LINK: Technical Capability Model download]
I’m sharing it because standardized specifications help everyone. If you find it useful, tell me how you’re applying it. If you find gaps, tell me what’s missing.
This framework evolves through use, not theory.
What Comes Next
This is a working framework. I’m testing it. Refining domains. Adjusting definitions. Adding capabilities I didn’t realize I needed.
Maybe someone will tell me this exists in chapter 7 of an enterprise architecture book I haven’t read. Great. Point me to it. But right now, this is what I built because I needed it.
Take this framework. Adapt it. Make it work for your context. Add your domain-specific capabilities. Remove what you don’t need. The value isn’t in my specific catalog. The value is in having A catalog that everyone where you work uses consistently.
Architecture needs standardized technical capabilities. Not to eliminate creativity. To eliminate rework.
When architects speak the same language, architecture accelerates. A Technical Capability Model is one way to provide that language.
This post is part of my Architecture Foundations series exploring systematic approaches to enterprise architecture. Read more at authorityrule.com/