Everyone Is a Software Architect

When I was younger I was awed by Software Architects. It’s never been a formal title at companies I worked at but it was always obvious who the people were that drove the architecture of the systems I worked on. When I joined 7shifts as one of three web developers I found myself needing to contribute to defining the architecture for the web application. Today 7shifts is 350 people with an Engineering team of almost 100 people. We’ve seen rapid growth and our focus on strong software architecture has been one of the reasons we’ve been able to handle that growth. I’ve learned that everyone can be a “Software Architect” and grown to believe that everyone should be.

About Software Architecture

One of the things that puts software architecture out of the reach of many is a simple fact that it is difficult to define what exactly it is. There are many definitions out there. I’m a fan of this one by Ralph Johnson:

“Architecture is about the important stuff. Whatever that is”

Much like dark matter, however, The best way we have to understand it is to observe its effects. I think about architecture in terms of this, admittedly simplistic chart.

If you find yourself below the line you will likely find yourself feeling that everything is always broken. Bugs are high, bug fixes cause new bugs, and customers complain about quality. If you are above the line you end up in an equally painful place where everything seems to take forever. This might seem like a lose-lose situation but if you never consider your architecture you will likely end up in a place where both things are true. Everything is broken all the time and everything takes a long time.

Thinking about Architecture

Earlier in my career, It always seemed that the folks defining architecture had some arcane knowledge bestowed upon them by a secret council of Software Architects. Now that I spend a significant amount of my time thinking about and developing architecture I have discovered the truth. Anyone can contribute to defining architecture. It only requires three basic skills.

1. Drawing Boxes and Arrows

The first is the ability to draw boxes and arrows. If you have a toddler’s grasp of drawing you are good to go. At the highest level, architecture is all about components (boxes) and relationships (arrows). If you can draw you can communicate the components and relationships that comprise your architecture.

2. Understanding Dependencies

The second key skill is an understanding of dependencies. People seem to struggle with this concept. It is overloaded and often talked about along with more complex topics like Dependency Inversion or Dependency Injection containers. Fundamentally the concept of dependencies in a software system is simple. If one piece of code knows something, a class name or parameter name, for example, about another piece of code it is dependent on that code. That knowledge forms a dependency and it means that if the second piece of code changes it may force the first piece to change.

That is the only thing you need to know about dependencies to contribute to architecture.

3. Weighing Trade-Offs

This is the only actual hard part of defining architecture. Every solution to a problem has tradeoffs and picking the best solution requires making the best tradeoffs for your business. Making the best tradeoffs requires a deep understanding of both the business goals and the options available. This required context is why you typically see the most experienced people defining the architecture. Often that context is acquired over many years and many mistakes.

Once you understand that picking trade-offs is all about context you can go in search of that context. That way you can acquire context deliberately and quickly instead of accidentally over many years. Try to answer these questions:

— What are the unique constraints of your business or project?
— What are the goals of your business or project?
— What things currently limit your system from achieving those goals?
— What tools and techniques already exist for addressing those limitations?

The first three can often be gathered by talking with other people in the organization. The last one may require doing some research.

Design for what Matters

So you understand software architecture and you have the skills required to define it. How do you start? The first step is identifying what is most important in your software system. Are you a bank? Security might be a top priority. Do you work for a small startup that is still looking for product/market fit? Productivity might be it. There can be more than one priority for your architecture but it can’t be everything. If everything is important, nothing is.

Implementing Architecture

I hope software architecture seems a lot less daunting than it did at the start of this article but I have some bad news. Understanding architecture is not the hardest part. It turns out that implementing your architecture is much more difficult. You can define a perfect architecture for your system but if the rest of the people working on it don’t implement it you won’t get the benefits of that architecture. This is why you can’t have just a single architect and everyone needs to understand your architecture.

There are three things we try to do at 7shifts to ensure our architecture is implemented consistently.

Cultivate a shared understanding: Make sure everyone understands where their work fits within the architecture and what impact they will have on it. Everyone should have the opportunity to ask why part of the architecture exists and get a good answer.

Create a single source of truth: Keep all information about your architecture centralized so that everyone can access it. For us, that means maintaining our architecture documentation in a GitHub repo to track progress, changes, issues, or requests for improvements.

Prioritize alignment over consensus: Some people are concerned that involving too many folks in the process of defining software architecture leads to “design by committee”. Resulting in a solution that does nothing particularly well. I like to say that the goal is alignment, not consensus. Someone should still be responsible for driving the architecture process and while they should listen to everyone’s opinions they will ultimately be the decision maker. The goal is to provide that decision maker with as much context as you can so they can make the best decisions possible.

Conclusion

Hopefully, you have more clarity on the importance of software architecture and how to encourage architecture thinking in your organization. Admittedly I don’t expect any developer to read this and be ready to immediately define the architecture for a large project. In my next post, I’ll walk through some of the concrete patterns we’ve applied to evolve our application in a healthy way.

Software Architecture is hugely important to the success of large software projects. Fast growth and no consideration for that architecture will inevitably lead to problems with no easy solutions. Start thinking about architecture early, define your goal, and iterate towards it.