How to Design a Web Application Architecture
When building a web application, why is the choice of architecture important? And what criteria determine whether your architecture is good or bad?
Join the DZone community and get the full member experience.Join For Free
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.
Published at DZone with permission of André Vieira. See the original article here.
Opinions expressed by DZone contributors are their own.