DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Custom Software vs. Readymade Software
  • Agile Software Life Cycle, Methodology, and Examples
  • Evolutionary Architecture: A Solution to the Lost Art of Software Design
  • Software Design Quality

Trending

  • The Modern Data Stack Is Overrated — Here’s What Works
  • Rethinking Recruitment: A Journey Through Hiring Practices
  • Segmentation Violation and How Rust Helps Overcome It
  • Doris: Unifying SQL Dialects for a Seamless Data Query Ecosystem
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Shearing Layers in Software Design

Shearing Layers in Software Design

See what the ''shearing layers'' concept of architecture can teach us about organizing our software.

By 
Gratus Devanesan user avatar
Gratus Devanesan
·
Nov. 05, 18 · Opinion
Likes (1)
Comment
Save
Tweet
Share
7.3K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Software development Software design agile Design

Published at DZone with permission of Gratus Devanesan, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Custom Software vs. Readymade Software
  • Agile Software Life Cycle, Methodology, and Examples
  • Evolutionary Architecture: A Solution to the Lost Art of Software Design
  • Software Design Quality

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: