Software Re-Architecting Best Practises

Data architecture connects business strategy and technical implementation, i.e. is a bridge in enterprise architecture between business processes and architecture of applications and systems. But what if the business strategy changes and the technical implementation remains the same? In what cases, without existing software re-architecture, you risk losing your SaaS business? In this article, we answer all these questions and tell you about all the pitfalls that you couldn’t consider before.

What is Software Software Re-Architecting 

Typically, the benefits of modernizing applications are described as: speeding up the delivery of new functionality, providing API access to existing application functionality through other services, and moving applications from on-premises to the cloud for increased scalability and performance, and as part of a long-term strategy. data center and IT infrastructure development.

Typically, the challenges of modernizing applications come down to high cost and complexity. If no ROI is taken into account when moving an application from on-premises to the cloud, then it's just for the sake of the move. On the other hand, applications that could benefit significantly from a platform or architecture change may be so closely tied to existing systems and infrastructure that the complexity of an upgrade can outweigh all its potential benefits.

The key to successful application modernization is choosing the right strategy and application modernization projects - for each application, it is important to have a clear plan for improving the customer experience and return on investment, based on the optimal combination of cloud benefits, speed, performance, scalability, development of new features, and more.

Reasons to Re-Architect Software for the Cloud

At the very beginning of any re-architecture project, it is extremely important to evaluate the applications. Analyzing your existing applications is almost always one of the most obvious ways to start any kind of transformation of this kind.

Once you have listed, you can plot the simplicity / complexity of each application on the X-axis and the potential value in the event of an upgrade on the Y-axis. Potential value could include the importance of the application to customer interactions and the future of the organization.

The apps that hit the top-right box for high value and low labor are the most obvious and least controversial candidates to start an app modernization project with.

Your System Cannot Withstand the Load

When the software does not withstand the load of users - it slows down, constantly falls due to the inability to process requests, we can solve this problem either by purchasing additional service capacity, or by changing the architecture of the project in such a way as to optimize the load.

Often, application upgrades include patterns such as refactoring with microservices, platform changes, or application hosting changes. While it is entirely possible to easily migrate applications without major rework, in most cases it makes sense to restructure applications to take advantage of cloud models, and to leverage containers and Kubernetes.

It is important to remember that the change legacy architecture is applied on a project-by-project basis and after upgrading, it is always necessary to carry out full testing.

Old Tech Stack

The problem with hiring developers, because such a stack of technologies is no longer supported, or problematic old technologies are used (for example, asp.net WebPages, which have security problems and Microsoft no longer develops this technology).

Many organizations try to replace outdated systems, sometimes for 3-5 years. Each time, it all starts with defining a technological approach, which is then worked on as part of a large multi-year modernization program. Then this program comes to a standstill, because the needs of the business outstrip the technology strategy and, therefore, you have to start all over again. Taking a gradual, waterfall approach to a big change program means that some of the work goes down the drain. Sometimes a different approach is used: some of the new technologies are introduced into the existing architecture. In both scenarios, it is neither possible to retire completely outdated versions nor to meet the key business goals of cost savings and risk reduction.

Why does this happen?

First, unsatisfactory results are the result of shortcomings in the organization itself. Business leaders often mistakenly think that if new technologies are imposed on the old system, the company will get a new result. This is not the case.

Secondly, any modernization requires a large change program with a series of individual projects and teams. These projects directly contradict the BAU (Business As-Usual) concept. The business as usual is to meet business requirements with existing systems, while new project teams are given a new set of requirements at the start. The gap between what the business really needs and what was agreed at the beginning of the program is widening. Although there are change control systems, they take a long time to work with and, because of the contracts already signed with suppliers, also a lot of money.

The third reason for failure is the desire to maintain a functional balance with the existing set of systems and business processes. It all starts with a promise to give the business exactly what it has today, along with some vague "improvement" in technology. But even defining and agreeing on the current functionality “as is” is incredibly time and power consuming, and new systems have to be implemented according to the “big bang” model.

Our observations from a number of cases show that only half of the problems lie in technology itself: working methods, organizational structure and management are equally important to success.

Database Compliances Problems

Another problem is often caused by the fact that previously data was collected in a database, and with the release of the GDPR, HIPAA and other regulatory laws, we cannot store this data. And the data was stored anyhow, and now you need to change the databases.

