Assess Form

Eval current structural form — architecture, rigidity, pressure pts, capacity for change → transformation readiness pre-metamorphosis.

Use When

• Before significant architectural change → understand starting pt
• System feels "stuck" + reasons unclear
• External pressure (growth, market shift, tech debt) mounting + response uncertain
• Assess proposed transformation feasible given current form
• Periodic health checks long-lived systems (annual form assessment)
• Complementing

  adapt-architecture

  — assess first, then transform

In

• Required: System (codebase, organization, infrastructure, process)
• Optional: Proposed transformation direction (what system need to become?)
• Optional: Known pain pts or pressure srcs
• Optional: Previous transformation attempts + outcomes
• Optional: Time horizon for potential transformation
• Optional: Available resources for transformation

Do

Step 1: Inventory Current Form

Catalog structural elements no judgment — understand what exists pre-eval.

1. Map structural components:
   • Modules: distinct functional units (services, teams, pkgs, depts)
   • Interfaces: how modules connect (APIs, protocols, contracts, reporting)
   • Data flows: info movement
   • Dependencies: what depends on what (direct, transitive, circular)
   • Load-bearing: components everything else relies on
2. Doc form's age + history:
   • When each major component introduced?
   • Which changed recently vs static?
   • "Geological layer" structure (old core, newer additions, recent patches)?
3. ID "skeleton" vs "flesh":
   • Skeleton: structural decisions extremely costly to change (lang, DB, deploy model)
   • Flesh: functional decisions easier to change (business logic, UI, config)

Structural Inventory Template:
┌──────────────┬──────────┬────────────┬───────────────────┬──────────┐
│ Component    │ Age      │ Last       │ Dependencies      │ Type     │
│              │          │ Modified   │ (in / out)        │          │
├──────────────┼──────────┼────────────┼───────────────────┼──────────┤
│ Auth service │ 3 years  │ 6 months   │ In: 12 / Out: 3  │ Skeleton │
│ Dashboard UI │ 1 year   │ 2 weeks    │ In: 2 / Out: 5   │ Flesh    │
│ Data pipeline│ 4 years  │ 1 year     │ In: 3 / Out: 8   │ Skeleton │
│ Config store │ 2 years  │ 3 months   │ In: 0 / Out: 15  │ Skeleton │
└──────────────┴──────────┴────────────┴───────────────────┴──────────┘

→ Complete structural inventory: components + ages + mod recency + dep profiles + skeleton/flesh classification. "X-ray" of current form.

If err: Inventory incomplete (components unknown/undocumented) → finding — form has opacity = transformation risk. Doc what you can, flag unknowns, plan discovery gaps.

Step 2: Map Transformation Pressure

Forces pushing change + forces resisting.

1. Catalog external pressures (demanding change):
   • Growth: current form can't handle increasing load
   • Market: competitors/users demand capabilities
   • Technology: underlying becoming obsolete/unsupported
   • Regulatory: compliance reqs current form doesn't meet
   • Integration: must connect w/ systems current form wasn't designed for
2. Catalog internal pressures (demanding change from within):
   • Tech debt: accumulated shortcuts slow dev
   • Knowledge concentration: critical knowledge in too few ppl
   • Morale: team frustration w/ current form
   • Operational burden: maintenance cost consuming dev resources
3. Catalog resistance forces (opposing change):
   • Inertia: existing form works "well enough"
   • Dep lock-in: too many things depend on current form
   • Knowledge loss risk: transformation may destroy institutional knowledge
   • Cost: transformation reqs investment uncertain return
   • Fear: previous attempts failed

→ Pressure map showing direction + magnitude. Pressure significantly > resistance → transformation overdue. Resistance significantly > pressure → transformation fails w/o first reducing resistance.

If err: Balanced picture (neither strong) → system may not need transformation — or analysis surface-level. Dig deeper: interview stakeholders, measure specific pain pts, project 12-18 months. What pressures intensify?

Step 3: Assess Rigidity

How flexible/rigid is current form — can bend or break?

1. Test interface flexibility:
   • Modules replaceable no cascading changes? (loose coupling = flexible)
   • Interfaces well-defined + stable? (contract clarity = flexible)
   • How many "god modules" exist (all depends)? (concentration = rigid)
2. Test data flexibility:
   • Data migration straightforward? (schema evolution tools, versioning)
   • Data formats standardized or bespoke? (bespoke = rigid)
   • How entangled is business logic w/ data structure? (entangled = rigid)
3. Test process flexibility:
   • Team ship changes quickly? (deploy pipeline health)
   • Test suite comprehensive? (safety net for change)
   • How many "don't touch" components exist? (forbidden zones = rigid)
4. Calc rigidity score:

Rigidity Assessment:
┌──────────────────────┬─────┬──────────┬──────┬──────────────────────┐
│ Dimension            │ Low │ Moderate │ High │ Your Assessment      │
├──────────────────────┼─────┼──────────┼──────┼──────────────────────┤
│ Interface coupling   │ 1   │ 2        │ 3    │ ___                  │
│ God module count     │ 1   │ 2        │ 3    │ ___                  │
│ Data entanglement    │ 1   │ 2        │ 3    │ ___                  │
│ Deployment friction  │ 1   │ 2        │ 3    │ ___                  │
│ Test coverage gaps   │ 1   │ 2        │ 3    │ ___                  │
│ "Don't touch" zones  │ 1   │ 2        │ 3    │ ___                  │
├──────────────────────┼─────┴──────────┴──────┼──────────────────────┤
│ Total (max 18)       │ 6-9: flexible         │ ___                  │
│                      │ 10-13: moderate        │                      │
│                      │ 14-18: rigid           │                      │
└──────────────────────┴───────────────────────┴──────────────────────┘

