One of the first questions asked as I start or join a software project is what I think about the solution architecture. This question may either be an attempt to have the current architecture assessed or a first step in building the application. The answer can often be frustrating to the listener as it always begins with a question. Furthermore, there are questions that follow that first one. That does not mean there is no “template” for architecting a solution. However, I think it is important to look at what we are doing in order to take the proper steps.

Define The Problem

The most critical factor in creating a solution architecture is not the design of the architecture, it is the solution. Otherwise, you are setting up a classic cart-before-horse approach. There is just too much about a well-designed solution that hinges on the problem you are solving to not focus there first. I once heard it best described as a good architect keeps asking “and then what?” as they listen to someone walk through a problem. The first step is understanding the problem and related processes in detail so you can avoid designing yourself into a corner. A failure to properly understand this point counteracts the skills of even the best architects.

Requirements and Constraints Drive Solution Architecture

Everyone likes to start with an “it does everything” approach to define a solution. There is nothing wrong with this. However, a solution architecture that is the best fit requires us to drill deeper. Here are just a few key data points every modern solution needs to address.

• Who is the Audience?
• What is the size of the initial user base? (how many users?)
• How frequently will this be used by the users?
• What is the expected/useful time frame required to solve the problem?
• Where does the user experience need to fall between form and function?
• What sort of data is going to be captured?
• How long does the data need to be retained?
• How private or public is the solution and the data? (security concerns)
• What current technical resources are available?
• What is the “happy path” and what sort of exceptions might occur?
• How should the user experience the “happy path” and exceptions?
• What is the expected interface? (Desktop, mobile, phone, audio, visual, or others)
• How is this expected to grow in user base, features, and access?

As you can see, this is a lengthy list. It is also just the beginning. The definition of a good solution architecture includes one that is scalable, maintainable, stable, usable, and understandable. However, it also needs to properly and fully address the problem to be solved. Likewise, there is a context to the problem that needs to be understood as well. As an example, check out the sort of questions a building architect should ask: https://maxablespace.com/questions-an-architect-should-ask-a-client/

Software Architecture Is Like Building Architecture

I find the best examples to help understand software design and architecture is to look at building a house. There are a lot of ways to build a house. Therefore, there are a lot of questions to be answered before architecting a plan. The link above provides a list of such questions. Software is at least as complex as a physical building. Thus, it makes sense that we need to answer a lot of questions before designing a software solution.

There is a lot of context around the solution that impacts architecture much like context impacts a building. Think about building a house on a beach and then think about that same house on a mountainside or uneven ground. Then think about the house in a field of empty acres as compared to the middle of a congested subdivision. Context means a lot when architecting a solution. Therefore a good architect will ask questions and dig deep to understand the context around the desired solution.

Software Architects are a rare breed. There is only a small percentage of developers that grow into architects for a reason. There is a requirement to be able to fully grasp the business context for a solution and then translate that into the technical architecture. Thus, your best approach to starting a solution architecture is to do your homework and understand the problem to be solved and the proposed solution. Only then can you start on the system architecture.

Check out this article for some more thoughts on getting started with your project: http://54.197.223.3/RB/blog/planning-and-design/