It is crucial to recognize that great software doesn’t arise by chance. It begins with a strong architectural foundation.

Why Software Architecture Matters?

A well-structured architecture is essential for the success of any software project. Without it, even the most promising applications may struggle to scale, become difficult to maintain, and ultimately fail.

While you can’t become an expert overnight by reading a book, having the right resources will guide you toward building better, more intelligent, and more adaptable systems. Read more about White Box Core Concepts

At White Box, we highly recommend two game-changing resources:

📖 Clean Architecture by Robert Martin (Uncle Bob)
🎥 Software Architecture Fundamentals by Neal Ford & Mark Richards

Clean Architecture – Robert Martin (Uncle Bob)

Robert Martin, commonly known as Uncle Bob, is a highly respected figure in the software development community. His book, Clean Architecture, is an essential reading for any developer who aspires to create enduring software.

What makes this book so valuable? It teaches you how to design modular, flexible, and maintainable architectures that can withstand the test of time. Rather than focusing on a single framework or technology, Uncle Bob’s principles are timeless, making them relevant to nearly any software project.

At White Box, we have integrated these principles into our development process, allowing us to create software that is both efficient and easy to extend and maintain.

If you are committed to writing high-quality, enduring code, this book is essential reading.

Software Architecture Fundamentals – Neal Ford & Mark Richards

If you want a hands-on approach, this video series by Neal Ford and Mark Richards is an excellent resource. It covers theoretical concepts and delves into the real-world applications of software architecture.

Here’s what you’ll get from it:

📌 Architectural styles – Learn about different types of architecture (monolithic, microservices, event-driven, etc.) and when to use them.
📌 Common mistakes (antipatterns) – Avoid the pitfalls that lead to unscalable, inefficient, and messy software.
📌 Practical insights – Gain practical insights from two industry veterans who have learned what strategies are effective and which ones are not.

This series distinguishes itself by encouraging critical thinking about architecture, rather than merely adhering to a set of guidelines. It is ideal for developers seeking to enhance their skills and acquire real-world architectural knowledge.

Applying This Knowledge to Real Projects

To effectively learn software architecture, it’s essential to apply theoretical concepts to real projects. At White Box, we promote a culture of experimentation, encouraging our team members to explore new architectural patterns. However, we also emphasize the importance of understanding and adhering to fundamental principles throughout this process.

By integrating these advanced techniques into our projects, we not only enhance our team’s skills but also improve the overall design and performance of our software solutions.

Here’s how you can start applying these principles:

✅ Think before you code – Plan your architecture before jumping into development.

✅ Prioritize modularity – Keep components independent and loosely coupled.

✅ Avoid complexity – A simple, well-structured system is always better than an over-engineered one.

✅ Learn from mistakes – Study real-world architectural failures and understand what went wrong.

✅ Document your design – Maintain clear documentation to ensure that the architecture is understandable and maintainable for others. 

✅ Implement testing early – Integrate testing into your development process to catch issues early and ensure quality. 

✅ Prepare for security – Integrate security considerations into your architecture from the beginning to protect against vulnerabilities. 

✅Stay updated with industry trends – Keep learning about new technologies and architectural patterns that can enhance your approach. 

Start Your Software Architecture Journey Today!

Software architecture is not just a technical skill; it embodies a mindset that enables you to create enduring software. Whether you learn through books, videos, or hands-on experiences, dedicating time to mastering architecture fundamentals will significantly benefit your career.

🚀 Which architectural principles or books have helped you the most? Let’s discuss this in the comments

Challenge:

Our customer’s B2B sales team needed help managing their complex sales process, getting useful feedback and insights about their activity and expected sales results. Existing off-the-shelf tools were assessed but did not meet the expectations of the sales management team so White Box Technologies was asked to build a custom solution to fit their needs perfectly.

Solution:

Custom-built Sales Management Tool, covering the whole sales process and keeping track of salespeople’s activity and results.

User Group: 

Sales and marketing professionals (managers and agents)

Context: 

