Index
A
- A/B testing, Culture of Experimentation
- abstraction distraction antipattern, Build Anticorruption Layers
- abstractions, leaky, Pitfall: Leaky Abstractions-Pitfall: Leaky Abstractions
- accidental (unintentional) coupling, Microservices, Antipattern: Inappropriate Governance, Antipattern: Reporting
- Ackoff, Russel, Fitness Functions
- adaptation, evolution vs., Why Evolutionary?, Adaptation versus evolution
- Amazon
- Amazon Cloud, Combining Fitness Function Categories
- Ambler, Scott, Evolutionary Data
- anticorruption layers, “Serverless” Architectures, Build Anticorruption Layers
- antipatterns, Evolutionary Architecture Pitfalls and Antipatterns-Pitfall: Planning Horizons
- application programming interfaces (APIs), How Is Long-term Planning Possible When Everything Changes All the Time?
- application services, ESB-driven SOA
- appropriate coupling
- in Big Ball of Mud, Big Ball of Mud
- in broker EDAs, Brokers
- in COTS software, COTS Implications
- in ESB-driven SOA, ESB-driven SOA
- in layered monolithic architecture, Layered architecture
- in mediator EDAs, Mediators
- in microkernels, Microkernel
- in microservices, Microservices
- in modular monoliths, Modular monoliths
- in monolithic architectures, Unstructured monoliths
- in serverless architectures, “Serverless” Architectures
- in service-based architectures, Service-based architectures
- service templates for, Case Study: Service Templates
- architectural concerns, Multiple Architectural Dimensions
- architectural coupling, Architectural Coupling-ESB-driven SOA
- architectural quanta, Architectural Quanta and Granularity-Architectural Quanta and Granularity
- architectural styles
- artificial intelligence (AI), Fitness Functions Using AI
- atomic fitness functions, Atomic Versus Holistic, Brokers
- automation
B
- BaaS (Backend as a Service), “Serverless” Architectures
- back port, Temporal
- Big Ball of Mud antipattern, Big Ball of Mud, Can’t evolve a ball of mud
- bit rot, Once I’ve Built an Architecture, How Can I Prevent It from Gradually Degrading Over Time?
- blue/green deployments, Make Decisions Reversible
- bounded context
- break upon upgrade test, Temporal
- broker EDA, Brokers-Brokers
- Brooks, Fred
- Brown, Simon, Multiple Architectural Dimensions, Modular monoliths
- budgeting, CFO and Budgeting
- building evolutionary architecture, Putting Evolutionary Architecture into Practice-Building Evolutionary Architectures
- building enterprise fitness functions, Building Enterprise Fitness Functions
- business case for, The Business Case
- CFO and budgeting, CFO and Budgeting
- connections between team members, Connections Between Team Members
- convincing others of benefits, Convincing Others
- cross-functional teams, Cross-Functional Teams-Cross-Functional Teams
- culture of experimentation, Culture of Experimentation
- easiest-first starting point, Low-Hanging Fruit
- external change, Dealing with External Change
- fitness functions using AI, Fitness Functions Using AI
- future state of, Future State?
- generative testing, Generative Testing
- highest-value-first starting point, Highest-Value
- infrastructure as starting point, Infrastructure
- organizational factors, Organizational Factors-Connections Between Team Members
- organizing teams around business capabilities, Organized Around Business Capabilities
- PenultimateWidgets as platform, Case Study: PenultimateWidgets as a Platform
- PenultimateWidgets case study, Case Study: Enterprise Architecture at PenultimateWidgets
- product over project, Product over Project
- reasons for building, Why Should a Company Decide to Build an Evolutionary Architecture?-Adaptation versus evolution
- reasons not to build, Why Would a Company Choose Not to Build an Evolutionary Architecture?
- reasons to build, Why Should a Company Decide to Build an Evolutionary Architecture?-Adaptation versus evolution
- starting points, Where Do You Start?-Case Study: Enterprise Architecture at PenultimateWidgets
- team coupling characteristics, Team Coupling Characteristics-Culture of Experimentation
- team culture, Culture
- testing as starting point, Testing
- business capabilities
- business case for evolutionary architecture, The Business Case
- business concerns
- business metric, cycle time as, Cycle time as a business metric
C
- change
- Chaos Monkey, Combining Fitness Function Categories
- cloud environments, sacrificial architecture and, Build Sacrificial Architectures
- code reuse
- coding standards, fitness functions and, What is a Fitness Function?
- component cycles, Testable, Case Study: Guarding Against Component Cycles-Case Study: Guarding Against Component Cycles
- components, defined, Modularity
- Conformity Monkey, Combining Fitness Function Categories
- considered harmful, Mitigate External Change
- consulting judo, Case Study: Consulting Judo
- continual architecture, Once I’ve Built an Architecture, How Can I Prevent It from Gradually Degrading Over Time?
- continual fitness functions, Triggered Versus Continual
- Continuous Delivery
- Continuous Deployment, Deployment Pipelines, Cycle time as a business metric
- continuous integration (CI), Deployment Pipelines
- contracts, Microkernel
- Conway's Law, Conway’s Law
- Conway, Melvin, Conway’s Law
- Cook, John D., Antipattern: Code Reuse Abuse
- coordination friction, Cross-Functional Teams
- COTS (Commercial Off The Shelf) software, COTS Implications
- coupling, Testable
- cross-functional teams, Cross-Functional Teams-Cross-Functional Teams
- culture
- customization pitfall, Pitfall: Product Customization
- cycle time
- cyclomatic complexity, What is a Fitness Function?
D
- data (see evolutionary data)
- data coupling, inappropriate (see inappropriate coupling)
- data-driven development, Hypothesis- and Data-Driven Development
- database migration tools, Evolving Schemas
- databases
- DBAs
- decoupling, forced, Antipattern: Inappropriate Governance
- dependences, external, Mitigate External Change-Mitigate External Change
- deployment pipelines
- DevOps
- Dijkstra, Edsger, Mitigate External Change
- dimensions
- disruptive change, How Is Long-term Planning Possible When Everything Changes All the Time?
- Docker, How Is Long-term Planning Possible When Everything Changes All the Time?
- domain dimension, microservices and, Microservices-Microservices
- domain-centric teams, Cross-Functional Teams-Cross-Functional Teams
- domain-driven design (DDD)
- domain-specific architectures, Other architectural characteristics dominate
- domain-specific fitness functions, Domain-specific
- duplication, coupling vs., Antipattern: Code Reuse Abuse
- dynamic equilibrium, How Is Long-term Planning Possible When Everything Changes All the Time?
- dynamic fitness functions, Static Versus Dynamic
E
- easiest-first approach, Low-Hanging Fruit
- eBay, Build Sacrificial Architectures, Sacrificial architecture
- Eclipse Java IDE, Microkernel
- ecosystem, software development, How Is Long-term Planning Possible When Everything Changes All the Time?
- Edison, Thomas Alva, Culture of Experimentation
- emergent fitness functions, Intentional Over Emergent
- endpoints, versioning, Version Services Internally
- engineering safety net, Dealing with External Change
- enterprise architecture, Case Study: Enterprise Architecture at PenultimateWidgets
- Enterprise Resource Planning (ERP) software, Antipattern: Vendor King
- enterprise services, ESB-driven SOA
- enterprise-wide fitness functions, Building Enterprise Fitness Functions
- Evans, Eric, Architectural Quanta and Granularity, Architectural Quanta and Granularity
- event-driven architectures (EDA), Event-Driven Architectures-Mediators
- evolution, adaptation vs., Why Evolutionary?, Adaptation versus evolution
- evolutionary architecture (generally)
- adaptable architecture vs., Why Evolutionary?
- balancing long-term planning with constant change, How Is Long-term Planning Possible When Everything Changes All the Time?
- basics, Evolutionary Architecture
- Conway's Law and, Conway’s Law
- defined, Once I’ve Built an Architecture, How Can I Prevent It from Gradually Degrading Over Time?
- dimensions of, Multiple Architectural Dimensions-Multiple Architectural Dimensions
- evolvability of architectural styles, Evolvability of Architectural Styles-Microkernel
- future state of, Future State?
- guided change and, Guided Change
- in practice, Summary, Putting Evolutionary Architecture into Practice-Building Evolutionary Architectures
- (see also building evolutionary architecture)
- incremental change and, Incremental Change
- pitfalls and antipatterns, Evolutionary Architecture Pitfalls and Antipatterns-Pitfall: Planning Horizons
- (see also inappropriate coupling)
- preventing degradation of, Once I’ve Built an Architecture, How Can I Prevent It from Gradually Degrading Over Time?
- reasons for name, Why Evolutionary?
- reasons not to build, Why Would a Company Choose Not to Build an Evolutionary Architecture?
- reasons to build, Why Should a Company Decide to Build an Evolutionary Architecture?-Adaptation versus evolution
- evolutionary data, Evolutionary Data-Case Study: Evolving PenultimateWidgets’ Routing
- evolvability
- evolvable architectures
- anticorruption layers, Build Anticorruption Layers
- avoiding snowflake servers, Remove Needless Variability
- building, Building Evolvable Architectures-Evolving Module Interactions
- Continuous Delivery vs. snapshots, Prefer Continuous Delivery to Snapshots
- COTS implications, COTS Implications
- coupling and cohesion for, Appropriate Coupling and Cohesion
- defining fitness functions for each dimension, 2. Define Fitness Function(s) for Each Dimension
- engineering practices, Engineering Practices
- fitness functions, Fitness Functions
- guidelines for building, Guidelines for Building Evolutionary Architectures-Version Services Internally
- identifying dimensions affected by evolution, 1. Identify Dimensions Affected by Evolution
- in new projects, Greenfield Projects
- making decisions reversible, Make Decisions Reversible
- mechanics of building, Mechanics-3. Use Deployment Pipelines to Automate Fitness Functions
- migrating architectures, Migrating Architectures-Evolving Module Interactions
- mitigating external change, Mitigate External Change-Mitigate External Change
- PenultimateWidgets case study, Case Study: Evolving PenultimateWidgets’ Ratings-Case Study: Evolving PenultimateWidgets’ Ratings
- prefer evolvable over predictable, Prefer Evolvable over Predictable
- refactoring vs. restructuring, Fitness Functions
- removing needless variability, Remove Needless Variability-Remove Needless Variability
- retrofitting existing architectures, Retrofitting Existing Architectures-COTS Implications
- sacrificial architectures, Build Sacrificial Architectures
- service template case study, Case Study: Service Templates
- updating libraries vs. frameworks, Updating Libraries Versus Frameworks
- using deployment pipelines to automate fitness functions, 3. Use Deployment Pipelines to Automate Fitness Functions
- versioning, Version Services Internally
- expand/contract pattern, Shared Database Integration
- experimentation, culture of, Culture of Experimentation
- external change, Dealing with External Change
- external dependences, Mitigate External Change-Mitigate External Change
F
- FaaS (Function as a Service), “Serverless” Architectures
- Facebook, Hypothesis- and Data-Driven Development
- fan in operation, Deployment Pipelines
- fan out operation, Deployment Pipelines
- Farley, Dave, Engineering Incremental Change
- feature toggles, Deployment Pipelines, Make Decisions Reversible, Pitfall: Product Customization, Adaptation versus evolution
- fitness functions, Fitness Functions-Review Fitness Functions
- adding to PenultimateWidgets' invoicing service, Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service-Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service
- AI for, Fitness Functions Using AI
- and retrofitting existing architectures, Fitness Functions
- atomic vs. holistic, Atomic Versus Holistic
- automated vs. manual, Automated Versus Manual
- basics, What is a Fitness Function?
- brief definition, Fitness Functions
- categories of, Categories-Domain-specific
- combining categories of, Combining Fitness Function Categories-Combining Fitness Function Categories
- cycle time and, Pitfall: Lack of Speed to Release
- defined, Guided Change
- deployment pipelines with, Deployment Pipelines
- domain-specific, Domain-specific
- engineering safety net, Dealing with External Change
- enterprise-wide, Building Enterprise Fitness Functions
- guided change with (see guided change with fitness functions)
- importance of early identification, Identify Fitness Functions Early-Identify Fitness Functions Early
- in COTS software, COTS Implications
- intentional over emergent, Intentional Over Emergent
- key, Identify Fitness Functions Early
- not relevant, Identify Fitness Functions Early
- ownership and maintenance of, Testable
- relevant, Identify Fitness Functions Early
- review of, Review Fitness Functions
- static vs. dynamic, Static Versus Dynamic
- systemwide, Fitness Functions
- temporal, Temporal
- triggered vs. continual, Triggered Versus Continual
- fluid dependencies, Prefer Continuous Delivery to Snapshots
- forced decoupling, Antipattern: Inappropriate Governance
- Fowler, Chad, Remove Needless Variability, Antipattern: Inappropriate Governance
- Fowler, Martin, Build Sacrificial Architectures, Sacrificial architecture
- frameworks, libraries vs., Updating Libraries Versus Frameworks
- functional cohesion, Architectural Quanta and Granularity
- functionality, porting of, Case Study: What to Port?
- future state of evolutionary architecture, Future State?
G
- generative testing, Generative Testing
- Gibson, William, “The Future Is Already Here…”
- GitHub, architectural restructuring at, Case Study: Architectural Restructuring while Deploying 60 Times/Day-Case Study: Architectural Restructuring while Deploying 60 Times/Day
- Goldilocks Governance
- Google, 20% time at, Culture of Experimentation
- governance
- greenfield projects, Greenfield Projects
- guarded dependencies, Prefer Continuous Delivery to Snapshots
- guided change with fitness functions, Guided Change
- in Big Ball of Mud, Big Ball of Mud
- in broker EDAs, Brokers
- in COTS software, COTS Implications
- in ESB-driven SOA, ESB-driven SOA
- in layered monolithic architecture, Layered architecture
- in mediator EDAs, Mediators
- in microkernels, Microkernel
- in microservices, Microservices
- in modular monoliths, Modular monoliths
- in monolithic architectures, Unstructured monoliths
- in serverless architectures, “Serverless” Architectures
- in service-based architectures, Service-based architectures
I
- IBM (San Francisco Project), Antipattern: Last 10% Trap
- immutable infrastructure, Remove Needless Variability
- inadvertent (accidental) coupling, Microservices, Antipattern: Inappropriate Governance, Antipattern: Reporting
- inappropriate coupling, Inappropriate Data Coupling-Age and Quality of Data, Technical Architecture
- (see also appropriate coupling)
- age/quality of data, Age and Quality of Data
- Big Ball of Mud as example of, Big Ball of Mud
- business concerns, Business Concerns-Pitfall: Planning Horizons
- code reuse abuse, Antipattern: Code Reuse Abuse-Antipattern: Code Reuse Abuse
- incremental change antipatterns, Incremental Change-Antipattern: Inappropriate Governance
- Last 10% trap, Antipattern: Last 10% Trap
- leaky abstractions, Pitfall: Leaky Abstractions-Pitfall: Leaky Abstractions
- PenultimateWidgets case study, Case Study: Reuse at PenultimateWidgets, Case Study: Goldilocks Governance at PenultimateWidgets-Pitfall: Lack of Speed to Release
- planning horizons pitfall, Pitfall: Planning Horizons
- product customization pitfall, Pitfall: Product Customization
- reporting antipattern, Antipattern: Reporting
- Resume-Driven Development, Pitfall: Resume-Driven Development
- technical architecture, Technical Architecture-Antipattern: Code Reuse Abuse
- two-phase commit transactions, Two-Phase Commit Transactions-Two-Phase Commit Transactions
- vendor king antipattern, Antipattern: Vendor King
- inappropriate governance, Antipattern: Inappropriate Governance
- incremental change
- antipatterns, Incremental Change-Antipattern: Inappropriate Governance
- basics, Incremental Change
- building blocks for agility at architecture level, Building Blocks-Conflicting Goals
- combining fitness functions categories, Combining Fitness Function Categories-Combining Fitness Function Categories
- deployment pipelines and, Deployment Pipelines-Deployment Pipelines
- engineering of, Engineering Incremental Change-Case Study: What to Port?
- GitHub case study, Case Study: Architectural Restructuring while Deploying 60 Times/Day-Case Study: Architectural Restructuring while Deploying 60 Times/Day
- hypothesis- and data-driven development, Hypothesis- and Data-Driven Development-Hypothesis- and Data-Driven Development
- identifying conflicting evolution goals, Conflicting Goals
- in Big Ball of Mud, Big Ball of Mud
- in broker EDAs, Brokers
- in COTS software, COTS Implications
- in ESB-driven SOA, ESB-driven SOA
- in layered monolithic architecture, Layered architecture
- in mediator EDAs, Mediators
- in microkernels, Microkernel
- in microservices, Microservices
- in modular monoliths, Modular monoliths
- in monolithic architectures, Unstructured monoliths
- in serverless architectures, “Serverless” Architectures
- in service-based architectures, Service-based architectures
- inappropriate governance antipattern, Antipattern: Inappropriate Governance
- PenultimateWidgets case studies, Engineering Incremental Change-Engineering Incremental Change, Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service-Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service, Case Study: What to Port?
- testability of architecture, Testable-Testable
- indirection, Evolving Module Interactions
- infrastructure dysfunction, Infrastructure
- infrastructure services, ESB-driven SOA
- integration coupling, Microservices
- intentional fitness functions, Intentional Over Emergent
- internal resolution, Version Services Internally
- Inverse Conway Maneuver
- irrational artifact attachment, Pitfall: Planning Horizons
- isolation of layers, Layered architecture
L
- Last 10% trap, Antipattern: Vendor King, Antipattern: Last 10% Trap
- last responsible moment principle, Build Anticorruption Layers, Pitfall: Lack of Speed to Release
- layered architecture, Once I’ve Built an Architecture, How Can I Prevent It from Gradually Degrading Over Time?, Layered architecture
- lead time, Pitfall: Lack of Speed to Release
- leaky abstractions, Pitfall: Leaky Abstractions-Pitfall: Leaky Abstractions
- legacy data, Age and Quality of Data
- Let's Stop Working and Call It A Success Concession principle, Antipattern: Vendor King
- libraries
- Linux, How Is Long-term Planning Possible When Everything Changes All the Time?
- LMAX, Other architectural characteristics dominate
- long-term planning, How Is Long-term Planning Possible When Everything Changes All the Time?-Once I’ve Built an Architecture, How Can I Prevent It from Gradually Degrading Over Time?
M
- manual fitness functions, Automated Versus Manual
- Meadows, Donella H., Multiple Architectural Dimensions
- mediator EDA, Mediators-Mediators
- message bus, ESB-driven SOA
- microkernel, Microkernel-Microkernel
- microservices architecture, Microservices-Microservices
- migration
- modularity, architectural coupling and, Modularity
- monitoring-driven development (MDD), Triggered Versus Continual
- monolithic architectures, Monoliths-Modular monoliths
P
- package dependency cycles, Case Study: Guarding Against Component Cycles-Case Study: Guarding Against Component Cycles
- pair programming, Remove Needless Variability
- 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
- deployment pipelines at, Deployment Pipelines, Case Study: Adding Fitness Functions to PenultimateWidgets’ Invoicing Service
- evolving routing, Case Study: Evolving PenultimateWidgets’ Routing
- functionality porting decisions, Case Study: What to Port?
- Goldilocks Governance, Case Study: Goldilocks Governance at PenultimateWidgets-Pitfall: Lack of Speed to Release
- guarding against component cycles, Case Study: Guarding Against Component Cycles-Case Study: Guarding Against Component Cycles
- Inverse Conway Maneuver, Conway’s Law
- legality of open-source libraries, Building Enterprise Fitness Functions
- operational aspects of incremental change at, Engineering Incremental Change-Engineering Incremental Change
- reusable components, Case Study: Reuse at PenultimateWidgets
- selective scaling, Case Study: Selective Scale at PenultimateWidgets
- selling platform, Case Study: PenultimateWidgets as a Platform
- separation of domain services and reporting services, Antipattern: Reporting
- star rating service upgrade, Incremental Change, Engineering Incremental Change-Engineering Incremental Change, Case Study: Evolving PenultimateWidgets’ Ratings-Case Study: Evolving PenultimateWidgets’ Ratings
- performance requirements, fitness functions and, What is a Fitness Function?
- pitfalls, Evolutionary Architecture Pitfalls and Antipatterns-Pitfall: Planning Horizons
- plug-ins, Microkernel-Microkernel
- porting of functionality, Case Study: What to Port?
- predictability, evolvability vs., Prefer Evolvable over Predictable, Predictable versus evolvable
- primordial abstraction ooze, Pitfall: Leaky Abstractions
- product customization pitfall, Pitfall: Product Customization
- product, project vs., Product over Project
- production environment, exploratory testing in, Deployment Pipelines
- proof of concept, Build Sacrificial Architectures
- provider team, Dealing with External Change
- pull model, Mitigate External Change
- pull updates, Updating Libraries Versus Frameworks
- push updates, Updating Libraries Versus Frameworks
R
- refactoring, restructuring vs., Fitness Functions
- registry, Microkernel
- relevant fitness functions, Identify Fitness Functions Early
- reporting services antipattern, Antipattern: Reporting
- Resume-Driven Development, Pitfall: Resume-Driven Development
- retrofitting existing architectures, Retrofitting Existing Architectures-COTS Implications
- reusability trap, Antipattern: Last 10% Trap
- reusable frameworks
- reuse of code (see code reuse)
- reversible decisions, Make Decisions Reversible
- Richards, Mark, Prefer Evolvable over Predictable
- risk, managing with incremental change, Less Risk
- routing
- Rumsfeld, Donald, Prefer Evolvable over Predictable
S
- sacrificial architectures, Build Sacrificial Architectures, Sacrificial architecture
- Sadalage, Pramod, Evolutionary Data
- San Francisco Project, Antipattern: Last 10% Trap
- scaling
- schemas
- Scientist (GitHub framework), Case Study: Architectural Restructuring while Deploying 60 Times/Day-Case Study: Architectural Restructuring while Deploying 60 Times/Day
- second system syndrome, Build Sacrificial Architectures
- selective scaling, Case Study: Selective Scale at PenultimateWidgets
- separation of concerns, Layered architecture
- serverless architectures, “Serverless” Architectures-“Serverless” Architectures
- servers, snowflake, Remove Needless Variability
- service discovery, Evolving Module Interactions
- service endpoints, versioning, Version Services Internally
- service templates
- service, as component, Modularity
- service-based architectures, Service-based architectures-Service-based architectures
- service-oriented architectures (SOA), Service-Oriented Architectures-ESB-driven SOA
- set-based development, Culture of Experimentation
- share nothing architecture, Engineering Incremental Change, Microservices, Microservices
- Shared Database Integration, Shared Database Integration-Option 3: Existing data and integration points
- Simian Army, Combining Fitness Function Categories
- snapshots, Prefer Continuous Delivery to Snapshots
- snowflake computers, Remove Needless Variability
- snowflake servers, Remove Needless Variability
- software architecture, Software Architecture
- software development ecosystem, How Is Long-term Planning Possible When Everything Changes All the Time?
- speculative updating, Prefer Continuous Delivery to Snapshots
- spike solutions, Culture of Experimentation
- Spolsky, Joel, Pitfall: Leaky Abstractions
- static fitness functions, Static Versus Dynamic
- Sunk Cost Fallacy, Pitfall: Planning Horizons
- systemwide fitness functions, Fitness Functions
T
- Taylor, Jeffrey, Hypothesis- and Data-Driven Development
- teams
- connections between members, Connections Between Team Members
- coupling characteristics, Team Coupling Characteristics-Culture of Experimentation
- cross-functional, Cross-Functional Teams-Cross-Functional Teams
- culture of experimentation, Culture of Experimentation
- dealing with external change, Dealing with External Change
- engineering culture, Culture
- ideal size, Connections Between Team Members
- organizational factors, Organizational Factors-Connections Between Team Members
- organizing around business capabilities, Organized Around Business Capabilities
- product over project, Product over Project
- risks of not identifying fitness functions, Identify Fitness Functions Early
- structured by functional skills, Conway’s Law
- structured by service boundaries, Conway’s Law
- (see also Inverse Conway Maneuver)
- two-pizza, Product over Project
- technical architecture
- technical debt, Build Anticorruption Layers, Build Sacrificial Architectures, Adaptation versus evolution
- temporal fitness functions, Temporal, Building Enterprise Fitness Functions
- testability, Testable-Testable
- testing
- Toyota, Culture of Experimentation
- tradeoffs, Fitness Functions
- transactions, Two-Phase Commit Transactions-Two-Phase Commit Transactions
- triggered fitness functions, Triggered Versus Continual
- Twitter, Build Sacrificial Architectures
- two-pizza teams, Product over Project
Building Evolutionary Architectures
Published by
O'Reilly Media, Inc., 2017