The document discusses various barriers to changing software over time and recommendations for addressing them. The main barriers covered are lack of design, coupling between components, invasive APIs, dehydration where the same code is shared across contexts, investments in infrastructure that then dictate design, reliance on specific team skills rather than general skills, and accumulating technical debt. Recommendations include upfront design, reducing coupling, adding boundaries, separating contexts, delaying technology decisions, broadening team skills, and paying down debt continuously.

1. SOFTWARE ISN’t a building
Designing technical architecture for change
by: David Fox, Director of Technical Architecture Design

2. agenda
• Buildings vs So!ware
• Tension Between Malleability and Complexity
• Barriers to Change in So!ware and Their Solu"ons

3. Architects
All they do is draw boxes and lines on whiteboards.
Who needs them?

4. building architecture

5. SOFTWARE architecture

6. Building ARCHITECTURE
FAIL

7. What makes software
hard to change?

8. “If you pick any one aspect of so!ware then
you can make it easy to change…making
everything easy to change makes the en"re
system very complex. Complexity is what
makes so!ware hard to change.”
Ralph Johnson speaking with Mar"n Fowler - “Who Needs an Architect?”
h#p://mar"nfowler.com/ieeeSo!ware/whoNeedsArchitect.pdf

9. Barriers to change
• Lack of Design
• Coupling
• Invasive APIs
• Dehydra"on
• Infrastructure Investments
• Team
• Technical Debt

10. LACK OF DESIGN
Turns out you do need that architect designer

11. DESIGN SYMPTOMS
• “Let’s just use Framework X” before star"ng to think about design
• “Let’s just start coding”
• No clear design leader(s)/ownership
• Developers le! to decide on components without overall direc"on
• Ge#ng bogged down in details

12. DESIGN RECOMMENDATIONS
• Developers must have some idea of the overall design before coding begins
• Team must agree on design and be aware of general design and roles of
components
• Work “outside in”. Use the walking skeleton.
• Designer(s) must work with the team throughout development and review work
directly to ensure design is being followed
• Choose frameworks based on your architecture, not the other way around

13. Coupling

14. Connascence
• So!ware quality metric and taxonomy of coupling
• Used by Meilir Page-Jones in ACM ar"cle
“Comparing Techniques by Means of
Encapsula"on and Connascence” in 1992
• Expanded in “What every programmer should
know about object-oriented design” in 1996
• Visit h$p://connascence.io for more info

15. Connascence
• Name
• Type
• Meaning
• Posi"on
• Algorithm
• Execu"on
• Timing
• Values
• Iden"ty
• Strength
• Locality
• Degree
Connascences Proper!es
Image source: http://connascence.io/locality.html

16. Coupling recommendations
• Iden"fy strong connascence and refactor to weak wherever possible
• Boundaries between components, par"cularly foreign APIs, are essen"al
• Adding layers does add (some) complexity, but:
• Reveals intent in the ubiquitous language of the domain
• Eases re-implementa"on of components
• Improves testability
• Learn and follow good prac"ces, such as SOLID

17. Invasive APIs
and leaky abstrac"ons

18. INVASIVE API SYMPTOMS
• Dependencies on implementa"on reach up through layers
• Specialized implementa"on types are exposed in APIs
• Custom types are used when simple, built-in types would suffice
• Infrastructure is needed in other layers to support a leaky abstrac"on

19. INVASIVE API recommendations
• Always put boundaries between your domain and foreign APIs
• Translate data structures at boundary
• Ensure core of domain remains pure and free of external dependencies
• Use standard types that don’t require clients to import implementa"on details
• Prefer libraries that use open standards
• Unless the infrastructure really is transparent, favor designs where boundaries are
enforced, and don’t leak outside the component
• Prefer external mapping or configura"on over annota"ons

20. Dehydration
There is such a thing as too DRY

21. Dehydration SYMPTOMS
• Confla"ng persistence, domain, and presenta"on concerns
• “One Big Model”
• Sharing code between models in separate contexts
• Func"ons used by mul"ple clients contain special cases specific to those
clients

22. Dehydration RECOMMENDATIONS
• Don’t try to be DRY at the cost of strong coupling
• Denormaliza"on is OK
• Consider the true impact of eventual consistency
• Separate aspects of models into bounded contexts
• If a model is suppor"ng mul"ple concerns, and has code specific to those
use cases, it’s a sign mul"ple models might help, even if they end up being
very similar
• It’s OK to have similar code in mul"ple places, especially separate modules

