A common saying by software architects is “that’s an implementation detail”. All too often we treat software architecture and implementation as two separate things, where implementation is something that happens once a software architecture is defined. In fact, it’s the other way around: software architecture should be viewed as a first draft, where implementation reveals more details and refinements. In this provocative keynote Mark Richards discusses the intersection of architecture and implementation, and how the two must be in constant alignment to achieve success. Through real-world examples, he shows how implementation can get out of alignment with the architecture, causing the system to fail to achieve its desired goals. He then shows some techniques and tools to help ensure alignment between architecture and implementation.

2. “We need an architecture that can
scale to 500,000 users with an average
response of 600ms under full load”
“No problem. I’m on it.
business
sponsor
software
architect

3. “Here’s the
architecture for the
new system…”
software
architect
development
team

4. “What protocol should we
use between services?”
“That’s an
implementation detail…”
software
architect
development
team

5. “What persistence
framework should we
use?”
“That’s also an
implementation detail…”
software
architect
development
team

6. “What third-party libraries
and services should we
use?”
“Again, an implementation
detail. Architecture is my job—
implementation is yours.”
software
architect
development
team

9. isomorphism

10. isomorphism
isos (meaning “equal”) and morphe (meaning “form”, or “shape”)
how close does the shape of one thing match the
shape of the other thing?

11. how close does the shape of the architecture match the
shape of the problem domain?
architecture to domain isomorphism

12. microservices architecture
single purpose functions deployed as separate
units with each unit owning its own data

13. layered architecture
single deployment with functionality
grouped by technical categories

14. how close does the shape of the architecture match the
shape of the implementation?
architecture to implementation isomorphism

15. how close does the shape of the architecture match the
shape of the implementation?
architecture to implementation isomorphism

16. Case Studies

17. “We’re expecting anywhere from several
thousand to a million concurrent customers
on the new system.”

19. software
architect

20. item_id
current_inv
max_inv
min_inv
Inventory
get current inventory
Too slow, and the services are too
tightly coupled together

21. item_id
current_inv
max_inv
min_inv
Inventory
update-able
in-memory cache
containing inventory
amounts
read-only
replicated cache
containing
inventory amounts

22. item_id
current_inv
max_inv
min_inv
Inventory
Much faster, and the services are
decoupled and no longer dependent
on each other

23. 500 mb
500 mb
1.0 GB

24. 1000 mb
2500 mb
3.5 GB

25. 1500 mb
2500 mb
4.0 GB

26. 1500 mb
2500 mb
4.0 GB
https://myapp.com/placeOrder?id=27a54826s
Service Unavailable
HTTP ERROR 503. The service is unavailable

27. Microservices
Scalability
Elasticity
Performance
Coupling

28. Microservices
Scalability
Elasticity
X
Scalability
Elasticity

29. “We have a very tight budget and timeframe
for this new venture, and we’re expecting a
significant amount of change to the underlying
data structures as we learn more about this
new line of business. We need to move fast
when those changes happen.”

31. persistence layer component component component
presentation layer
business layer
component component component
component component component
services layer component component component
Layers of isolation
Separation of
concerns
Good change
control
software
architect

32. persistence layer component component component
presentation layer
business layer
component component component
component component component
services layer component component component
Better
performance
calling the
database
directly
It’s easier
having the
code and
SQL together

33. persistence layer component component component
presentation layer
business layer
component component component
component component component
services layer component component component

34. “Wait—here’s the best part—then they said ‘Sure, we’ll have those
database changes out to you right away.’ Ha ha ha ha ha ha ha…”
persistence layer component component component
presentation layer
business layer
component component component
component component component
services layer component component component

35. Isolation
Change control
Performance
Convenience

36. XIsolation
Change control
Isolation
Change control

37. How does implementation get out of alignment with
architecture, and how can we prevent it from happening?

38. communication

39. “The most effective way to deal with
constant database change is to leverage
closed layers in the architecture. I’ve got to
let the development team know…”
software
architect
development
team

40. Architecture Decision Records
to the Rescue!

41. short text file; 1-2 pages long, one file per decision
(markdown, textile, asciidoc, plaintext, etc.)
architecture decision records
short noun phrase describing the decision
proposed, accepted, superseded
description of the problem and alternative
solutions available (documentation)
justification (the “why”)
tradeoffs and impact of decision

