I believe that each new project needs to have a well-defined plan with milestones and end-goals, so everybody sees the finish line. It does not matter if it’s big or small, enterprise or personal. In my opinion, one of the firsts technical steps would be to define the application architecture.
What is application architecture?
There is a certain thrill when starting a new business or project, and nowadays there is always an online component of it. The web is the place where everything is happening, no need to convince anyone here.
Application architecture is not the first step of this complex process, but I believe it should be one that is taken into consideration in the early stages.
But, what does it actually means?
Well, to put it as simple as possible, is a plan. It can be compared with the plan that an architect will create for a new building. They design it from the foundation up, taking care of a structure, looks, distribution, and all the details needed to have in the end an exquisite new building.
When talking about a web application, defining the architecture becomes very important as it will determine not only how the business presence will be noticed but also define at least two ways of scaling the business or how to sift it, if needed.
Why architecture is important?
Returning to the comparison made earlier, in the case of a building, if you do not do it, then it will fall off or not look attractive and in the end, it will not get sold or rented.
Architecture, in the context of a web application, will define the key elements that are needed, will draw a path for the entire development cycle, and will ensure that all the business requirements have a translation into the technical end product.
Developers nowadays have the bad habit to first learn the framework rather than the language itself, and I am not gonna dwell on that anymore right now (to be honest I believe it’s the industry’s fault, not theirs). So, when developing a new application that will serve a new or existing business, without the architecture, each developer will code following the business specs but without having a clear path of what is needed to be achieved.
Here is where architecture comes into play. For starters, each developer will be able to follow his own “style”, but none of them will ever lose sight of the end goal.
Scaling the app based on the evolution of the business is one of the advantages that architecture also brings to the table. I saw this mistake done by most of the companies that I worked at and in all the cases, after a period of time, everything will fall and crumble and everyone was asking why.
Extending the business is another key advantage that application architecture will bring to the table. We all live in a world that is changing, daily, so being flexible is one of the key factors of any business. Having a well-structured application, with a very good understanding of its current capacities will give you a solid set of building blocks for an extension, of any kind I may say.
Who should handle the application architecture?
I believe each team of developers should have at least one member that has at least a few years of experience and has done multiple types of projects.
Defining the architecture could be a complicated technical task or could be a guideline (policy) for whoever will end up writing the code. As long as the principles are sound and “business” is covered then it should be all good.
Ideally, the developer I talked about above should be the one handling this. Mostly you want a smart one, that has experience in different types of applications and has the ability to understand business. This could also be defined as “a group task” where everyone put their minds together and come out with the best solution for the “business specs”.
Honestly, at the end of the day, it matters that the architecture application exists, not who did it.
Application architecture principles and KPIs
- Development language and frameworks
The business specs are there and all that is missing is what “tools” we will be using to develop. Define them!
- Uptime and Scalability
Long story short: it needs to work, it needs to handle whatever amount of traffic or load it receives. In our current world, it is important to be there when a user decides to use it, regardless of the motif;
- Performance and UX
It’s proven that bad performance and high load time will make users unhappy and even make them drop the usage of the application (you can read something here);
- Device behavior
We leave in a world where with a mobile phone you can do almost everything online. So be sure your app will serve and work no matter the device is being accessed from;
- Online presence and integration with social media
Maybe this will not apply to all types of businesses but this needs to be considered from the start. Your future to be users are present on social media already, and you will want to be able to get to them. The role of architecture here is that the application should always be ready to integrate easily with any of the social platforms.
Last but definitely not least. It is of utmost importance to track everything and understand, at any given point in time, how your app is doing and what your users are doing with it. Only with this, you will be able to adapt everything to suit the business. Just do it from the start and integrate it within the architecture, it’s easy this way.
As a list KPIs to follow and monitor, I believe the most important one are:
- Uptime (> 99.95%)
- Time To Interactive (< 2s)
- Bounce rate
- New visits
- Navigation behavior
- Drop pages
- Heat Maps