#MAGA – MAKE
ARCHITECTURE GREAT AGAIN
Reda Hmeid
A little about me
• Reda Hmeid – Ree-da H—meed
• Architect
• Twitter: @softwareda
• LinkedIn: redahmeid
• Blog: https://medium.com/openlight
THE YEAR WAS 2000
I was on my first software project
The architecture
was….interesting
Built upon servlets that served
dynamically generated Javascript
and HTML, calling an EJB 1.0
backend system, off a single
codebase
The code versioning strategy
was….interesting
We used to code directly on the Unix
box.
My day consisted of
vi FrontEndControllerServlet.java
My day consisted of
Edit edit edit
My day consisted of
:wq
My day consisted of
vi AnotherControllerServlet.java
My day consisted of
Edit edit edit
My day consisted of
:wq
My day consisted of
javac */*/*.java
My day consisted of
restart.sh
But then….
I discovered the Unix command –
Escape K
My day now consisted of
vi FrontEndControllerServlet.java
My day now consisted of
Edit edit edit
My day now consisted of
:wq
My day now consisted of
vi AnotherControllerServlet.java
My day now consisted of
Edit edit edit
My day now consisted of
:wq
My day now consisted of
Escape-K; Enter
As you can see
It saved me so much time
One day I used Escape-K as
normal
Except someone had logged onto the
unix box with the same logon
And so the most recent
command was
rm –r */*/*
HOW DID THIS MESS
HAPPEN?
Or…whose fault is it that I fell into the pits of hell?
Businesses have always wanted to deliver
business features and benefit quickly
Some things are still the same
What tools and processes were
used
• TeamConnect - VCS
• Scripted builds (we didn’t even use
Ant yet)
• Waterfall
They were no….
• Agile
• CI/CD
• Cloud
• Git
• TDD
• Docker
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
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
Your architecture is the
foundation upon which the rest of
your software is built.
A good architecture is not just
optional
HOW TO MAKE AN
ARCHITECTURE GREAT
Principles and guidelines
A product of circumstance
A great architecture is shaped by its
environment and ecosystem.
A product of circumstance
A great architecture is shaped by the
tools, processes, people and technology
available. These are both limitations and
opportunities
We have these available to us
• Agile
• CI/CD
• Cloud
• Git
• TDD
• Docker
• Plus many more…
This is tiki taka….and it is sh*t
We encourage a purist approach to
architecture but not a dogmatic one
For example
Microservices are self contained, separately
deployable, separately running application
code doing just one thing.
Change the emphasis
Every era requires a different emphasis
upon its architecture.
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
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
Loose Coupling
No Frameworks…avoid libraries….better
APIs…physical segregation
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

Make architecture great again

  • 1.
    #MAGA – MAKE ARCHITECTUREGREAT AGAIN Reda Hmeid
  • 2.
    A little aboutme • Reda Hmeid – Ree-da H—meed • Architect • Twitter: @softwareda • LinkedIn: redahmeid • Blog: https://medium.com/openlight
  • 3.
    THE YEAR WAS2000 I was on my first software project
  • 4.
    The architecture was….interesting Built uponservlets that served dynamically generated Javascript and HTML, calling an EJB 1.0 backend system, off a single codebase
  • 5.
    The code versioningstrategy was….interesting We used to code directly on the Unix box.
  • 6.
    My day consistedof vi FrontEndControllerServlet.java
  • 7.
    My day consistedof Edit edit edit
  • 8.
  • 9.
    My day consistedof vi AnotherControllerServlet.java
  • 10.
    My day consistedof Edit edit edit
  • 11.
  • 12.
    My day consistedof javac */*/*.java
  • 13.
    My day consistedof restart.sh
  • 14.
    But then…. I discoveredthe Unix command – Escape K
  • 15.
    My day nowconsisted of vi FrontEndControllerServlet.java
  • 16.
    My day nowconsisted of Edit edit edit
  • 17.
    My day nowconsisted of :wq
  • 18.
    My day nowconsisted of vi AnotherControllerServlet.java
  • 19.
    My day nowconsisted of Edit edit edit
  • 20.
    My day nowconsisted of :wq
  • 21.
    My day nowconsisted of Escape-K; Enter
  • 22.
    As you cansee It saved me so much time
  • 23.
    One day Iused Escape-K as normal Except someone had logged onto the unix box with the same logon
  • 24.
    And so themost recent command was rm –r */*/*
  • 25.
    HOW DID THISMESS HAPPEN? Or…whose fault is it that I fell into the pits of hell?
  • 26.
    Businesses have alwayswanted to deliver business features and benefit quickly Some things are still the same
  • 27.
    What tools andprocesses were used • TeamConnect - VCS • Scripted builds (we didn’t even use Ant yet) • Waterfall
  • 28.
    They were no…. •Agile • CI/CD • Cloud • Git • TDD • Docker
  • 29.
    The problem wasthis… 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 isthe foundation upon which the rest of your software is built. A good architecture is not just optional
  • 32.
    HOW TO MAKEAN ARCHITECTURE GREAT Principles and guidelines
  • 33.
    A product ofcircumstance A great architecture is shaped by its environment and ecosystem.
  • 34.
    A product ofcircumstance A great architecture is shaped by the tools, processes, people and technology available. These are both limitations and opportunities
  • 35.
    We have theseavailable to us • Agile • CI/CD • Cloud • Git • TDD • Docker • Plus many more…
  • 36.
    This is tikitaka….and it is sh*t We encourage a purist approach to architecture but not a dogmatic one
  • 37.
    For example Microservices areself contained, separately deployable, separately running application code doing just one thing.
  • 38.
    Change the emphasis Everyera requires a different emphasis upon its architecture.
  • 39.
    Change the emphasis Theemphasis 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
  • 41.
    Loose Coupling No Frameworks…avoidlibraries….better APIs…physical segregation
  • 42.
    Final Thoughts • “Continuousattention 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

Editor's Notes

  • #37 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
  • #38 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