Part 036 — Architecture as Constraints, Evolutionary Design, Delivery Safety, and Distributed Decision-Making

Positioning

Architectural thinking bukan hanya membuat diagram atau memilih teknologi.

Architectural thinking adalah kemampuan untuk memahami bagaimana keputusan tentang:

• boundaries;
• data;
• contracts;
• deployment;
• ownership;
• failure;
• and change

memengaruhi delivery speed, quality, dan organizational flow.

Core thesis: arsitektur yang baik tidak hanya bekerja secara teknis; ia membuat perubahan aman, ownership jelas, dependency terkendali, dan team dapat mengambil keputusan tanpa menunggu satu architect atau senior engineer.

1. Architecture as Decision Structure

Architecture can be viewed as:

• significant decisions;
• constraints;
• boundaries;
• and trade-offs.

It shapes:

• what changes together;
• what can fail independently;
• what needs coordination;
• and who can own a capability.

2. Architecture versus Design

Architecture

Decisions with broad, long-lived, or costly-to-reverse consequences.

Design

Implementation choices within those boundaries.

The line is contextual.

A naming choice is usually design.

A data ownership choice is often architecture.

3. Architectural Thinking

Architectural thinking asks:

What boundary exists?
Who owns the data?
How does failure propagate?
What must remain compatible?
How is change deployed?
How is behavior observed?
How is the decision reversed?
Who must coordinate?

4. Quality Attributes

Common quality attributes:

• availability;
• reliability;
• performance;
• scalability;
• security;
• maintainability;
• testability;
• operability;
• deployability;
• compatibility;
• modifiability;
• and recoverability.

Architecture is a trade-off among these, not optimization of one.

5. Architecture and Product Context

Good architecture depends on:

• product strategy;
• customer expectations;
• scale;
• regulatory constraints;
• team capability;
• and change frequency.

A technically elegant design can still be wrong for the product.

6. Architecture and Delivery

Architecture affects:

• lead time;
• review scope;
• test scope;
• release coordination;
• failure blast radius;
• and recovery.

Example:

Shared database
-> coordinated schema changes
-> cross-team review
-> synchronized release
-> longer lead time

7. Change Coupling

Change coupling means components frequently need coordinated modification.

Sources:

• shared data;
• duplicated business rules;
• shared library release;
• tight API;
• synchronized deployment;
• and unclear ownership.

Measure actual change patterns, not only static dependencies.

8. Temporal Coupling

Temporal coupling exists when systems must be available simultaneously.

Synchronous calls often increase temporal coupling.

Asynchronous messaging can reduce it, but introduces:

• ordering;
• duplicate;
• consistency;
• and replay concerns.

There is no free decoupling.

9. Deployment Coupling

Deployment coupling occurs when multiple components must release together.

Mitigations:

• backward-compatible contract;
• feature flag;
• expand-contract;
• and consumer compatibility.

10. Data Coupling

Shared data can create:

• ownership ambiguity;
• schema coordination;
• security exposure;
• and hidden consumers.

A data boundary should answer:

• who owns writes;
• who defines semantics;
• and how others access it.

11. Organizational Coupling

If every change needs several teams, delivery flow suffers.

This may indicate mismatch among:

• team boundaries;
• domain boundaries;
• and system boundaries.

Architecture and organization influence each other.

12. Conway's Law

Systems tend to mirror communication structures.

Implication:

• if one capability spans many teams, coordination becomes architecture;
• if one team owns disconnected components, cognitive load grows.

Use as an observation tool, not a deterministic law.

13. Team Cognitive Load

A team can only hold limited complexity.

Cognitive load includes:

• domain;
• code;
• infrastructure;
• operations;
• and coordination.

Architecture should reduce unnecessary cognitive load.

14. Bounded Ownership

A team should ideally own a meaningful vertical capability, including:

• code;
• data;
• tests;
• deployment;
• and operations.

Ownership boundaries may not be perfect, but ambiguity should be explicit.

15. Component Teams versus Stream-Aligned Teams

Component team

Owns technical layer or component.

Risk:

• handoffs;
• queues;
• and local optimization.

Stream-aligned team

