When building new technology, selling your organization on the notion of a discrete technical design phase for the project can sometimes be difficult. This is especially true if there is a feeling among your team members or your stakeholders that the problem is already well understood, or that an incumbent toolset is the de-facto selection for new work, and that a quick win is within reach.

When building software that has to be enterprise-grade, quick wins and shortcuts are often fool’s gold. There are several good reasons why you should take the time to do technical design. Chief among them: It’s a chance to develop a reference architecture – technical documentation that outlines how the components of the final product will relate and work together. Throughout implementation, your reference architecture will serve as your blueprint, guiding you through the technical process.

Wait, what is it?

In the context of modern software development, a reference architecture includes at least the following:

• A technical decomposition of the problem set that groups required features into functional areas that can be bundled and deployed as services or microservices
• Technical descriptions of the external interfaces of each service
• A service topology and plan for inter-service communication and coordination (event bus, message broker, transaction manager, REST etc).
• Technology and component selections for each service, validated with technical proofs of concept where appropriate
• Infrastructure selection and operations planning

A reference architecture will consist of numerous pieces of documentation, and typically includes technical illustrations (entity-relationship, sequence, component diagrams) as well as source code from the technical proofs of concept.

What’s so great about a reference architecture?

The process of technical design and the creation of a reference architecture can improve the quality and success of your project in several ways. Here are just a few:

• By better allocating resources. Technical design phases are smaller in scope than implementation phases. This allows the team size to scale as needed, rather than trying to make everyone on a larger team busy from day one.
• By challenging assumptions and refining requirements. A significant portion of creating a reference architecture is component selection. As you evaluate products, frameworks and databases, you’ll start to see the problem through different lenses. This insight can lead to a better understanding of what you’re being asked to solve. And you’ll gain this insight before any code has been written.
• By zeroing in on complexity. In thinking through the design of your system at a technical level, you’ll quickly identify the most complex parts. This is the right time to experiment. Technical proofs of concept will enable you to vet your component selection and software architecture with little investment, and without holding up your development team.
• By creating predictability. Throughout the technical design phase, your team’s understanding of the problem and solution are cataloged in a reference architecture. That body of knowledge will enable you to plan the implementation phase as accurately as possible, and will serve as an amendable guide in the sprints to come.

At Cantina, because we work with clients of different sizes, in different industries, some with and some without their own technical teams, we have to be flexible when it comes to our process. But we insist on conducting technical design, and we always start by creating a reference architecture. It’s the technical blueprint that will guide your team to a successful solution assembly.