Building Evolvable Architecture
Building Evolvable Architecture:
Mechanic
1) Identify Dimentions Affected by Evolution
2) Define Fitness Function(s) for Each Dimention
3) Use deployment Pipelines to Automate Fitness Functions
Evolvable Arch in Greenfield Projects
Retrofitting Existing Architectures
-Identify Appropriate Coupling and Cohesion
-Develop Engineering Practices
-Identify and design Fitness Functions
What is Refactoring Vs Restructuring
COST (Commercial off-the-shelf) Implications
Migrating Architectures
Migrations Steps:
-A monolith architecture as the starting point for migration, a "share every thing" architecture.
-The service based, "share a little as possible" end result of the migration.
-Business functionality groups
-Transactiona boundaries
-Deployment goals
Evolving Module Interactions
Module with efferent and afferent coupling --> Modules with a common dependency-->Splitting the shared dependency-->SHaring a dependency via a JAR file -->Duplicatting a shared library to eliminate a coupling point.
Guideline for building Evolutionary Architecture:
-Rmove Needless Variability
-one of the goal of Continuous Delivery is stability
-Modern DevOps replaced snowflakes with immutable infrastructure.
-Immutable infrastructure
-Make Decisions Reversible
- Blue/green deployments
-Feature Toggles
-Prefer Evolvable over Predictable: All architectures become iterative because of unknown unknowns; agile just recognizes thi and does it sooner.
-Build Anti-corruption Layers
Build Sacrificial Architectures
Migrate External Change
Updating Libraries Versus Frameworks
Prefer continuous delivery to Snapshots
Version Services Internally
Evolutionary Architecture Pitfalls and Anti-patterns:
Antipatterns: Vendor King
Pitfalls: Leaky Abstractions
Antipattern: Last 10% Trap
Antipattern: Code Reuse Abuse
Pitfalls: Resume-Driven Development
Incremental Change
Antipattern: Inappropriate Governance -Forced Decoupling
Goldilocks Governance at PenultimateWidgets
Pitfall: Lack of Speed to Release
Business Concerns:
Pitfall: Product Customization
-Unique build for each customer
-Permanent feature toggles
-Product-driven cutomizaition
Antipattern: Reporting
-Separation of domain and reporting services, coordinated via message queues
Pitfall: Planning Horizons: Don't become irrationally attached to handcrafted artifacts.
-----------------
Putting Evolutionaryy Architecture into Practice:
--------------------
Organizational Factors
-Cross functional Teams (Business Analysts, Architecture, Testing, Operations, Data)
Finding new resources via automating DeveOps
Organization around Business Capabilities
Organize teams around business capabilities not job functions.
Product over Project: teams emphasis is to model their work around products rather projects.
e.g Amazon's "Two Pizza " Teams
Dealing with External Change: Consumer driven contracts use thests to estabilsh contracts between a provider and consummers.
Connections Between Team Members:
Team Coupling Characteristics
Culture
Culture Experimentation
-Encourageing explicit improvement
-Spike and Stabilize
-Creating Innovation time
-Following set-based development
-Connecting engineers with end-users
CFO and Budgeting
Building Enterprise Fitness Functions
Where do you Start?
-Low hanging gruit
-Highest Value
-Testing
-Infrastructure
Future State?
-Fintess Functions Using AI
-Generative Testing
Why or Why NOt?
-Predictabble vs Evolvable
-Scale
-Advance Business cpabilities
-Cycle time as a business metric
-Isolating architectural characteristics at the quantum level
Mechanic
1) Identify Dimentions Affected by Evolution
2) Define Fitness Function(s) for Each Dimention
3) Use deployment Pipelines to Automate Fitness Functions
Evolvable Arch in Greenfield Projects
Retrofitting Existing Architectures
-Identify Appropriate Coupling and Cohesion
-Develop Engineering Practices
-Identify and design Fitness Functions
What is Refactoring Vs Restructuring
COST (Commercial off-the-shelf) Implications
Migrating Architectures
Migrations Steps:
-A monolith architecture as the starting point for migration, a "share every thing" architecture.
-The service based, "share a little as possible" end result of the migration.
-Business functionality groups
-Transactiona boundaries
-Deployment goals
Evolving Module Interactions
Module with efferent and afferent coupling --> Modules with a common dependency-->Splitting the shared dependency-->SHaring a dependency via a JAR file -->Duplicatting a shared library to eliminate a coupling point.
Guideline for building Evolutionary Architecture:
-Rmove Needless Variability
-one of the goal of Continuous Delivery is stability
-Modern DevOps replaced snowflakes with immutable infrastructure.
-Immutable infrastructure
-Make Decisions Reversible
- Blue/green deployments
-Feature Toggles
-Prefer Evolvable over Predictable: All architectures become iterative because of unknown unknowns; agile just recognizes thi and does it sooner.
-Build Anti-corruption Layers
Build Sacrificial Architectures
Migrate External Change
Updating Libraries Versus Frameworks
Prefer continuous delivery to Snapshots
Version Services Internally
Evolutionary Architecture Pitfalls and Anti-patterns:
Antipatterns: Vendor King
Pitfalls: Leaky Abstractions
Antipattern: Last 10% Trap
Antipattern: Code Reuse Abuse
Pitfalls: Resume-Driven Development
Incremental Change
Antipattern: Inappropriate Governance -Forced Decoupling
Goldilocks Governance at PenultimateWidgets
Pitfall: Lack of Speed to Release
Business Concerns:
Pitfall: Product Customization
-Unique build for each customer
-Permanent feature toggles
-Product-driven cutomizaition
Antipattern: Reporting
-Separation of domain and reporting services, coordinated via message queues
Pitfall: Planning Horizons: Don't become irrationally attached to handcrafted artifacts.
-----------------
Putting Evolutionaryy Architecture into Practice:
--------------------
Organizational Factors
-Cross functional Teams (Business Analysts, Architecture, Testing, Operations, Data)
Finding new resources via automating DeveOps
Organization around Business Capabilities
Organize teams around business capabilities not job functions.
Product over Project: teams emphasis is to model their work around products rather projects.
e.g Amazon's "Two Pizza " Teams
Dealing with External Change: Consumer driven contracts use thests to estabilsh contracts between a provider and consummers.
Connections Between Team Members:
Team Coupling Characteristics
Culture
Culture Experimentation
-Encourageing explicit improvement
-Spike and Stabilize
-Creating Innovation time
-Following set-based development
-Connecting engineers with end-users
CFO and Budgeting
Building Enterprise Fitness Functions
Where do you Start?
-Low hanging gruit
-Highest Value
-Testing
-Infrastructure
Future State?
-Fintess Functions Using AI
-Generative Testing
Why or Why NOt?
-Predictabble vs Evolvable
-Scale
-Advance Business cpabilities
-Cycle time as a business metric
-Isolating architectural characteristics at the quantum level
Comments
Post a Comment