Our customer, a large multi-national company in the field of Telecommunications, was in need of a tool to assist with their sales and marketing activities, managing the whole sales process from marketing Leads to closing successful sales Opportunities.

After the evaluation of multiple of off-the-shelf Sales Management solutions, our customer decided to entrust us to build a custom solution for them, perfectly tailored to their complex sales process – which gives them an important competitive advantage.

Project: 

The project involved a team of 6 software engineers from White Box, testers and Operations team, working together with the Product Owner and Business Analyst from the Customer. The team used Scrum framework to organize its activities and managed to deliver the initial version of the software in 8-9 months, working in 2 week sprints.

Years later, the product is still being evolved by a similar size team from White Box, delivering new features and changes to existing processes, with ease and low risk for unexpected bugs.

Our team is responsible for the whole development life cycle, from analysis of new requirements, development, testing and Level 2 support, handling incidents and solving all issues that may occur in a production environment.

Maintaining Flexibility

This relative flexibility of the solution after years of evolving requirements following ever-changing business needs, was made possible by taking constant care of the quality of design (using principles such as: Clean Architecture, DDD, Modularity, low coupling, etc) as well as the quality of the code (making constant use of SOLID principles, OOP paradigms, design patterns, etc).

Good architecture is key to the future flexibility of any software product and our team took great care to keep the architecture clean at all times. Architecture is not just what the team decides at the beginning of the project, architecture is what evolves out of the code written every day by every developer, so it is essential that all team members are aware of their role in keeping the code easy to maintain and to understand in the future, as well as delivering the current requirement from the sprint backlog.

Technology

Stack

The technology stack we considered most suitable for this project:

• Java in the backend, using Spring for dependency injection, Spring Security, Spring Transactions, JPA, Hibernate, Elasticsearch for fast fuzzy queries, Relational database for persistence and data querying, Kafka message broker for integrating with other software systems, Redis for cacheing, etc.
• Angular in the front-end, with Angular Material design components
• Deployed in Docker containers in a Kubernetes cluster on prem
• Continuous Integration / Automated builds and deployments using TeamCity
• Thousands of automated tests (unit, integration, API) checking the integrity of our system at every commit and providing feedback in under 20 minutes (for acceptance testing pipeline cycle)

Architecture

The architecture of our solution was designed using principles from: Hexagonal Architecture/Ports-and-adaptors (concepts first introduced by Alistair Cockburn), DDD (Domain-Driven Design, developed by Eric Evans), with a rich domain model containing all of the business logic (handling the essential complexity) and isolated from the infrastructure details (handing the accidental complexity of our system).

Success Factors

The team had a high level of autonomy, choosing their own tools, technologies and way of working together to achieve the business goals of our customer.

Passionately discovering all business details needed to fully cover the complexity of our customer’s sales and marketing proprietary processes, in a way becoming sales and marketing experts ourselves, striving to talk the language of our users and become trusted advisors also in aspects related to the business side, not only technical.

Constant evaluation and improvement in the way we work, interact with our customer, communicate among ourselves and with all other stakeholders.

Continuous improvement for us as software professionals, keeping up to date with the evolution of technology, best practices and learning from the best in the world in order to bring the most value to our customers’ projects. We read books, attend conferences, watch training videos and share our passion and knowledge among us, in order to be sure we are near the top, not only compared to our local competition, but in the global context.

Our job provide us the unique opportunity of being world class software engineers, regardless of our location, it is only up to us if we make use of this opportunity, by channeling our passion for software and our determination to improve.

As in almost every other industry, we hear the word quality a lot in Software. What company does not display it proudly on their website or advertise it in their marketing material? Ask any sales rep of any software company and they will say quality is most important and is what they deliver on every project.

Yet still, in reality, most projects are seriously lacking quality and most members of our profession have a hard time giving a very convincingly definition of what quality means. Most projects, in best case scenarios, start by looking pretty and in good shape while newborn and very young, but do not age gracefully and sooner than anyone would hope, development slows down significantly and many changes result in unexpected (and apparently unrelated) failures and sometimes even costly bugs.

How it’s built is just as important as what it does

