MSA Complexity Guide (Enterprise)
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
The complexity-to-application mappings in the table below, and the Go/No-Go and readiness rules that follow, are team-level heuristics (illustrative starting points) that this guide proposes, not universal thresholds. Each organization should adjust them to its own domain risk and capability.
Table 1. AIDLC application, ontology, and harness level by complexity
| 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
Table 2. Technical complexity levels (L1-L5): description, characteristics, examples
| 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 |
CQRS, event sourcing, and distributed transactions are independent design choices that need not appear together. For example, you can apply CQRS without event sourcing, or use Saga-based distributed transactions without CQRS. The L1-L5 ordinal above is a rough proxy for overall complexity, not a dependency chain in which each level builds on the previous one.
Axis 2: Organizational Readiness
Table 3. Organizational readiness levels (A-D): description, characteristics, checklist
| 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)
Figure 1. Recommended application strategy matrix by technical complexity and organizational readiness
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.
Figure 2. Go/No-Go decision tree for whether to apply AIDLC
Decision Criteria
Every combination of technical complexity (L1-L5), organizational readiness (A-D), and whether expert support is available maps to exactly one outcome (Go/Partial/No-Go) in the table below. Every cell is covered exactly once with no overlap. Expert availability only disambiguates L4-C, L4-D, L5-C, and L5-D.
Table 4. Go/Partial/No-Go decision by technical complexity, organizational readiness, and expert support
| Technical Complexity | Readiness A | Readiness B | Readiness C | Readiness D |
|---|---|---|---|---|
| L1 | Partial | Go | Go | Go |
| L2 | Partial | Go | Go | Go |
| L3 | Partial | Partial | Go | Go |
| L4 | No-Go | Partial | Go if expert, else Partial | Go if expert, else Partial |
| L5 | No-Go | No-Go | Go if expert, else Partial | Go if expert, else Partial |
The action for each outcome is as follows.
Go (Proceed Immediately)
Apply full AIDLC, write the ontology and harnesses, and run agent-based code generation. Expert review is required for L4-5 Go cases.
Partial (Phased Approach)
Run a POC project first, complete the training program, secure expert support, then adopt AIDLC in phases.
No-Go (Do Not Proceed)
Improve organizational readiness through training and POC, hire an expert or engage consulting, then re-evaluate.
Risk Assessment Matrix
Table 5. High/Medium/Low criteria by risk factor
| Risk Factor | High | Medium | Low |
|---|---|---|---|
| Technical Complexity | L4-5 | L2-3 | L1 |
| Organizational Readiness | A (No experience) | B (Single champion) | C-D (Team/org experience) |
| 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+ High: No-Go
- 1-2 High: Partial (phased approach)
- 0 High: Go
Detailed Guides
L1-L2: Simple MSA
Application guide for Level 1 simple CRUD services and Level 2 synchronous MSA orchestration patternsL3-L4: Async & Saga
Application guide for Level 3 async event-driven MSA and Level 4 Saga + compensating transaction patternsL5: Event Sourcing
Application guide for Level 5 distributed transactions + CQRS + Event Sourcing patternsOntology Guide
Ontology depth and writing guidelines by MSA complexity levelHarness Checklist
Required harnesses and implementation guide by MSA patternVerification Methodology
Verification methods to ensure quality when applying AIDLC in complex MSANext 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