Software architecture (is) for developers

Software architecture might not be for everyone but every developer should have basic knowledge about it.

Well, as a software developer, I didn’t really consider the architecture of the system I was working on for a long time. Even though I was able to build my side of functionality or successfully finish my tasks, I often had the feeling of missing the whole picture. It almost felt like I was looking at my system through the fog. I was able to see only the closest components. This feeling of uncertainty made me dig deeper, try to explain and analyze all the systems that I had the chance to work on, to get their specific features. Some of the times I even found myself comparing them to see the good and the bad sides of each.

Even though it was not my role at the time, I always tried to look at the applications from an architect’s perspective(the best that I could) and still in the meantime preserve the perspective of the developer involved in the code.

In time I came to realize that there are these minimum architecture-related concepts that every developer should be aware of:

1. Software architecture definition
2. The differences between software architecture & software design
3. Particular characteristics in software architecture that helped me write better code

— — —

1. Software architecture definition

When it comes to clearly define what software architecture is, I found many interpretations, from “the process of defining a structured solution that meets all of the technical and operational requirements” to “the set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.” All of them seemed pretty abstract and ambiguous for a software developer in the early years of his career. From my experience the simplest way to think about software architecture, no matter the level of experience is this:

Software architecture is a set of characteristics combining both technical and business requirements (at project and the organization level) with which I will able to define a skeleton that will help me build a performant, secure, and easy to extend system(application).

2. The differences between software architecture & software design

Often I encounter confusion between software architecture vs. software design, and I think that again, is because we have this tendency of giving metaphoric and abstract definitions.

As already discussed, the architecture is a blueprint defining the high-level units of our system: the way they interact, work and evolve in relationship with one another. Choosing the right or the wrong architectural pattern will determine how scalable, reliable, performant, and secure the system will be.

On the other hand, a system design shapes things at the code level, the way each component works, the purpose of each element, and so on. Having a strong system design helps the development team to be more efficient and organized in terms of understanding what are the responsibilities of functions, modules, classes, what they can do or can’t do. By identifying a system’s design we can later decide what design patterns we should use in certain contexts.

Simply said, software architecture is focused on the entire system, while software design focuses on a more specific level (component, module, etc).

3. Particular characteristics in software architecture that helped me write better code

There is a fine line between software development and software architecture. In my opinion and from the experiences I had within the teams I had the chance to interact with, I can say that is obvious when an architect is too focused on abstractions and has no idea about what is happening in the application and at the same time I can clearly see when a developer has no knowledge about the software architecture. Since in this article, we are not debating an architect’s involvement in development but a developer’s curiosity and knowledge about the software architecture, let’s look a bit at how this can help us write better code.

From all the questions that we address when talking about software architecture there are two that can significantly help in the development process: “What are the main components, the application can be divided into? and “How these components share responsibility?”

Understanding how the system is divided into components and how they interact brings a lot of clarity in the process of defining the responsibilities of each and seeing where best practices integrate and bring value to reduce the interdependence of different parts of code and ease the process of creating unit tests. At the same time, we create a huge advantage because it will become easier to identify frequently used components, create a common area and apply the right patterns.

How beautifully everything works together and how natural it comes to building a quality-oriented project when we try to grasp what exactly we are developing and why certain decisions were made.

— — —

Understanding that my team needs an overview of the application’s architecture was a stepping point in reconsidering how certain pieces of the system interact. This is extremely useful especially when we discuss complex team organization with dedicated sub-teams. It’s hard to keep track of how all the components interact, define clear requirements(especially for the teams we are dependent on), and create pieces of components that fit together when there is no overview.

All in all, if the base of the system is build the right way we will have a successful product if not, at some point we will have to start over or rewrite important parts. When I’m referring to the base I particularly consider two directions:

• Architecture is the foundation of the application, we already discussed this, is like building a house. It has to allow you to later create the walls, the roof, and other details that you might want along the way or when the trends evolve and change, but above all, it should give stability and direction for how the rest will evolve at a structural level. The architecture is a system’s base and has to be carefully thought of to bypass any major design changes & code refactoring at a later point in time.
• On the other side, the development team is also the base. We can have the best architecture plan but if the ones building it step by step don’t have the knowledge/ overview to support it we will have a lot of trouble.

I really believe that even though we can work in distributed teams, with clearly defined roles we should never limit ourselves to the comfort zone of the task at hand, we should be curious and eager to understand what we are building. Always get motivated into growing and finding ways of improving our work.

A small improvement at the code level made with the thought of supporting the system’s architecture or design will have a huge impact in time.

So, even if there is a fine line between software development and software architecture that line should be crossed from time to time in order to bring a fresh change of perspective. This is valid on both sides, the architect and the developer. I really believe that we need to bring system architecture closer to the development team and make it more approachable.