In a nutshell, your organization should take compliance management seriously or it might not stay in business at all. If implementing a new compliance management software project each time a new regulation comes along sounds expensive, non-compliance can be financially disastrous to the enterprise. And it is getting more expensive with each passing year.

Manual DSAR processing—that is, providing a form where customers can fill out a request, then fulfilling it with manual processes—can actually be more expensive. Some of the more involved DSARs include access to whatever data you have about them, to data portability, and to have their data purged. According to Gartner, the average cost of manual DSAR processing is $1,400—even higher for larger companies with customer information scattered across hundreds of applications and databases. Even if you anticipate a relatively low volume of customer requests, the costs can mount up quickly when your customer base is in the tens of millions.

You Want to Migrate to the Cloud

Organizations typically face several important challenges when migrating their infrastructure to the cloud. One of them is associated with the complexity of choosing a cloud provider, whose services would best suit the requirements of the organization, both in terms of quality and cost. The second is caused by the desire to avoid being bound to one vendor (lock-in). The surest way to deal with both is to choose multiple cloud providers (multi-cloud) and hybrid cloud, which allows you to store some of your data and applications in the private cloud and some in the multi-cloud.

Individual development or iPaaS?

iPaaS (integration platform as a service) is one of the services that the SaaS ecosystem is rich in. This set of cloud services is designed to develop, execute, and maintain integration flows that connect any combination of on-premises and cloud services, processes, applications, and data within one or more organizations. Cloud connectivity is key for iPaaS offerings, such as MuleSoft's CloudHub, Tibco Cloud Bus, Microsoft Azure cloud integration services, and Red Hat OpenShift.

Automation of various types of business processes is used as a cost reduction strategy. However, most of the digital transformation of enterprises remains focused on developing new products and moving to continuous delivery. Companies mainly focus on creating or purchasing software with unique features, while Low / No Code iPaaS frameworks are not the most suitable solution for these purposes.

Out-of-the-box iPaaS solutions ensure the interoperability of heterogeneous integration systems when moving infrastructures and data to the cloud, that is, accelerate the transition without requiring interruption of work processes. Given the uniqueness of the data of each organization, it is best to use iPaaS for data migration, but if the need arises, it makes sense to turn to custom software.

Change Software Interface

Another reason for rearchitecturing can be related to interface design updates. Here we can offer to use new technologies like Angular or React and they just need to be connected with the backend. The interface of the application determines how comfortable users will feel when using it. And the first step to take is to choose the right technology.

The web is rife with data comparing React vs Angular. Some even object to such a comparison. How can a framework (Angular) be compared to a library (React)? However, the discussions are still ongoing. Therefore, we want to share our opinion in order to facilitate your choice.

Choose React if:

• You need a modular interface structure for your application.
• You are looking for a personalized solution that leaves enough room for your project.
• Your project is a single page application such as a chat, data visualization application, or even an online game.
• You are planning an SEO promotion.
• Then you plan to create a cross-platform mobile app using React Native.

Choose Angular if:

• You are creating a large-scale single page web application.
• The app will have many features and active content.
• Your goal is a long-term project.
• You are thinking of building a combined or sequential web app instead of a native or cross-platform mobile app.

Software Re-Architecting Process

When people discuss legacy software re-architecting code, they have a tendency to focus only on the end state of the design - the shiny new architecture that is better, faster, stronger.  However, there are many more challenges to making a re-architecture project a reality and these will ultimately prove to be the biggest factors in whether or not the project will be a success.

Software Reverse Engineering

Software reverse engineering (SRE) is the practice of analyzing a software system, either in whole or in part, to extract design and implementation information. A typical SRE scenario would involve a software module that has worked for years and carries several rules of a business in its lines of code; unfortunately, the source code of the application has been lost – what remains is “native” or “binary” code. Reverse engineering skills are also used to detect and neutralize viruses and malware, and to protect intellectual property. Software developers proficient in SRE will be needed should software components like these need to be maintained, enhanced, or reused. 

Breaking Up a Monolithic Software Into Modules

As monolithic systems become too large to deal with, many enterprises are drawn to breaking monolithic to microservices architecture. It is a worthwhile journey, but not an easy one. We've learned that to do this well, we need to start with a simple service, but then draw out services that are based on vertical capabilities that are important to the business and subject to frequent change. These services should be large at first and preferably not dependent upon the remaining monolith. We should ensure that each step of migration represents an atomic improvement to the overall architecture.

Distributing a Web Application Into Services

