Hi everyone! It has been a long time since I started a journey to interact with the best minds in the Software development business and understand their secrets on how to build robust, scalable software. Almost three months in, this amazing series on Software Architecture, it is finally at its midpoint!
What started as a three-part series is now a separate beast itself just like the Learning CSS Series. I truly and completely wish to invest myself in the pursuit of making this series an all-encompassing knowledgebase for anyone who wishes to be a Software Architect!
I have successfully reached the end of drafting all the parts of this amazing journey and I am excited to launch these over the next few weeks with an amazing surprise to all the readers at the end!!
So without waiting, let us begin!
In the last blog, we went into understanding a bit more about the process that goes into designing a system, and the architecture process that a software architect follows.
This time we explore the nitty-gritties of System Requirements and the types of applications used to define them.
Understanding System Requirements
Types of Requirements
There are two types of requirements:
- What the System should do? ( Functional Requirements )
- Business Flows: What are the business flows of the system? E.g. Login flow, registering telemetry data etc.
- Business Services: What services the system should have? E.g. data access service, token service etc.
- User interface: How and what the user interface should look like?
- What should the System deal with? (Non-functional requirements)
- SLAs
- Performance
- Load
- Data Volume
- Concurrent Users
While functional requirements play a key role in the overall lifecycle of a project, more so from a development point of view, it is more often than not that the non-functional requirements truly orchestrate the architecture of software.
Non-functional requirements are those requirements that tell us what the system should deal with.
There are 5 main non-functional requirements that we usually deal with.
- Performance
- Load
- Data Volume
- Concurrent Users
- SLAs
Non-functional Requirements
Performance
We should always keep two things in mind when we talk about performance.
- Always talk in numbers
- Latency and throughput
When the client asks for a fast system, as an architect the first question should be what fast means.
Fast can refer to a lot of things in a lot of contexts. Certain systems can define fast in terms of microseconds e.g. ott platforms and others can define fast systems as in a couple of seconds like a secure service portal.
The rule of thumb is that when there is a client/customer at the end of the system, we want the system to complete its end-to-end processes in less than a second.
When we work with a business or B2B environment, we are looking at systems which can measure performance in less than 100 ms of any task.
The reason for the above is that humans in general are less perceptive to delays. The data that we get in 1 sec or less than 100 ms looks and feels almost the same. While for software or a machine with CPU cycles far faster, even 100 ms will look a lot slower.
Latency answers the question that how much time it take to complete a single task.
E.g.
- How much time does it take the user to store data in a database using an API call?
- How much time does it take to read a single file in an application?
Throughput answers the question that how many tasks can be performed in a given time unit.
E.g.
- How many users can be saved in a database in a minute?
- How many files can be read in a second?
These both are important as let’s say even if a system has a latency of 1 second, we have no idea of judging its throughput without any additional info.
In an ideal, perfect scenario, with a latency of 1 second, the system could have a throughput of 1000 in a minute. But in a scenario where the code is buggy and has many memory leaks and no concurrency, it could be only 60, which is latency X no. of seconds in a minute.
Load
Load refers to the quantity of work that the system can perform without crashing.
The definition of work can be different for different applications.
For example:
In a Web API – Work can be defined as the number of concurrent API calls that can be made without crashing.
We can see from above that it looks eerily similar to throughput. An important thing to note here is that while the throughput defines the time unit for work to be done, Load defines the availability of a system, that is the system remaining in a workable condition and not crashing down.
An example can be as follows:
While the throughput dictates that the application has to handle 100 requests per second, the load defines that the system will keep performing in spite of 500 requests without crashing even if they take longer than a second to process.
This is an important point as with Load, we deal with peak level numbers and parameters and this actually tells us what a system can handle.
Remember: ALWAYS LOOK AT EXTREME CASES IN ANY SYSTEM BEFORE DEFINING IT!
Data Volume
Data Volume defines the amount of data ( GB or TB or PB ) that a system will accumulate over time.
Defining data volume helps us with the following:
- Deciding on Database types
- Designing queries
- Storage Planning
We also look for answers to following two questions when defining Data Volume:
- Do we require data on “Day One”?
- What is the expected data volume growth?
E.g.
A system might need 500 MB of data on day one, while it is expected to grow by 2 TB every year.
Concurrent Users
Concurrent users define the number of users that will be using a system simultaneously.
This is quite similar to the load requirement. But there is one major difference.
There are many times in an application where no actual requests are made but the users are still actively present on it. This is called a “Dead Time”. Concurrent Users are defined even in these dead times whereas the load only referes to the actual requests.
The Rule of Thumb we follow here is that:
Number of concurrent users = Load X 10
SLA – Service Level Agreements
SLA defines the required uptime for a system in percentage.
This term is used by almost all the lead cloud service providers.
For example, a 99.99% of SLA can be broken down as follows:
This means a 99.99% SLA will give you less than 1 hour of downtime every year. This is actually offered by Microsoft Azure.
SLAs are important to manage client expectations.
Let’s say a client asks for a 99.9999% SLA, it simply becomes unrealistic though achievable.
For this SLA to be real, we would need independent data centres on every continent, nodes connecting every city the app is launched in with each data centre having its own power sources with dual power backup etc.
So always set up realistic client expectations with SLAs.
And finally, remember to never begin working on a system without setting all these expectations correct.
Who defines system requirements?
Generally, the Architect/System analyst along with the clients defines functional system requirements. They know the most about the application goals and it makes sense for them to define these requirements.
But with non-functional requirements, the clients usually have no clue!
Here the job of an architect comes in:
- Frame the requirement boundaries – Tell the client what is realistic and what will work with their current capabilities.
- Discuss numbers – Always calculate every possible scenario in terms of numbers.
These help in getting information to form the non-functional aspects of system requirements better.
Application Types
One of the things that architects do when they walk in to design a system is to determine or proceed with the kind of application that needs to be developed.
This is usually done after both the functional and the non-functional requirements have been defined as now the architect can make informed decisions
The most common types of applications are as follows.
Web Apps
Web apps also known as websites in general are one of the most popular types of apps and have been there since the inception of the internet.
Web apps are suitable for the following requirements:
- User Interface: The ease of building web apps UI makes it suitable to consider if UI is a priority.
- User-Initiated Actions: Web Apps are useful for actions initiated by the users like filling forms etc.
- Large Scale: With the internet being widely accessible on various devices, web apps reach a larger audience. The infrastructure to support this is also very accessible.
- Short-Focused Actions: Such as clicking for navigation, filling forms, adding details etc. Not suitable for long-running actions such as generating Business intelligence by crunching billions of numbers.
Request Response based architecture makes web apps simpler and can greatly ensure the end user goals are fulfilled on time.
Web API
Web APIs are quite similar to web apps with one important difference. They don’t serve web pages but data in some form of structure such as JSON. They also aren’t only run on browsers but can run with other platforms as well serving a channel of data to the applications utilising these.
Nowadays almost all apps also expose some APIs for multiple reasons. This can be to check health, enable developers to test features, allow third-party integrations etc.
Web APIS are suitable for the following requirements:
- Data retrieval and Storage: Makes it easier to store data and retrieve it using multiple endpoints and platforms.
- Client-Initiated Actions: Like browsers asking the server to serve a request for a number of users.
Large Scale: With the internet being widely accessible on various devices, web APIS reach a larger audience. The infrastructure to support this is also very accessible. - Short-Focused Actions: Such as clicking for navigation, filling forms, adding details etc. Not suitable for long-running actions such as generating Business intelligence by crunching billions of numbers. Web APIs can serve this data further to a large number of endpoints wherever they are exposed.
Mobile
As the name states, mobile apps are the apps that are served on some form of a mobile device such as a smartphone.
They generally run on an android or an IOS-powered device and work well with APIs.
Mobile apps are suitable for the following requirements:
- User interaction: Such as for games and interactive apps.
- Frontend for Web API: Apps that need to just be used as a frontend to an already implemented backend.
- Location: Apps such as food delivery, cab apps etc. that are sensitive to a user’s location and can benefit from sensors in mobiles such as GPS sensors.
Console
Command line apps or console apps are those apps that run in a CLI (Command line interface).
They have the following features:
- No fancy UI
- Long or Short term processes
- Require technical knowledge
- Limited interaction
Console apps are suitable for the following requirements:
- Long-running processes: Such as real-time querying and monitoring logs of systems
- Power-user actions: Such as admin commands to reboot networks/systems etc.
Services
Services are like console apps, with two important distinctions:
- They have no UI at all as opposed to the command line interface of console apps.
- They are managed by a service manager such as the windows operating system.
Services are used for long-running processes like monitoring.
Desktop
Desktop apps are those apps that mainly run on the pc and have all their requirements met and stored by the PC itself. They might connect to the web and have generally a great user interface.
An example of such an app can be Microsoft office. A supremely popular app suite on the PC.
They are popular for User-centric activities like word processing or gaming.
More types of apps
With the introduction of the cloud, there are more types of apps flooding the market such as function apps where users/systems utilise only the needed code hosted over a cloud. Some examples are as follows:
So that is it for part 4! In part 5 we shall explore more about how architects select the technology stack and meet with the numerous *lities that Architects use!
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!
Leave a Reply