{"id":6937,"date":"2022-09-16T14:10:50","date_gmt":"2022-09-16T06:10:50","guid":{"rendered":"https:\/\/slash.bravefactor.com\/?post_type=resources&#038;p=6937"},"modified":"2024-01-25T12:38:52","modified_gmt":"2024-01-25T04:38:52","slug":"4-things-to-consider-when-building-software-architecture","status":"publish","type":"resources","link":"https:\/\/slash.co\/articles\/4-things-to-consider-when-building-software-architecture","title":{"rendered":"4 Things to consider when building software architecture"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">So it\u2019s time to start building the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Software_architecture\" rel=\"noopener\">software architecture<\/a>, and you\u2019ve 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.<\/span><\/p>\n<h2>Decoupled software architecture<\/h2>\n<p><span style=\"font-weight: 400;\">To begin with, let\u2019s 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.<\/span><\/p>\n<p><img fetchpriority=\"high\" decoding=\"async\" class=\"wp-image-10196 aligncenter\" src=\"https:\/\/slash.co\/wp-content\/uploads\/2022\/09\/64ccd7b8c76f4d67874635b7_Decoupled20Drupal_0-300x150.png\" alt=\"Software Architecture\" width=\"418\" height=\"209\" title=\"\" srcset=\"https:\/\/slash.co\/wp-content\/uploads\/2022\/09\/64ccd7b8c76f4d67874635b7_Decoupled20Drupal_0-300x150.png 300w, https:\/\/slash.co\/wp-content\/uploads\/2022\/09\/64ccd7b8c76f4d67874635b7_Decoupled20Drupal_0-1024x512.png 1024w, https:\/\/slash.co\/wp-content\/uploads\/2022\/09\/64ccd7b8c76f4d67874635b7_Decoupled20Drupal_0-768x384.png 768w, https:\/\/slash.co\/wp-content\/uploads\/2022\/09\/64ccd7b8c76f4d67874635b7_Decoupled20Drupal_0-1536x768.png 1536w, https:\/\/slash.co\/wp-content\/uploads\/2022\/09\/64ccd7b8c76f4d67874635b7_Decoupled20Drupal_0-2048x1024.png 2048w\" sizes=\"(max-width: 418px) 100vw, 418px\" \/><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You may be thinking, \u201cWhat are micro services?\u201d Well, first we list the key services available to the user of the insurance portal; for example:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Login<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">User profile<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Insurance policy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Insurance quote<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Insurance payment<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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\u2026<\/span><\/p>\n<h2>Reasonably fast performance<\/h2>\n<p><span style=\"font-weight: 400;\">Naturally users desire fast performance with speedy response times. For an architect, it\u2019s 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Let\u2019s 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,\u00a0 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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\u2019s 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).<\/span><\/p>\n<p><span style=\"font-weight: 400;\">As you can gather from the above example, \u201cspeed\u201d 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!<\/span><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/p>\n<h2>Architecture runway<\/h2>\n<p><span style=\"font-weight: 400;\">Our third point to consider is the architecture runway and ensuring that you\u2019re 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\u2019s unpack that a bit further.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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\u2019s 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\u00a0 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">It\u2019s 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!<\/span><span style=\"font-weight: 400;\">\u00a0<\/span><\/p>\n<p><strong>Also Read : <\/strong><a href=\"https:\/\/slash.co\/articles\/scalable-software-architecture\/\">10 Things You Need to Know About Scalable Software Architecture<\/a><\/p>\n<h2>Integration<\/h2>\n<p><span style=\"font-weight: 400;\">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?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Let\u2019s break this down into more easily digestible content. So in most cases we don\u2019t build a standalone application which doesn\u2019t communicate to any other system. There are a plethora of useful building blocks in today\u2019s 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Here\u2019s 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Ultimately it\u2019s important to be confident in the decision you make, which in turn can embolden your development team. Don\u2019t 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.<\/span><\/p>\n","protected":false},"featured_media":10188,"parent":0,"template":"","resource-topic":[63],"resource-type":[43],"class_list":["post-6937","resources","type-resources","status-publish","has-post-thumbnail","hentry","resource-topic-software-development","resource-type-articles"],"_links":{"self":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resources\/6937","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resources"}],"about":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/types\/resources"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/media\/10188"}],"wp:attachment":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/media?parent=6937"}],"wp:term":[{"taxonomy":"resource-topic","embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resource-topic?post=6937"},{"taxonomy":"resource-type","embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resource-type?post=6937"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}