The web is full of great articles, covering the fantastic features offered by new technologies. Unfortunately, thousands of developers in enterprise-level companies are left out of this digital transformation due to legacy code and rigid infrastructures.
In today's article, I am going to describe my experience with Digital Transformation, providing insightful examples and suggestions, to help enterprise companies see the benefits of enhancing their technological stacks.
I have now been involved in a couple of these projects, and have embraced a journey of creating technological advances. This hasn't only resulted in creating shiny new tools for developers. It also indirectly produced the following side effects, that, in the long run, greatly outnumbered the cost involved in implementing the transformation:
- Increase job demand: It is well known that a company that offers the possibility to work on new technologies is a great selling point for developers.
- Increase the candidate level: This was an unknown consequence of adopting new code. The pool of developers applying for the jobs offered not only increased, but it also improved in quality.
- Reduce developing costs: Most of today's technologies have been designed to support developers in achieving more by spending less time
- Increase internal features: Fancy tools come with fancy features
- Increase employee morale: Introducing new technologies, within one of my previous projects, increased overall employee morale, and supported personal development (offering new tools to learn)
What is "Digital Transformation"?
There are different definitions of "Digital Transformation", depending on the industry for which they are used. In the technical industry, the definition can be:
Digital Transformation is the process required to modernize business technologies, and procedures. These changes will enable companies to transition from rigid legacy code, to a modern tech stack, that will inevitably support business growth, and flexibility.
It is very common to see companies sit on their old codebases, enjoying the stability that they provide. Unfortunately, the IT industry is well known for being extremely fast moving, so keeping hold of ancient code is a recipe for failure (as new competition joins the market).
How to embrace the transformation
Implementing this transformation is not a simple task. It requires lots of planning, and it is usually beneficial to go through the journey with an engineer that has experience with it.
Many companies try to achieve migrations by just rewriting the complete codebase. People generally prefer this "clean canvas" approach over achieving the transformation with gradual improvements.
We are now going to define two different approaches: Clean canvas and Gradual increments:
Clean canvas approach
I am of the opinion that starting from scratch multiplies the risk of failure. Legacy code is called so, because it is written with tools that are no longer maintained, and/or were developed by an employee that has since left the company. In this situation, I oppose a "clean canvas" approach, as the possibility of a hidden feature can pose a risk to the overall project.
In summary, a clean canvas approach has some negative consequences:
- It cannot be deployed gradually
- It requires one to maintain two codebases (legacy and flexible) for the duration of the project
- It will not produce "improvements" until fully completed (and deployed)
- It may get blocked by hidden features within the legacy code
- It is extremely hard to properly estimate
- It may need lots of planning before the rewrite can take place
Gradual increments approach
Achieving digital transformation, using gradual increments, offers many different benefits. These benefits make it less risky, and more affordable, for most of the companies for which I have been working.
With the use of this method, the full transformation project is split into "smaller" standalone milestones. Achieving of all these "mini-projects", will provide the same end-result as a full rewrite.
The idea of adopting this process is usually discarded by many managers, and senior engineers, because it may require more steps from the previously mentioned approach. I actually think that these extra steps can be beneficial for the overall success of the project, because they can help developers make better decisions.
My comments on the gradual increments approach are:
- It provides quick feedback thanks to the gradual approach (useful for morale, project cost, stakeholder, and project architecture)
- It allows the project to be agile, and adaptable to possible hidden features
- It should produce a better end result thanks to its flexible approach
- It requires one single codebase (simple to manage)
A real life example
Starting this journey of transformation is not simple, and finding the right time is really complicated. I have experienced the best results when the transformation is associated with a company-wide project. For example, a gradual migration could be combined with an overall "security enhancement" of the application, or aligned with a "Re-brand" project, in conjunction with third party integration work. Then, it could be paired with a "big feature release".
Combining the transformation with another project usually gives it a defined deadline, justifying its costs, and defining the scope of the step that can be undertaken within the given timeline.
For this article, we are going to define the steps, and improvements, that can be taken to achieve a Digital transformation of a Web application in conjunction with a re-branding project.
The company
Our example company has been a leader in the sector for 8 years, and has most of its code written in plain PHP 4, hosted on dedicated, costly servers. It also has a front end written in plain CSS, with a touch of jQuery.
Its creator has left the company 4 years ago, and most of the new code is written on top of the old code. To avoid unexpected behavior, there are no unit tests, or end-to-end tests available.
The tech-stack described above is not really appealing for many developers, and unfortunately, it is quite a common situation across our industry.
The company mentioned above is going through an internal re-branding project, where all parts of the business have been asked to modify their "image" to align with the newly created style.
We are going to take advantage of this project by enhancing the UI tech-stack, using a new framework, and removing the redundant technologies.
Define your project
I am against excessive project planning. But due to the new technologies involved, and the importance of the project across the company, it is beneficial to define the overall project scope, and requirements ahead.
I am not talking about a fully-detailed 50 page document, but it is important to make the right choices, and sometimes a little research is essential.
For example, in our case, the company has to decide between React, VUE and Angular. The choice will shape the future of the company, and it should not only be done from a technical prospective.
Angular developers seem to be scarce around the area, so the main choice will be between React and Vue. Further research has shown that one of the senior developers seems to be quite good at React, and he is willing to help the project, while on the other hand, there is a nice VUE Meetup in the company's hometown, and some of the developers that have recently attended it are keen to learn Vue.
In a clean canvas approach, this decision, and many other technical ones, should have been made ahead of the project's start date. In a gradual approach, however, there is room to try different paths, and define the project from the feedback received. (These are the extra steps mentioned above in the "Gradual increments approach" section).
The final decision is to try executing a very small project for each of the frameworks.
The first step
The first step is always going to be the hardest to make, and for this reason, I usually suggest starting with a comparably small project. I have done projects for which "starting" meant adding a single script tag in the current codebase, or implementing a single API call to a new cloud service.
In our case, we are going to start the creation of our new Brand by creating a so-called style-guide using the component based architecture offered by the frameworks.
In our first step, we are going to create a small Proof of Concept (POC) in both frameworks, and use the feedback gained from these implementations to move our transformation forward.
TIP: Make the first step as small as possible, allowing you to release it within weeks. This will help you get "serious" about the digital transformation.
Feedback loop
The main advantage of the "Gradual approach", is the ability to gain a close, and active, feedback loop. This must be used regularly, to ensure the success of the project.
I am not saying that implementing a small POC will always help you make the right decision. There are, however, circumstances in which it can really make a big impact. It is important to remember that when this transformation is being solely developed by house developers, most of the technologies will be new for the majority of the employees.
To continue our example above, the company has decided to use the VUE framework, as it seems to produce better results, and provide an easy learning curve.
VUE is very simple to use, and is, therefore, really beneficial to migration projects, as it allows an existing "legacy" developer to learn it quickly.
Release
As with all agile projects, it is important to try, and release, as fast as possible. Getting internal feedback is great, but starting to get a feel for the real world is something else.
Our developers have started to "migrate" existing styles from the legacy CSS structure to a component based architecture. This work is low risk (as its mostly required to move code), but it will speed up future changes to the UI required to achieve the overall re-brand.
Metrics and Results
For many years now, I have been involved in meetings, wearing both a developer's, and a manager's, hat. I am well aware that it is great when developers are happy, but unfortunately, happiness alone does not pay the bills (even if happy employees are known to be more productive).
For this reason, it is important to define a set of tangible metrics that can be used to support the cost, and investment, necessary to progress the migration to the next level.
Gathering this information is usually simpler that it sounds, but it needs to be done prior to the start of the project.
Conclusion
In my next article, we are going to define the technical steps necessary to achieve a Digital Transformation. This is going to use the example introduced above, explaining all the steps necessary to get started, and to migrate a legacy code to a future proof tech stack.
All of the above information comes from personal experience, and it should be taken with a grain of salt, as the result may vary between different companies and organizations.
The digital world is constantly improving, and as such, the tools and methods used to achieve Digital Transformation change overtime. Creating a flexible and agile environment is the best way to continuously adapt to changing technical standards.
This article was written by Simone Cuomo who is a Senior Software Engineer at This Dot.
You can follow him on Twitter at @zelig880.
Need JavaScript consulting, mentoring, or training help? Check out our list of services at This Dot Labs.
Top comments (0)