4 Things to Consider When Building Software Architecture • Slash

So it’s time to start building the software architecture, and you’ve many things running through your mind at the moment. You want to build an architecture that will serve the project well, something that is scalable and easily modified if need be. To that end, here is a tidy list of five key points to consider when building your software architecture.

Table of Contents

Decoupled Architecture

To begin with, let’s consider a decoupled architecture. A decoupled architecture will provide us the ability to decouple the functions of one large service into smaller services that operate independently of one another. No one likes it when one service causes the entire system to crash so decoupling offers a tactful approach to your software architecture.

To better envision a decoupled architecture, consider a big insurance portal service which has a login, user profile, insurance policy, insurance quotes, payments, etc. If this service uses a monolith style architecture and the database goes down or has some issue generating PDFs that causes a crash, the entire service becomes inoperable. For obvious reasons, this is not an opportune situation so we prefer to take a micro services approach.

You may be thinking, “What are micro services?” Well, first we list the key services available to the user of the insurance portal; for example:

Login
User profile
Insurance policy
Insurance quote
Insurance payment

All of these functions are separated into micro services so that if one fails, it does not impact the others or make the entire system inoperable. This in essence is decoupling. So perhaps the user currently cannot make a payment, but can login, edit/check their profile, generate an insurance quote.

It is equally important to decide how much to decouple vs couple the services together. For example, a fitness app showing exercise/activity also needs to retrieve user data like profile and preference info. These can be separated, but may function better if coupled so this needs careful consideration as responsiveness is a clear priority for users. Therein lies the transition to our second point…

Reasonably Fast Performance

Naturally users desire fast performance with speedy response times. For an architect, it’s essential to find the optimal response time performance. So yes we want to be fast, but not overdo it so as to overcomplicate the development. When building the software architecture, we must find the sweet spot between the optimal performance for the current architecture and what we need to prepare for the possible future feature needs; as well, how far we need to prepare.

Let’s consider the following example. We are building an e-commerce website, and naturally we would like the pages, e.g. product and payment pages, to load as quickly as possible. Anything in the below 2-second mark range is acceptable. For the architecture therein, we would optimize the assets loading speed by adding CDN; additionally, ensuring the scripts, images, assets for the pages are optimally built to load properly so the APIs (RESTful / GraphQL) respond in less than a second using either http 1 or 1.1 protocol. Moreover, for the future runway of this e-commerce site architecture, in order to be able to add further features while maintaining optimal response time using the same protocol, we would not consider overcomplicating things by employing http 2 (gRPC), web socket or a tcp/udp socket connection.

Consider another instance, if we are building a real-time chat application, we also need to take into account its performance. Hence, designing an architecture ideal for real-time chat, we cannot rely on using Http 1 or 1.1 protocol (APIs as RESTful / GraphQL) to send messages or Bosh for long polling to pull updates from time to time. For the time being it can work though it’s not suitable long term as we cannot scale to handle hundreds of thousands of users simultaneously with this method. Therefore, we have to consider a more long-life connection protocol like tcp socket (XMPP for mobile), web socket (ex: SocketIO) for Node or http 2 (gRPC).

As you can gather from the above example, “speed” from an architecture viewpoint is defined in a number of ways. There are many aspects to consider, and one must judge carefully in order to build the best software architecture for the project!

Architecture Runway

Our third point to consider is the architecture runway and ensuring that you’re continuously investing into it. Using our previous insurance portal example, when taking functional and non-functional features into account for a big solution like an online platform for selling insurance, we can see the vision of the project. This will enable us to create the most optimal runway for the team; however, the team cannot see the whole picture or anticipate all the inevitable changes on the horizon. Let’s unpack that a bit further.

The vision is to build an insurance portal platform for selling a variety of insurance packages; perhaps auto insurance with limited user/agent features. However, we also know that at some point down the line we or the client may want to add other types of insurance like homeowner’s insurance or company insurance using the same user/agent functionalities. In this situation we must design in a manner that allows the user/agent profiles or logins to be separated into micro services in turn enabling the future service/platform to re-use the functionalities already built. So you can see here our first point of decoupling comes in handy when considering our architecture runway.

It’s key for the architecture runway to be flexible, easily extendable and grow with the project. As the features or solution grows, more technical complexity arises; therefore, as an architect we need to continuously extend the runway to enable the development to move forward as far as possible. No crystal ball needed, just good planning and foresight!

Integration

Similar to the architecture runway, we come to the important point of integration. We must consider the integration to third parties, libraries, legacy systems, internal systems and so on. There is the obvious need to tailor the communication method to each of those systems, effectively and efficiently. For example, how can we design an integration of client to client single sign-on for services such as Microsoft 365, internal SSO, AWS Cognito or Google Authenticator? For that matter, what about an integration to legacy systems to push the data to them when saving, or pulling batch data for them to use in our newly built system?

Let’s break this down into more easily digestible content. So in most cases we don’t build a standalone application which doesn’t communicate to any other system. There are a plethora of useful building blocks in today’s world which we can employ to speed up the development of a product not limited to only the software development field. However, for software development there are many services that function as one service platform, service infrastructure, service software and so on. We can leverage these services to accelerate the software building process. That said, there are also legacy systems which are needed for new software to work.

Here’s a good example that showcases the challenges of integration. A previously completed project of ours required a connection to one specific government platform. However, the connection method was anything but contemporary, i.e. HTTP protocol, TCP socket protocol, etc. The connection instead was through SMTP protocol behind a VPN using XML as a standard file format. Consequently, we initially needed to solve the connectivity part by using the correct VPN client, authenticating the VPN credentials and compliance, solving the SMTP connection using a Node.js based SMTP connector to send and receive messages. Following that, we needed to know the time and frequency of the communication to the government server. Plus to top it all off, how to parse the message of XML had to be solved; including storing and processing the data accordingly such as updating the database record, storing those messages into AWS S3 and so on.

As you can see there are a number of integration considerations to keep in mind when designing your software architecture. Simply put, integration can be complicated and vulnerable to having issues so meticulously designing the architecture can mitigate risks and plan for the unexpected.

Ultimately it’s important to be confident in the decision you make, which in turn can embolden your development team. Don’t second guess or opt for half measures, go all the way. Carefully considering and planning the points discussed will result in a better project and in due course, greater finished product for the client.