42. if developers don't know why you made a
decision, they are less likely to agree with it
“Do this.”
software
architect
development
team
“No. We
don’t agree.”

43. Second Law of
Software Architecture
“Why is more important
than how”
?

44. justification (the “why”)
tradeoffs and impact of decision
architecture decision records

47. collaboration

48. availability
scalability
performance
software architecture software development

49. software architecture software development
availability
scalability
performance

50. software architecture
software development
leadership
mentoring
availability
scalability
performance

51. if developers are not involved in the
decision, they will be less likely to follow it
“Do this because it
performs better.”
software
architect
development
team
“Okay.”
“We found a
better way to do
this.”
later…

52. “We’re going to use request/reply
messaging between our services because
it’s faster and more scalable.”
software
architect
“Actually, we decided to use REST
because it’s just as fast and it scales better
than messaging. Look it up on Google or
ChatGPT.”
development
team
the problem…

53. “But…but…this is my
decision…and messaging is faster
and more scalable in our
environment…”
software
architect
“Whatever. We’re
moving forward with
REST.”
development
team
the problem…

54. software
architect development
team
the problem…

55. “I ran some benchmarks between
REST and messaging in our production
environment. Take a look at this…”
software
architect development
team
demonstration defeats discussion

56. response
times
user load
REST
Messaging
This is our
expected load
Our production environment
This is our response
time SLA
demonstration defeats discussion

57. “Based on this, I’m thinking we
should probably use messaging to
communicate between our microservices.
What do you think?”
software
architect
“We were thinking of using REST,
but you’re right—based on this data,
messaging is a better choice.”
development
team
demonstration defeats discussion

58. proposed, accepted, superseded
architecture decision records

59. Status: RFC by 22 June
…
indicates request for
comments status prior to
the decision being made
with an end date

60. Accepted
Proposed
Status: RFC by 22 June

61. architecture risk
storming

62. architecture risk
storming

63. Microservices

64. Microservices

65. architectural
governance

66. “I hope the development team is
complying with the architecture decisions I
communicated through the ADR”
software
architect
development
team

67. “With all these coding changes, I
hope the architecture is still meeting its
scalability requirements.”
software
architect
development
team

68. “An architectural fitness function provides
an objective integrity assessment of some
architectural characteristic(s).”
architecture fitness functions

69. start
if (c1)
f1() f2()
if (c2)
f3() f4()
end
7
6
5
4
3
2
1
8
7
6
5
4
3
2
1
nodes
edges

70. response
times
!
threshold or trend reached
track
architecture fitness functions

71. average
duration
time
concurrent
users testing elasticity and scalability
operational characteristics
response time trend analysis
instances starting
instances started

72. only the business and service layers can access
the persistence layer to control change
throughout the architecture
structural integrity

73. https://www.archunit.org/
https://github.com/TNG/ArchUnit
https://search.maven.org/search?
q=g:com.tngtech.archunit
structural integrity

74. https://github.com/TNG/ArchUnitNET
NuGet: ArchUnitNET
structural integrity

75. H
https://github.com/BenMorris/NetArchTest
structural integrity

76. H
https://www.hello2morrow.com/products/
sonargraph/architect9
structural integrity

77. @Test
public void presentation_layer_cannot_access_persistence_layer() {
noClasses().that().resideInAPackage("..presentation..")
.should().accessClassesThat().resideInAPackage("..persistence..")
.because("we have a closed-layered architecture to control changes " +
"made in the database and persistence layer. Persistence " +
"layer can only communicate with the business layer.")
.check(myClasses);
}
structural integrity

78. public Presentation_Layer_Cannot_Access_Persistence_Layer() {
var result = Types.InCurrentDomain()
.That()
.ResideInNamespace("Myapp.Presentation")
.ShouldNot()
.HaveDependencyOn("Myapp.Persistence")
.GetResult().IsSuccessful;
}
structural integrity

80. “Developers should never take
components designed by
architects as the last word.
Rather, the initial design should
be viewed as a first draft, where
implementation will reveal more
details and refinements.”
embrace continuous
architecture change