The CodeWolf

Hi guys!
This is an early release to part five of the ongoing Knowing Software Architects Series. I hope to quickly enable a lot of our readers who ask about how can they use these methods and information in their own tech requirements. But as is the case with all good things, patience and perseverance will be the key here!

All things said I assure you that the readers of this series will definitely be able to craft their own architecture document by the end of this long long journey!

In the last blog, we explored the nitty-gritties of System Requirements and the types of applications used to define them.

This time we move ahead in choosing our technology stack as an Architect and meet the *-ilities that help us achieve our non-functional requirements!

Technology Stack

Choosing a tech stack can be one of the most important tasks that a Software Architect has to do.

This becomes even more important considering that this is an irreversible change. We can not go three months down the line and say that we want to change our tech stack. This would lead to substantial delays and even increase the cost of the project.

The second reason could be the emotional aspect of the decision. The tech stack is heavily influenced by the development team’s preferred choice, despite it being an inferior model as to what is needed for the task. Changing a tech stack mid-project can lead to disarray in a team and can cause a loss of valuable manpower and time.

Therefore it is crucial that when we choose a tech stack:

• We heavily document it
• Choose with a clear mind
• Make sure a group effort is involved.

Considerations of a technology stack

There are certain considerations that we must keep in mind whenever we are choosing any technology stack

• Can perform the task
• Community of the chosen tech stack
• Popularity of the tech stack

All of these form the foundation of a technology stack that we need to choose.

Backend stack

The backend can consist of a combination of the following:

Some of the candidates that we can choose for a backend language can be as follows:

Lets us understand the pros and cons of each of these:

1. .NET Classic
   1. Founded in 2001 by Microsoft
   2. Windows only
   3. General purpose
   4. Performance – OK
   5. Object Oriented
   6. Very mature
   7. Statically typed
   8. Blurred roadmap
   9. IDE – Visual Studio

2. .NET Core
   1. NET Next
   2. Vocal, growing community
   3. Cross Platform
   4. Great performance
   5. Not fully baked yet
   6. IDE – Visual Studio, VS Code

3. Java
   1. Founded in 1995 by Sun Microsystems
   2. Huge Community
   3. Very popular
   4. General purpose
   5. Object Oriented
   6. Statically typed
   7. Interest has reduced in community
4. Node.js
   1. Founded in 2009 by Ryan Dahl
   2. Large community
   3. Optimized for highly-concurrent Web apps
   4. Great performance apps
   5. JavaScript-based
   6. Dynamically typed
   7. Not suitable for long-running tasks

5. PHP
   1. Founded in 1994 by Rasmus Lerdorf
   2. Large community
   3. A little messy
   4. Focused on Web Apps &
   5. Very easy to learn
   6. Web API
   7. Not polished
   8. Not popular in the current landscape

6. Python
   1. Founded in 1989 by Guido van Rossum •
   2. Supports any type of application
   3. Scripting language
   4. Very popular
   5. Very easy to learn
   6. Huge, supportive community

In summary we can use the following table to summarise the pros and cons for each language for the backend stack:

Frontend Stack

Before we jump into the frontend stack, let us remind ourselves of what constitutes a frontend.

The Frontend is the graphical user interface of a computer that makes it easier to use.

Ideally, when choosing a frontend stack, we would want to preserve components and not easily create the UI. We would also want to avoid repetitions and maintain performance with the renders being done.

When we talk about app types, following are the apps where a frontend can be designed

1. Web Apps  
2. Mobile
3. Desktop

Frontend Web Apps

For frontend web apps, we deal with web technologies such as HTML, CSS and javascript.

Here our choice can be dictated by what type of framework for javascript we want to choose.

Two popular frameworks Angular and React can be compared here as follows:

While both have similar popularities with React having an edge recently, Angular should only be chosen if the team has the time and capabilities to devote resources to learning and implementing it. React on the other hand takes much lesser time to get used to for building web apps.

Mobile apps

The choice in the mobile apps frontend stack is not straightforward. However, we can have the following considerations when trying to choose frameworks for this:

We can use the following table to help pick the relevant framework/technology for the mobile frontend stack

Desktop applications

Since a huge chunk of popular desktop apps are made for windows, we shall discuss these over here.

Again let’s take a look at the popular windows technologies and a comparison for their choice.

Data Store technology

Selecting a data storage technology is perhaps a more important choice in the Technology stack as most of our data will be stored here.

We can broadly classify data stores into two types of databases:

