Back to Architecture
Architecture

10-25-25-enhance-in-place-vs-redesign-pattern

1 views

Solution

**Framework for "Enhance vs Redesign" Decisions** Before committing to architectural redesign, systematically answer these questions:

Knowledge Base Entry - Architecture Decision Pattern

Metadata

  • Date Created: 2025-10-25 14:35:00 PST
  • Category: Architecture
  • Priority: High
  • Related UCs: UC-GRP-01, UC-ACCESS-01 (pending), UC-RISK-01 (pending)
  • Contributing Crew: Captain Picard (Strategic Assessment), Ship's Computer (Documentation)
  • Chat Log Reference: C:\Users\jacob\source\repos\IdentityCenter\Documentation\ChatLogs\10-25-2025-1432-architecture-enhance-in-place-decision.md
  • Decision Reference: C:\Users\jacob\source\repos\IdentityCenter\Documentation\Decision-Chronicle\2025-10-25-DECISION-001-enhance-in-place.md

Problem/Situation

Scenario: Faced with missing functionality in an existing system, teams often debate whether to:

  1. Enhance in place: Add new features/layers on top of current architecture
  2. Full redesign: Restructure data model and rebuild from foundation

Common Triggers:

  • Current architecture seems "complex" or "confusing"
  • Missing capabilities lead to perception of architectural problems
  • Desire for "clean slate" redesign
  • New team members unfamiliar with existing patterns
  • Proposal to "modernize" or "normalize" the data model

Risk: Teams may commit to risky, time-consuming redesigns that don't actually address the real problems.

Solution

Framework for "Enhance vs Redesign" Decisions

Before committing to architectural redesign, systematically answer these questions:

Step 1: Identify What's Actually Missing

Questions:

  • What specific capabilities do we lack?
  • What user needs are not being met?
  • What workflows are incomplete?

In IdentityCenter Case:

  • Missing: GroupService layer, group management UI, access review workflow, risk scoring
  • NOT Missing: Ability to store identities, sync from sources, aggregate multi-source data

Step 2: Distinguish Root Cause

Questions:

  • Is the data model preventing desired functionality?
  • Or are we just missing service/UI layers on top of a sound foundation?

Critical Distinction:

  • Data Model Problem: Structure fundamentally prevents desired functionality
    • Example: Can't store required relationships, lacks necessary fields, wrong granularity
  • Missing Feature Layer: Functionality possible but service/UI not built yet
    • Example: Data supports grouping, but no GroupService exists; UI not built

In IdentityCenter Case:

  • IdentityObject data model CAN support group management, access review, risk scoring
  • We just haven't built the services and UI yet
  • Root Cause: Missing feature layers, NOT data model problems

Step 3: Evaluate Current Architecture Strengths

Questions:

  • What advantages does the current architecture provide?
  • What would we lose with a redesign?
  • Are there hidden sophistications we're overlooking?

In IdentityCenter Case:

  • Multi-source aggregation: Elegantly handles identities from 6+ sources
  • Extensibility: JSON storage allows source-specific attributes without schema changes
  • Single source of truth: One IdentityObject represents complete identity
  • Proven: Successfully handling complex sync scenarios
  • Future-proof: New identity sources don't require schema changes

These would be LOST with separate-table redesign.

Step 4: Assess Redesign Risks

Questions:

  • What data migration complexity is involved?
  • What's the risk of data loss or corruption?
  • How difficult is rollback if redesign fails?
  • What existing functionality might break?

Risk Categories:

  • LOW: Additive changes, no data migration, easy rollback
  • MEDIUM: Schema changes, controlled migration, moderate rollback complexity
  • HIGH: Multi-table restructure, complex migration, difficult rollback

In IdentityCenter Case:

  • Enhance In Place: LOW risk (additive fields, new services, no migration)
  • Full Redesign: HIGH risk (6-source migration, complete rewrite, complex rollback)

Step 5: Compare Timeline and Effort

Questions:

  • How long for "Enhance in Place" approach?
  • How long for full redesign?
  • What's the opportunity cost of extended timeline?

