4 Things to Consider When Building Software Architecture

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.

Decoupled software 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.

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.

In software architecture 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! 

Also Read : 10 Things You Need to Know About Scalable Software Architecture


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 in software architecture 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.

Promsopeak Sean Nuon
Sean Promsopeak Nuon
Lead engineer
Sean is technology-driven and passionate about working with technology that helps people. Now he finds himself as an executive member of Slash, executing the technology operation side from an entrepreneurship point of view. He has over 9 years of working experience dealing with technical problems, project management and team mindset building. He splits time between Solution Architect & Lead developer for enterprise clients and as part of the management team, he helps build future-proof architecture, define quality standards, team culture, and hiring & training practices.
In this article

Explore more resources

5 Things to Consider When Choosing a Mobile App Development Partner in Singapore
5 Things to consider when choosing a mobile app development partner in Singapore
Discover essential tips for choosing the perfect mobile app development partner in Singapore. Learn about expertise, portfolios, communication, technology, and value to ensure your app's success.
6 minute read·
by Henry Panhna Seng ·
June 21, 2024
AI prompt engineering
AI prompt engineering techniques: the power of crafting effective prompts with special prompt formulas
Learn the art of AI prompt engineering techniques to maximize the potential of generative AI. Discover effective strategies and tips to craft precise prompts for optimal AI outputs. Explore advanced solutions at Slash's Generative AI Solutions.
7 minute read·
by Kevin Yin Seng ·
July 15, 2024
Skip to content