How to future-proof your enterprise digital transformation plan

By its very nature, enterprise digital transformation projects are long running and massive in nature, with most taking six years or more to complete. In such a situation, it can be a daunting task to ensure that your enterprise digital transformation plan is future proof. We are living in an era where technology standards often change massively every year and newer implementation technologies are coming up all the time. Here are some suggestions to ensure that your enterprise digital transformation plan is future-proof.

Build technology review cycles into the process

Enterprise Digital Transformation Plan

Some steps must be taken to accommodate the fact that between the time the technology choice for a digital transformation is made and the time the implementation actually begins, newer and better technologies may appear. What can be done is to have technology review cycles built into your digital transformation plan. The purpose of these review cycles is to ensure that time is already planned and budgeted to perform the necessary changes.

For instance, consider that you have a digital transformation plan signed off in January 2017 that indicates .Net as the implementation technology, with the technology design phase starting August 2018. When August 2018 rolls around, you would have a technology review cycle automatically kick off whereby the choice of technology would be reviewed again. If, for instance, J2EE has caught up between January 2017 and August 2018, then the choice of technology would be switched in a one-month cycle to J2EE. After that, the normal design process would roll on.

Build sponsor review cycles into the process

Enterprise Digital Transformation Plan
MIT Sloan Review

Another humungous source of issues during large, complex, long-running programs like enterprise digital transformation is that during the course of the project, several key sponsors and leads of departments move out of their roles to be replaced by new incumbents. It is often seen that the new person has a completely different perspective on various aspects of the transformation, including technology, implementation methodology, and business logic. What typically happens is that the new incumbent’s preferences do not surface early enough, and sometimes don’t appear until it is very late in the process. The result: unhappy faces all around, a very expensive round of code changes, and dissatisfied departmental heads.

The solution is to have periodic sponsor review cycles built into the digital transformation process. By having periodic reviews of the architecture, design, implementation, and technology built into the process, it is ensured that any new person raises his or her objections fairly early in the process. These cycles should be built into the process at regular intervals. These review cycles should happen regardless of the actual phase in which the transformation is happening right now.

Ensure technology extensibility

Enterprise Digital Transformation Plan

This is again tied to the fact that in a large, complex, multiyear engagement like enterprise digital transformation, technology elements can become outdated or there may be a need to extend or modify what has been coded in an earlier implementation. This means that design for extensibility principles have to be followed. If you take a class library for instance, there must be enough facilitating code there to add newer classes and also newer ways of designing functions for objects against their classes.

In most cases, this would necessitate that you depend on technology platforms like J2EE or .Net, which have popular support in the development universe.

If you are building a set of routines, for instance, there must be enough supporting variables and objects defined in there that may not immediately be used, but in the future, they may well be used. What this means is that you will be called upon to fully define functions, programs, objects, and classes with all the variables and objects required. In terms of functions, you would be called upon to write them in such a universal fashion that in the future, the same function can be used to call and return a new type of data.

Build for an interconnected world

In some ways, this ties in with a need for technology extensibility. However, the reason this is being called out separately is due to the importance of interconnectedness today. Most applications today are being called upon to support social plugins and sharing. Take the example of Microsoft Word. Word 2016 supports sharing functionality from its screen whereby you are asked to save your file off in the cloud in a .docx format to enable sharing. This is just one such example. Similarly, browsers are also being called upon to support sharing and social type of functionality, Microsoft’s Edge being a case in point.

With these kinds of trends in play, almost all of the code you write will have to support either sharing/social type of plugins (frontend oriented applications) or Big Data/analytics type of plugins (backend-oriented applications). Even if your initial design does not see any need for these kinds of functionality, your code will need to have the associated variables and objects defined and ready for future use.

Document intended outcomes

This is somewhat tied into the need for sponsor review cycles but is still called out separately because it holds weight on its own. Complex, multiyear programs like enterprise digital transformation involve possibly even hundreds of stakeholders from various departments and several sponsors. In such engagements, the overall design and outcomes must be part of a living document that can be updated from various approved sources, managers, leads and sponsors. It is very important to maintain extremely high-quality documentation to ensure that handovers can be seamless and changes in personnel does not delay or impact the engagement significantly.

It is not just about documenting design and intended outcomes . Even smaller aspects like minutes of meetings can be hugely influential in such large programs. By documenting intended outcomes along with the design and the discussions, you are putting in an iron-clad guarantee that several years later, any issues that arise can be easily handled.

Photo credit: Pexels

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top