Blog

Digital Transformation Strategies often fail to cross the chasm between a CDO/CIO’s Transformational vision and the long tail of ‘Business As Usual’. This can be averted by adopting a pragmatic strategy that connects the vision to ground-level actions.

Digital Transformation fails because the teams that define the strategy and the teams that implement are often disconnected. More than often the teams do not participate in each other’s planning sessions. Almost always, the technologists are expected to hurry to code and start implementing the ask.

This leads to three issues:

1. Wrong KPI get used to define the usefulness of software and systems developed
2. What was built does not match the aim of the strategist
3. This leads to a loss of trust between the business and technology

Crucial Four Steps Towards Digital Transformation

Any organization on an ambitious digital transformation journey need to take these distinct steps:

1. Identify clear organizational priorities (vision, business goals, etc)
2. Identify a prioritization approach for ordering business processes that will be transformed
3. Identify a tech approach for transformation of the legacy, business process by business process
4. Identify an approach to retire the legacy

Step 1: Identifying Organizational Priorities for Digital Transformation

Any organization on an ambitious digital transformation journey need to identify clear priorities.

These three make sense to me:

1. Knowing the Client: A Customer 360^o is a common approach to accomplish this
2. Being Client Centricity: For organizations serving individuals, Service Personalization and obsession with Quality are common approaches to accomplish this
3. Build Systems that Connect: Two approaches are gaining popularity. API based approach to connect to internal-to-internal and internal-to-external systems. Kafka based messaging bus to connect mostly internal-to-internal systems. OpenAPIs are becoming popular across industries.

Step 2: Identifying Prioritization Approach for Ordering Business Processes for Digital Transformation

It is important to identify technical systems that support various businesses and functions that need to be transformed.

Consider these two methods :

Shu-Ha-Ri + Hour-Glass Model for Platform MVP

This approach recommends a Learn – Digress – Transform approach.

In this approach, the transformation teams become part of the system. The team identifies the first ‘strand’ using the hour-glass model for platform MVP, a business process that connects the client, the user interface they use, the backend systems. This ‘strand’ is then transformed, strangulate and then slowly transform the whole.

This method works were:

1. the org is ready for change, so there won’t be deep resistance to change, and
2. there are structures that can be isolated and transformed.

Read these posts for more details about ShuHaRi and Hour-Glass Model for Platform MVP.

Inverse Shu-Ha-Ri or Outside-In + Hour-Glass Model for Platform MVP

This approach recommends an inverse of the Learn – Digress – Transform approach.

This is where the innovative system is built outside the system, merged into the legacy to replace an existing system.

In this approach, the transformation teams stay outside the system rather than be part of the system. The team identifies the first ‘strand’ using the hour-glass model for platform MVP, a business process that connects the client, the user interface they use, the backend systems. This ‘strand’ is then merged to strangulate the existing one and so slowly transform the whole.

This method works were:

1. the org was not ready for change, so there was deep resistance to change, and
2. there are powerful power centers that would suck the oxygen out of any transformation by using complexities, matrix reporting, and control functions (Legal, Finance, Regulations, etc).

Apple is possibly a more famous example where it did an Inverse Shu-Ha-Ri with Apple II to create Macintosh because the org was so steeped in Apple II culture that it would have sucked Macintosh dry. This was repeated again when the iMac was created.

Read these posts for more details about Inverse Shu Ha Ri – An Alt Approach to Transformation and Hour-Glass Model for Platform MVP.

Step 3: Identifying Tech Approach

These are the common ones that get called out in most programs I have been part of:

1. Identify systems that support various business processes.
2. Encapsulate the whole system as a Microservice
3. Expose the relevant business function as an API based on API specs per TM Forum’s specifications
4. Use backend connectors (DB change trackers like Golden Gate) to feel data from legacy system to the new modern system over a Kafka like messaging bus
5. Build new modern UIs on top of the new modern backends
6. Refactor each Microservice to replace the legacy system to allow all incoming data moving to the new modern backends directly
7. Use ELK (ElasticSearch, Logstash, Kibana) to monitor systems
8. Retire old UIs
9. Repeat for the next system

Step 4: Identify Approach to Retire the Legacy

An ideal approach to retire legacy is to change all interface code to return errors. This will stop systems for feeding or reading from it. But the legacy data and its integrity are retained for any analysis or warehousing to WORM storage.

Attribution

Featured Image is adapted from @RobCottingham image shared under (CC BY-NC 2.0). Special thanks to my co-workers Ramanathan S.P (Ram) and Rohith Rajagopal who contributed to the original piece on which this is based.