Patterns of Evolutionary Architecture

Patterns of
Evolutionary
Architecture
Chris Gow and Shawn Button
Toronto Agile - 2017

To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
People
Patterns
Conway’s
Law
Work
Together
Wrap Up

Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
People
Patterns
Conway’s
Law
Work
Together
Wrap UpWrap Up

Change
Change in an application is inevitable.
We need to support:
1. New business requirements (“We need to sell a new
type of widget”)
2. Updates to existing technologies (“We need to patch
our platform’s security hole ASAP”)
3. New technologies (“This database doesn’t support our
needs, we need to move to a NoSQL db”)
4. New non-functional needs (Yah, our business is
booming. Oh SH*T, our business is booming!)

Principle - Design for Change
Since change is inevitable, let’s design our
architecture to expect change, harnessing it for
the customer’s advantage.

manageability
modifiability
modularity
operate
ability
orthogonality
portability
precision
predictability
producibility
probability
recoverability
relevance
reliability
repeatability
reproducibility
resilience
responsiveness
The Architecture “-ilities”
deployability
discoverability
distributability
durability
effectiveness
efficiency
usability
extensibility
failure-transpar
ency
fault-tolerance
fidelity
flexibility
inspectability
Installability
Integrity
interoperability
learnability
maintainability
accessibility
accountability
accuracy
adaptability
administrability
affordability
auditability
autonomy
availability
compatibility
composability
configurability
correctness
credibility
customizability
debugability
degradability
determinability
dependability
reusability
robustness
safety
scalability
seamlessness
self-sustainability
serviceability
secure
ability
simplicity
stability
standards-compliance
survivability
sustainability
tailorability
testability
timeliness
traceability
List from “Building Evolutionary Architectures”

Principle - Evolvability as
First Class Concern

Principle - Evolvability as First-Class Architectural Concern
Architecture involves a series of trade-offs. There are many different concerns
that you need to juggle. Non-functional requirements (NFRs) like scalability,
performance, security. As well there are business features are the point of the
application.
The requirement to deliver quickly, and to be able to evolve our application
over time should prioritized against our need for performance, etc. They
because “first class citizens” in all architectural tradeoffs.
Alongside concerns such as scalability, performance, security, etc. Frequent
Delivery and Evolvability and should be primary concern.

Intro
Guiding
PrinciplesCoupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
People
Patterns
Conway’s
Law
Work
Together
Wrap Up

Coupling in software occurs whenever a change in one component requires
changes in another component and this affects the evolvability of your
application. Some degree of coupling may be necessary, you want to minimize
the coupling and keep it isolated and at system boundaries. When coupling is
uncontrolled you can get yourself into a big ball of mud situation.
Some examples of coupling are 3rd party systems, communication patterns
and data structures.
Principle - Coupling

Anti-pattern: Big Ball of Mud
“A Big Ball of Mud is a casually, even haphazardly, structured system. It’s
organization and structure appears to be dictated more by expediency than
design. A quick fix here, a bandaid there, a temporary solution on top of
another and what was once tidy becomes overgrown as piecemeal growth
allows elements of the system to sprawl in an uncontrolled fashion”
- Brian Foote - 1999

Inappropriate and Appropriate Coupling

Inappropriate and Appropriate Coupling
Coupling can either hamper the evolution of your architecture or help
accelerate it if applied appropriately.
Coupling is inappropriate when your architecture is being constrained by
previous design choices or external libraries and frameworks. When changes
and fixes are isolated and generally not risky; components are small with
minimal dependencies then coupling is appropriate.

Risky changes, long periods of instability, developers afraid to make changes
to parts of the code, unable to adapt to a new framework. These are types of
inappropriate coupling and they really affect how your architecture can evolve
and change as business requirements change. Often coupling hides behind
the promise of speed and utility but when not looked out for, your
architecture can run off the rails
Some examples of inappropriate coupling are
● Utility classes - sticking functions such as formatting functions (date
format, number format, money format) in a single class
● Single object type representation throughout application (e.g.. A canonical
Product type)
● Using a 3rd party’s data type throughout your application (eg. A Facebook
User type)
Inappropriate Coupling

Anti-Pattern: Spooky Action At A Distance

Anti-Pattern: Spooky Action At A Distance
- Not applying the DRY Principle: Every piece of knowledge must have a
single, unambiguous, authoritative representation within a system
-
- Changing one thing affects something else, potentially unrelated
- Changes to the UI should not have any effect on the database and
many database changes should not affect the UI

Anti-Pattern: Misapplying the DRY Principle

