Digital Transformation of Software Companies
"Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt." (Pivotal.io).
Neerventure helps software-driven organisations go through the difficulties of digital transformation,
leveraging the full power and flexibility of Cloud-Native application architectures.
Benefits of Digital Transformation
Every software developing company needs to continuously adapt. To changing environments, to evolving customer needs.
To catch up with competitors, to stay connected to evolving systems. To embrace new technologies and not fall behind.
The following list of benefits is taken from Pivotal's excellent article Digital Transformation: How to Become a Disruptor.
Risks of Digital Transformation
Whenever change is required in an existing system, risk is involved. It's important to acknowledge this to be able to take measures to control it.
The original software's documentation may be incomplete or worse, missing.
The people who architected and developed the legacy system may no longer be around.
Reverse engineering seems like the only way to proceed, but this is obviously extremely tedious.
Whenever the choice is made to work on a new version of a product, choices have to be made on how to achieve this.
In small organizations, it's hard to just set a team apart that does maintenance on the old product
and one that will work on the innovation.
Having the same team
shift between maintenance and innovation
however is also far from ideal. This process is sometimes referred to as thrashing, where developers
keep losing time in continuously switching context between maintenance and innovation.
Transformation, however needed, can cause a period of perceived stagnation, depending on how it's done.
Even if a separate team is set up, chances are that changes to the 'legacy' software is reduced to the bare minimum.
This can obviously cause trouble if your customer base expects incremental feature builds.
On the other hand, managing two separate product development paths that also need to be in sync is expensive and complex.
You need to have a well thought out strategy to cope with the transition process in a way that keeps your customers satisfied.
Any full replacement of an existing version of a platform can suffer from missing functionality relative to the old platform.
We see this very often. Customers get used to little details in your software that you have not even thought of.
Any different handling of specific user interaction can lead to a user feeling thrown back because he/she needs to adapt behavior
working with the software.
It's very important to involve customers in getting your software innovation right, if it changes the way users
have to interact with your product.
New software development is itself risky so that there may be unexpected problems with a new system.
It may not be delivered on time and for the price expected.
When an existing legacy system is being replaced, the amount of work involved is obviously much bigger
than with an MVP (minimum viable product) of a new system.
Cost prediction comes with careful planning and strict procedures.
You have to invest in innovating your software, but how do you calculate return on investment?
Jean-Pierre Fayolle has written an elaborate blog post on the
Technical debt and ROI of a refactoring.
In short, there is no short answer ;-).
Strategies for Digital Transformation
It is clear by now that
Cloud-Native applications are the future.
Converting existing (legacy) applications to cloud-native is however a tedious job, as we have seen.
According to Gartner, there are 5 different methods of migration:
Redeploying to an IaaS environment and changing the application’s configuration to work in a new virtual hardware environment.
Redeploying to PaaS, thereby making use of familiar languages and frameworks while at the same time taking advantage
of the cloud characteristics running on top of the provider’s infrastructure.
Modifying an existing codebase to meet cloud adoption or legacy modernization goals. Then rehosting or refactoring it to the cloud.
Discarding existing code and rearchitecting the application for a new software framework. Alternatively known as rearchitecting.
Discarding an existing application and using a proprietary pay-as-you-go SaaS solution instead.
According to Cloudyn,
the financial implications vary, but so do the benefits
"At first glance, rehosting may appear a more economical migration solution. But you may not get the same level of
performance of a re-engineered solution or realize the full strategic benefits of the cloud. What’s more,
cloud vendors may not be best suited to support your legacy applications. So, in some circumstances,
rehosting may be more trouble than it’s worth."
I have seen many situations in which companies had to deal with legacy but wanted to move into the Cloud-Native era.
Each one was different, but the important thing to remember is that you need to have a structural approach to innovation or you risk becoming a
prisoner of your Legacy System.