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.
- 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.
- 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…
- 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.