→ Rigidity score quantifies structural resistance transformation encounters. Flexible (6-9) → incremental. Rigid (14-18) → dissolution before reconstruction (see

dissolve-form

).

If err: Inconclusive (moderate score but unclear where real problems) → focus highest-scoring dims. System can be flexible overall but 1 extremely rigid component blocks transformation. Target that specifically.

Step 4: Estimate Change Capacity

System + team ability to absorb + execute transformation.

1. Available transformation energy:
   • % team capacity allocatable to transformation?
   • Org support (budget, mandate, patience)?
   • Right skills (architecture, migration, testing)?
2. Change absorption rate:
   • How many changes per time unit no destabilize?
   • Recovery time post-significant change?
   • Staging/canary mechanism for incremental?
3. Transformation experience:
   • Team successfully transformed similar before?
   • Tools + practices (feature flags, strangler fig, blue-green)?
   • Risk tolerance?
4. Calc change capacity:
   • High: dedicated team, strong tooling, prior exp, org support
   • Moderate: part-time, some tooling, limited exp
   • Low: no dedicated, no tooling, no exp, resistant org

→ Change capacity assessment → can execute proposed transformation given resources + skills + org support?

If err: Low capacity + high pressure → first transformation isn't system — team capability. Invest tooling, training, org buy-in before architectural transformation.

Step 5: Classify Readiness

Combine pressure + rigidity + capacity → readiness classification.

1. Plot on matrix:

Transformation Readiness Matrix:
┌─────────────────┬────────────────────────┬────────────────────────┐
│                  │ Low Rigidity           │ High Rigidity          │
├─────────────────┼────────────────────────┼────────────────────────┤
│ High Pressure   │ READY — Transform now  │ PREPARE — Reduce       │
│ + High Capacity │ using adapt-architecture│ rigidity first, then   │
│                 │                        │ use dissolve-form       │
├─────────────────┼────────────────────────┼────────────────────────┤
│ High Pressure   │ INVEST — Build capacity│ CRITICAL — Invest in   │
│ + Low Capacity  │ first, then transform  │ capacity AND reduce    │
│                 │                        │ rigidity before change │
├─────────────────┼────────────────────────┼────────────────────────┤
│ Low Pressure    │ OPTIONAL — Transform   │ DEFER — No urgency,    │
│ + Any Capacity  │ if strategic value is  │ monitor pressure and   │
│                 │ clear, otherwise defer │ reassess quarterly     │
└─────────────────┴────────────────────────┴────────────────────────┘

2. Doc classification:
   • Label (READY / PREPARE / INVEST / CRITICAL / OPTIONAL / DEFER)
   • Key findings per dim
   • Recommended next step
   • Risk factors changing classification
3. READY →

   adapt-architecture

4. PREPARE →

   dissolve-form

   reduce rigidity
5. INVEST → build capacity (training, tooling, org support) + reassess
6. CRITICAL → address capacity + rigidity simultaneously (may need external help)
7. OPTIONAL/DEFER → doc + set reassessment date

→ Clear justified readiness classification + specific next steps. Enables informed decision about when + how to transform.

If err: Ambiguous (moderate pressure + moderate rigidity + moderate capacity) → default PREPARE — reduce rigidity incrementally while monitoring pressure. Builds capability + reduces risk whether or not full transformation eventually needed.

Check

• Structural inventory complete: components + ages + deps + types
• Transformation pressure mapped (external, internal, resistance)
• Rigidity score calc'd across all dims
• Change capacity assessed (resources, absorption, exp)
• Readiness classification determined + justified
• Next steps documented per classification
• Reassessment date set (even if currently READY)

Traps

• Assess only technical system: Transformation readiness includes organizational. Technically flexible system + org-rigid team still fails.
• Optimistic capacity estimation: Teams consistently overestimate capacity while maintaining normal ops. Use 50% of stated as realistic.
• Ignore resistance forces: Pressure mapping only cataloging change forces misses resistance slowing/stopping. Resistance often stronger than appears.
• Assessment paralysis: Form assessment hours to days, not weeks. Taking too long → system too complex to assess fully — higher abstraction + drill into problems.
• Confuse rigidity w/ stability: Rigid ≠ stable. Stability comes from well-designed flexibility; rigidity = absence of designed flexibility.

→

• adapt-architecture

  — primary transformation skill; assess-form determines readiness

• dissolve-form

  — PREPARE or CRITICAL → rigidity reduction before transformation

• repair-damage

  — systems needing repair before assessment meaningful

• shift-camouflage

  — surface-level adaptation may resolve pressure no full transformation

• forage-resources

  — resource exploration informs form assessment when "what should we become?"

• review-software-architecture

  — detailed technical architecture eval

• assess-context

  — AI self-application variant; maps structural assessment → reasoning ctx malleability, rigidity mapping, readiness