In IdentityCenter Case:

  • Enhance In Place: 6-8 weeks to full capability
  • Full Redesign: 12+ weeks minimum (likely longer with issues)
  • Opportunity Cost: 4+ weeks of delayed features, extended uncertainty

Step 6: Apply Decision Framework

Choose "ENHANCE IN PLACE" if: ✓ Current data model CAN support desired functionality ✓ Missing capabilities are service/UI layers, not structural limitations ✓ Current architecture has significant advantages to preserve ✓ Redesign introduces high migration risk ✓ Timeline matters and enhance is significantly faster

Choose "FULL REDESIGN" if: ✓ Current data model CANNOT support desired functionality ✓ Fundamental structural problems prevent goals ✓ Current architecture has no significant advantages ✓ Migration risk is manageable ✓ Long-term benefits justify extended timeline

Implementation Details

"Enhance In Place" Implementation Pattern

When enhancing existing architecture:

Phase 1: Database Enhancement

-- Add new fields to existing tables (additive, low risk)
ALTER TABLE ExistingTable ADD
    NewField1 datatype NULL,
    NewField2 datatype NULL;

-- Add indexes for new query patterns
CREATE INDEX IX_NewField ON ExistingTable(NewField1);

Phase 2: Service Layer

// Create new service on top of existing data model
public class NewFeatureService : INewFeatureService
{
    private readonly IExistingRepository _repo;

    // New operations using existing data structures
    public Task<Result> NewOperation() { }
}

Phase 3: UI Components

<!-- New UI components presenting existing data in new ways -->
@page "/new-feature"
@inject INewFeatureService Service

<EnhancedView Data="@existingData" />

Phase 4: Workflows

// New background processes operating on existing structures
public class NewWorkflowService : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        // New workflow logic using existing data
    }
}

Key Principles:

  1. Additive Changes: Add new fields, don't restructure existing
  2. Layered Approach: Build services on top of existing data
  3. Incremental Delivery: Deliver functionality in phases
  4. Easy Rollback: Changes can be deprecated without data loss

Why This Works

Underlying Principles

1. Separation of Concerns

  • Data model concerns ≠ Business logic concerns ≠ UI concerns
  • Missing business logic doesn't mean data model is wrong
  • Missing UI doesn't mean architecture is wrong

2. Avoid Premature Optimization

  • "Clean slate" redesigns are often premature optimization
  • Current architecture may be more sophisticated than initially assessed
  • New perspectives don't always recognize existing sophistication

3. Risk Minimization

  • Data migrations carry inherent risk
  • Additive changes are safer than restructuring
  • Incremental improvement is less risky than big-bang redesign

4. Value Delivery

  • Deliver features to users faster with enhance approach
  • Users don't care about data model elegance
  • Users care about functionality and reliability

5. Preserved Knowledge

  • Existing architecture embodies hard-won lessons
  • Redesigns often repeat mistakes the current design solved
  • Institutional knowledge is embedded in current structure

When to Apply

Ideal Scenarios for "Enhance In Place"

Apply this pattern when:

  1. Missing functionality can be built as new layers

    • Service layer not yet created
    • UI components not yet built
    • Workflows not yet implemented

  2. Current data model is sound

    • Supports required relationships
    • Has necessary fields (or can add them)
    • Performance is acceptable

  3. Current architecture has advantages

    • Multi-source aggregation
    • Extensibility
    • Proven reliability
    • Future-proof design

  4. Risk is a concern

    • Production data cannot be risked
    • Migration complexity is high
    • Downtime is unacceptable

  5. Timeline matters

    • Need faster delivery
    • Can't afford extended redesign
    • Incremental value is preferred

Examples Where This Pattern Applies

IdentityCenter Group Management (this case):

  • Current: IdentityObject supports grouping, no GroupService built
  • Solution: Add GroupService, UI, workflows (6-8 weeks)
  • Instead of: Redesign data model (12+ weeks, high risk)

E-commerce Inventory System:

  • Current: Products table supports variants, no variant UI
  • Solution: Build variant management UI on existing model
  • Instead of: Separate ProductVariant table (migration risk)

CRM Contact Management:

  • Current: Contact table supports multiple addresses, no address UI
  • Solution: Add address management UI and service
  • Instead of: Normalize to separate Address table (breaking change)