Owns customer or product flow.

Risk:

• duplicated platform capability;
• or excessive cognitive load.

The right topology depends on context.

16. Platform Teams

A platform team should provide:

• self-service;
• documented interfaces;
• reliability;
• and support model.

If consumers need manual tickets for routine work, platform dependency remains high.

17. Enabling Teams

An enabling team helps other teams acquire capability.

It should not become permanent approval gate.

Success means the receiving team becomes more independent.

18. Architecture as Guardrails

Guardrails define safe decision space.

Examples:

• additive APIs;
• one owner per data domain;
• feature flags for rollout;
• no direct cross-service database writes;
• mandatory observability for critical state transitions.

Guardrails enable autonomy.

19. Guardrail versus Gate

Guardrail

Provides rule and automated feedback.

Gate

Requires approval before proceeding.

Use gates for high-risk cases.

Use guardrails for repeatable safe decisions.

20. Architectural Decision Rights

Clarify:

• what teams can decide;
• what needs cross-team review;
• what needs security;
• and what needs architecture governance.

Ambiguity creates either risky autonomy or slow escalation.

21. Reversible versus Irreversible Decisions

Reversible decisions:

• feature flag;
• internal abstraction;
• temporary adapter.

Irreversible or expensive:

• data deletion;
• external contract;
• public API;
• customer migration;
• and organizational boundary.

Decision depth should match reversibility.

22. One-Way and Two-Way Doors

Two-way door

Can be reversed cheaply.

One-way door

Difficult or costly to reverse.

Use faster local decisions for two-way doors.

Use broader evidence for one-way doors.

23. Evolutionary Architecture

Evolutionary architecture supports incremental change through:

• fitness functions;
• modular boundaries;
• compatibility;
• observability;
• and controlled rollout.

It does not mean no upfront thinking.

24. Big Design Up Front versus No Design

Both extremes are risky.

Too much upfront design

• assumptions harden;
• feedback delayed;
• and scope expands.

No design

• hidden coupling;
• data ambiguity;
• and rework.

Use enough design to expose high-cost decisions.

25. Thin Architectural Slice

A thin slice validates:

• boundary;
• contract;
• deployment;
• observability;
• and failure.

Example:

• one tenant;
• one workflow;
• one downstream consumer;
• and one reversible rollout.

26. Architectural Spike

A spike should answer a decision question.

Example:

Can the existing event platform preserve ordering per quote under the required throughput?

Output:

• evidence;
• conclusion;
• and remaining uncertainty.

Not production code by default.

27. Fitness Functions

A fitness function automatically checks architecture characteristics.

Examples:

• contract compatibility;
• dependency rule;
• performance threshold;
• security policy;
• module boundary;
• and deployment independence.

Automation makes architecture executable.

28. Architecture Test Examples

• no direct dependency from domain to infrastructure package;
• event schema remains backward compatible;
• p95 below threshold;
• cross-tenant access denied;
• migration validation zero mismatch;
• and every critical state transition emits trace.

29. Architecture Decision Record

An ADR should include:

• context;
• decision;
• alternatives;
• consequences;
• and review trigger.

Architecture is a sequence of decisions, not a frozen diagram.

30. Architecture Review

A good review focuses on:

• assumptions;
• trade-offs;
• failure modes;
• migration;
• operations;
• and reversibility.

Avoid style-only or authority-only review.

31. Proportional Review

Low-risk reversible change:

• local team review.

Cross-service or public contract:

• broader review.

Security/data/irreversible change:

• specialist and governance review.

32. Architecture Review Bottleneck

Symptoms:

• all designs wait for one architect;
• review queue grows;
• teams avoid decisions;
• and architecture context remains centralized.

Mitigations:

• guardrails;
• decision taxonomy;
• templates;
• office hours;
• and delegated review authority.

33. Architect as Enabler

An effective architect or senior engineer:

• clarifies principles;
• helps teams reason;
• reviews high-risk decisions;
• and spreads capability.

Not every decision should require their approval.

34. Architecture and Sprint Work

Architecture work should be represented through:

• enabler;
• spike;
• migration;
• debt;
• reliability;
• or feature slice.