So what does quality mean? What are the characteristics of a genuinely well-built software product and why do they matter? According to Robert C. Martin (Clean Architecture) any software product has two main values:

• first, the more obvious value, the functionality it provides to the Business (the customer). It is the what, that the Customer has hired us to deliver. Hopefully, at go-live, our software does exactly what it was asked of it and exactly what is needed at that moment.
• however, there’s a second, maybe even more important quality: how easy it is to change the software, to accommodate new requirements in the future. This is not very obivous at first, when ideally most of the requirements are already built into the product. But if this was done at the expense of its flexibility, its ability to easily change with time, the first value will diminish very rapidly until the whole project becomes virtually useless and needs to be rebuilt.

In real life, most projects are so focused on What they deliver that the How it’s achieved is given a seat somewhere back in the stands, at nosebleed distance from the main stage. This is partly because how well a software system is build is not very easy to measure, especially if the customer is not exactly savvy in terms of software architecture, clean code and the best practices of our profession.

How to achieve quality

Building a software that remains relatively easy and safe to change as years (and tonns of new requirements) go by is no trivial thing. It takes constant care, from the start of the project and throughout it’s lifetime. Here are some of the things that can help, if applied diligently.

According to Dave Farley (Modern Software Engineering), in order to deliver quality in our day to day work, we need to focus on two main competences:

• we need to become experts at learning
• we need to become experts at managing complexity

Learning

Beside being one of the best predictors of job motivation, constant learning is the essence of what Software Development is all about: beside the most obvious part of our constant learning, the technology we employ and the techniques for applying our knowledge to the problem domain, we are in a profession of learning mainly because before we build anything useful, we must first be sure we understand very well what we’re supposed to build. 

According to Dave Farley, this is accomplished using the behaviours of: 

• Working iteratively
• Employing fast, high-quality feedback
• Working incrementally
• Being experimental
• Being empirical

“Software development is an exercise in exploration and discovery. We are always trying to learn more about what our customers or users want from the system, how to better solve the problems presented to us, and how to better apply the tools and techniques at our disposal.

[..] Learning is at the heart of everything that we do. These practices are the foundations of any effective approach to software development, but they also rule out some less effective approaches.” (Dave Farley)

Complexity

The real enemy of a software developer doing a good job, in terms of the quality they produce, is often the complexity of the systems we need to work on. If we were asked to work on simple, disposable apps, with short lifespans and no prospect for them to ever change, then this whole discussion about how things are done would have no point. 

However, in Enterprise Software at least, systems are used for many years (sometimes decades), with the expectation of flexibility and adaptability with the changing business requirements. And one element that adds most complexity to our software in an Enterprise environment is the integration with other systems, upstream and downstream. 

Most modern software systems are complex and large, too complex and large to completely fit into our brain at any time, regardless of how smart our engineers are. So we need to use techniques to properly manage this complexity, among which, according to Dave Farley, top candidates are:

• Modularity
• Cohesion
• Separation of concerns
• Information hiding/abstraction
• Coupling

Maintaining Flexibility

Maintaining the flexibility of a solution, after years of evolving requirements following ever-changing business needs, is made possible by taking constant care of the quality of design (using principles such as: Clean Architecture, DDD, Modularity/Cohesion, low coupling, etc) as well as the quality of the code (making constant use of SOLID principles, OOP paradigms, design patterns, etc).

Good architecture is key to the future flexibility of any software product and our team took great care to keep the architecture clean at all times. Architecture is not just what the team decides at the beginning of the project, architecture is what evolves out of the code written every day by every developer, so it is essential that all team members are aware of their role in keeping the code easy to maintain and to understand in the future, as well as delivering the current requirement from the sprint backlog.

One way to ensure the architecture can support such flexibility over the long term si to design using principles from: Hexagonal Architecture/Ports-and-adaptors (concepts first introduced by Alistair Cockburn), DDD (Domain-Driven Design, developed by Eric Evans) – with a rich domain model containing all of the business logic (handling the essential complexity) and isolated from the infrastructure details (handing the accidental complexity of our system).