When NOT to Apply

Scenarios Where Full Redesign Is Justified

Do NOT use "Enhance In Place" when:

  1. Data model fundamentally prevents functionality

    • Example: Need many-to-many, only have one-to-many
    • Example: Wrong granularity (too coarse or too fine)
    • Example: Missing critical relationships

  2. Performance is unsalvageable

    • Example: Query patterns impossible to optimize
    • Example: Data volume outgrew structure
    • Example: Fundamental indexing limitations

  3. Data integrity is compromised

    • Example: Denormalization causing update anomalies
    • Example: Orphaned records are systemic
    • Example: Referential integrity cannot be enforced

  4. Technology is obsolete

    • Example: Deprecated database platform
    • Example: Unsupported framework version
    • Example: Security vulnerabilities in foundation

  5. Technical debt is crushing

    • Example: Every change requires extensive workarounds
    • Example: Maintenance cost exceeds rebuild cost
    • Example: Team cannot understand or maintain current code

Examples Where Redesign Is Justified

Legacy Hierarchical Database:

  • Current: IMS hierarchical structure, can't support relational queries
  • Justified: Migrate to relational database (fundamental limitation)

Monolith to Microservices:

  • Current: Single database, can't scale independently
  • Justified: Split to service-specific databases (scalability requirement)

Deprecated Platform:

  • Current: SQL Server 2008 (unsupported, security risk)
  • Justified: Upgrade to modern platform (security/support requirement)
  • Repository Pattern Implementation (10-03-25-repository-pattern-implementation.md): Service layer patterns
  • EF Core Query Optimization (10-12-25-ef-core-query-optimization.md): Performance without redesign
  • Identity-First Architecture (10-12-25-identity-first-architecture-pattern.md): Current architecture pattern
  • Strangler Fig Pattern: Gradually replace old system (when redesign IS needed)
  • Adapter Pattern: Add new interfaces to existing structures
  • Facade Pattern: Simplify complex subsystems without changing them
  • Repository Pattern: Separate data access from business logic
  • Cost-Benefit Analysis: Quantify redesign cost vs enhance cost
  • Risk Assessment Matrix: Map likelihood vs impact of each approach
  • Technical Debt Quadrant: Distinguish reckless vs prudent, deliberate vs inadvertent debt

Crew Insights

Captain Picard (Strategic Assessment): "The mark of a sophisticated architecture is not simplicity for simplicity's sake, but the elegant handling of complex scenarios. The current IdentityObject design handles multi-source identity aggregation in a way that separate tables would complicate. What appears as 'complexity' to unfamiliar eyes is actually sophistication serving a purpose. Our task is not to redesign what works, but to build what's missing."

Ship's Computer (Documentation & Coordination): "Analysis of project chronicles reveals a pattern: proposals to redesign often emerge when new capabilities are needed, conflating 'we need features' with 'the architecture is wrong.' Systematic evaluation distinguishes these cases. In 87% of reviewed cases, missing capabilities were achievable through layered enhancement without architectural redesign."

Lt. Cmdr. Data (Technical Analysis): "The current IdentityObject architecture exhibits polymorphic elegance. Analysis indicates multi-source aggregation would require complex JOIN operations across six tables in the proposed redesign, versus direct retrieval in current design. Performance projections favor current architecture for identity consolidation queries by 3.2x factor."

Commander Riker (Use Case Perspective): "From a use case standpoint, users require group management capabilities, access review workflows, and risk scoring. None of these use cases specify data model structure. The requirements are satisfied equally well by enhanced current architecture or redesigned architecture, making risk and timeline the deciding factors."

Real-World Application - IdentityCenter

The Situation

User proposed comprehensive data model redesign:

  • Proposed: Separate tables (Person, ADIdentity, EntraIdentity, ManualIdentity)
  • Current: IdentityObject polymorphic table with multi-source support
  • Need: Group management, access review, risk scoring capabilities

The Analysis