Let’s say that we build a web app. At the beginning we serve 1000 happy customers, our product grows and within a year, we now need to serve 1 million customers. We would like to serve these customers as fast as possible, without them feeling latency. On top of that, we would like the app to be available at all times, no matter what. And, we want the app to perform its intended functionality fully, meaning, we need Reliability.

4 Reasons for architecting a distributed system

Availability. It is the probability that a system is available at any given time. Make sure that if one server fails, we have another server to replace it without the user noticing any delay. Even better, constantly monitoring the server for making sure it is available for upcoming requests from the customers. Having multiple components ready to take on the role helps make the system highly available.

Scalability. There are multiple components to scalability scalable databases, and system that can hold and manage petabytes of data, and/or a system that can handle millions of concurrent requests. In each of these cases, we can use a distributed approach to build a system that can scale when we need it to. Adding components to the system shouldn’t be hard if we architect our system for scale from the beginning.

Reliability. The probability that a system will produce correct outputs. A reliable system does not silently continue and deliver results with missing or corrupted data. Instead, it detects failures, fires an alert and, if possible, recovers from it. Building a system with reliability in mind is making sure that our customers can rely on the response and data provided by the system. This might include that they are building their business on, like biz dev analysis, risk management analysis for financial institutions and more. As we make a system more reliable we reduce the chance of it failing within a specific time period. We do this by increasing the redundancy or replication of the components and manage them for high availability, making them more reliable.

Transparency. The customers are not aware of the distributed system, since they interact with the products the same as they would with a centralized system. Meaning the distribution of the system is isolated from the customer. We gain all the benefits of a distributed system without the customer feeling it.

Cloud Migration

Enterprises are moving workloads to the cloud for a variety of reasons, whether it is data center dismantling, migrating legacy workloads, or building and running high-performance applications in a more flexible environment. Running traditional and native cloud work applications in the cloud requires consistently high performance and reliability across the entire stack.

For many organizations that are not yet using the capabilities of cloud technologies, the most important issue is “migration to the clouds” - preparing for the transfer of the company's IT infrastructure to virtual space in order to improve the quality of services and reduce operating costs. What steps are required for re-architecting applications for cloud? Migration includes developing a plan, deploying infrastructure in the cloud, migrating data, testing infrastructure, and launching services.

Choosing a cloud provider

Migration to the cloud involves moving data, settings, services and applications from the local site of a company or organization to a virtual data center of a cloud provider. This migration usually takes several days. Choosing a service provider - a cloud provider that meets all the requirements of the migration project - is a major challenge.

Inventory of IT infrastructure

Once this choice is made, you should start with a thorough inventory of your infrastructure, including physical network and IT hardware, software, and services. Often, this not only promotes migration, but also allows you to optimize the IT infrastructure, put it in order, redistribute processes and loads, without which it will be extremely difficult to successfully “move” to the cloud. It will allow you to get a clear idea of ​​the existing IT infrastructure, to understand how the components interact with each other, and so on. This will facilitate the migration process and simplify testing of the services migrated to the cloud.

List to move

While many modern business applications are originally designed to run in a cloud infrastructure, legacy software is not easy. Reengineering of such systems and their quality audit may be required. It is necessary to compile a detailed list of the services transferred to the clouds, the associated information systems and the computing, network and storage resources necessary for them. In short, you need an accurate inventory of everything that needs to move to the cloud.

To do this, you will need to understand what process is needed and what it is for, how many resources it consumes, what are the security requirements, after which you can determine what exactly should be put into the cloud.

When deciding whether to use the cloud, companies often wonder how secure it is to move corporate data to the cloud. Although modern cloud services are characterized by a fairly high level of security, you should not "bring" everything into the cloud, this can be fraught with serious business risks.

If such work cannot be performed by the customer himself, then providers often offer their services for the primary audit of information systems. This audit allows not only to better plan the transfer of services to the cloud platform, but also to identify the current shortcomings and problems of the existing IT landscape and eliminate them.

Choice of migration tools

Next, you need to decide on the migration tools. Having a virtualized environment makes things easier — moving virtual servers is straightforward. There are special P2V tools for "converting" physical servers into virtual machines, although there are also "pitfalls" here. Companies often have concerns about security, the scale and complexity of the task, uncertain migration paths, disparate toolkits, and lack of expertise.