Avoid architecture as a separate abstract stream with no product consequence.

35. Architecture and Product Backlog

A good architectural backlog item states:

• problem;
• consequence;
• scope;
• evidence;
• and enabled capability.

Weak:

Implement target architecture.

Stronger:

Decouple approval-rule evaluation so customer-specific changes can release without coordinated updates across three services.

36. Architectural Debt

Architectural debt can include:

• unclear boundaries;
• cyclic dependency;
• duplicated ownership;
• shared database;
• and coordinated release.

Debt should be tied to:

• recurring cost;
• defect;
• or roadmap constraint.

37. Architectural Debt Interest

Interest appears as:

• slow changes;
• repeated defects;
• many reviewers;
• release coordination;
• and operational ambiguity.

Track actual interest.

38. Architecture Modernization

Modernization should be staged.

Possible sequence:

1. observe;
2. isolate;
3. introduce boundary;
4. migrate;
5. validate;
6. decommission.

Avoid rewrite as default.

39. Strangler Pattern

A strangler approach incrementally replaces behavior.

Steps:

• route a narrow capability;
• preserve compatibility;
• observe;
• expand;
• and retire old path.

Useful for legacy modernization.

40. Branch by Abstraction

Introduce abstraction before replacing implementation.

Benefits:

• incremental merge;
• controlled switch;
• and rollback.

Risk:

• temporary complexity.

41. Expand-Migrate-Contract

For schema/contract:

1. expand compatibly;
2. migrate consumers/data;
3. contract old path.

This reduces synchronized change.

42. Feature Flags

Feature flags support:

• incremental rollout;
• A/B test;
• kill switch;
• and deployment-release separation.

Need:

• owner;
• default;
• metric;
• and removal date.

43. Compatibility

Compatibility dimensions:

• backward;
• forward;
• data;
• protocol;
• and behavioral.

A schema can be syntactically compatible but behaviorally breaking.

44. API Evolution

Use:

• additive fields;
• optional behavior;
• tolerant readers where safe;
• explicit deprecation;
• and compatibility tests.

Avoid silent semantic changes.

45. Event Evolution

Event changes need:

• consumer inventory;
• replay behavior;
• enum handling;
• ordering;
• duplicate;
• and version policy.

Events are long-lived contracts.

46. Database Evolution

Safe database change requires:

• ownership;
• migration;
• compatibility;
• index/performance impact;
• validation;
• and rollback or containment.

Avoid destructive change before consumers migrate.

47. Data Ownership

A data owner defines:

• meaning;
• write authority;
• quality;
• lifecycle;
• and access.

Shared writes create ambiguity.

48. Distributed Transactions

Distributed transactions introduce:

• partial failure;
• retry;
• compensation;
• and consistency trade-offs.

Use explicit state and idempotency.

49. Saga Thinking

A saga coordinates multi-step operations through:

• local transactions;
• events/commands;
• and compensation.

Need:

• state visibility;
• duplicate handling;
• timeout;
• and recovery.

50. Idempotency

Idempotency prevents repeated requests from producing repeated side effects.

Design requires:

• key;
• scope;
• persistence;
• retention;
• and response replay.

It is a delivery safety mechanism.

51. Retry

Retry is not automatically resilient.

Unsafe retry can amplify:

• load;
• duplicate side effects;
• and cascading failure.

Need:

• idempotency;
• backoff;
• limit;
• and failure classification.

52. Timeouts

Timeouts should be explicit.

Too long:

• resource retention;
• slow failure.

Too short:

• false failure;
• unnecessary retry.

Timeout is a product and operational choice.

53. Circuit Breaker and Bulkhead

Circuit breaker limits repeated calls to failing dependency.

Bulkhead limits blast radius through resource isolation.

These patterns add state and operational complexity.

Use when evidence supports.

54. Eventual Consistency

Eventual consistency requires product semantics.

Questions:

• What temporary state is visible?
• How long is acceptable?
• Can user retry?
• How is reconciliation done?
• What is source of truth?

Do not hide eventual consistency as purely technical.

55. Observability as Architecture

Observability should be designed into boundaries.

Critical flows need:

