Value Creation
Code refactoring
Whenever a disruptive technology is quickly adopted by many people, it creates the feeling that it has already been implemented everywhere. This was the case with electricity, digital microcomputers, the Internet, and nowartificial intelligence. Just as we were surprised when we encountered a computer that was not connected, we find it hard to believe that there are still legacy systems withapplicationarchitectures other thanartificial neural networks.
These systems not only exist but also make up a large part of the software landscape of organizations in Brazil and around the world. Studies such as theInfosys Knowledge Institute's application modernization report,KPMG's global technology report, andThoughtworks' legacy systems modernization reportclaim that legacy systems make up between 74 and 88% of organizations'applicationsand their maintenance consumes approximately 80% of companies' IT budgets.
Application modernizationprojects are among the most frequently carried out here at Inmetrics. The scenarios we face are very varied, bringing us face to face with different styles ofapplication architecture. As analyzing them is a fundamental step in modernization projects, we will dedicate this text to them.
Although there are many types, we can divideapplicationarchitectures into two main styles: centralized and distributed. The decision for one of the styles goes through a series of criteria ranging from the feasibility of modernizing the application to security and use. Let's better understand each of the styles.
In the early days of software development, the standard architecture was themonolith: a unified, indivisible code base that combined the user interface, business logic, and data access layers. This type of structure required the entire application to be deployed as a cohesive entity.
Nowadays, it is rare to start developing digital products using a classic monolithic architecture. However, many widely used systems around the world employ an architecture based on the monolith. The developers atShopify, for example, chose to evolve it into a modular monolith.
This example leads us to another type of centralizedapplicationarchitecture, which is modular design. As the name suggests, instead of a unified and indivisible base, the software is developed in reasonably independent and interchangeable modules. Although compiled into a single executable, each module has a specific responsibility and communicates with the others through well-defined interfaces.
Among the types of centralizedapplicationarchitecture, none has become as widely used as layered architecture. It has become the classic description of software architecture: data,backend, andfrontend—in the case of three-tier systems.
The main feature of this type of architecture was what made it so prevalent in the software industry: each layer has a specific responsibility and its dependencies flow from top to bottom, unidirectionally: thefrontendknows thebackend, but the reverse is not true; the same applies to thebackend-database relationship.
With this architecture, when corrections and improvements are needed in one of the layers, the other two remain unchanged. This organization facilitates the division of labor among the teams responsible for the application, in addition to preserving the integrity and evolutionary state of each layer, when maintenance is needed in the others.
Local networks and, above all, the global computer network, the Internet, have established a new paradigm for computing. Consequently—and almost naturally—distributed styles ofapplication architecture have emerged.
Here, it is worth highlighting two characteristics that have become increasingly necessary for current requirements. First, the separation of the system: software began as monoliths, was separated into modules and layers, and continues to be divided into smaller parts, as we will see below.
The second characteristic is the need for connection between programs. What defines a network is the fact that it is distributed; to take full advantage of this characteristic,applicationarchitectures would need to replicate this principle.
Based on these premises, client-server applications were developed. In this type of architecture, one machine serves part of the application while the other receives the service. This is the type of architecture used on any website, including those that do not use content management systems. The code, even if only in HTML, remains on a server while the client—a browser—accesses it.
With Internet traffic capacity increasing rapidly, we saw the beginning of the consolidation of service-oriented architectures at the turn of the last century. In this type, the application is formed by the result of services from other applications, each with its own distinct logic. They are autonomous, have their own logic that is unknown to others, and communicate through standardized interfaces.
Service-oriented architecture—also known as SOA—enabled the first major levels of integration and scalability. It is a very common type of architecture in large banking applications, which typically need to interact with older legacy systems while offering a more fluid user experience.
Following the trend of fragmenting applications into smaller and smaller parts, we have moved towards microservice-oriented application architectures, which are widely used today. It follows the principles of SOA with one fundamental difference: while SOA provides a central point of service governance, responsible for routing and protocol translation, microservice architecture also has decentralized governance. They communicate directly with each other, point-to-point, via APIs. The autonomy of each service increases, enabling changes to each service at its own frequency, without impacting the functioning of the entire application.
Currently here at Inmetrics, when developing new digital products or modernizing applications, it is already common practice to create systems using serverless architecture, which takes full advantage of cloud computing distribution. We will dedicate a future post solely to this type of architecture.
As we mentioned at the beginning of this article, here at Inmetrics we encounter a variety ofapplication architectures. By combining quality engineering practices, artificial intelligence, and cloud computing, we carry out variousapplication modernizationprojects to transform legacy systems, restructuring them into modern architectures.
If you want yourapplicationsto take full advantage of the capabilities of the cloud andAI,talk to us! Our team is ready to transform your legacy systems into modern programs.Click here and chat with us!
