What It Means To Be a Software Architect At SSENSE
Software architect is not a new position but despite being around for quite some time, it is always something that brings some confusion to many companies. Especially those that are growing quickly and suddenly see themselves with the need to introduce this position in their organizational structure.
The common questions revolve around the following areas:
a) What does a software architect do?
b) What value does a software architect bring?
This stems from the fact that, at least in companies that develop their own software, the most common position is the developer, where it is divided by the level of expertise or by knowledge area.
An architect is not the team leader, not the senior developer of a team, nor the manager. As a software architect for 5 years, in this article, I’ll describe my view of the architect’s role and how it functions specifically at SSENSE.
Defining Software Architecture
In order to define what a software architect does, and its potential place in the organization, we should start by looking at what software architecture means.
The term is borrowed from the equivalent role in the construction world, but the comparison isn’t perfect. In construction, the architect may be perceived to focus on form over function, prioritizing aesthetics, while the engineers do the opposite and actually make it possible to build what has been planned.
In 2000, the Institute of Electrical and Electronics Engineers (IEEE) posted the standard 1471 to recommend the practice for an architectural description for software-intensive systems. In this standard, there is a better attempt to define that the architecture consists of “… the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”.
Martin Fowler addressed the topic and refined the previous statement by defining the architecture as the “shared knowledge of the system” and made of “hard to change decisions”. Those decisions mainly influence the internal quality of the software built, such as which language to use, which modular design to adopt, and so on. Due to its internal nature, these decisions are not commonly perceived by the users of the system nor the business, as they tend to manifest themselves in the medium term.
Figure 1. Attempts to illustrate the economic consequences, and therefore the value of having an architecture in place. A good design, built as the result of those hard to change decisions, can help to continue to deliver new functionality at the same or better pace as time progresses. On the other hand, not having a design, or a poor one can lead to immediate gains but make adding new features increasingly difficult and costly in the medium to long run.
As a company grows, in size and in the complexity of the solutions it needs to provide, creating and maintaining this design becomes a full-time position. And so, this is where a software architect — or team of — comes in.
What a Software Architect Does
When I decided to pursue this position in our industry, I chose to first define, as concretely as possible, what being a software architect would mean. Instead of providing yet another definition, I opted instead to establish the tenets of what an architect would do, and converged on the following 3:
- Bring Business and Engineering Together
- Stay Technically Relevant
- Help Your Teams to Grow and Perform
It is important to note that although there are connections between all of them, there is not a hierarchy or level of importance that differentiates one from another. They are all important and I aim to apply them equally.
Bring Business and Engineering Together
As your company grows, it is a given that you will face increasingly complex challenges. At this point, it helps to have someone who has the experience of having developed complex or mission-critical systems to look at it, not only from the technical point of view but also from the business perspective. This involves more than just thinking about what technology or pattern to use, but to challenge and suggest alternative solutions on how to achieve the desired results.
The architect would understand the goal we want to achieve, evaluate the current scenario, and then build the design — the architecture — to achieve such a goal. This is best done if you can navigate between both worlds: business and technology, while aiming to bring them closer together.
Part of my schedule includes reaching the business, analyzing the upcoming projects, and discussing the motivations, the priorities, and potential trade-offs you may have to do to satisfy requirements such as deadlines.
As the picture becomes clearer, I start and refine the architecture I want to propose. Here I will leverage a set of artifacts to capture and transmit the vision. I like to use the context map to propose the boundaries and illustrate the relationship between the domains the solution will achieve.
This usually provides a high enough view of the solution that both business and engineering can refer to and use as a guide for the underlying decisions that will follow. For those decisions, I adopt a mix of two diagrams: the C4 model and the Business Process Model and Notation (BPMN).
The C4 model is one of the available options that allow capturing the architecture, with a technical focus. It establishes four levels: context, container, components, and code. I stop before reaching the code level, as it would be too early and likely too prone to errors due to the lack of details.
The BPMN on the other hand proposes a set of metaphors to capture the business process. I find it the “perfect” way to whiteboard how the solution will work and bring both business and engineering to the same level of understanding.
Unless there is a specific requirement or concern, I start with the BPMN to solidify the understanding of the problem and then go through the C4. It is important to highlight that the BPMN that is produced is expected to be further refined and maintained by both business and engineering, as a live document.
Stay Technically Relevant
A common misconception is that the architect spends most — if not all — their time drawing diagrams or talking at a high/abstract level. I absolutely spend time on this as new projects appear, but I try to stay technically relevant, and this means coding! Definitely not as much as the early days or as a developer does, but I believe it is important to be rooted in reality, and that means being capable of understanding the code produced by the teams you work with, and even contributing to it.
Don’t forget that none of the developers report to you, hence it is important to be able to gain the trust of the team, and I do not know any better way other than truly contributing to their day-to-day, even if not every day! :)
I do this by looking at the pull-requests and sharing feedback about the good points and suggestions for improvement. This, combined with a shared experience from other architects, developers serve as the basis for ideas to improve or for new concepts to attempt to apply company-wide.
Help Your Teams to Grow and Perform
The best architecture will only be useful if it gets to see the light of the day, and the teams of developers you work with are the ones responsible for that.
I believe this offers yet another opportunity to help those team members in two separate aspects:
- Share experiences on how to handle the different aspects of the development, from strategies on how to split complex projects, to ways to evaluate and approach new technologies. This is referred to as “Thinking architecturally”, and aims at making them grow and ultimately be comfortable with the new challenges.
- Share specific knowledge on a given pattern, tooling, or approach that is either in use or soon to be introduced. This aims to help them to perform better and perhaps correct or improve certain aspects of the current software in use.
It is important to stress that this is a bi-directional and collaborative process, where both parties have the opportunity to learn and contribute.
No Shortage of Challenges
SSENSE is in hypergrowth and it comes with an equal amount of challenges and opportunities, as the business processes become more complex and the technical landscape evolves.
As an architect, I am currently applying Domain Driven Design, strategically adopting Event Sourcing, balancing the alternatives for hosting of an ever-increasing number of microservices, and looking for the efficient use of polyglot persistence options (RDBMS, NoSQL, Graph). Those are just some of the areas we are leveraging to allow the aforementioned growth to continue as we expand the teams.
Did I mention that we are hiring? Check out our open positions including software architects!
Editorial reviews by Deanna Chow, Liela Touré, & Mikhail Levkovsky.