• correlation;
• state;
• metrics;
• logs;
• traces;
• and actionable alerts.

Without observability, distributed architecture becomes opaque.

56. Failure Domains

A failure domain is the scope affected by a fault.

Architecture should aim to:

• isolate tenants;
• isolate workloads;
• and prevent cascading failure.

Blast radius is a design property.

57. Graceful Degradation

Graceful degradation preserves partial capability.

Examples:

• read-only mode;
• manual approval;
• cached reference data;
• or delayed non-critical event.

Degradation must be explicit and safe.

58. Recovery as Architecture

Architecture should support:

• rollback;
• roll-forward;
• replay;
• reconciliation;
• backup;
• and compensation.

Recovery should not be invented during incident.

59. Deployment Architecture

Delivery quality depends on:

• artifact immutability;
• configuration;
• rollout;
• health checks;
• and environment parity.

Deployment is part of architecture.

60. Progressive Delivery

Progressive delivery uses:

• pilot;
• canary;
• percentage;
• tenant;
• and feature flag.

It reduces risk by limiting exposure and increasing evidence.

61. Release Safety

Release safety includes:

• compatibility;
• observability;
• rollback;
• support readiness;
• and decision ownership.

A green pipeline alone is not enough.

62. Architecture and Test Strategy

Architecture determines useful test layers.

Examples:

• pure domain logic -> unit;
• service boundary -> contract;
• database -> integration;
• critical journey -> E2E;
• failure mode -> resilience test.

63. Testability as a Quality Attribute

Poor testability increases:

• feedback time;
• defect risk;
• and change cost.

Architectural choices should support:

• isolation;
• deterministic state;
• and controllable dependencies.

64. CI/CD as Architecture Feedback

Pipeline can enforce:

• compatibility;
• architecture boundary;
• security;
• and deployability.

Slow or flaky CI weakens architectural feedback.

65. Architecture and Flow Metrics

Useful signals:

• cross-team blocked time;
• coordinated release frequency;
• review latency;
• change failure rate;
• and time to recover.

Architecture quality should be visible in delivery behavior.

66. Bottleneck Theory

A system's throughput is constrained by its bottleneck.

Optimizing non-bottleneck activity may not improve delivery.

Examples:

• faster coding while review queue grows;
• more teams while environment remains constrained;
• and more features while release window is fixed.

67. Architecture Bottlenecks

Common architectural bottlenecks:

• shared database;
• central service;
• one release train;
• one specialist;
• one integration environment;
• and central approval.

68. Queue around Architecture

When every change needs review:

• decision queue grows;
• work ages;
• and teams start parallel work.

The fix may be:

• clearer guardrails;
• not simply more reviewers.

69. Approval versus Enablement

A centralized architecture function should ask:

• Which decisions require approval?
• Which can use standards?
• Which can be automated?
• Which can be delegated?

Approval should be reserved for material risk.

70. Distributed Decision-Making

Distributed decision-making requires:

• clear boundaries;
• principles;
• evidence;
• and escalation triggers.

Autonomy without context is unsafe.

Control without autonomy is slow.

71. Decision Taxonomy

Example:

Local

Internal implementation, reversible.

Team-level

Service contract or operational behavior.

Cross-team

Shared contract, data, or release.

Governance-level

Security, compliance, irreversible data, broad platform.

Each category has a review path.

72. Architecture Principles

Good principles are:

• memorable;
• actionable;
• contextual;
• and testable where possible.

Examples:

• Prefer additive contract evolution.
• One authoritative owner per business fact.
• Critical state transitions must be observable.
• Rollout must be reversible where practical.
• Teams own operations for their services.

73. Principle Exception

Exceptions should record:

• reason;
• consequence;
• mitigation;
• owner;
• and review date.

A principle without exception process becomes either dogma or ignored.

74. Architecture Governance

Healthy governance provides:

• principles;
• decision pathways;
• specialist access;
• and learning.

Unhealthy governance provides:

• centralized taste;
• long queues;
• and no accountability for delay.

75. Governance Metrics

Useful metrics:

• decision latency;
• rework after review;
• exception aging;
• approval queue;
• and recurring decision categories.

