MSA Complexity Guide
A guide to evaluate project suitability for AIDLC (AI-Driven Development Life Cycle) and determine ontology and harness strategies based on MSA difficulty levels.
Why MSA Complexity Matters
Simple CRUD vs Complex MSA
AIDLC is not uniformly applicable to all projects. The application approach must vary based on technical complexity and organizational readiness.
Simple CRUD Project Characteristics:
- Single service, single database
- Synchronous request-response patterns
- Clear transaction boundaries
- Simple rollback (DB transactions sufficient)
Complex MSA Project Characteristics:
- Multiple independent services, distributed data
- Asynchronous event-driven communication
- Distributed transactions (Saga, compensating transactions)
- Eventually Consistent data models
- Complex inter-service dependencies
AIDLC Application Differences
| Complexity | AIDLC Application | Ontology Level | Harness Level |
|---|---|---|---|
| Simple CRUD | Full immediate adoption | Lightweight schema | Basic Quality Gate |
| Synchronous MSA | DDD integration required | Standard ontology | Service contract verification |
| Async Events | Event schema ontology required | Full ontology | Event schema + idempotency |
| Saga/CQRS | Full AIDLC + expert required | Knowledge Graph | Compensating transaction verification |
Core Principles:
- Higher complexity requires more sophisticated ontology and harnesses
- Lower organizational readiness requires phased adoption
- Imbalance between technical complexity and organizational readiness risks project failure
AIDLC Difficulty Matrix
Evaluate Technical Complexity and Organizational Readiness on two axes to determine AIDLC application strategy.
Axis 1: Technical Complexity
| Level | Description | Characteristics | Examples |
|---|---|---|---|
| L1 | Single Service CRUD | - Single DB - Synchronous API - Simple transactions | User management service |
| L2 | Synchronous MSA | - Multiple services - REST/gRPC orchestration - Distributed DB | Order-Inventory-Payment MSA |
| L3 | Async Event-Driven | - Event bus - Eventually Consistent - Domain events | Event-sourced order system |
| L4 | Saga + Compensating Transactions | - Distributed transactions - Compensation logic - Orchestration/Choreography | Travel booking Saga |
| L5 | Distributed Tx + CQRS + Event Sourcing | - Read/Write separation - Event store - Complex projections | Financial trading platform |
Axis 2: Organizational Readiness
| Level | Description | Characteristics | Checklist |
|---|---|---|---|
| A | No Champion | - No AIDLC experience - No DDD experience - No ontology understanding | ☐ AIDLC training required ☐ POC project needed |
| B | Single Champion | - 1 AIDLC expert - Team training required - Guide-dependent | ☐ Verify champion capability ☐ Team onboarding plan |
| C | Team Experience | - Multiple AIDLC practitioners - Practical DDD experience - Ontology design capable | ☐ Team review process ☐ Best practice sharing |
| D | Org Standard | - Organization-wide AIDLC standard - Ontology reuse library - Harness templates | ☐ Org standard docs ☐ Reusable assets |
Difficulty Matrix (Recommended Application Strategy)
Color Legend:
- 🟢 Green (Ready): Full AIDLC application recommended
- 🟡 Yellow (Caution): Phased adoption or expert support required
- 🔴 Red (High Risk): High risk, proceed after sufficient preparation
- ⛔ Red (Not Recommended): Improve organizational readiness first
Go/No-Go Decision Tree
Flowchart for deciding whether to apply AIDLC to a project.
Decision Criteria
✅ Go (Proceed Immediately)
Conditions:
- Technical Complexity ≤ L3 AND Organizational Readiness ≥ B
- OR Technical Complexity = L4-5 AND Organizational Readiness ≥ C AND Expert support available
Actions:
- Apply full AIDLC
- Write ontology/harness
- Agent-based code generation
⚠️ Partial (Phased Approach)
Conditions:
- Technical Complexity ≤ L2 AND Organizational Readiness = A
- OR Technical Complexity = L3 AND Organizational Readiness ≤ B
- OR Technical Complexity ≥ L4 AND No expert available
Actions:
- Run POC project first
- Complete training program
- Secure expert support
- Phased AIDLC adoption
🛑 No-Go (Do Not Proceed)
Conditions:
- Technical Complexity ≥ L4 AND Organizational Readiness ≤ A
- OR Technical Complexity = L5 AND Organizational Readiness ≤ B
Actions:
- Improve organizational readiness (training, POC)
- Hire expert or engage consulting
- Re-evaluate after preparation complete
Risk Assessment Matrix
| Risk Factor | High 🔴 | Medium 🟡 | Low 🟢 |
|---|---|---|---|
| Technical Complexity | L4-5 | L2-3 | L1 |
| Organizational Readiness | A (No experience) | B-C (Some experience) | D (Org standard) |
| Data Sensitivity | Financial, Healthcare | Personal data | Non-sensitive |
| Project Scale | 20+ services | 5-20 services | 1-5 services |
| Timeline Pressure | < 3 months | 3-6 months | 6+ months |
Overall Risk Assessment:
- 3+ 🔴: No-Go
- 1-2 🔴: Partial (phased approach)
- 0 🔴: Go
Detailed Guides
📄️ L1-L2: Simple MSA
Application guide for Level 1 simple CRUD services and Level 2 synchronous MSA orchestration patterns
📄️ L3-L4: Async & Saga
Application guide for Level 3 async event-driven MSA and Level 4 Saga + compensating transaction patterns
📄️ L5: Event Sourcing
Application guide for Level 5 distributed transactions + CQRS + Event Sourcing patterns
📄️ Ontology Guide
Ontology depth and writing guidelines by MSA complexity level
📄️ Harness Checklist
Required harnesses and implementation guide by MSA pattern
📄️ Verification Methodology
Verification methods to ensure quality when applying AIDLC in complex MSA
Next Steps
- DDD Integration: Integrating Domain-Driven Design with AIDLC
- Ontology Engineering: Detailed ontology design guide
- Harness Engineering: Harness implementation best practices
- Adoption Strategy: Organization-wide AIDLC adoption roadmap