Patterns of Evolutionary Architecture - Agile and Beyond 2018

Patterns of
Evolutionary
Architecture
Chris Gow and Shawn Button
Agile and Beyond 2018

Do the following
sound familiar?

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

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.

Anti-Pattern: No Design
While we don’t want to design everything up front, we also
don’t want to not have the entire system be emergent and
have no plan. That typically leads to systems that are brittle,
coupled in inappropriate ways and are viscous, not cohesive.

Anti-Pattern - Ivory Tower Architect

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.

Anti-Pattern: Steamrolled Architect

Anti-Pattern - Steamrolled Architect
Architects that have little influence over the development of the
product can’t ensure that the architecture continues to meet the
needs of the business.
We have seen this happen for multiple reasons, including:
• The business does not listen to IT’s advice, and insists all
development effort be spent on new features
• The architect is powerless within IT, so the team does not take
their guidance
• Architects perform project management activities, rather than
architectural
• Architects who do not have the knowledge to guide good
architecture

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

Anti-Pattern: If Framework is Good, Use It All!
A common anti-pattern is the over-use of frameworks. Applications become
excessively complicated by using a framework that requires a solution might not be
a match for the problem we are trying to solve.
E.g. Spring :)
We also see this in large home-grown Enterprise frameworks. They are created to
simplify and standardize creation of new apps, but end up forcing the same solution,
regardless of whether it is the best solution.
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

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 extension over customization
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: Vendor King / Last 10% Trap

Exercise: What Do You See At Your Org
Find someone from a different organization than yours.
In this pair, share what architectural anti-patterns do you see
in your orgs?
You have 5 minutes

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 - 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.

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.

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.

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: 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)

Exercise: The Process of Architecture
Find a different person from a different organization than
yours.
In this pair, share how your org ensures good architecture
happens.
You have 5 minutes.

What is an Evolutionary Architecture?
"An evolutionary architecture
supports guided, incremental change
across multiple dimensions."
Ford, Neal; Parsons, Rebecca; Kua, Patrick. Building Evolutionary Architectures: Support Constant Change

What is an Evolutionary Architecture?

Evolutionary Architecture
vs.
Emergent Design

Evolutionary Architecture vs. Emergent Design
In Emergent design the code guides you on where to go next
based on learning
In Evolutionary architecture you guide the system on where to
go based on business objectives

Architecture Is A Balancing Act

Architecture Is A Balancing Act
Architects are constantly faced with trade-offs.
There are many, many different aspects to architecture, and
often improving one results in a reduction of another.

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

Business goals
Build
Architecture
measures
Architecture
decisions
Architecture
guidance
Architecture
qualities
Double Loop Architecture

Double loop architecture is a process that you can use to
ensure that your architecture continues to satisfy the
business needs of your product.

A Fitness Function
"... is an objective function used to
summarize how close a
prospective design solution is to
achieving the set aims.”

Fitness Functions For Architecture
Define a set of criteria by which we can measure the
fitness of our architecture.
These can be qualitative or quantitative.
Qualitative functions can be automated.
They might also be atomic or holistic.
An atomic fitness function can be tested in isolation. For
example, modular coupling. Holistic functions must be
tested with other functions. For example performance and
reliability might impact each other.

Example Tools for Fitness Functions
! Static code analysis
! Unit test frameworks
! penetration testing tools
! load testing tools
! monitoring tools
! logging tools
! run through CI/CD pipeline
! trigger based on an event

Fitness Function for "Coupling"
public void testMatch() {
DependencyConstraint constraint = new DependencyConstraint();
JavaPackage persistence = constraint.addPackage("com.xyz.persistence");
JavaPackage web = constraint.addPackage("com.xyz.web");
JavaPackage util = constraint.addPackage("com.xyz.util");
persistence.dependsUpon(util);
web.dependsUpon(util);
jdepend.analyze();
assertEquals("Dependency mismatch", true, 
jdepend.dependencyMatch(constraint));
}

Fitness Functions in CI/CD Pipeline

https://blogs.sap.com/2016/04/06/load-testing-with-jmeter-test-results-visualization-using-kibana-dashboards/
Make fitness function measures visible

Fitness Function Landing
Zones

http://wirfs-brock.com/blog/2011/07/20/introducing-landing-zones/
Attribute Minimum Target Outstanding
Battery life – standby 300 hours 320 hours 420 hours
Battery life – in use 270 minutes 300 minutes 380 minutes
Footprint in inches 2.5 x 4.8 x .57 2.4 x 4.6 x .4 2.31 x 4.5 x .37
Screen size (pixels) 600 x 400 600 x 400 960 x 640
Digital camera resolution 8 MP 8 MP 9 MP
Weight 5 oz. 4.8 oz. 4.4 oz.
Landing Zone for Smart Phone