Do not measure number of approvals as success.

76. Architecture Forum

A forum should focus on:

• significant decisions;
• cross-team learning;
• and risk.

Avoid broad status updates.

Use pre-reads and clear decision ownership.

77. Communities of Practice

Communities can share:

• patterns;
• incidents;
• and standards.

They should influence through evidence, not become hidden gatekeepers.

78. Architecture Decision Quality

A high-quality decision includes:

• context;
• alternatives;
• evidence;
• trade-offs;
• consequences;
• and review trigger.

A correct-looking diagram is insufficient.

79. Architecture Review Questions

What problem is solved?
What is the simplest adequate design?
What must remain compatible?
How does it fail?
How is it observed?
How is it rolled out?
How is it recovered?
Who owns it?
What future option is constrained?

80. Avoiding Premature Abstraction

Wait for evidence of variation.

But do not wait so long that duplication hardens into incompatible behavior.

Use:

• two or more real examples;
• roadmap evidence;
• and change frequency.

81. Avoiding Distributed Monolith

Symptoms:

• many services;
• synchronous call chains;
• shared database;
• coordinated release;
• and unclear ownership.

Microservices do not guarantee autonomy.

82. Avoiding Platform Overreach

A platform can become broad and slow if it tries to solve every future use case.

Use:

• internal customer;
• adoption evidence;
• and narrow product thinking.

83. Avoiding Rewrite Bias

Rewrites underestimate:

• hidden behavior;
• migration;
• customer variation;
• and operational knowledge.

Prefer staged modernization unless evidence supports replacement.

84. Avoiding “Temporary” Permanence

Temporary adapters, flags, and dual writes need:

• owner;
• exit criteria;
• and cleanup date.

Otherwise temporary complexity becomes architecture.

85. Avoiding Senior Bottleneck

A senior or architect should replace personal review with:

• principles;
• examples;
• automated checks;
• and delegated decision rights.

86. Architecture and Scrum Events

Refinement

Expose boundaries, risks, and enablers.

Planning

Sequence integration and risk reduction.

Daily Scrum

Inspect critical dependency and integration.

Review

Show capability and operational evidence.

Retrospective

Inspect systemic bottlenecks and architecture friction.

87. Architecture Work Slicing

Slice by:

• one workflow;
• one tenant;
• one contract;
• one consumer;
• one migration cohort;
• or one failure mode.

Avoid horizontal layers that produce no integrated learning.

88. Architecture and Definition of Done

DoD may include:

• contract compatibility;
• integration;
• observability;
• migration evidence;
• and release readiness.

Do not leave architectural quality outside delivery.

89. Architecture Risk Register

Track:

90. Worked Example: Approval Rule Consolidation

Problem

Approval rules duplicated across three services.

Delivery impact

• three coordinated changes;
• inconsistent behavior;
• and long review.

Architecture options

1. Shared library.
2. Central rule service.
3. Authoritative evaluation in Quote service with contract.

Decision criteria

• ownership;
• latency;
• deployment coupling;
• availability;
• and change frequency.

Chosen path

Authoritative evaluation with additive result contract.

Rollout

• shadow comparison;
• pilot;
• consumer migration;
• remove duplicate logic.

91. Worked Example: Event Evolution

Problem

New approval status must reach Order consumers.

Unsafe path

Replace enum immediately.

Evolutionary path

• add optional metadata;
• preserve old mapping;
• contract-test consumers;
• enable pilot via flag;
• migrate;
• deprecate old behavior.

Outcome

Lower coordination and release risk.

92. Worked Example: Shared Database Bottleneck

Symptoms

• schema changes wait for central review;
• hidden consumers;
• synchronized release;
• and rollback fear.

Improvement

• identify data owner;
• inventory consumers;
• expose stable API/view;
• use expand-contract;
• and remove direct writes.

Evidence

Lower dependency wait and independent releases.

93. Worked Example: Architecture Review Queue

Symptoms

One architect reviews all changes.

Intervention

• classify decisions;
• publish guardrails;
• automate dependency rules;
• delegate team-level review;
• reserve architect review for high-risk changes.

Success signal

