Shearing Layers in Software Design

Using a Theory From Architecture in Software Design

Shearing Layers is a concept introduced by Frank Duffy and developed by Steward Brant. The fundamental realization here is that buildings are not static concepts, but are evolving entities that interface with a living environment. Buildings change and grow over time — the change might be due to environmental wear and tear, a user's fancy, municipal by-laws, or any number of human and environmental things.

This notion has been recognized in software development as well and may have strongly contributed to the emergence of the agile manifesto. Gene Hughson explores this specific relationship in his blog as well, linking these concepts out of building architecture to software architecture.

I want to extend this exercise and look at shearing layers mean to software development and software organization.

Thinking about Shearing Layers When Designing Software

The fundamental idea here is life-cycles and the ability to support life-cycles of varying periods within a single product. Forcing an infrastructure layer (Site, Structure level) to change and evolve at the rate of client code, or API contracts, or forcing API contracts to evolve at the pace of infrastructure we doom our software and our teams to failure - in the former our software becomes unreliable, in the latter it becomes irrelevant.

Understanding layers is an exploration of software design and while I am making some suggestions, those should simply be seen as conversation starters. Software teams need to recognize shearing layers in their process and create procedures and checks and balances that help specific layers thrive.

Cross-Functional Teams and Layers

An often heard clamor on agile teams is that some team X, or some infrastructure Y, cannot upgrade fast enough, for team A to succeed. The conversation of layers should help prevent and guide conflict.

Adjoining layers should work at a similar pace, while naturally the customer-facing layer might evolve faster and be driven to change more frequently. When such a fast-moving layer eventually hits a wall where it requires a fundamental switch that penetrates deep into the core, the work needs to begin with an understanding that it will take time. An organization invested, for security or historic reasons, to on-premise infrastructure cannot simply open up its arms and embrace serverless functions running on Amazon.

Organizationally, lower layers, like site, need to be considered strategic and be in-line with the long-term organizational vision, while layers higher up will be tactical and may be subject to almost whimsical changes. This means that change, even tactical changes, need to fit within the organization strategy - any change not in-line with the current strategy, will require a strategic shift.

This is not new information, but recognizing the sharing layers within your strategic infrastructure, no matter which team you actively belong to, allows you to gain insights as to which changes will necessarily be costly, will require alignment from senior leadership, and which changes can be achieved relatively quickly.

Timesteps and Story Points

It helps when considering shearing layers to consider a concept of timesteps. Instead of saying that sometimes, on some layer, moves faster or slower, which seems judgemental, we should instead consider that different layers have a different passage of time. A "site" layer will have a timestep of years — the smallest change possible will take a year to move to production; while UI will have timesteps of hours. To create equality among teams we need a measure that looks at story points delivered in a given timestep. If the UI team can manage 10 story points in a single timestep all teams should manage that, while the value of the timestep is specific to the layer, and a story point an organizational measure of complexity. This naturally breaks the idea that story points should be relative measures and not used to compare teams. However, it would be great if they could be used to compare teams, with the notion of relative, predetermined, measures of timesteps. Two teams that deliver 3 story points are not the same, but two teams that deliver 3 story points across the same timestep are delivering at the same rate.

Adopting timesteps is a way to align teams across shearing layers and allow for more practical conversations on alignment.