Scaling Software Architecture in Your Organization: A Practical Guide to Thinking Architecturally — Part I

Published in

SSENSE-TECH

8 min readFeb 10, 2023

Have you ever wondered why software projects often fail despite having a solid architecture in place? Software architecture is often misunderstood as an activity carried out from an ivory tower by a select few individuals who are disconnected from the reality of day-to-day life. However, this couldn’t be further from the truth. So, what is software architecture? And how can we scale it in our organizations?

This series aims to demystify software architecture and provide pragmatic ways to disseminate it across organizations.

Part I will review and expand on the definition of architecture and common pitfalls. Part II will discuss how SSENSE has adopted a federated model as a way to scale. Part III will conclude with a focus on the developers and how they can adopt this architectural mindset.

What is Software Architecture?

In a previous article I covered what I do as a software architect at SSENSE, and one of those activities is to define — or refine — the architectural solutions we have within our domains. Software architecture captures the decisions taken and is part of the shared knowledge of the systems within your company.

Should the architect be responsible for making all decisions? No, and the reasons are the following:

It would not be efficient to block the development until the architect has all the definitions.
It would negatively impact the quality of deliverables. The architect making decisions in isolation would cause the developers to become simple executors, preventing them from leveraging the discovery that takes place as part of the actual coding.

The architecture should focus on the hard-to-change decisions[1], those that have the biggest impact on the business or that transcend the boundaries of the development team/domain.

What are the top considerations when it comes to software architecture?

While it is hard to generalize what those decisions are for any given industry or context, let’s look at a non-exhaustive list summarizing the top considerations to take into account:

Which development language should be used?

Having too many languages can make scaling horizontal initiatives — such as observability, developer tooling, and security — difficult.
If you have non-negotiable specific quality requirements, such as latency, the language you choose may not allow you to meet said requirements.

How should my application be hosted? (Cloud, on-prem or hybrid)

Cloud may give you advantages to offload development but comes with tooling and process changes.

Which cloud provider services should be used and which ones should we implement ourselves?

Cloud providers offer services that promise to offload the maintenance needs from you.
But it comes with trade-offs in terms of cost or functionality that may not be compatible with your context.

How should we handle authentication, authorization, and security practices?

Security should be baked into the development process, not added afterwards.
Inconsistency or lack of authentication and authorization can pose a threat to business continuity.

How do we ensure business continuity for the application?

Handling outages in the infrastructure should be compatible with the financial impact.
Increases in traffic are factored in to make sure all Service Level Agreements (SLA) are honored.

What is the responsibility segregation?

Assessing if the responsibility for a given business capability belongs to your domain or not.
Clarifying the changes that will ripple through other domains.

Now that we have reviewed the definition and some basic guidelines, let’s examine common pitfalls you may encounter as you adopt the architecture practice.

What Can Go Wrong

“The road to hell is paved with good intentions” — Bernard of Clarivaux

Having an active software architecture practice is supposed to be a positive thing, but it is not uncommon to see it stumble or be heavily criticized by those who fail to understand it or avoid its pitfalls.

Beware of the Ivory Tower

Joel Sposky, software engineer and writer who co-founded Stack Overflow and launched Trello, once wrote about how we should not let “architecture astronauts” scare us. He mentions how great thinkers see patterns and have a tendency to create abstractions to model the solutions. While there is nothing wrong with abstractions, if they rise too high they lose the specific meaning of the problem they were supposed to solve.

One of the first dangers to avoid is overly abstract solutions. Not knowing when to stop may lead to overly complex solutions, partially due to the generic nature of the abstractions or by including unnecessary elements.

As an example, consider the task of calculating insurance costs for shipping goods. Based on the current requirements this will be determined by the cost of the goods and the destination country. With these two variables, you locate the cost per $1 for the destination country and perform the calculation.

This architecture proposes a generic approach where the backend would capture the settings for this domain, and then share them with the frontend via events. The frontend would have a local copy of this data just to serve the read requests, which in our case is the rate per destination country. This appears to be a valid design, so what is wrong?

We created an abstraction to address the challenge of making settings defined in a backend application available to be exposed to the more demanding frontend. If we look at the requirement, we will discover that the settings for the insurance only change once a year and contain less than 200 entries.

This raises the question: is a generic approach necessary when the data is so static and limited? Perhaps a simpler solution would suffice.

Figure 2. A simpler approach that is focused on the problem.

The alternative proposal embraces the scope of the problem while still abstracting the source of the data for the application. The lambda can use a simple repository pattern to make the application indifferent to where the data is coming from. If and when the application changes and there is a need for a more complex UI to maintain the settings, or the frontend needs more settings, the architecture can evolve.

The Technology Merry-Go-Round

Technology changes all the time, and the pace is only accelerating. As a consequence, people feel the pressure of not using the latest framework/tools/languages and experience FOMO (fear of missing out). Many, especially those in the early stages of their architecture career, succumb to this pressure and end up adopting technologies that are either not ready for the intended use or disconnected from delivering business value.

This is a second potential pitfall. As architects, we have to be deliberate when selecting what is part of the architecture[2]. While no one wants to be the last one still using a legacy technology, it’s crucial to assess its maturity level and carefully weigh the benefits and risks of using anything new within a specific project.

Figure 3. Choosing a new technology without considering the implications tends to lean towards the new.

Instead, consider relying on a more deliberate approach to decide if the technology is ready, or if the project is the best candidate for something new. This way, you can ensure that your technology choices are both effective and relevant to your goals.

We will discuss the use of Technology Radar and Architecture Catalog to help you make this decision in the next article.

Running Too Fast Towards Technology

I like to think that the best software architects are still developers at heart. This helps us stay rooted in reality and recall that, in the end, our solutions will materialize themselves in the form of software applications and services.

As developers, most of our formative years are geared towards mastering tools, data structures, and algorithms. Unsurprisingly, this leads us to start thinking about those topics as soon as new projects begin.

This is a potential third pitfall. Focusing on technology for technology’s sake instead of asking first, if and why we should be delivering a specific business capability within our domain — or at all.

Figure 4. A choreographed execution between two services.

Figure 4 illustrates a choreographed execution between two services. Service A needed service B to do something and the decision was to integrate using events. This is a perfectly valid solution, but in this case unnecessary as both services are within the same domain and service B capabilities are only needed from service A.

A simpler, yet valid solution, could be to make service B a module of service A and have the same segregation without the network overhead and added cognitive complexity.

Figure 5. Revised approach with simpler integration.

To Be Continued …

Consistently practicing software architecture brings many benefits but is not something that can be accomplished overnight, nor is it immune to problems while being established.

The first challenge is determining what should be part of the architecture, which can occur when the focus is not on the outcomes and fails to align with business objectives. Other common issues stem from being in a technology merry-go-round, always chasing the shiny new thing — even before it is ready to be used — and neglecting the lessons of the past.

To avoid these pitfalls, it’s crucial to focus on understanding what the intent is, and what the new or updated business capabilities are, and segregating the responsibilities accordingly. Technology will follow!

How fast and wide you are making architecture practice part of your development culture is a challenge that needs to be tackled, and will be the topic of my next article on this series.

Until next time!