Index
A
- A/B testing, Culture of Experimentation
- abstraction distraction antipattern, Build Anticorruption Layers
- abstractions, leaky, Pitfall: Leaky Abstractions-Pitfall: Leaky Abstractions
- abstractness (metric), Abstractness, Instability, and Distance from the Main Sequence
- Ackoff, Russel, Outcomes Versus Implementations
- adaptation, evolution versus, Adaptation versus evolution
- ADRs (Architectural Decision Records), Documenting Fitness Functions
- afferent coupling, Afferent and Efferent Coupling-Afferent and Efferent Coupling
- agile methods
- AI (artificial intelligence), Fitness Functions Using AI
- Amazon
- anticorruption layers, Build Anticorruption Layers-Build Anticorruption Layers
- antipatterns (see pitfalls and antipatterns)
- APIs (application programming interfaces)
- Architectural Decision Records (ADRs), Documenting Fitness Functions
- architectural fitness functions, What Is a Fitness Function?
- architectural governance, automation of, Automating Architectural Governance-Summary
- A11y and other supported architecture characteristics, A11y and Other Supported Architecture Characteristics
- ArchUnit, ArchUnit-Layer checks
- availability fitness function (case study), Case Study: Availability Fitness Function
- code-based fitness functions, Code-Based Fitness Functions-Cyclomatic Complexity and “Herding” Governance
- DevOps, DevOps
- enterprise architecture, Enterprise Architecture-Fidelity Fitness Functions
- fitness functions as architectural governance, Fitness Functions as Architectural Governance-Fitness Functions as Architectural Governance
- fitness functions you're already using, Fitness Functions You’re Already Using
- integration architecture, Integration Architecture-Case Study: Choosing How to Implement a Fitness Function
- legality of open source libraries, Legality of Open Source Libraries
- linters for code governance, Linters for Code Governance
- load-testing along with canary releases (case study), Case Study: Load-Testing Along with Canary Releases-Case Study: Load-Testing Along with Canary Releases
- turnkey tools, Turnkey Tools-Fitness Functions You’re Already Using
- what features to port (case study), Case Study: What to Port?
- architectural quanta, Architectural Quanta and Granularity-Coordination
- architecture characteristics (term), The Challenges of Evolving Software
- ArchUnit, ArchUnit-Layer checks
- artificial intelligence (AI), Fitness Functions Using AI
- asynchronous communication, Communication
- atomic fitness functions, Scope: Atomic Versus Holistic
- automation
- availability fitness function, Case Study: Availability Fitness Function
B
- back port, Cadence: Triggered Versus Continual Versus Temporal
- Beck, Kent, Fitness Functions as Architectural Governance
- behavior-driven development (BDD), Documenting Fitness Functions
- Big Ball of Mud antipattern, Afferent and Efferent Coupling, Can’t evolve a Big Ball of Mud
- bit rot, The Challenges of Evolving Software, Once I’ve Built an Architecture, How Can I Prevent It from Degrading Over Time?
- blue/green deployments, Make Decisions Reversible
- bounded context
- break upon upgrade test, Cadence: Triggered Versus Continual Versus Temporal
- Brooks, Fred
- budgeting, CFO and Budgeting
- building evolvable architecture, Putting Evolutionary Architecture
into Practice-Summary
- advanced business capabilities, Advanced business capabilities
- anticorruption layers, Build Anticorruption Layers-Build Anticorruption Layers
- architecting and developing for evolvability, Architect and Develop for Evolvability
- architecting for testability, Architect for Testability
- avoiding excessively large teams, Avoid excessively large teams
- balancing cognitive load with business capabilities, Balance cognitive load with business capabilities
- building enterprise fitness functions, Building Enterprise Fitness Functions-Carving Out Bounded Contexts Within Existing Integration Architecture
- business case for, The Business Case-Case study: Fidelity fitness function
- CFO and budgeting, CFO and Budgeting
- Conway's Law, Conway’s Law, Don’t Fight Conway’s Law-Team coupling characteristics
- COTS implications, COTS Implications
- cross-functional teams, Default to cross-functional teams
- culture of experimentation, Culture of Experimentation-Culture of Experimentation
- cycle time as business metric, Cycle time as a business metric
- defining fitness functions for each dimension, Step 2: Define Fitness Function(s) for Each Dimension
- enterprise architecture at PenultimateWidgets (case study), Case Study: Enterprise Architecture at PenultimateWidgets
- evolving PenultimateWidgets' ratings (case study), Case Study: Evolving PenultimateWidgets’ Ratings-Case Study: Evolving PenultimateWidgets’ Ratings
- favoring evolvability over predictability, Prefer Evolvable over Predictable, Predictable versus evolvable
- fitness function-driven architecture, Fitness Function-Driven Architecture
- fitness functions using AI, Fitness Functions Using AI
- future state of, Future State?
- generative testing, Generative Testing
- greenfield projects, Greenfield Projects
- guidelines, Guidelines for Building Evolutionary Architectures-Version Services Internally
- highest-value-first starting point, Highest Value First
- identifying dimensions affected by evolution, Step 1: Identify Dimensions Affected by Evolution
- infrastructure as starting point, Infrastructure
- last responsible moment principle, Last Responsible Moment
- “low-hanging fruit” as starting point, Low-Hanging Fruit
- making decisions reversible, Make Decisions Reversible
- mechanics of, Mechanics-Step 3: Use Deployment Pipelines to Automate Fitness Functions
- migrating architectures, Migrating Architectures-Evolving Module Interactions
- mitigating external change, Mitigate External Change-Mitigate External Change
- organizational factors, Organizational Factors-CFO and Budgeting
- organizing teams around business capabilities, Organize teams around business capabilities
- Postel's Law, Postel’s Law
- practical considerations, Putting Evolutionary Architecture
into Practice-Summary
- principles of, Building Evolvable Architectures-Summary
- product over project, Think product over project
- reasons against, Why Would a Company Choose Not to Build an Evolutionary Architecture?-Planning on closing the business soon
- reasons for, Why Should a Company Decide to Build an Evolutionary Architecture?-Adaptation versus evolution
- removing needless variability, Guidelines for Building Evolutionary Architectures-Version Services Internally
- retrofitting existing architectures, Retrofitting Existing Architectures-COTS Implications
- sacrificial architectures, Build Sacrificial Architectures-Build Sacrificial Architectures, Sacrificial architecture
- scale issues, Scale
- starting points, Where Do You Start?-Case Study: Enterprise Architecture at PenultimateWidgets
- team coupling characteristics, Team coupling characteristics
- team culture, Culture-Culture
- testing as starting point, Testing
- updating libraries versus frameworks, Updating Libraries Versus Frameworks
- using deployment pipelines to automate fitness functions, Step 3: Use Deployment Pipelines to Automate Fitness Functions
- versioning services internally, Updating Libraries Versus Frameworks
- business case for evolutionary architecture, The Business Case-Case study: Fidelity fitness function
- business concerns, Business Concerns-Pitfall: Excessively Long Planning Horizons
- business metric, cycle time as, Cycle time as a business metric
C
- canary releases, load-testing along with, Case Study: Load-Testing Along with Canary Releases-Case Study: Load-Testing Along with Canary Releases
- CC (cyclomatic complexity), Cyclomatic Complexity and “Herding” Governance
- chaos engineering, DevOps-DevOps
- Chaos Monkey, DevOps
- Chidamber & Kemerer metrics suite, Evolving Module Interactions
- CI (see continuous integration)
- cloud environments, sacrificial architecture and, Build Sacrificial Architectures
- code reuse (see reuse of code)
- code-based fitness functions, Code-Based Fitness Functions-Cyclomatic Complexity and “Herding” Governance
- cognitive load, team design and, Balance cognitive load with business capabilities
- commit transactions, two-phase, Two-Phase Commit Transactions
- communication governance, in microservices, Communication Governance in Microservices-Communication Governance in Microservices
- component coupling, Retrofitting Existing Architectures-COTS Implications
- component cycles, What Is a Fitness Function?
- concurrency fitness function, Case study: Concurrency fitness function
- connascence
- Constantine, Larry, Afferent and Efferent Coupling
- containers and containerization, The Challenges of Evolving Software
- continual tests, Cadence: Triggered Versus Continual Versus Temporal
- Continuous Delivery
- Continuous Delivery (Humble and Farley), Engineering Incremental Change
- Continuous Deployment, Cycle time as a business metric
- continuous fitness functions, Cadence: Triggered Versus Continual Versus Temporal
- continuous improvement (kaizen), Culture of Experimentation
- continuous integration (CI)
- contracts, Contracts-Case Study: Microservices as an Evolutionary Architecture
- Conway's Law, Conway’s Law, Don’t Fight Conway’s Law-Team coupling characteristics
- Conway, Melvin, Don’t Fight Conway’s Law
- Cook, John D., Reuse Patterns
- correlation IDs, Case Study: Choosing How to Implement a Fitness Function
- COTS (Commercial Off The Shelf) software, COTS Implications
- coupling (see specific types, e.g.: afferent coupling)
- coupling, duplication versus, Reuse Patterns
- cross-functional teams, Default to cross-functional teams
- culture
- customization pitfall, Pitfall: Product Customization
- cycle time
- cyclomatic complexity (CC), Cyclomatic Complexity and “Herding” Governance
D
- data (see evolutionary data)
- data duplication, Data Duplication-Data Duplication
- data mesh, Data Mesh: Orthogonal Data Coupling-Data product quantum
- data product quantum (DPQ), Data product quantum-Data product quantum
- data-driven development, Hypothesis- and Data-Driven Development
- databases
- DDD (domain-driven design), bounded context and, Connascence Intersection with Bounded Context, Case Study: Microservices as an Evolutionary Architecture
- decoupling, forced, Antipattern: Inappropriate Governance
- dependences, external, Mitigate External Change-Mitigate External Change
- deployment pipelines
- design, manufacturing versus, Summary
- DevOps, automating, Default to cross-functional teams
- DevOps-related fitness functions, DevOps
- Dijkstra, Edsger, Mitigate External Change
- dimensions
- directionality of imports, Directionality of Imports
- distance from the main sequence (metric), Abstractness, Instability, and Distance from the Main Sequence
- Docker, The Challenges of Evolving Software
- documentation, fitness function, Documenting Fitness Functions-Documenting Fitness Functions
- domain-driven design (DDD), bounded context and, Connascence Intersection with Bounded Context, Case Study: Microservices as an Evolutionary Architecture
- Domain-Driven Design (Evans), Connascence Intersection with Bounded Context
- domain-specific architectures, Other architectural characteristics dominate
- domain-specific fitness functions, Coverage: Domain-Specific Fitness Functions?
- DPQ (data product quantum), Data product quantum-Data product quantum
- duplication, coupling versus, Reuse Patterns
- dynamic connascence, Dynamic connascence
- dynamic fitness functions, Result: Static Versus Dynamic
- dynamic quantum coupling, Dynamic Quantum Coupling-Coordination
E
- eBay, Build Sacrificial Architectures
- Edison, Thomas Alva, Culture of Experimentation
- efferent coupling, Afferent and Efferent Coupling-Afferent and Efferent Coupling
- elasticity, Coverage: Domain-Specific Fitness Functions?
- emergence (term), Why Evolutionary?
- emergent fitness functions, Proactivity: Intentional Versus Emergent
- enterprise architecture, Enterprise Architecture-Fidelity Fitness Functions
- Enterprise Resource Planning (ERP) software, Vendor King antipattern and, Antipattern: Vendor King-Antipattern: Vendor King
- enterprise-wide fitness functions, Building Enterprise Fitness Functions-Carving Out Bounded Contexts Within Existing Integration Architecture
- Equifax data breach, Case Study: Zero-Day Security Vulnerability
- ERP (Enterprise Resource Planning) software, Vendor King antipattern and, Antipattern: Vendor King-Antipattern: Vendor King
- ETL (Extract, Transform, and Load), Case study: UDP communications
- Evans, Eric, Connascence Intersection with Bounded Context
- evolution, adaptation versus, Adaptation versus evolution
- evolutionary architect, Enterprise Architecture
- evolutionary architecture (generally)
- adaptable architecture versus, Why Evolutionary?
- Conway's Law and, Don’t Fight Conway’s Law-Team coupling characteristics
- defined, Evolutionary Architecture
- dimensions of, Multiple Architectural Dimensions-Multiple Architectural Dimensions
- emergent design versus, Why Evolutionary?
- future state of, Future State?
- guided change, Guided Change
- in practice, Putting Evolutionary Architecture
into Practice-Summary
- incremental change, Incremental Change
- long-term planning, How Is Long-Term Planning Possible When Everything Changes All the Time?-How Is Long-Term Planning Possible When Everything Changes All the Time?
- microservices as, Case Study: Microservices as an Evolutionary Architecture-Case Study: Microservices as an Evolutionary Architecture
- pitfalls and antipatterns, Evolutionary Architecture Pitfalls and Antipatterns-Summary
- preventing degradation, Once I’ve Built an Architecture, How Can I Prevent It from Degrading Over Time?
- reasons not to build, Why Would a Company Choose Not to Build an Evolutionary Architecture?-Planning on closing the business soon
- reasons to build, Why Should a Company Decide to Build an Evolutionary Architecture?-Adaptation versus evolution
- see-also=building evolvable architecture; evolvable architectures, Evolutionary Architecture-Multiple Architectural Dimensions
- terminology, Why Evolutionary?
- topologies (see topologies of evolutionary architecture)
- evolutionary data, Evolutionary Data-Summary
- evolvability
- evolvable architectures
- anticorruption layers, Build Anticorruption Layers-Build Anticorruption Layers
- avoiding snowflake servers, Remove Needless Variability
- building (see building evolvable architecture)
- COTS implications, COTS Implications
- coupling and cohesion for, Appropriate Coupling and Cohesion-Appropriate Coupling and Cohesion
- defining fitness functions for each dimension, Step 2: Define Fitness Function(s) for Each Dimension
- favoring evolvability over predictability, Prefer Evolvable over Predictable, Predictable versus evolvable
- guidelines for building, Guidelines for Building Evolutionary Architectures-Version Services Internally
- identifying dimensions affected by evolution, Step 1: Identify Dimensions Affected by Evolution
- migrating architectures, Migrating Architectures-Evolving Module Interactions
- mitigating external change, Mitigate External Change-Mitigate External Change
- refactoring versus restructuring, Appropriate Coupling and Cohesion
- removing needless variability, Remove Needless Variability-Remove Needless Variability
- retrofitting existing architectures, Retrofitting Existing Architectures-COTS Implications
- sacrificial architectures, Build Sacrificial Architectures-Build Sacrificial Architectures, Sacrificial architecture
- updating libraries versus frameworks, Updating Libraries Versus Frameworks
- using deployment pipelines to automate fitness functions, Step 3: Use Deployment Pipelines to Automate Fitness Functions
- evolving software architecture (generally), Evolving Software Architecture-Summary
- expand/contract pattern, Shared Database Integration
- experimental media, fitness functions as, Fitness Functions as Experimental Media-Case study: Concurrency fitness function
- experimentation, culture of, Culture of Experimentation-Culture of Experimentation
- external dependences, Mitigate External Change-Mitigate External Change
- eXtreme Programming (XP), Fitness Functions as Architectural Governance
F
- Facebook, Hypothesis- and Data-Driven Development
- fan in/fan out operation, Deployment Pipelines
- Farley, Dave, Engineering Incremental Change
- feature toggles, Deployment Pipelines, Adaptation versus evolution
- fidelity fitness functions
- fitness functions, Fitness Functions-Summary
- abstractness, Abstractness, Instability, and Distance from the Main Sequence
- adding to PenultimateWidgets' invoicing service, Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service-Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service
- afferent/efferent coupling, Afferent and Efferent Coupling-Afferent and Efferent Coupling
- AI for, Fitness Functions Using AI
- as architectural governance, Fitness Functions as Architectural Governance-Fitness Functions as Architectural Governance
- atomic versus holistic, Scope: Atomic Versus Holistic
- automated versus manual, Invocation: Automated Versus Manual
- automating with deployment pipelines, Step 3: Use Deployment Pipelines to Automate Fitness Functions
- availability fitness function (case study), Case Study: Availability Fitness Function
- categories of, What Is a Fitness Function?-What Is a Fitness Function?
- as checklist, not a stick, Fitness Functions as a Checklist, Not a Stick
- choosing how to implement, Case Study: Choosing How to Implement a Fitness Function-Case Study: Choosing How to Implement a Fitness Function
- code-based, Code-Based Fitness Functions-Cyclomatic Complexity and “Herding” Governance
- concurrency fitness function case study, Case study: Concurrency fitness function
- COTS software and, COTS Implications
- cyclomatic complexity and herding governance, Cyclomatic Complexity and “Herding” Governance
- defined, Guided Change, What Is a Fitness Function?
- defining for each dimension in evolvable architecture, Step 2: Define Fitness Function(s) for Each Dimension
- DevOps-related, DevOps
- directionality of imports, Directionality of Imports
- distance from the main sequence, Abstractness, Instability, and Distance from the Main Sequence
- documenting, Documenting Fitness Functions-Documenting Fitness Functions
- domain-specific, Coverage: Domain-Specific Fitness Functions?
- enterprise-wide, Building Enterprise Fitness Functions-Carving Out Bounded Contexts Within Existing Integration Architecture
- as experimental media, Fitness Functions as Experimental Media-Case study: Concurrency fitness function
- fidelity, Fidelity Fitness Functions
- fidelity case study, Case study: Fidelity fitness function
- fitness function-driven architecture, Fitness Function-Driven Architecture
- guided change with (see guided change with fitness functions)
- instability, Abstractness, Instability, and Distance from the Main Sequence
- intentional versus emergent, Proactivity: Intentional Versus Emergent
- outcomes versus implementations, Outcomes Versus Implementations-Outcomes Versus Implementations
- static versus dynamic, Result: Static Versus Dynamic
- testing framework, Where Is My Fitness Function Testing Framework?
- triggered versus continual versus temporal, Cadence: Triggered Versus Continual Versus Temporal-Cadence: Triggered Versus Continual Versus Temporal
- who should write, Who Writes Fitness Functions?
- forced decoupling, Antipattern: Inappropriate Governance
- Ford, Chris, Mitigate External Change
- Fowler, Chad, Remove Needless Variability, Antipattern: Inappropriate Governance
- Fowler, Martin, Appropriate Coupling and Cohesion, Build Sacrificial Architectures, Sacrificial architecture
- frameworks, libraries versus, Updating Libraries Versus Frameworks
- frozen caveman antipattern, Enterprise Architecture
- functional cohesion, High Functional Cohesion
- future state of evolutionary architecture, Future State?
G
- generative testing, Generative Testing
- GitHub, architectural restructuring at, Enterprise Architecture
- “Go To Statement Considered Harmful” (Dijkstra), Mitigate External Change
- Goldratt, Eliyahu M., Culture
- Google, 20% time at, Culture of Experimentation
- governance, Antipattern: Inappropriate Governance
- GraphQL contracts, Contracts
- greenfield projects, Greenfield Projects
- guided (term), Fitness Functions
- guided change with fitness functions, Guided Change, Fitness Functions, Case Study: Microservices as an Evolutionary Architecture
H
- Hackman, J. Richard, Avoid excessively large teams
- Henney, Kevlin, Evolving Module Interactions
- herding, Cyclomatic Complexity and “Herding” Governance
- Hickey, Rich, Build Anticorruption Layers
- high static coupling, High Static Coupling-High Static Coupling
- highest-value-first approach, Highest Value First
- holistic fitness functions, Scope: Atomic Versus Holistic
- “How Do Committees Invent?” (Conway), Don’t Fight Conway’s Law-Team coupling characteristics
- Humble, Jez, Engineering Incremental Change
- hypothesis-driven development, Hypothesis- and Data-Driven Development
I
- immutable infrastructure, Remove Needless Variability
- inadvertent (accidental) coupling, Antipattern: Reporting Atop the System of Record
- inappropriate data entanglement, Inappropriate Data Entanglement-Age and Quality of Data
- inappropriate governance, Antipattern: Inappropriate Governance-Antipattern: Inappropriate Governance
- incremental change, Incremental Change, Engineering Incremental Change-Summary
- adding fitness functions to PenultimateWidgets' invoicing service (case study), Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service-Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service
- COTS software and, COTS Implications
- deployment pipelines and, Deployment Pipelines-Deployment Pipelines
- engineering of, Engineering Incremental Change-Summary
- GitHub case study, Enterprise Architecture
- hypothesis- and data-driven development, Hypothesis- and Data-Driven Development
- inappropriate governance antipattern, Antipattern: Inappropriate Governance-Antipattern: Inappropriate Governance
- “just enough” governance at PenultimateWidgets (case study), Case Study: “Just Enough” Governance at PenultimateWidgets
- lack of speed to release, Pitfall: Lack of Speed to Release-Pitfall: Lack of Speed to Release
- microservices and, Case Study: Microservices as an Evolutionary Architecture
- pitfalls and antipatterns, Incremental Change-Pitfall: Lack of Speed to Release
- validating API consistency in automated build (case study), Case Study: Validating API Consistency in an Automated Build-Case Study: Validating API Consistency in an Automated Build
- indirection, Evolving Module Interactions
- infrastructure dysfunction, Infrastructure
- instability (metric), Abstractness, Instability, and Distance from the Main Sequence
- integration architecture, Integration Architecture-Case Study: Choosing How to Implement a Fitness Function
- intentional fitness functions, Proactivity: Intentional Versus Emergent
- internal resolution, Version Services Internally
- Inverse Conway Maneuver, Don’t Fight Conway’s Law
- irrational artifact attachment, Pitfall: Excessively Long Planning Horizons
L
- Last 10% trap, Antipattern: Last 10% Trap and Low Code/No Code
- last responsible moment principle, Last Responsible Moment, Build Anticorruption Layers, Pitfall: Lack of Speed to Release
- layered architecture, Carving Out Bounded Contexts Within Existing Integration Architecture
- LCOM (Lack of Cohesion in Methods), Evolving Module Interactions
- lead time, Pitfall: Lack of Speed to Release
- leaky abstractions, Pitfall: Leaky Abstractions-Pitfall: Leaky Abstractions
- legal issues, open source libraries and, Legality of Open Source Libraries
- Let's Stop Working and Call It A Success Concession principle, Antipattern: Vendor King
- libraries, frameworks versus, Updating Libraries Versus Frameworks
- linters, Linters for Code Governance
- literate programming, Documenting Fitness Functions
- LMAX, Fitness Function-Driven Architecture
- load-testing, canary releases and (case study), Case Study: Load-Testing Along with Canary Releases-Case Study: Load-Testing Along with Canary Releases
- long-term planning, in evolutionary environment, How Is Long-Term Planning Possible When Everything Changes All the Time?-How Is Long-Term Planning Possible When Everything Changes All the Time?
M
- manual fitness functions, Invocation: Automated Versus Manual
- manufacturing, design versus, Summary
- Martin, Robert, Abstractness, Instability, and Distance from the Main Sequence
- MDD (monitoring-driven development), Cadence: Triggered Versus Continual Versus Temporal
- Meadows, Donella H., Multiple Architectural Dimensions
- mechanical sympathy, Fitness Function-Driven Architecture
- micro-frontend framework, High Static Coupling
- microservices
- migration
- modular monoliths, Carving Out Bounded Contexts Within Existing Integration Architecture
- modules, migrating shared, Evolving Module Interactions-Evolving Module Interactions
- monitoring-driven development (MDD), Cadence: Triggered Versus Continual Versus Temporal
- monolithic architecture, migrating to service-based, Migration Steps-Migration Steps
P
- packages, directionality of imports, Directionality of Imports
- Page-Jones, Meilir, Connascence-Dynamic connascence
- Pais, Manuel, Balance cognitive load with business capabilities
- PenultimateWidgets (fictional case study)
- adding fitness functions to invoicing service, Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service-Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service
- availability fitness function, Case Study: Availability Fitness Function
- evolving from relational to nonrelational databases, Case Study: Evolving from Relational to Nonrelational
- evolving routing, Case Study: Evolving PenultimateWidgets’ Routing-Case Study: Evolving PenultimateWidgets’ Routing
- functionality porting decisions, Case Study: What to Port?
- “just enough” governance, Case Study: “Just Enough” Governance at PenultimateWidgets
- legality of open-source libraries, Legality of Open Source Libraries
- load-testing along with canary releases, Case Study: Load-Testing Along with Canary Releases-Case Study: Load-Testing Along with Canary Releases
- operational aspects of incremental change at, Incremental Change-Incremental Change
- reusable components, Case Study: Reuse at PenultimateWidgets
- star rating service upgrade, Incremental Change-Incremental Change, Case Study: Evolving PenultimateWidgets’ Ratings-Case Study: Evolving PenultimateWidgets’ Ratings
- UDP communications, Case study: UDP communications
- validating API consistency in automated build, Case Study: Validating API Consistency in an Automated Build-Case Study: Validating API Consistency in an Automated Build
- what features to port, Case Study: What to Port?
- pitfalls and antipatterns, Evolutionary Architecture Pitfalls and Antipatterns-Summary
- abstraction distraction, Build Anticorruption Layers
- Big Ball of Mud, Can’t evolve a Big Ball of Mud
- business concerns, Business Concerns-Pitfall: Excessively Long Planning Horizons
- defined, Evolutionary Architecture Pitfalls and Antipatterns, Evolutionary Architecture Pitfalls and Antipatterns
- inappropriate governance, Antipattern: Inappropriate Governance-Antipattern: Inappropriate Governance
- incremental change, Incremental Change-Pitfall: Lack of Speed to Release
- “just enough” governance at PenultimateWidgets (case study), Case Study: “Just Enough” Governance at PenultimateWidgets
- lack of speed to release, Pitfall: Lack of Speed to Release-Pitfall: Lack of Speed to Release
- Last 10% trap, Antipattern: Last 10% Trap and Low Code/No Code
- leaky abstractions, Pitfall: Leaky Abstractions-Pitfall: Leaky Abstractions
- planning horizons, Pitfall: Excessively Long Planning Horizons
- product customization, Pitfall: Product Customization
- reporting atop the system of record, Antipattern: Reporting Atop the System of Record
- Resume-Driven Development, Pitfall: Resume-Driven Development
- reuse at PenultimateWidgets (case study), Case Study: Reuse at PenultimateWidgets
- Vendor King, Antipattern: Vendor King-Antipattern: Vendor King
- planning horizons, excessively long, Pitfall: Excessively Long Planning Horizons
- porting of functionality, Case Study: What to Port?
- Postel's Law, Postel’s Law
- Postel, Jon, Postel’s Law
- predictability, evolvability versus, Prefer Evolvable over Predictable, Predictable versus evolvable
- primordial abstraction ooze, Pitfall: Leaky Abstractions
- product customization pitfall, Pitfall: Product Customization
- product, project versus, Think product over project
- programming languages, evolution of, How Is Long-Term Planning Possible When Everything Changes All the Time?
- Project to Product (Kersten), Think product over project
- project, product versus, Think product over project
- pull model, Mitigate External Change
- pull updates, Updating Libraries Versus Frameworks
- push updates, Updating Libraries Versus Frameworks
R
- reactive fitness function, Communication Governance in Microservices
- read operation, write operation versus, Data Duplication-Data Duplication
- refactoring, restructuring versus, Appropriate Coupling and Cohesion
- referential integrity, Referential Integrity
- relational databases, evolving to nonrelational, Case Study: Evolving from Relational to Nonrelational
- reporting services antipattern, Antipattern: Reporting Atop the System of Record
- REST contracts, Contracts
- restructuring, refactoring versus, Appropriate Coupling and Cohesion
- Resume-Driven Development, Pitfall: Resume-Driven Development
- retrofitting existing architectures, Retrofitting Existing Architectures-COTS Implications
- reuse of code
- reversible decisions, Make Decisions Reversible
- Richards, Mark, Prefer Evolvable over Predictable
- roulette mutation, Fitness Functions
- routing (PenultimateWidgets case study), Case Study: Evolving PenultimateWidgets’ Routing-Case Study: Evolving PenultimateWidgets’ Routing
- Rumsfeld, Donald, Prefer Evolvable over Predictable
S
- sacrificial architectures, Build Sacrificial Architectures-Build Sacrificial Architectures, Sacrificial architecture
- Sapir–Whorf hypothesis, Connascence
- scaling
- schemas
- Scientist (GitHub framework), Enterprise Architecture
- second system syndrome, Build Sacrificial Architectures
- security
- servers, snowflake, Remove Needless Variability
- service discovery, Evolving Module Interactions
- service mesh, Sidecars and Service Mesh: Orthogonal Operational Coupling-Sidecars and Service Mesh: Orthogonal Operational Coupling
- service-based architectures, migrating monolithic architectures to, Migration Steps-Migration Steps
- service-oriented architectures (SOA), code reuse in, Reuse Patterns
- services, versioning internally, Version Services Internally
- set-based development, Culture of Experimentation
- share nothing architecture, Incremental Change, Case Study: Microservices as an Evolutionary Architecture
- Shared Database Integration, Shared Database Integration-Option 3: Existing data and integration points
- shared modules, Evolving Module Interactions-Evolving Module Interactions
- Sidecar pattern, Sidecars and Service Mesh: Orthogonal Operational Coupling-Sidecars and Service Mesh: Orthogonal Operational Coupling
- Simian Army, DevOps
- single responsibility principle, Architect for Testability
- Skelton, Matthew, Balance cognitive load with business capabilities
- snowflake infrastructure, Remove Needless Variability
- snowflake servers, Remove Needless Variability
- SOA (service-oriented architectures), code reuse in, Reuse Patterns
- software architecture (generally)
- spike solutions, Culture of Experimentation
- Spolsky, Joel, Pitfall: Leaky Abstractions
- stamp coupling, Contracts
- static connascence, Static connascence
- static coupling, High Static Coupling-High Static Coupling
- static fitness functions, Result: Static Versus Dynamic
- Strangler Fig pattern, Case study: Concurrency fitness function
- Structured Design (Yourdon and Constantine), Afferent and Efferent Coupling
- Sunk Cost Fallacy, Pitfall: Excessively Long Planning Horizons
- synchronous communication, Communication
- synthetic transactions, Cadence: Triggered Versus Continual Versus Temporal
- system-wide fitness functions, Outcomes Versus Implementations
T
- TDD (test-driven development), Cyclomatic Complexity and “Herding” Governance, Fitness Function-Driven Architecture
- Team Topologies (Pais and Skelton), Balance cognitive load with business capabilities
- teams, Don’t Fight Conway’s Law
- (see also Inverse Conway Maneuver)
- balancing cognitive load with business capabilities, Balance cognitive load with business capabilities
- coupling characteristics, Team coupling characteristics
- cross-functional, Default to cross-functional teams
- culture of experimentation, Culture of Experimentation-Culture of Experimentation
- engineering culture, Culture-Culture
- excessively large, Avoid excessively large teams
- organizational factors, Organizational Factors-CFO and Budgeting
- organizing around business capabilities, Organize teams around business capabilities
- product over project, Think product over project
- two-pizza, Default to cross-functional teams
- technical architecture
- technical debt, Build Anticorruption Layers, Build Sacrificial Architectures, Adaptation versus evolution
- technical partitioning, Carving Out Bounded Contexts Within Existing Integration Architecture
- temporal fitness functions, Cadence: Triggered Versus Continual Versus Temporal
- test-driven development (TDD), Cyclomatic Complexity and “Herding” Governance, Fitness Function-Driven Architecture
- testability, architecting for, Architect for Testability
- testing
- topologies of evolutionary architecture, Evolutionary Architecture Topologies-Summary
- Toyota, Culture of Experimentation
- transactionality, Consistency
- triggered fitness functions
- Twitter, Build Sacrificial Architectures
- two-pizza teams, Default to cross-functional teams
..................Content has been hidden....................
You can't read the all page of ebook, please click
here login for view all page.