During the decades of existence in the software development arena, various paradigm shifts have been experienced in IT architectures. These changes have led to large phases of modernization in business systems starting with the first major modernization that allowed migrating the first computer systems to routine programming. Later on, the client-server model changed complete architectures to give way to layered programming where the Model-View-Controller pattern radically changed the way of structuring solutions towards better maintainability.
With the rise of the Internet and the need for Business Integration (B2B / B2C), a new interconnectivity model emerged: SOA. The way to connect and orchestrate both internal and external systems changed dramatically with the service-oriented paradigm. Later, the arrival of cloud computing, although having started as a watershed in infrastructure provisioning, would also change the way we design software solutions by making them “cloud native” (e.g. serverless), assuming that many services would be deployed in a more elastic infrastructure.
If we conduct a quick analysis, we can see that everything points towards a granularization of solutions.
Figure 1. Evolution of software architecture
This timeline now has a new player – Microservices. As SOA was at the time, not actually being a specific technology, it is a paradigm that establishes various criteria in which solutions should be designed, and basically consists of designing small components with high granularity, minimal responsibility, low coupling and data domain segmentation. Today, many companies already use this paradigm to design their new solutions, which provides agility in business changes, high availability and fault tolerance (coupled with the power of containerization).
Figure 2. What is the best strategic path to Microservices architecture?
However, the explicit question that clients or prospects have asked us is, ‘’I have a monolithic architecture (read on MVCs, Web Services, APIs, centralized DBs, etc) so how do I modernize my applications? I’ll add a few more, ‘’Do I have to modernize them (all)?’’, ‘’How should I carry out my project portfolio to keep business operations running and, at the same time, avoid falling victim to technological obsolescence?
The answer, as any consultant would probably give, is ‘’It depends.’’
We aren’t only talking about all things technical as patterns to migrate evolutionarily do exist. Instead, we’re talking about the correct strategy one needs to follow to modernize a company’s technological assets. We’ve never recommended following trends. So, before typing away at the keyboard, we recommend you analyze the above mentioned points well. That is, carry out a technological diagnosis of the organization, or at least of the solutions and architectures that are possible candidates for modernization.
Figure 3. Consider complexity vs. business agility
This technological diagnosis must be part of a strategic roadmap that allows a company to do two things: 1) Design, build and deploy maintainable and highly available solutions while maintaining business operations in line; and 2) project investment and its return to avoid the programmed obsolescence of its technological assets.
We’ll continue talking about this roadmap in the following section.
To be continued…
This article was originally posted in spanish on Mijail’s LinkedIn.
We want to hear from you. Reach out to us today.