How to Design a Web Application Architecture
Thirty years after Tim Berners-Lee created the World Wide Web in 1989, the Web – and the browsers that ran on it – is the ubiquitous delivery mechanism for remote software functionality. And the growing ubiquity of cloud computing means that web applications – whether SPA, PWAs, or native apps – are becoming the de facto standard for the delivery of all software. Over the same period, the three-tier client-server architecture has evolved with the Service-Oriented approach now the dominant methodology.
But, when building a web application, why is the choice of architecture important? And what criteria determine whether your architecture is good or bad? This blog looks at how you can design a modern web application architecture that supports your needs today – without storing up problems for the future.
Why Is Web Application Architecture Important?
A web application architecture includes all the software modules and components, internal and external systems, and the interactions between them that constitute an application. In addition to addressing all the business needs set at the start of the development, the architecture ensures that all non-functional requirements (such as maintainability and agility) are met.
A well-structured web application architecture ensures your web apps can scale as the business demands while ensuring that all the concepts are correctly isolated and that all interdependencies have been taken into account. Overall, the application architecture ensures not only that your web application functions properly on a stand-alone basis but that it integrates well with all the other software in your estate.
What Are the Hallmarks of a Good Web App Architecture?
The first thing to say is that architecture is more of a process than an event. It is not static: you can only create an architecture with the knowledge available to you at that time. In 2020, no-one could have predicted a global lockdown and the need to ensure that your entire workforce must have remote access to every business service. But even in less disruptive years, new learnings are acquired, new use cases emerge, and new tools come onto the market – all of which will cause you to iterate your core architecture as a result.
In this context, discoverability is very important. If you know that your architecture will have to evolve, then have you tracked the dependencies between different parts of the application? If you have to make a change, are you clear on what other changes need to be made as a result? Are you able to minimize the impact of doing so?
The core benchmark of the quality of your web app architecture is the extent to which you can avoid creating technical debt: this term refers to the cost – in terms of time, effort, and money – of the rework associated with making the wrong decisions at the start of the process. A good software architecture will allow you to accommodate inevitable changes without incurring much in the way of technical debt. So, in a very real sense, only time will tell whether your architecture is sound or not.
What Are the Costs of Getting It Wrong?
The major problem is the issue of technical debt. With a poorly designed architecture, technical debt escalates quickly: any change has significant impact on many different applications, inadequate discoverability means new code creates issues in different parts of the application – and any fixes that are applied will only introduce new problems. A simple application can very easily become a sprawling labyrinthine monster that makes change difficult and time-consuming – and puts a massive brake on organizational innovation.
Core Principles for a Sound Modern Web Application Architecture
At OutSystems, we follow an approach based on what we call core business ‘entities’, which are the foundational components of the services you want to create. The aim is to centralize functionality and re-use it across the portfolio – if you need to make a change, you make it once, and everyone can use it. OutSystems is therefore targeted not at a single application but a portfolio of applications: the economies of scale that our platform can create only become evident when you have re-use of individual services across multiple applications.
When OutSystems started, we were very focused on empowering people to build web applications quickly. However, once our customers started to have multiple applications built with our platform, it became clear that they were creating technical debt – which was the last thing we wanted. Ever since, we’ve been very focused on providing training and guidance to our customers on how to architect the application properly. This training very much draws on sharing best practices: these were not propagated in a lab and then passed onto customers but were evolved from evidence and experience gained over thousands of different projects.
Benefits of the OutSystems Approach
Rather than simply providing a set of tools, OutSystems provides a high-performance low-code development platform – creating a complete ecosystem in which your applications exist. OutSystems also takes a uniquely visual approach to application architecture, which provides a higher level of abstraction than is available from any other platform: most applications are created through the combination of different services using a ‘drag and drop’ interface that doesn’t presume a deep background in coding. So, you can deliver mission-critical applications without needing the ‘rock star’ developers that are in very short supply.
The platform also includes an impact analysis algorithm – we call this True Change™ owing to the total visibility it provides – that helps users to understand the ripple effect of any changes and prompts them to remediate any issues. We also provide tools so that the development team can monitor technical debt with, including an architecture dashboard– updated daily – that helps users to understand if best practice is being violated and assesses the maintainability and any performance penalties of new services being introduced.
This goes beyond discoverability to provide a largely self-healing mechanism. When change is implemented, the platform will, in many cases, automatically adapt to that change or highlight the fact that the changes couldn’t be implemented correctly. So, it automatically ‘red flags’ any issues that arise, e.g., if you are introducing vulnerabilities or if certain attributes are missing or incompatible with previously created services.
So, the OutSystems platform is not just a fast method of building applications but has lots of other characteristics – from testing through to staging and managing software – that provide our customers with the speed and agility they need to compete effectively.
To find out more about OutSystems best practices to build a sound web application architecture, take a look at our TechTalk Web and Mobile Architecture with Architecture Dashboard.