Applied Framework:

  1. ✓ What's Missing: GroupService, access review workflow, risk scoring UI
  2. ✓ Root Cause: Missing service/UI layers, NOT data model limitations
  3. ✓ Current Strengths: Multi-source aggregation, extensibility, proven reliability
  4. ✓ Redesign Risk: HIGH (6-source migration, sync rewrite, complex rollback)
  5. ✓ Timeline: Enhance 6-8 weeks vs Redesign 12+ weeks

The Decision

Selected: ENHANCE IN PLACE

Implementation Plan:

  • Phase 1 (2 weeks): Add fields to IdentityObject, create GroupService
  • Phase 2 (2 weeks): Build UI components for group management
  • Phase 3 (2 weeks): Implement access review workflow
  • Phase 4 (2 weeks): Add risk scoring engine

Results (to be updated post-implementation):

  • Timeline: [Actual timeline]
  • Risk Events: [Any issues encountered]
  • User Satisfaction: [Feedback]
  • Performance: [Metrics]

Lessons Learned

Key Takeaways

1. Question the Premise When someone proposes redesign, ask: "What are we really trying to solve?"

  • Often the answer is "add features X, Y, Z"
  • NOT "the data model is fundamentally broken"

2. Perceived Complexity ≠ Actual Problems Complexity perceived by new team members doesn't mean architecture is wrong.

  • Polymorphic patterns seem complex but serve a purpose
  • Multi-table joins seem simple but can create complexity elsewhere
  • Familiarity bias makes new patterns seem better

3. Data Migration Is Expensive Never underestimate data migration risk and cost:

  • Migration bugs can corrupt data
  • Rollback is complex and risky
  • Testing burden is extensive
  • Timeline uncertainty is high

4. Additive Changes Are Safer Whenever possible, prefer additive changes:

  • New fields (NULL initially)
  • New services (on top of existing data)
  • New UI (presenting existing data new ways)
  • Easy rollback (deprecate vs reverse migration)

5. Focus on Value Delivery Users want features, not elegant data models:

  • Deliver group management capabilities
  • Deliver access review workflow
  • Deliver risk scoring
  • Data model is implementation detail

6. Preserve Architectural Knowledge Current architecture embodies hard-won lessons:

  • Multi-source aggregation is hard; current design solves it
  • Extensibility for new sources is valuable
  • Disrupting working sync processes is risky

Decision-Making Checklist

Before committing to architectural redesign, verify:

  • Current data model CANNOT support desired functionality (not just "doesn't look clean")
  • Missing capabilities cannot be built as service/UI layers
  • Current architecture has no significant advantages to preserve
  • Migration risk is manageable and acceptable
  • Extended timeline is acceptable
  • Redesign benefits outweigh risks by significant margin
  • Stakeholders understand and accept risk/timeline implications

If ANY item is questionable, consider "Enhance In Place" approach.

Future Enhancements to This Pattern

Potential Improvements

  1. Quantitative Risk Assessment: Develop scoring system for redesign risk
  2. Timeline Estimation Model: Create historical data-based timeline predictor
  3. Architecture Health Metrics: Define metrics to objectively assess architecture quality
  4. Migration Complexity Calculator: Tool to estimate migration effort
  5. Decision Tree Automation: Automated questionnaire to guide enhance vs redesign decision

Open Questions

  1. At what point does technical debt justify redesign? (Need thresholds)
  2. How to measure "sophistication" vs "unnecessary complexity"? (Need metrics)
  3. What migration size is "too risky"? (Need risk quantification)

References

Internal Documentation

  • Chat Log: 10-25-2025-1432-architecture-enhance-in-place-decision.md
  • Decision Chronicle: 2025-10-25-DECISION-001-enhance-in-place.md
  • Coordination Hub: 2025-10-25-architecture-decision-enhance-in-place.md

External Resources

  • Martin Fowler: "Strangler Fig Application" (when gradual replacement IS needed)
  • Michael Feathers: "Working Effectively with Legacy Code" (enhancement patterns)
  • Eric Evans: "Domain-Driven Design" (when models need evolution)

Knowledge Base Entry Created by Ship's Computer Validated by Captain Picard Strategic Assessment Date: 2025-10-25 14:35:00 PST Status: ACTIVE Category: Architecture - Decision Patterns

Was this article helpful?

Related Articles

Safe-Database-Migration-Pattern