| name | technical-basics |
| description | Master technical domain knowledge - understand architecture, scalability, technical constraints, trade-offs, and implications. Use for feasibility assessment, design discussions, and communicating with engineering teams. |
| allowed-tools | Write |
| metadata | {"version":"2.0","claude-code":{"context":"fork","agent":"Explore","user-invocable":true}} |
Technical Basics for BA
You don't need to code. You need to understand trade-offs.
What is Technical Domain Knowledge?
Definition: Understanding how technology systems work, their constraints, scalability boundaries, and design trade-offs - enough to have smart conversations with engineers.
Why it matters:
- Unrealistic requirements: Asking for impossible things
- Missed constraints: Not understanding why engineer says "no"
- Bad prioritization: Not realizing feature X is 100x harder than Y
- Poor decisions: Technical trade-offs seem obvious to engineer, mystery to you
When to Use:
- ✅ Assessing feature feasibility
- ✅ Understanding technical constraints
- ✅ Evaluating architecture options
- ✅ Discussing scalability implications
- ✅ Making informed technical trade-offs
5 Core Technical Concepts
1. Scalability: The Numbers
How many users can system handle?
TYPICAL SCALABILITY JOURNEY:
10-100 users:
- Single server (everything on one machine)
- Database on same server
- Works great for MVP
- Cost: $10-50/month
100-1,000 users:
- Separate database server
- Load balancer in front
- Caching layer added
- Cost: $100-500/month
1,000-10,000 users:
- Multiple app servers
- Database read replicas
- Cache + CDN
- Microservices considered
- Cost: $1K-5K/month
10,000-100,000 users:
- Microservices architecture
- Database sharding (split data)
- Advanced caching strategies
- Dedicated infrastructure
- Cost: $10K-50K/month
100K+ users:
- Global distribution
- Advanced optimization
- Custom infrastructure
- Requires specialized engineers
- Cost: $100K+/month
Question to ask: "How many users do we expect at launch? In 1 year? In 3 years?"
This determines architecture choice.
See: references/scalability.md
2. Architecture: Build vs Buy vs Wait
Three ways to solve technical needs:
Build (Custom code):
- Best fit for unique needs
- Slowest to market
- Most expensive
- Ongoing maintenance burden
- Example: Custom CRM for your specific workflow
Buy (Third-party service):
- Fast to market
- Lower cost initially
- Limited customization
- Integration overhead
- Example: Stripe for payments, Twilio for SMS
Wait (Use what you have):
- Cheapest option
- Familiar to team
- May not scale well
- Technical debt grows
- Example: Use existing analytics instead of building new one
3. Technical Debt: Pay Now or Later
Every shortcut costs us later.
TAKING A SHORTCUT (Tech Debt):
Approach: Hardcode user permissions in code (quick, dirty)
Cost today: 1 hour instead of 4 hours
Cost later: When we need to change permissions, we change 50 files
DOING IT RIGHT:
Approach: Build permissions system (takes longer)
Cost today: 4 hours instead of 1 hour
Cost later: Easy to change, maintain, expand
Cost avoided: Refactoring nightmare
BA Perspective:
- Understand when team is taking shortcuts
- Document technical debt (interest compounds)
- Plan for paydown (like financial debt)
- Factor into timelines and budgets
4. Integration Complexity: Connecting Systems
Most projects integrate with existing systems. This is hard.
INTEGRATION DIFFICULTY LEVELS:
Level 1 - API to API (REST, GraphQL):
- Two systems talk via API
- Effort: 1-2 weeks
- Risk: Low
- Example: Our app calling payment processor API
Level 2 - Database Integration:
- Systems share database
- Effort: 2-4 weeks
- Risk: Medium (data consistency issues)
- Example: Old system needs to read new system's data
Level 3 - Legacy System Integration:
- Integrating with 20-year-old system
- Effort: 4-12 weeks
- Risk: High
- Example: New app needs to talk to mainframe system
Level 4 - Complex Data Sync:
- Systems need to stay in sync (two-way)
- Effort: 8-16 weeks
- Risk: Very high (inconsistency, conflicts)
- Example: Salesforce + custom system sync
Rule: Plan 3x longer for integrations than greenfield features
5. Testing: The Quality Equation
More testing = higher quality = higher cost
TEST PYRAMID:
/\
/ \ E2E (End-to-End)
/────\ 10 tests, 1 hour each
/ \
/────────\
/ / \ \ Integration
/ / \ \ 30 tests, 30 min each
/ / \ \
/──/──────────\──\
Unit Tests: 100 tests, 1 min total
FORMULA:
Code Coverage + Risk = Testing Effort
- Critical path (payments): 90% test coverage
- Nice-to-have feature: 60% test coverage
- Configuration: 30% test coverage
Common Technical Trade-Offs
Speed vs Quality
Fast Launch (3 months):
- Minimal testing (50% coverage)
- Some technical debt
- Launch quickly, gather feedback
- Risk: Quality issues, user frustration
Careful Launch (6 months):
- Comprehensive testing (90% coverage)
- Clean code, documented
- Polished at launch
- Risk: Missing market window, delayed ROI
Decision factors:
- Market timing (are we too late already?)
- Competitive pressure (will competitor beat us?)
- Reputational risk (is product quality critical to brand?)
Simplicity vs Features
Simple MVP (100K project):
- Core feature only
- Works well for 1,000 users
- Easier to understand/maintain
- Limits addressable market
Feature-Rich (500K project):
- 5 major features
- More complex, harder to maintain
- Serves more use cases
- Harder to get right
Monolithic vs Microservices
Monolithic (One codebase):
- Easier to build initially
- Faster to launch
- One failure takes down everything
- Easier to coordinate
Microservices (Multiple separate systems):
- Scalable (each service independent)
- Resilient (failure isolated)
- Complex to build/operate
- Need experienced team
Questions BA Should Ask Engineers
When exploring new feature:
- "Is this feasible? Rough effort?"
- "Any technical blockers?"
- "Does this require architectural changes?"
- "Will this impact scalability?"
- "How does this integrate with existing systems?"
When prioritizing:
- "Which is technically riskier, A or B?"
- "Which takes more time, A or B?"
- "Can we build A and B in parallel or sequential?"
- "Does building A make B easier or harder?"
When planning timeline:
- "How long is actual development vs testing vs integration?"
- "What are the critical path items (blocking others)?"
- "What can run in parallel?"
- "What's the biggest technical risk?"
Tools & Templates
- 📋 Technical Feasibility Assessment:
assets/feasibility-assessment.md
- 📋 Scalability Planning Worksheet:
assets/scalability-worksheet.md
- 📋 Integration Complexity Evaluation:
assets/integration-complexity-template.md
- 📋 Technical Risk Assessment:
assets/technical-risk-template.md
- 📋 Trade-off Analysis Template:
assets/tradeoff-template.md
Usage Examples
/technical-basics "scalability" "Do we need microservices for our use case?"
/technical-basics "integration" "How hard is integrating with Salesforce?"
/technical-basics "tradeoff" "Should we use our custom solution or third-party?"
BA Standards & References
Based on:
- Software Architecture: System design, patterns, scalability
- System Design: CAP theorem, consistency models
- Operations: Deployment, monitoring, reliability
- Engineering Economics: Cost of technical decisions
Detailed Frameworks:
- 📚
references/scalability.md - Scaling from 10 to 1M users
- 📚
references/architecture-patterns.md - Monolithic vs microservices vs serverless
- 📚
references/integration-approaches.md - APIs, databases, messaging, file transfers
- 📚
references/technical-risk.md - Identifying and mitigating technical risks
- 📚
references/tradeoff-framework.md - Making informed technical choices