Anti-Pattern: Misapplying the DRY Principle
In many architectures it is common to have a small set of core classes or types
that represent core domain concepts in your organization.
It is tempting to have only one such type for each concept (eg. A single
Product class type or Customer class), however different parts of your
organization will have different interpretations of what each of these
concepts.
Attempting to have a single model to put all of these interpretations in a single
type leads to ambiguity and a model that is more difficult to understand.

Cohesive Systems - Appropriate Coupling
When a change in one thing does not affect any other thing then the system is
exhibiting an appropriate level of coupling or cohesiveness. A highly cohesive
system exhibits reduced risk, increased productivity, and components are
simplified and generally “Do one thing really, really well”. Testing of
components is much simpler as the degree of cohesiveness increases, the
amount dependencies decreases.
As individual components become simplified and more cohesive their
interactions with other components may become more complex. A message
passing function call from type to another type is highly coupled, passing the
same message over a message bus requires a higher degree of infrastructure
complexity.

Principle: Keep coupling isolated and at system
boundaries

Eliminate effects between unrelated things
Principle: Keep coupling isolated and at system
boundaries

Pattern: Bounded Contexts
Multiple models exist within a large project, when code based on distinct
models is combined software becomes buggy, unreliable and difficult to
understand. It’s also often unclear which context a model should not be
applied. A Bounded Context gives team members a clear and shared
understanding of what has to be consistent and what can develop
independently.
Explicitly set boundaries and keep model strictly consistent within these
bounds

Pattern: Abstraction / Anti-Corruption
layer

A layer that permits only the information your model needs to pass through
when other models (or systems) are communicating to it. Permit information
through the anti-corruption layer in a format that works best for your model
and discard the external model’s representation. This allows your model to
evolve in a manner that works best for it and not be affected by changes in
the external model’s own evolution.
An anti-corruption layer can also abstract away dependencies when working
with frameworks and existing legacy code bases
Pattern: Abstraction / Anti-Corruption layer

Principle - Changeable/Deferred Decisions

Principle: Changeable/Deferred Decisions
Changeable Decisions
Whenever possible we want to make our decisions changeable. If we can
change our decisions it protects us from the risk of future unknowns.
Deferred Decisions
For changes that are hard to reverse, figure out ways that we can defer the
decisions as much as possible. The longer we wait the more we know about
what we actually need.

Anti-Pattern: Big Design Up Front

Anti-Pattern: Big Design Up Front
We are afraid of making mistakes in design, so we spend a lot of time
analyzing and designing up front, in order to make sure we get it right the first
time.
Unfortunately:
● We won't get it right. No matter how much effort we put into it.
● We will add things to our architecture that we will not need.
● It will delay our ability to deliver something quickly to customers to get
early value and feedback.

Pattern: Lightweight Collaborative Design

Pattern: Lightweight Collaborative Design
While we want to minimize up-front design, we still have to think about the
architecture.
Create lightweight, collaborative, living design.
For example, do it in front of a white-board with the entire team.

Pattern: Build
Throwaway Prototypes

Pattern: Build Throwaway Prototypes
In order to see if a technology decision is correct, make a quick prototype.
We stress that they should be throwaway, because we need to keep them light,
and just do the minimum that we need in order to learn if it is suitable.
If you are faced with a choice between several architectures, do prototypes for
both and learn which works best for you. Do “set-based” design, where you
explore multiple alternatives at once.

Pattern: Sacrificial Architecture

Pattern: Sacrificial Architecture
Since we understand that it is difficult and expensive to get our architecture
perfect up front, be prepared to throw away any architectural element.
A great example is Twitter. They started with Ruby on Rails, which allowed
them to quickly get into the market. When they needed to scale they changed
their architecture. Yes it was painful to change, but they were able to get into
the market quickly, and as they scaled they had a much better idea of their
needs.

Principle: YAGNI
(You Ain’t Gonna Need It!)

Principle: YAGNI (You Ain’t Gonna Need It)
As engineers we have the desire to build a robust framework that will handle everything
that we ever need to handle, forever into the future.
The problem is that only a subset of the cool features we add will ever get used. The
rest just add complexity and slow us down.
When you design your architecture keep YAGNI in mind. Only add something if you
need it to deliver a feature for a needed non-functional requirement.
If you’ve built an evolvable architecture you can always add it later!

Anti-Pattern: Enterprise Platform

Anti-Pattern: Enterprise Platform
The company creates a platform for all teams to use, with the best of intentions:
● Faster delivery by providing the plumbing.
● People can move between teams because the platform is the same.
● We can enforce governance, monitoring, etc.
Unfortunately this is a form of coupling that can slow teams down.
● They are dependent on a framework, and they can’t change.
● In order to make it work for everyone’s needs it will get bigger and bigger, and then
it won’t really work well for anyone.