Meanwhile, vendors are constantly working to expand the possibilities for migrating applications and databases between the client's data center and the cloud, trying to ensure the coexistence of cloud and on-premises applications/data and their migration between the customer's site and the cloud "with one click". For example, at Oracle, the workload can already be easily transferred between the customer site and the cloud.VMware vCloud Extender allows you to consolidate clouds and move VMs to the cloud using an intuitive graphical interface. To convert a physical server into a virtual machine and transfer it to the provider's cloud, you can use the VMware vCenter Converter utility. In this case, the main server continues to work. Another option is to create images of physical disks, convert them to the format of virtual disks and transfer them to the provider's cloud, to a virtual environment. Another “natural” move method is backing up and restoring at a new site.

Ensuring network connectivity

A separate issue is ensuring network interaction between the client's IT infrastructure and the provider's cloud platform, that is, network connectivity. It is solved by the joint efforts of the provider and the client. Communication channels must guarantee user access to the cloud. This may require taking into account the routing, addressing, bandwidth and reliability of communication channels, as well as information security (for example, the need for a VPN), horizontal (increasing the number of VMs) and vertical (increasing the capacity of a specific VM) cloud scalability.

Drawing up a detailed migration plan

The migration plan will contain information about the services migrated to the cloud at all stages, with the ability to verify each stage. It reflects what exactly will be transferred to the cloud, in what sequence, in what time frame. The success of the subsequent processes and stages depends on this. The migration plan lists critical and important services, taking into account the priority of their migration. In most cases, migration is possible without stopping the service.

Your migration plan needs to define Downtime and Data Loss Amount metrics and how to minimize them. It is better to update and modify applications before migration, otherwise it will be difficult to identify the source of problems. Application dependency maps will help you work out the mechanisms for the correct transfer to the cloud. A clear migration plan also prescribes data migration procedures.

Test migration

Migration is a step-by-step process, and it is better to start it with a test migration. Request a test cloud access from your chosen provider and practice the migration procedures on simple services.

The gradual and phased approach allows you to quickly identify and eliminate problems that arise during the transfer process. Transferring everything at once is not only inconvenient, but also extremely risky. Gradual or partial migration is the preferred option for an organization with a distributed infrastructure.

Before starting a test migration, it is useful to determine the health and availability requirements of the cloud service.

Ardas Re-Architecting Case Study

One of our most famous projects also had to go through software-architecting. Email template visual builder with AMP support for high-end marketing that we started to develop in 2016 is currently facing many changes. Last year we started to consider re-architecting legacy software due to three reasons.

Easy employee onboarding

While we were working on the first editor, we were constantly changing the vectors of development and the original architecture no longer allowed us to implement everything that we had planned. 

As a result, by adding something new in the editor, we got a lot of places where the editor duplicates itself (functions, classes). To avoid this in the future, we decided to rewrite the editor completely so that everything was in the correct sequence and any new team member could easily figure out the code.

The need for new features

When we laid the initial architecture in the editor, we did not assume that in the future we might need such functionality as simultaneous editing, collaboration, commenting, conflict resolution, etc. Therefore, it is now impossible to implement this functionality without re-architecture.

Two different languages

We currently have two languages. For the editor we use JavaScript, and for the cabinet we use Angular. In this regard, we decided that it is better to use one language to reuse different components in different parts of the application, so we are now rewriting everything based on Angular.

For modernization, we have divided our team into two parts. Most of the experts are working on the new editor, the rest support the old one and also release some updates. At the moment, 5 Angular developers and 2 full-stack developers are working on the new version of the editor. 

We plan to finish software re-architecture in March 2022 to present a completely new editor to users. It will not be fully ready, but it will allow us to collect feedback and work on improvements.

Ready To Change Your Software?

Whether because of changes in user, industry, or technology needs, software architecture will continue to evolve. Architecture cannot be stagnant, as each of the companies profiled here can attest. Rather, it is a living, breathing set of entities.

Great software architecture, on the other hand, is art. For everything that might change in a product, there are certain user needs that will stay constant. A smart approach to changes system architecture lays a solid foundation for the product that is needed now, but is malleable enough to support the product that might be needed tomorrow.

Ready to start on the path to modernizing your software with a practical approach? Using an Agile modernization approach with proper planning and the right people on your team will put you on the path to success. The development team at Ardas is experienced in modernizing legacy applications and working with clients who have complex environments. Put your process of rearchitecting existing software on the path to success, start the conversation with our development team today.