Lean Software Architecture: Focus On the Pain – Part 3 of 3

In previous parts of this series, we outlined a simple two step process for being a lean software architect:

1. Build the simplest thing that could possibly work
2. Focus on the pain

In part one of this series, we outlined some specific examples of complexities that today’s software architects may consider. And in part two of this series we defined some ground rules that help you determine if you’re building the simplest thing that could possibly work. In this final part, let’s discuss how to focus on the pain to determine when adding additional complexity to the system is justified.

Once you’ve selected the simplest thing that could possibly work, it’s time to start looking around for pain points. Perhaps you’re seeing redundant queries as the application grows or struggling with unit testing business logic due to tightly coupled data access. This is where abstracting data access into a separate layer can add value.

Perhaps your presentation layer is getting bloated with excessive amounts of logic to handle the interactions among your business logic classes. At this point creating a service layer and migrating such code to this new layer can simplify your controllers. Waiting until this point avoids creating a service layer that may not be necessary or worthwhile.

Maybe your data access story has grown more complex, involving multiple databases and third party services that persist data. Abstracting data access to sit behind the repository pattern can hide this complexity behind a clean simple interface the application can leverage.

Real Craftsmen Consider the Options

Adding complexity is much like adding options on a car. There’s no best practice for selecting options. Automatic transmissions, sunroofs, and heated seats are useful to some and a total waste of money for others. They’re all useful in a certain context and their value thus lies in the eyes of the beholder. In both cars and software, the more options you check, the more money you have wrapped up. So be wary of a blind devotion to perceived “best practices” – it can lead to building more application than you need. Speculative architecture is risky for the same reason speculating in stocks is risky: The investment may sink or swim.

This discussion just scratches the surface of architectural considerations. To learn more about thinking pragmatically about software architecture, check out “Architecting Applications for the Real World in .NET” on Pluralsight.