Anti-Pattern: If Framework is Good, Use It All!

Anti-Pattern: If Framework is Good, Use It All!
E.g. Spring :)
Really, it’s the urge for over-complication that’s the problem.
Find the simplest way to do something. Do it. Maybe that’s enough. If not you
can come back and add to it later (see also YAGNI)
As much as possible keep your domain logic agnostic of the framework you
are using! Build an abstraction layer between you and your framework.

Anti-Pattern: Vendor
King / Last 10% Trap

Anti-Pattern: Vendor King / Last 10% Trap
Buying a product from a big vendor can seem very attractive. They
promise you that they give you the features you want without needing
those nasty developers.
● First 80% is easy. Next 10% is hard. Last 10% is impossible.
● Might not support for rapid delivery (no automated tests, poor code
control practices, hard to deploy)
● Might be hard to evolve (locked into a someone else’s architecture)
● Vendor Lock-in - Makes it hard to change your mind
● Look for vendors that allow
This also might apply to the frameworks you use. There lock-in pressure
when you choose to use Drupal, Rails, Spring, Angular, etc.
As much as possible keep your domain logic agnostic of the framework
you are using!

Anti-Pattern: Premature Micro-Services

Anti-Pattern: Premature Micro-Services
Microservices are a great way to encourage decoupling components.
But they come with extra complexity around design, code management,
deployment, testing, operations.
They might also not be appropriate when you are in MVP stage.
This doesn’t mean don’t do it, but realize that you need to build the
infrastructure, the discipline and the practices to support it.
Start slow with a couple of services. Grow your services as you learn how to do
it.

Principle - Frequent Delivery
Focus on delivering more frequently.
In order to evolve your architecture you need
the infrastructure, discipline and practices to
allow you to deploy frequently with safety.
(Side benefits: gives us opportunities for earlier value and
feedback. You know, agility).

Pattern - Automate All The Things

Pattern: Automate All The Things
Delivering frequently will require a lot of re-work and will be dangerous, unless
you can automate your repetitive tasks:
● Testing (unit -> end-to-end)
● Deployment
● Environment provisioning
● Performance testing
● Production monitoring
● Tech debt measures (test coverage, complexity, etc.)
● etc….

Pattern: Invest in Practices
Delivering frequently requires discipline and heavy investment in modern
technical practices. You will need
This might require:
● Creating new “Devops” infrastructure
● Training/coaching/mentoring in the new practices
● Hiring new people with the new skills
● Slowing down a little until you gain the ability to speed up (relief from
deadlines)

http://bonkersworld.net/building-software

Anti-Pattern: The Rewrite Trap
- Always harder than you expected
- Takes longer
- While we are re-writing we still have to keep the old system updated, so
making changes in two places
- Faced with the same compromises that you made the first time
- Using the same people and the same practices, we will end up with the
same mess
Company killing examples: Lotus 123, Mozilla

Principle - Improve Incrementally

Pattern: Improve Incrementally
To avoid the dangerous and risky rewrite trap improve your legacy application
incrementally.
Pull out a small bits of behaviour, while keeping the existing application
running.
The new pieces can be built with modern architectural concerns, including
evolvability.
Eventually you may have moved everything over to the new architecture, and
can decommission the legacy application.

All transactions
Strangler Pattern in Action - The Interceptor
Client
Scary
Legacy
App
Backend
System
Interceptor
/ Facade
New
Business
Logic
Some transactions

Pattern - The Strangler
Don’t rewrite your legacy application in one go. Incrementally move features
over to your new architecture, while keeping the old one running.
Gradually evolve a new system over the edges of the old.
Intercept transactions going to your legacy system, and route them to the
new.
It works best if the old and new systems are not aware of each other.

Pattern - Sprout Component
Client
Scary
Legacy
App Backend
System
New
Business
Logic
New
Some “Seam”

Pattern - Sprout Component
From Michael Feathers “Working Effectively With Legacy Code.” Feathers
described it as a way to refactor existing code. Find a “seam” into the existing
app, and write new behaviour in a new method or class.
But this could also be used at a higher architectural level.
Potential seams:
● Method calls in code
● Events on a message Bus
● Significant business events
● Table updates
● Log files
○ 3rd party integrations
○ File extracts (eg. Excel, CSV)
There’s lots of options. Be Creative!

Principle - People First
As technologists we have an instinct to try to solve our problems through
processes or tools.
Unfortunately a lot of our problems are only solvable through individuals and
interactions.

Conway’s law
“Any organization that designs a system
(defined broadly) will produce a design
whose structure is a copy of the
organization's communication structure.”
- Melvin Conway

Consequence of Conway’s Law
Your company’s organization structures will exert pressure on the architecture
of your applications.
For example, if you have “back-end,” “middle-tier,” and “front-end” hierarchies,
and you are attempting trying to move to a micro-service architecture you will
find it difficult. And in fact you might end up building “micro-services” that are
“middle-tier” and “back-end” services, rather than being organized around
your domain.

Principle - Organize to take advantage of Conway’s Law.

Principle - Organize to take advantage of Conway’s
Law.
Define an org structure that supports your real or desired application
structure.
Minimize dependencies between teams (which slow you down) by organizing
to match your architecture.

Pattern - Autonomous Feature Teams
A feature team has all of the necessary resources, skills and autonomy to
complete end-to-end customer features on their own. They work across all
components and disciplines.
(As opposed to a “component team” that only delivers one of many pieces that
are needed to deliver customer value).
By organizing into feature teams you lessen the dependencies that will slow
down delivery.

Pattern - Product over Project

Pattern - Product over Project
People working on a “project” expect that they are on a temporary
assignment. When it’s done, they will move on to other projects.
The application is seldom treated as a 'product', that needs to live in
production for many years after the project is completed.
This encourages short-term thinking - deliver the next set of features - rather
than taking attempting to maximize the the long-term value of the product.
This leads to problems such as the accumulation of technical debt.
Long-term, product thinking is essential for people from both business and
technology.

Principle - Work Collaboratively

● Good architecture can’t be done in a isolation
● Different perspectives make a better product
● Avoid the us against them mentality “Business doesn’t know
what they’re talking about”, instead work together to reach
your shared goal
Principle - Work Collaboratively

Anti-Pattern - Internal
Vendor/Customer Relationship

Anti-Pattern - Internal Vendor/Customer
Relationship
Everyone that’s necessary to produce value for the customer (business,
technology, operations, etc.) should have the shared goals of the maximizing
value delivered to the customer.
Unfortunately we often find an antagonistic relationship between these
groups. It seems that it becomes more important to “win” or to assign blame
the other groups, than to work together to create valuable software.

Pattern - Shared Prioritization

Pattern - Shared Prioritization
We make an artificial distinction between “business features” and
“architecture.” In reality both are necessary to deliver value to our customers.
Prioritize architectural concerns (such as performance, security, technical
quality, evolvability, etc), UX requirements (usability, accessibility), alongside
business requirements as peers.
This is fractally collaborative - it applies at team, product, and portfolio level.

Anti-Pattern - Ivory Tower Architecture

Anti-Pattern - Ivory Tower Architecture
Architecture that is devised hidden away in relative isolation from the
day-to-day development activities suffers from significant problems.
The models in this type of architecture are often designed with little or
no input from the development teams who will be charged with coding
the architecture “vision”.
Perfect in theory, but often unproven and incomplete, ivory tower
architectures often fall victim to over complications and reflect features
from every system the architects were involved with instead of what is
necessary to solve your business problem.

Being the repository of all knowledge and decision making makes them into a
dependency, and an impediment to teams delivering rapidly.
Architects might struggle with finding their new role in an environment where
autonomous feature teams are rapidly delivering.
They need to transition to being a coach and mentor.
They need to teach teams how to create good architecture, and eventually
empower the teams to make their own architectural decisions.
Pattern - Architect as Coach

Unix Principles:
1. Make each program do one thing well. To do a new job, build afresh
rather than complicate old programs by adding new “features”.
2. Expect the output of every program to become the input to another, as
yet unknown, program. Don't clutter output with extraneous information.
Avoid stringently columnar or binary input formats. Don't insist on
interactive input.
3. Design and build software, even operating systems, to be tried early,
ideally within weeks. Don't hesitate to throw away the clumsy parts and
rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task,
even if you have to detour to build the tools and expect to throw some of
them out after you've finished using them.
Doug McIlroy, E. N. Pinson, B. A. Tague (8 July 1978). "Unix Time-Sharing System Forward". The Bell System Technical Journal. Bell
Laboratories. pp. 1902–1903.
None of This Is New!

Patterns of Evolutionary Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Patterns of Evolutionary Architecture

Similar to Patterns of Evolutionary Architecture (20)

More from Shawn Button

More from Shawn Button (6)

Recently uploaded

Recently uploaded (20)

Patterns of Evolutionary Architecture