In this session we will discuss the use of Agile constructs within the domain of software architecture. This will include an exploration of how to balance emergent designs with intentional planning. Additional ancillary topics will also be addressed including: common architecture principles, guidelines for measuring good architecture, and an evaluation of agile techniques.
By the end of the session, attendees will have a new perspective on architecture that will empower them to create flexible software solutions.
2. #craftingdigital
Who Is This Guy?
Steve P. Green
Steve currently serves as the Chief Executive
Officer for Blue Rivet, a collaborative digital agency
in Kansas City.
My professional experience
I consider code an art form, and have worked to master
the craft over the last 18 years at some of the finest
technology companies in Kansas City.
3. #craftingdigital
Understanding My Bias
Seth Godin
One of the most-loved marketing gurus on
the internet, generating 50 million views per
month.
I believe that building software is fun. More importantly, I
view it as something worthy of mastery.
“If it’s work, we try to do
less. If it’s art, we try to
do more.” – Seth Godin
5. #craftingdigital
How Do We Think About Architects?
Architectural Astronauts
Beware of folks who love to think about abstractions more
than coding software.
There is this notion
that architecture is
beyond programming.
6. #craftingdigital
Why Is Architecture Being Minimized?
Architecture is No Longer a Prerequisite
There are many contributing factors that have caused
traditional architecture to be de-emphasized.
Architecture Still Happens
Even if not explicitly seen, architecture still occurs in all
development cycles, just in different ways.
Speed to Market – Increasing pressure to deliver
value as fast as possible.
Advanced Tooling – Development systems make it
easier to “do the right thing”.
Lower Barriers – Young engineers enter the
workforce with a heightened focus on delivery.
Continuous Delivery – Developers want to
maximize learnings from their code.
7. #craftingdigital
The Agile Misnomer
Working Software > Documentation
• This has been interpreted as "working
software, no documentation”.
• Traditional architecture is viewed in a
waterfall approach with diagrams as
the output.
• So if we’re not doing diagrams, are we
doing architecture? Yes, it’s just a
continuous activity in the agile
iterations.
Responding to Change > Having a Plan
• This has been interpreted as
”responding to change, having no
plan”.
• We want something we can change
rather than a plan set in stone;
something to iterate on.
• This isn’t cowboy coding; planning is
not bad, it just must be mutable.
8. #craftingdigital
Agile Team Roles
Agile Is Focused on the Team
Agile has been primarily concerned with the team
space, which has dramatically impacted what
architecture actually is.
Where Is the Architect?
Notice that in a traditional agile team, there is no
defined architect role.
9. #craftingdigital
Is Architecture Even Relevant?
What is the current
state of architecture in
our industry?
Architectural Thinking Is Key
A whiteboard is the most important architectural tool you
have, because it promotes architectural thinking
throughout the team.
10. #craftingdigital
Economics vs. Craftsmanship
“We need to put less
effort on quality so we
can build more features
for our next release"
Business Wants Features, Not Architecture
If we are going to be successful at building solid
architectural systems, we must make an economic
case for it.
Nothing Happens Until Something Is Sold
While good architecture should be fundamental to a
software craftsman, it still must be sold.
11. #craftingdigital
External vs. Internal Quality
Good UX
Few Defects
Good Design
External
Quality
Internal
Quality
Kill the Quality Myth
Good design breaks the cycle of quality myth: that it’s impossible
to have both good code that can be built quickly.
12. #craftingdigital
Good Design Accelerates Features
FUNCTIONALITY
TIME
Good Design
No Design
The Design Stamina Hypothesis
Good design promotes the long-term vision of a project
by making features easier to implement over time.
13. #craftingdigital
A Real World Example
Bad architecture builds quietly over time until it
becomes unmanageable.
No one sets out to design software poorly; rather it happens slowly over time. Consider this
messy kitchen. The designer didn’t set out to create this disaster. Instead, it happened naturally
over time as the result of small bad decisions that incrementally destroyed this space.
14. #craftingdigital
An Example In Code
This is a massive SQL query
from the Daily WTF called the
“Query of Despair”.
However, even though it is
hard for us humans to
understand, the computer has
no problem.
The “Query of Despair”
15. #craftingdigital
How Is Architecture Measured?
“Any fool can write code a
computer can understand. Good
programmers write code that
humans can understand.” – Fowler
Good Design Is
Easily Consumed
1 Delivery: maintaining
good design allows us to
deliver solutions faster
given it is easier to work
with the code.
2 Change: a solution that
preserves good design is
more flexible which
makes it easier for it to
manage change.
3 Complexity: well
designed solutions strive
for simplicity, allowing
developers to handle
complex challenges.
Bad architecture often leads to frustrated, depressed, and de-motivated teams.
18. #craftingdigital
The Architectural Process
To understand what software architecture “is”, it is
important to contrast it with software requirements.
The process and effort used to
determine “what” should be
built is software analysis. This is
generally a single activity
conducted before the build
cycles start.
The constant decisions
surrounding “how” to build an
application are its design. These
are made both before the build
starts and continue through
delivery.
Design
Is Not A
One-Time
Activity
Design is an evolutionary process throughout the construction of an application.
Software Requirements Software Architecture
19. #craftingdigital
Requirements Are Not Architecture
Do I Need a Business Analyst?
Short answer: YES. These roles have a dramatic
impact on the success of an Agile team. They improve
communication and guide the product vision.
20. #craftingdigital
The Architect Metaphor
How Do We Build?
When creating a structure, the designer and the builder
are separate roles. In software, the metaphor begins to
break down.
Blueprints – Construction blueprints are very
detailed. This is more aligned to actual source code
rather than system diagrams.
Construction – The act of building in software
development is completely automated, it’s called
the compiler.
If we apply this metaphor to software, all developers are actually architects.
21. #craftingdigital
How Do Coders Write Software?
Many people try to correlate building
software with building a house. This
is not only wrong, it’s dangerous.
In fact, building software is nothing
like building a house. It’s more artistic
than that. Coding is more than just
following a schematic design.
Coding is Like
Building a House?
23. #craftingdigital
An Alternate View
Building Software Is Like Writing a Book
The process of making software is actually much
more like writing a book than building a house. The
process:
Outline
The first thing an author does is create an outline of the story, a
plan or roadmap.
Write
An author then just writes, trying to complete his thoughts.
Revise
Once the complete thought is formulated, then the author goes fixes or
revises.
Review
When comfortable with his edits, an author may then send off for
editorial review.
Release
Finally, the story reaches a level of maturity that the author is able to
share it publically.
Coding Is an Art Form
While programmers work in a less accessible medium,
that doesn’t make it any less artistic. Coders are authors.
24. #craftingdigital
What Is Architecture?
“[Architecture] is the
stuff that’s hard to
change.” – Martin Fowler
Architecture is the important stuff that we want to get
right early on in the project. This often correlates to the
items that are difficult to modify.
Irreversibly = Complexity
A core driver of complexity is irreversibility. If
you can’t change you’re mind, then you’re
constrained.
26. #craftingdigital
What Makes a Good Design
Design Is Driven By Use Cases
Describing the design of a system by saying “it’s a .NET service” or
””we’re building a React app” is like saying “I’m building my house
with wood and nails”. It doesn’t tell us anything substantive.
A good design
allows major
decisions to be
deferred.
A good architect maximizes the number of
decisions not made. Instead, they focus on use
cases and business value so they can make the
most informed decision possible.
27. #craftingdigital
Communicating Design
A Library A Church
Think about a blueprint. It’s easy to look at one and understand the intent of the design. It screams it at you.
The shape of the building immediately conveys it’s use.
28. #craftingdigital
The Design Is In the Code
The most definitive description of a system is in the source code. Since code is a manifestation of the
software model, then the design can always be extracted from it. This means the code is always the primary
source of truth.
31. #craftingdigital
Horizontal vs. Vertical Slicing
Horizontal Slicing
The traditional approach to implementing a big feature
was to decompose the problem into it’s logical layers.
Specialists would be build their piece of the application
separately.
At the end of the build and integration phase would be
introduced to tie the application together.
This creates a slow feedback loop since the application
cannot be evaluated until all pieces are complete.
It eliminates the possibility of experimentation since each
layer is an all or nothing proposition.
32. #craftingdigital
Horizontal vs. Vertical Slicing
Vertical Slicing
An alternate approach breaks large features into several
small pieces that slice through application layers.
Slicing includes all work in each logical layer including
testing and integration.
At the end of the cycle, each slice meets the full definition of
done.
This creates a much faster development cycles which
improves the feedback loop.
Encourages experimentation between slices which allows
the design to evolve.
33. #craftingdigital
Vertical Slice Advantages
Smaller slicers are easier to understand.
It’s easier to estimate smaller pieces.
Increases team morale by demonstrating
daily progress.
Daily scrums become more interesting and factual.
The Art of Decomposition
At its core, engineering is the art of
decomposing really big problems into smaller
ones.
Ancillary Benefits
Outside of allowing an easier structure for evolutionary
design, vertical slicing has other benefits:
34. #craftingdigital
Slicing Over Time
Model Storming
Lightweight modeling on a Just-In-Time basis to
think through an aspect of the software.
Different Approaches
There is no good answer on how much up-front design you
may need as it depends on project factors. However, here
are some examples how code bases can change over time.
Time
35. #craftingdigital
Guiding Principles
Think Big – teams should maintain the overall vision and
direction of the architecture
Act Small – deliver small increments of high quality
solutions
Fail Fast – front load the riskiest parts of the projects early
in the development cycle
Learn Rapidly – identify and document successes and
challenges as soon as they happen
From Lean Software Development: An Agile Toolkit
All agile design methodologies stim from one of four
guiding principles.
The Last Responsible Moment
In Cone of Uncertainty, Boehm shows that
decisions made up front are rarely
correct.
36. #craftingdigital
Build An Architectural Runaway
Why a Runway?
We call it a runway because like with planes, if it isn’t
long enough you will crash. The list should force folks to
focus on the architecture not just the features.
A dedicated backlog
for architectural items
helps guide and
communicate the
design vision.
An architectural runway is a backlog maintaining the
priorities of the product from an architectural point
of view. It reflects the "-ilities" of a product, such as
scalability, maintainability, usability, reliability,
extensibility, security, reusability
39. #craftingdigital
The Seductive Power of Abstraction
Mechanical Sympathy
The effect of actually understanding what’s going on
under the hood; the full impact of your software.
It is critical that architects be involved in the day-
to-day coding. In larger companies, folks with an
architect title seem divorced from the actual code.
“All model are wrong,
some models are
useful.” – George Box
40. #craftingdigital
Kill The Ivory Tower
Architects Must Be In Code
We can’t really separate development and architecture,
they are the same activity.
Accountability – It is important for those making
technical decisions to have to live with them.
Collaboration – Encourages everyone to engage in
architectural thinking.
Conway’s Law
The software being written will reflect the
structure of the team writing it.
Utilitarian – Avoids creating a two class society in
the team: the good devs and the bad devs.
41. #craftingdigital
How Do We Know That Architecture Is Happening
“Architecture is not all about diagrams;
it’s about promoting collaboration and
communication about the critical parts
of the system.” – Martin Fowler
42. #craftingdigital
What Do Architects Do?
Traditional Tasks
Most of what architects have done traditionally
should be done by developers, or by tools, or not at
all.
Development Artifacts
Architects Everyone
Guidelines/Principles
Visualizations
Examples
Coding
Testing
Reviewing
43. #craftingdigital
What Is the Value of An Architect?
The architect should be the leader/facilitator of the
team. However, they should constantly promote
learnings within the team to promote architectural
thinking from the whole group.
“An architect’s value is
inversely proportional to
the number of decisions
he/she makes” – Martin Fowler
Architects are the guides
They are the experienced developers that can help the
team avoid the unknown “unknowns”. They guide the
team rather than create a plan for them to follow.
44. #craftingdigital
Architecture is Social
The shared
understanding between
team members of how
the system fits together.
Diagrams are sometimes useful, but they are just one
representation of the architecture. The most important
representation is:
Change Can Happen Anytime
Given that the system can change at any
time, it is critical for people to have a solid
understanding in their mind.
45. #craftingdigital
Review Code Commits
Map vs. Terrain
Sometimes the map can differ from the terrain.
In those instances, go with the terrain.
Stay In the trenches
Setting aside time each week to review code commits is a
great way to stay in sync with the team.
Take the theoretical to the practical. Can be a great
way to spark conversations within the team.
Allows the architect to remain engaged with the
process.
Gives the architect immediate insights as to what’s
happening on the ground.
Allows the architect to validate early decisions that
were made, and pivot if necessary.
46. #craftingdigital
Mob Code Reviews
The Most Important Question: “Why”
Remember that the goal of the code review is to
learn and teach. We want to encourage
intentional coding.
Always in person with the whole team, usually at the
end of the sprint.
Only review the commits in that sprint, but everyone
comes prepared to discuss.
Author start with something their “proud” of and
something their “ashamed” of.
Avoid the mundane items that can be caught by
static code analysis or tests.
Encourage an atmosphere that celebrates code.
It’s Not about Code Quality
Code reviews are the most under utilized tool an architect
can use to foster team building and learning.
47. #craftingdigital
Reviewing Good Design
Metrics are Key to Early Detection
Many teams have difficulty developing an early metric for
good design, instead relying mostly on the “eye” test during
code reviews.
A Better Design Criteria
Identifying good design is easier if we use a rubric based on
common code smells.
Rigidity – How easy is the design to change?
Fragility – Is the design easy to break?
Immobility – Can the design be re-used?
Viscosity – Is it hard to do the right thing?
48. #craftingdigital
Feed Opportunities
Peter Drucker
Mr. Drucker is a great American management consultant
and corporate philosopher.
“Don’t starve
opportunities and
feed problems.”
– Peter Drucker
7 Deadly Sins of Business
In a New York Times article, Peter Drucker
articulated 7 deadly sins in business. The sin below
often occurs in software as well.