1. SQL
2. Nosql

SQL

In a SQL database, the data is stored in data tables. Each table has a set of columns and we can form relationships between two tables to select data from a complex set of queries.

e.g.

Usually transactions in a SQL database follow the following ACID principles:

• Atomicity
• Consistency
• Isolation
• Durability

Querying is done by the SQL language which is structured and is very mature.

E.g. 

Nosql

Nosql databases tend to be the opposite of SQL databases.

Following are the features of any Nosql database:

• Emphasis on scale and performance
• Schema less design
• Data is usually stored in a JSON format.

The transactions in a Nosql database follow the following rules:

• Eventual consistency: The system guarantees that an action will be performed, but there is no guarantee when that action will be performed.
• Data can be temporarily inconsistent
• No standard querying structure

Choosing a data store

The choice eventually boils down two the following two facts:

1. Do you have a huge amount of data stored and managed frequently?
2. Do you have structured data?

Based on the above we can use the following table to decide which kind of data store we can pick in our stack.

Introduction to the *-ilities

We have now successfully picked our tech stack so what is next?

What are these -*ilities?

I assure you, you are not reading this wrong.

So let us understand first what -*ilities are!

-*ilities can be defined as a group of quality attributes that define the capabilities of an application.

Almost all these attributes end with the suffix -ilities hence the name.

Quality attributes in turn refer to the specific technical capabilities that should be used in order to fulfil the non-functional requirements.

These are very closely tied to the non-functional requirements and can be understood with an example.

Non-Functional requirement:

“The system must work under heavy load, but should not waste money on unused resources”

In order to fulfil the above requirement, we would have to work on the “Scalability” quality attribute.

We can map out this relationship further as below:

There are tons of quality attributes, however, we will discuss the most prominent five attributes here.

Scalability

Scalability refers to the ability of an application to add computing resources without any interruption.

We can have two types of Scaling.

1. Horizontal Scaling – Increasing the number of computing devices to add compute power.
2. Vertical Scaling – Increase the capability of the computing device to add compute power.

Manageability

Manageability refers to the act of knowing what is going on in an application and taking actions accordingly to manage it.

For example in an above manageable system, the system will continuously report its status to a monitoring agent and based upon this an actor can take decisions to keep the system running in top shape.

The best way to check whether the system is manageable is by checking who reports system health.

If the end users report the health of the system it is not manageable, whereas a system with proper monitoring agents notifying the actors themselves is a manageable system.

Modularity

Modularity is one of the more important quality out there. It minimises the maintenance of the system and makes it flexible for more important changes.

Modularity can be thought of in terms of a system as a set of well-defined building blocks that make a system. These blocks can be reshaped or modified or even removed without affecting the performance of the rest of the system.

Let us take an example of a modular system.

Consider the above system. If we were to replace the external API system, we would only need to change the small block of getting the data from API in our own system making it easily testable and very robust.

Extensibility

Extensible systems are those systems whose functionality can be extended without modifying its existing code.

Let’s understand this with an example.

In a non extensible system, we would always have to keep modifying our code to include any additional functionality like below:

Here to add a new format of data in API we have to change our switch case to extend it.

Now for an extendable system, the following scenario can be there:

The code has no idea whether the type of data is XML, JSON or CSV. It simply passes the data to a factory method which returns the formatted data. Here we are choice agnostic and thus the system does not need to keep its code modified for each change.

Testability

Testability can be defined as the attribute that tells us how easy is it to test an application.

There are following four major categories of testing:

1. Unit Testing
2. Integration testing
3. Manual Testing
4. Automated testing

For a system to be testable we look out for two major characteristics.

1. Independent modules and methods: This also reduces coupling and increases modularity which makes the components easy to maintain.
2. Single responsibility: The modules or methods only do specific small defined tasks in an application as they will be easier to test. E.g. the fetch API method must not also clean the data it fetches from an API.

---

So that is it for part 5! In part 6 we jump to a very important topic, Components architecture and the SOLID principles. I am sure it would be a blast for anyone preparing for new tech roles in their organisation or beyond!

Discover more in the next blog!!

I keep on coding something cool, visit ankush.tech to see what I am doing!

If you wish to read about my work, here is a book that I published recently – “CSS Bullets, a comprehensive guide to all the CSS you need!“

Interested in React? Learn react from scratch with my book, “REACT Bullets“.

Not subscribed to the newsletter? Subscribe now!!!

Thanks for sticking around!