Talk from Agile Tour London 2017.
Architecture is a dirty word in some circles within the Agile community. However, it was never the intention of the original signatories.
In this talk I try to show why getting the architecture right is so important and how we can make that happen.
29. The problem was this…
Built upon servlets that served
dynamically generated Javascript
and HTML, calling an EJB 1.0
backend system, off a single
codebase
30. A flawed architecture
• Wrong technology choice (Javascript)
• No separation between the view or
the controller
• Untestable code in isolation
• Leading to bad code
• Leading to slow deployments
• Making it difficult to debug
31. Your architecture is the
foundation upon which the rest of
your software is built.
A good architecture is not just
optional
32. HOW TO MAKE AN
ARCHITECTURE GREAT
Principles and guidelines
33. A product of circumstance
A great architecture is shaped by its
environment and ecosystem.
34. A product of circumstance
A great architecture is shaped by the
tools, processes, people and technology
available. These are both limitations and
opportunities
35. We have these available to us
• Agile
• CI/CD
• Cloud
• Git
• TDD
• Docker
• Plus many more…
36. This is tiki taka….and it is sh*t
We encourage a purist approach to
architecture but not a dogmatic one
37. For example
Microservices are self contained, separately
deployable, separately running application
code doing just one thing.
39. Change the emphasis
The emphasis used to be on reuse in our
architecture. This was in response to
slow release cycles and difficulty in
testing
40. Change the emphasis
Today, we have the ability to deploy
within minutes. But to achieve those
quick deployments, our emphasis has to
be on loose coupling components
42. Final Thoughts
• “Continuous attention to technical
excellence and good design enhances
agility.”
• The architecture of your software is
its foundation
• A great architecture is the first step
towards technical excellence
• A great architecture may have
prevented my hell in 2000
Hinweis der Redaktion
This means that we understand the principles behind the styles and patterns and not simply implement them. For example, superficially, microservices can be described as self contained, separately deployable and separately running units of code with a single responsibility. That is an accurate one-liner. But I have seen microservices
This means that we understand the principles behind the styles and patterns and not simply implement them. For example, superficially, microservices can be described as self contained, separately deployable and separately running units of code with a single responsibility. That is an accurate one-liner. But I have seen microservices