Digital Shift & Accelerated Disruption. Episode 2: Transforming your legacy IT systems from Titanic to speed boats

Legacy IT systems often have very poor time to market, it can take many months (or years) before an idea may be effectively implemented and rolled out in production. Legacy systems are often monolithic applications which are costly to be deployed in production, because you need to make exhaustive non regression tests on the whole perimeter to ensure quality, you need to perform lots of manual operations to deploy the application from an environment to the other… In this context, you can not afford to deploy just a small evolution (which you are not sure will not have a side effect somewhere else in the application, hence the full non regression testing) at this cost.
That’s why your best option will be to make big versions with lots of new features to optimize the cost of testing the whole application, the deployment cost, etc… and consequently, this big version will take months before going in production as there will be lots of work to do.

Modular-Architecture
Your mission if you choose to accept it: transform a monolithic system to a modular architecture.

To reduce this time to market, you may consider making IT investments to make your application more modular. What does it mean ? It means to divide your application in smaller applications that can have different life cycles rather than just one. For your e-commerce platform, typically, this could start with having distinct applications for the shopping path, the booking path, the aftersale, the customer account, etc… Then, when you make an evolution limited to your customer account, you won’t have to worry about unforeseen regression in other parts of the site, and thus you can limit the time and effort of the regression tests to the customer account.

 


It sounds rather obvious and straightforward, however when dealing with legacy applications, it’s a heavy technical project to address. Here is how we came to address such a transformation on a 10-year old critical e-commerce platform:
  • Make an enterprise architecture analysis to determine how the application should be divided in terms of functional consistency and lifecycles
  • Start to implement good practices such as unit testing whenever doing evolutions and whenever possible as it is not always easy depending on how coding was made. Set up the software factory foundations to ensure smooth integration between the different tools to deliver software : build, continuous integration, versioning, dashboard, testing. Most digital pure players use opensource tools that are really efficient.
100% open source factory: a technological choice but also a management choice to attract talents
100% open source factory: a technological choice but also a management choice to attract talents
  • Invest with business opportunities at the same time : an opportunity to split front-end layers with business layers in different applications may come along the implementation of a Content Management System (Drupal, Joomla…) to give more autonomy to business teams;  splitting the customer account to a different application while making business evolutions to it at the same time, etc…For any company that is not IT-centric, it is very difficult to make big IT investments decisions because the C-suite feels they’re paying for something they don’t clearly understand. The CIO should obviously have communication skills to explain the issues and strategy to adopt, he will also be wise to identify among the IT transformations which ones may turn into business projects as well to generate value in a shorter term. This may be by implementing a CMS (Content Management System) solution as said before to provide more flexibiliy for the marketing teams to animate their digital products, while separating the presentation layer from the business layer on a technical side. Or starting to modularize a specific part of the system where business teams would need urgently a life cycle different than the rest of the system, etc…
Automate
Automate, automate, automate: a long and tedious path but no other choice except if you believe in miracles
  • Beware of the increasing complexity brought by modularization : modularization comes along with some drawbacks though. As your information system is made up of more and more applications, you will create more and more dependencies between them, with interface compatibility to ensure, deployment issues between applications, etc…while it may seem very appealing to transform a monolithic legacy system to a modular system with each component able to have its own lifecycle, the thing is that you will replace some type of complexity (intrinsic dependencies in your monolithic code with high risk of regression when making evolutions to the code) with another kind of complexity (compatibility of the differents versions of each component, having different lifecycles, so that the whole system continues to work). Meaning that each time a new version of a component is released, you must ensure that it’s compatible with the other components it must be interacting with, through the right set of automated functional and performance testing. The more complex / modular your system gets, the more automated testing you must do as it will become something your teams can not easily master intellectually in the long run. The testing strategy is something too often underestimated (how to automate the most while containing the maintenance cost of the testing framework), but it turns out that in order to go fast with a complex system, this is one of the most important issue to address.
  •  Identify what kind of technical architectures / technical subjects should thus be addressed: setting up loosely coupled, asynchronous behaviors between applications whenever possible, working on API management, etc..

Rather than a Titanic application hard to move and with a long time to market, your system will thus be made of multiple smaller applications, much more easier to manage individually and ultimately with better separated times to market, but will also need much more automated testing and continuous delivery, more coordination between teams (not more people to coordinate but really more coordination between operational teams, a new way to work between them), global architecture thinking, and dependencies management.


This kind of transformation is far from being easy and it requires senior IT management with high soft skills, acumen and capability to keep cool to give time to the teams to work on complex streams while identifying how to continue to create business value so that other CxOs may feel trustful along the way.  At the same time, a company may decide to take the opportunity of change towards modularity to launch its organizational transformation towards agility at the same time, by giving responsibility to small teams made up of business and tech profiles on each modular application.

Leave a Reply

Your email address will not be published. Required fields are marked *