Decision latency decreases without higher change-failure rate.

94. Worked Example: Progressive Migration

Goal

Move quote approval metadata to new schema.

Slice

• pilot tenant;
• dual read;
• controlled write;
• validation metric;
• rollback;
• and reconciliation.

Expansion

Migrate cohorts after evidence.

95. Architecture Decision Template

## Problem

## Context

## Constraints

## Quality Attributes

## Options

## Recommendation

## Consequences

## Failure Modes

## Migration

## Observability

## Rollout and Recovery

## Owner

## Review Trigger

96. Architecture Risk Checklist

• Data ownership clear?
• Contract compatibility?
• Failure mode?
• Blast radius?
• Timeout/retry?
• Idempotency?
• Observability?
• Migration?
• Rollback/roll-forward?
• Operational owner?
• Security?
• Decision reversibility?

97. Bottleneck Checklist

• Where does work wait?
• Which decision is centralized?
• Which environment is scarce?
• Which contract requires coordination?
• Which knowledge is concentrated?
• Which approval can become guardrail?
• Which step can be automated?
• What happens when one person is absent?

98. Evolutionary-Delivery Checklist

• Thin slice?
• Real boundary validated?
• Feature flag?
• Additive contract?
• Pilot?
• Metrics?
• Rollback?
• Cleanup owner?
• Expansion criteria?
• Decommission plan?

99. Process Smells

• architecture work disconnected from backlog;
• every design needs central approval;
• public contracts lack versioning;
• shared database writes are common;
• feature flags never removed;
• migration has no decommission;
• and architecture success is measured by document count.

100. Internal Verification Checklist

Architecture governance

• What requires architecture review?
• Who decides?
• Are decision categories defined?
• Are guardrails documented?
• What is the exception process?

Service and data ownership

• Are service owners explicit?
• Who owns business data?
• Are shared databases used?
• Are consumer inventories maintained?
• Are operational owners known?

Contracts

• How are APIs/events versioned?
• Are compatibility tests used?
• Is deprecation governed?
• Are release sequences coordinated?

Delivery

• Are feature flags available?
• Is progressive rollout supported?
• Are migrations rehearsed?
• Is rollback tested?
• Are architectural fitness checks in CI?

Bottlenecks

• Is architecture review latency measured?
• Are specialists overloaded?
• Are environments scarce?
• Is decision authority concentrated?
• What recurring cross-team dependencies exist?

101. Practical Exercises

Exercise 1 — Change coupling map

Choose one feature and map every component/team that changes together.

Exercise 2 — Decision taxonomy

Classify recent decisions as local, team, cross-team, or governance-level.

Exercise 3 — Guardrail design

Convert one recurring approval into an explicit standard or automated check.

Exercise 4 — Evolutionary slice

Design a pilot migration with rollout and rollback.

Exercise 5 — Bottleneck analysis

Identify the current delivery constraint and propose one leverage point.

Exercise 6 — ADR review

Evaluate one ADR for consequences, failure modes, and review trigger.

102. Part Completion Checklist

You are done if you can:

• connect architecture to delivery flow;
• reason about coupling and ownership;
• use evolutionary design;
• distinguish guardrails from gates;
• design compatibility and migration;
• include failure, observability, and recovery;
• distribute decision rights;
• and reduce architecture-related bottlenecks.

103. Key Takeaways

1. Architecture shapes delivery and organization.
2. Boundaries determine coordination cost.
3. Quality attributes require explicit trade-offs.
4. Reversibility should determine decision depth.
5. Evolutionary architecture uses thin, evidence-producing slices.
6. Guardrails scale better than universal approval.
7. Compatibility enables independent delivery.
8. Observability and recovery are architectural concerns.
9. Architects and seniors should enable autonomy, not centralize it.
10. Internal architecture governance must be verified.

104. References

Conceptual baseline:

• General software architecture, evolutionary architecture, Team Topologies, and distributed-systems practices.
• Continuous delivery, progressive delivery, compatibility, migration, and architecture-decision concepts.
• Scrum transparency, self-management, cross-functionality, and incremental delivery principles.

These concepts do not describe internal CSG processes.