Quality Min Target Outstanding
Recovery 12h 15m Immediate
Availability 99.9 99.99 99.999
Landing Zone for Availability

Double Loop Architecture - Example
Business goals
Build
Architecture
measures
Architecture
decisions
Architecture
guidance
Architecture
qualities

Customers can
work whenever
they want
Build
Architecture
measures
Architecture
decisions
Architecture
guidance
Architecture
qualities

Customers can
work whenever
they want
Build
Architecture
measures
Architecture
decisions
Architecture
guidance
Availability

Customers can
work whenever
they want
Build
Architecture
measures
Architecture
decisions
Availability
Min Target Outstanding
Fitness Function
Landing Zone

Customers can
work whenever
they want
Build
Architecture
measures
Stories added to
backlog
Availability
Fitness Function
Landing Zone
• Provision rep. db
• Monitor service
• Automated switch

Customers can
work whenever
they want
Build
Architecture
measures
Stories added to
backlog
Availability
Fitness Function
Landing Zone
• Provision rep. db
• Monitor service
• Automated switch
• Product availability
measures
• Deliberate fail
(simian army)

Double Loop Architecture - Example 2
Business goals
Build
Architecture
measures
Architecture
decisions
Architecture
guidance
Architecture
qualities

We want to
safeguard
customer data
Build
Architecture
measures
Architecture
decisions
Architecture
guidance
Architecture
qualities

We want to
safeguard
customer data
Build
Architecture
measures
Architecture
decisions
Architecture
guidance
Security

We want to
safeguard
customer data
Build
Architecture
measures
Architecture
decisions
Fitness function
landing zone
Security
encrypt data Passwords encrypted
databases
Encrypted logs

We want to
safeguard
customer data
Build
Architecture
measures
Stories added to
backlog
Fitness function
landing zone
Security
databases
Encrypted logs
• Add hashing to
password field in
user table
• …

We want to
safeguard
customer data
Build
Architecture
measures
Stories added to
backlog
Fitness function
landing zone
Security
databases
Encrypted logs
• Add hashing to
password field in
user table
• …
Tests to validate
database is
encrypted

Business goals
Build
Architecture
measures
Architecture
decisions
Architecture
guidance
Architecture
qualities

Double-loop Architecture Tips
Define your fitness functions early.
Collaborate with the team and the business to prioritize
architectural improvements.
Continually refine the fitness functions as you learn more
about the architectural needs, as you improve, or as your
goals evolve.

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.
! 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

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.

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 Mentor

Architect as Mentor - Story
A mutual colleague of Declan’s and I once had an opportunity to work at an
organization where one of the architects in the department he was working in....

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.

http://agilemodeling.com/essays/initialArchitectureModeling.htm
Make the architecture visible

Architect Community
of Practice

Architect Community of Practice
Your architects will be spending more time with the team. This means that
they need to find a way to coordinate with each other.
Avoid introducing “governance” with accompanying hierarchy and process.
Instead create a community of practice which is empowered to provide
architectural oversight. It should be self-organizing and open to people other
then just the “architects.”
This encourages architecture over architects. It allows everyone to have a
say in the architecture, and provides a path for everyone to improve their
architectural knowledge and experience.

Architecture community - Story
Nulogy architecture community. Shawn was the first architect and wanted to share
that responsibility. At first this was challenging since developers kept deferring to
his decisions. We use a tool from Management 3.0 called delegation poker to help
determine the level of responsibility people should have and build our community

Architect community of practice - Story
Guidewire Architect group
Teams made many of their own decisions
Architects provided a broader view of the systems
Architects from different groups provided insight in how they solved similar
problems

Architecture Workshops
Regular Architecture Workshops:
• Allow everyone to contribute to the architecture, ensuring the
best possible solutions
• Spreads knowledge from the architect, and within the team
• Allows the architect and product owner to co-prioritize
between feature and architectural delivery
• Ensures that everyone understands the business goals
behind architectural decisions.

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.

Key Take Aways
• Drive architecture qualities from business goals
• Guide architecture through double loop architecture
• Share architecture responsibilities through the
organization

Patterns of Evolutionary Architecture - Agile and Beyond 2018

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Patterns of Evolutionary Architecture - Agile and Beyond 2018

Similar a Patterns of Evolutionary Architecture - Agile and Beyond 2018 (20)

Más de Shawn Button

Más de Shawn Button (6)

Último

Último (20)

Patterns of Evolutionary Architecture - Agile and Beyond 2018