Five Ways to Optimize Encapsulation in Your Software Architecture
Keeping unrelated things from affecting each other is a pillar of managing the complexity of a modern software development endeavor. Such insulation is generally called encapsulation. It doesn't matter what's being encapsulated—data, an algorithm, a design, a dependency, a variation in behavior. Any time you shield yourself from the adverse effects of a potential change, you're encapsulating.
Nobody has to wrangle more complexity in a software project than the person(s) responsible for its architecture. Software architects make sure that all the project's "pieces" fit together: All the components, applications, subsystems, and services have to connect. All the integrations have to work. All the relevant combinations of variants must be compatible.
In my mind, no trait of an architecture is more important than the degree to which unrelated things affect one another. In this article, I outline five techniques you can use to minimize accidental coupling by maximizing encapsulation. In summary, the techniques are as follows:
- Change your organization's culture to value encapsulation.
- Assume that you're going to change your mind, and take measures to support such changes.
- Instead of focusing on which overall path you will take, choose which path you will take first.
- Ensure that your architecture has a place for everything and that everything is in its place.
- Actively promote upgrading your developers' skills.
Technique 1: Create a Culture of Encapsulation
Culture is one of the more powerful forces in the world, right up there with compound interest. In the long run, the only way to make sure that unrelated things aren't accidentally coupled is to make vigilance against such accidents a natural part of how people do their work; make it part of your organization's culture.
Culture modification is a subtle art. A lot of what needs to be done is defined by context. The people you're trying to guide and your own personality play a huge role in defining which steps are the right ones. There is one fundamental principle, though: Create awareness of the need.
Central to modifying a culture is changing people's values. Make it apparent that encapsulation is something you and your organization consider important.
With the exception of the occasional saboteur planted by a competitor, or a generally malevolent entity, people want to do their jobs right. It's just not always clear how to do that (or even that it's allowed). You can't just say "Encapsulation matters here" and expect to get the effect you want. You have to show people you really mean it.
You need to show people how important encapsulation is, rather than just telling them. Bringing up encapsulation in code reviews has some impact, but it won't always translate into behavior changes for people who don't have strong abstract reasoning skills. Chastising people can modify their behavior long enough to make them try something different, but you'll have to hope their first effort works—you pretty much get only one shot.
In my experience, the best demonstration that you value something is to give up something else in favor of it. In this case, features make the perfect sacrifice. Watch carefully for the right conditions: a tight but still-flexible deadline, a complex feature or behavior, and a team worrying that they'll have to cut corners to deliver on time (see Figure 1). When the right moment presents itself, pounce! Argue that the deadline should be pushed back in order to avoid creating technical debt.
Figure 1 Find the right time to demonstrate your values.
If the deadline is moved, great! You sent a clear message: Doing things right is more important than getting them done when you first guessed they'd be done. If the deadline holds fast, you still win. The message is "This architect wants to do things right but still has boundaries."
If you send enough of those kinds of messages, people will most likely start to respond and modify their behavior. Some may even start to speak up, further accelerating the cultural shift.
The remaining techniques in this article can be used to further reinforce and develop a culture of encapsulation, but they also can stand on their own.