23. Infrastructure
investments
We already paid for the support contract!

24. investments symptoms
• We already bought the license to “Database X”, so we have to use that
• All our code is wri$en to use “Middleware Y”, so it’s hard to change
• We already hired our team for their experience with “Framework Z”

25. investments recommendations
• Wait un"l the “last responsible moment” to decide on specific technology
investments
• “Fake it un"l you make it” to put off implementa"on of components un"l all
requirements are known
• Design in terms of classes of technology rather than specific technologies
• Prefer libraries over large, invasive frameworks - and/or -
• Segregate implementa"ons using boundaries
• Prefer open-source so!ware

26. Team

27. TEAM SYMPTOMS
• Our developers only know “Framework X”
• Our developers aren’t sophis"cated enough to use “Technology Y”
• Developers don’t want to learn how to write SQL correctly
• The front-end team is responsible for that
• We have to run all updates through the database team
• Only Steve knows that par"cular part of the code

28. TEAM recommendations
• Invest in and encourage training in broad skill areas, not just technologies
• Structure teams so that more experienced engineers work on design and
modeling with less-experienced engineers
• Less experienced engineers review more experienced engineers’ code
• Push engineers to become more full-stack
• Don’t choose technologies only based on “what the team knows”

29. “organiza"ons which design systems ... are
constrained to produce designs which are
copies of the communica"on structures of
these organiza"ons”
Melvin Conway

30. TEAM recommendations
• Base designs on the problem domain, not team structure, and shape the team
around it
• Group developers based on bounded contexts and func"onality, not applica"on
layers or technologies
• Create smaller mul"-disciplinary teams
• Allow for direct communica"on between groups
• Integrate constantly

31. Technical Debt
Adding features no ma$er what the cost

32. Technical Debt SYMPTOMS
• Velocity isn’t nearly what it was when the project began
• We have to add features, there’s no "me to refactor
• This part of the code is a mess! We need to rewrite it
• We can refactor that code without breaking something

33. Technical Debt recommendations
• Pay down technical debt as you go
• If you must defer paying down debt to complete features, try:
• Refactor just enough to add a feature without incurring more debt (“the Boy
Scout Rule”)
• Have a “cleanup” phase a!er the feature push
• Ensure that there are tests in place so refactoring can be done regularly and with
confidence
• Prescrip"ve refactoring over “rewrites”. If you make it part of development, it isn’t
“extra expense”.

34. LACK OF DESIGN
Do overall design up front and empower leaders to guide
developers in implementa"on.

35. COUPLING
Learn about connascence, reduce strong to weak, and add
boundaries to segregate components.

36. INVASIVE APIS
Translate 3rd party APIs into your domain model and add
boundaries to prevent leaky abstrac"ons.

37. DEHYDRATION
Sacrifice DRYness if it reduces coupling. Split up large
models by bounded contexts. Reduce scope of shared
dependencies.

38. INFRASTRUCTURE
Wait un"l the “last responsible moment” and “fake it un"l
you make it” to ensure procurements reflect actual needs

39. TEAM
Invest in your team knowledge. Increase communica"on.
Your team structure is your architecture.

40. TECHNICAL DEBT
Pay it down as you go so it doesn’t grow out of control.
Refactoring is not rewri"ng and is part of development.

41. evolving architecture
How Buildings Learn: What Happens
A!er They're Built
By: Stewart Brand

42. About cantina
• Boston-based digital design and development agency
• Founded in 2007, 60+ employees
• We help clients like Putnam Investments, John
Hancock, CUNA Mutual Group, Epsilon, and Pearson
deliver be$er digital products for their customers
• Can"na’s people turn great ideas into digital reality,
execu"ng with the best design and development
techniques available

43. thank you

44. References
• “Who Needs an Architect?”
h$p://mar"nfowler.com/ieeeSo!ware/whoNeedsArchitect.pdf
• What Every Programmer Should Know About Object-Oriented Design
h$p://www.amazon.com/Every-Programmer-Should-Object-Oriented-Design/
dp/0932633315/ref=sr_1_1?qid=1446730637
• Connascence
h$p://connascence.io
• How Buildings Learn: What Happens A!er They're Built
h$p://www.amazon.com/How-Buildings-Learn-Happens-Theyre/dp/
0140139966

45. References
• Growing Object-Oriented So!ware, Guided by Tests
h$p://www.amazon.com/Growing-Object-Oriented-So!ware-Guided-Tests/dp/
0321503627/ref=sr_1_1?s=books&ie=UTF8&qid=1446730723