Reference Architectures 101

If I were asked about a single characteristic that all engineers share, I would say it’s an enthusiasm to solve problems. I’m not sure if it is something innate to me, but I love facing and overcoming challenges. I also know many other engineers in different areas of knowledge distinguished by the same passion.

One time, when talking to my nine-year old nephew about different professions, I compared this characteristic to a superpower. He loves the Avengers saga, so it was easier to explain to him the differences between disciplines by associating them with superheroes.

Designing Software Systems Begins with Selecting an Architectural Style

However, while solving problems is a great ability in software engineering; it has at least one drawback. Often, we’re so eager to start tackling a challenge that we forget to pause and ask what it is the context around it. Designing a software system is not an easy task. It’s a process of balancing needs, constraints, and multiple other factors that may conflict with each other.

A typical starting point when designing software systems is to select what architecture style (also called an architectural pattern) is the best for your needs. Microsoft defines an architectural style as “a family of architectures that share certain characteristics.” They don’t require specific technologies to make things work; it is general guidance on how to solve a problem in a particular context. Each style focuses on how to arrange code and other software elements.

Let’s compare this to churches, for example. Gothic is an architectural style where buildings share distinctive characteristics like flying buttresses, pointed arches, a vaulted ceiling, and large glass windows. In the software world, an event-driven architecture, for instance, consists of producers, consumers, routers, and, of course, events. This is consistent, regardless of how or where it is implemented.
[adinserter name=”Software-Development-eBook-Offer”]

An Architectural Patterns is a Set of Common Characteristics, Not a Step-By-Step Guide

Now, even though the Notre Dame Cathedral in France, the Duomo di Milano in Italy, and the Westminster Abbey in England are all Gothic-style, a quick web search will prove that they aren’t equal. The same goes for software architecture styles. Suppose you compare two applications built using the microservices pattern. Despite all the similarities resulting from following the style, there will be multiple different elements on each. This seems rather obvious. You won’t necessarily get good results by following the exact same steps, technologies, and tools that Netflix does.

Nevertheless, it’s tempting to copy others, especially the unicorns, even when you don’t have all the information about why some decisions were made. Even though some companies are very open in sharing details about their journey, you can only see what appears to be on the surface most of the time.

History goes that the Notre Dame Cathedral was built using recycled materials from a former Roman temple. I can’t imagine the architect in charge of the Duomo de Milano project thinking of getting stones from demolished pagan temples in France. Perhaps using marble from Mergozzo, less than 75 miles away, would make more sense, right?

An interesting point is reinforced from this rather silly comparison: as mentioned above, a style defines particular characteristics, but not the specifics on how to fulfill them. The implementation will be affected by the architect’s influence, the raw materials around it, and the purpose to be achieved. However, if copying others is not the best alternative when you want to start your own journey, what path should you follow? Do we need to design every system from scratch? Is that what our problem-solving superpower is for?

In one of the chapters of the book “97 Things Every Software Architect Should Know”, Eben Hewitt states that “[a]rchitects and developers learn to enter problem-solving mode immediately.” This is akin to waking up one morning in a forest and, just after realizing you aren’t in your cozy bed, immediately starting to walk home. Obviously, you would want to get home, right? However, how do you know in what direction home is? Are you in the same city? State? Maybe you’re on a different continent. Just walking won’t get you back home. But what if you had a map?

Enter Reference Architectures…

Hewlett-Packard Enterprise defines a reference architecture as “a document or set of documents that provides recommended structures and integrations of IT products and services to form a solution.”

If we decompose this definition, we can extract two distinctive pieces. Let’s start with “IT products and services.” Think of these as the raw materials, the brick and mortar of what you’re building. The same style might be created with different components.

Then we find the “recommended structures and integrations,” which define how these materials are arranged. This is important because the right combination most likely means a smoother implementation. Some components make it easier to interact with than others, depending on the manufacturer, protocols used, etc.

All this information is shared in a “document” or “set of documents” describing a “solution.” But, how do you know this solution is appropriate or well defined? The definition from the HP team continues: “The reference architecture embodies accepted industry best practices, typically suggesting the optimal delivery method for specific technologies.” This means that whoever is providing the recommended implementations already walked the path. You can leverage their experience.

Using the Map to Chart Your Course Home

Let’s go back to our example of building an application using the microservices architectural style. Microsoft provides a recommended implementation using several Azure components, and Amazon follows suit by describing how to make it using AWS. You can use this as a starting point. But, beyond working as guidance on how to start building your application, it also works as a discussion trigger.

If you’re in a highly regulated industry, your executive and legal team will be interested in knowing how the application information will be protected. Or maybe they will want to identify if the components’ type of licensing is the best for your goals. By using reference architectures, you can have your team participate in the analysis and discussions that are important for your company, even before writing a single line of code. You are looking at the map before starting your journey, which will help you identify potential risks and where they are.

Another potential benefit is that you can calculate the costs of implementing a solution in advance. Given that you can quickly look at the components you may end up using for building the application, it’s easier to determine what you have or not or look for alternatives. There might also be some buy versus build discussions.

This is even more useful for cloud environments since most of the components will increase the current billing amount and, in consequence, impact your budget. Or, if your organization hasn’t made the shift to the cloud yet, this will help your team to get a sense of what elements are required to have your first application “up there.”

Nothing is Written in Stone

Of course, no reference architecture is a complete solution. One size doesn’t fit all. There are still details to be filled in by your team, based on your environment, existing resources and systems, corporate standards, and budget. But having something to start with will be more useful than trying to reinvent the wheel. This will help you to avoid errors and delays that would be costly for your company.

About the Author
Jorge Gaona is Director of Cloud Architecture at 3Pillar Global.