SOFTWARE ISN’t a buildingDesigning technical architecture for change

by: David Fox, Director of Technical Architecture Design

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

ArchitectsAll they do is draw boxes and lines on whiteboards.

Who needs them?

building architecture

SOFTWARE architecture

Building ARCHITECTURE

FAIL

What makes software hard to change?

“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

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

LACK OF DESIGNTurns out you do need that architect designer

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

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

Coupling

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

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

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

Invasive APIsand leaky abstrac"ons

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

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

DehydrationThere is such a thing as too DRY

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

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

Infrastructure investments

We already paid for the support contract!

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”

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

Team

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

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”

“organiza"ons which design systems ... are constrained to produce designs which are copies of the communica"on structures of

these organiza"ons”

Melvin Conway

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

Technical DebtAdding features no ma$er what the cost

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

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”.

LACK OF DESIGNDo overall design up front and empower leaders to guide

developers in implementa"on.

COUPLINGLearn about connascence, reduce strong to weak, and add

boundaries to segregate components.

INVASIVE APISTranslate 3rd party APIs into your domain model and add

boundaries to prevent leaky abstrac"ons.

DEHYDRATIONSacrifice DRYness if it reduces coupling. Split up large models by bounded contexts. Reduce scope of shared

dependencies.

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

TEAMInvest in your team knowledge. Increase communica"on.

Your team structure is your architecture.

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

evolving architectureHow Buildings Learn: What Happens A!er They're Built By: Stewart Brand

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

thank you

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 Builth$p://www.amazon.com/How-Buildings-Learn-Happens-Theyre/dp/0140139966

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