How’s it going tech folks? I have been silent for a while but decided to make a noise after all. How to architecture your product precisely for it to operate without any abnormalities to meet its non-functional requirements is what I’m going to talk about. If you don’t properly architecture your product it might behave abnormally under a heavy load, could be vulnerable to attacks or even it could face a number of other consequences.

What’s Software Architecture

Let’s see what’s Wikipedia has to say,

Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. These structures are needed to reason about the software system. Each structure comprises software elements, relations among them, and properties of both elements and relations.

What Wikipedia is trying to say here is that the software application architecture serves as the blueprint which defines the structure of the final outcome so that it will meet all of its functional and non-functional requirements while ensuring it is technically feasible. The architecture of any product is the key carrier of its qualities such as performance, security etc. none of which can be achieved without a unifying architectural visualization. It’s a must to have the right balance of the users, system and business aspects to define the best architecture for the product.

How to Architecture

There is no any correct answer to this, but today I’m going to give you few guidelines that will help you in defining your next software architecture correctly. Always do remember to keep your product’s functional and non-functional requirements in mind when you are following the guidelines. Let’s jump right in.

Make it Cloud Ready

Cloud is the future of the software industry. You have to make your product cloud ready because otherwise, your product won’t last long as you picture it to be. In order to understand how you can make your application cloud ready lets refer to the Top 9 Rules for Cloud Applications by IBM. Okay, wait! Clam down! I know it’s from IBM, but these are generalized in a way you can use it with any public cloud provider of your choice. If your application has followed the rules given in the link, let’s say you are consuming PaaS services for your application, then you don’t have to worry about your infrastructure at all. Let’s say you are expecting high load during weekends due to the nature of your application, what you could do is auto-scale (scale up during the weekend and scale down afterward). Isn’t that cool?

If you are really curious to get started, below image shows an easier way to be cloud ready. I’m just kidding.

Follow Design and Architectural Pattern

First, you need to understand what a pattern is and how it can be applied to your product to reap the best results. A pattern is a solution to a recurring problem in the context of software designing. Having an understanding of the design and architectural patterns available will give you an idea when to use what pattern according to the product you are architecting. You might be wondering where to find all these patterns now. Stop worrying and refer to MS Cloud Design Patterns Infographic 2015 for a set of patterns that are commonly used. Okay, wait! I know it’s from Microsoft, but patterns are generalized in a way you can use it with any public cloud provider of your choice. Patterns are not limited to the above, there is a lot more… try Google! Wonderful right! I know :-)

Don’t Reinvent the Wheel

Oh! It’s time to justify myself before explaining it. The reason I gave you links in the above two points was that I didn’t want to reinvent the wheel. IBM and Microsoft, the biggest giants in the industry, have done a good job documenting above. So what I did is referring them rather than myself trying to explain everything from scratch which leads me to my next point. If you are using a public cloud provider (or own your own), consume IaaS and PaaS services as much as possible. The cloud provider will handle the scalability, security, performance, uptime and much more for you. Else, you can also consume trusted 3rd party services providers. An example would be, for authentication, you can use Auth0. I know using cloud services or 3rd party services will create a dependency with the service provider but what you can do to mitigate that is building an abstraction layer so you can move your application around without any hassle. Anyway, it’s up to you to decide how to architect your product now. The idea is to not to reinvent the wheel in the application because the moment you try to implement what has already been implemented, you lose.

Loosely Coupled and High Cohesion (micro-services)

In simple terms, all of your application components or functions should be loosely coupled and focused (high cohesion).

The diagram onto your left hand is a traditional monolithic application and on the right is a modern application properly layered and deployed which brings the advantages to the table. In earlier scenario, if you want to scale you need to scale the whole application (let’s say 5 application servers) but if you have deployed your application in layers, depending on the load you can scale your application accordingly (let’s say having 4 UI layers and 3 service layers).

What I’m trying to say here is, you can always have a micro-services architecture (micro-services-like architecture) in your application. Refer this link if you don’t know what micro-services are. It’s a trending topic these days and you have to study it to understand the beauty of it. By looking at the below pic you can get a rough idea.

Conclusion

There is no one-way path to define an architecture for a given product but if you follow above steps I’m sure you will end up having a great architecture for your product. That’s about it! If you have any questions, let me know in the comments below. Don’t forget to give your feedback on the post (happy-face).