“Success depends on previous preparation, and without such preparation there is sure to be failure.”
– Confucius –
By Lizette Robbertze, Organization Optimization Architect and Digital Strategist
In the digital economy, businesses based on technological innovations (such as FinTech’s) are greatly straining the old business giants’ ability to stay competitive. These ‘digital’ businesses use modern technologies to cater to the digital customer’s needs, especially related to flexible and personalised products with real-time purchase cycles.
Therefore, it has become crucial for the ‘old giants’ to consider large-scale digital transformations, which are costly and a huge operational risk for the business. To succeed, such a technology transformation must enable the business to implement modern competitive strategies while providing agility and resilience for the future.
Creating an Enterprise Architecture “Decision Centre” is crucial to mitigate the risks and ensure the success of the transformation program – the critical success factors of which are prioritised focus, design simplicity, and the alignment of a complete set of functional requirements.
However, even while following good architectural and deployment practices, some circumstances will complicate the execution of the transformation program. I will share twelve circumstances to consider in this article – presented in business, technology, and procurement categories.
Business considerations
- Legacy Business Models
A digital transformation is not only a technology transformation; it is also a business transformation. Businesses must redefine their product and service offerings while considering digital customers’ needs, which would mean a reduced sense of control that is only sometimes readily accepted. Further, with the automation of many operating environments, the role of employees must move from ‘doers’ to ‘thinkers’, ‘analysers’, and ‘interpreters’—which may require new skills and experience.
- Ongoing Operating Changes
Transforming a legacy technology environment is not an agile project; it takes time and touches the foundational elements of the architecture. During this time, businesses can’t remain stagnant and will still need changes to the legacy environment, which can occupy those skilled employees who are also crucial to the transformation program. Also, as the technology resources in the legacy environment know that their environments will become obsolete in the near future, keeping them happy and motivated is no small task.
- AI needs Machine Learning
AI has become a buzzword and is expected to be an intrinsic deliverable of digital transformation. However, it can only be delivered if businesses know ‘where’ they want to apply it and have the related business rules and data to ensure the ‘machines’ can ‘learn’ the intelligence needed for automated processing.
Technology considerations
- Legacy Core
Large organisations are known for their complex and federated architectures, meaning that business units have autonomy in their technology selections as long as they follow specific design rules and allow integration with certain centrally managed components. The centrally managed components allow, for instance, the ability to get a ‘single’ view of customers. While such federated architectures cater for the business nuances of different business units, the core components remain legacy technologies to accommodate those that still need to modernise their technology landscapes. Apart from being legacy, they can also be inefficient and incompatible with modern design practices, requiring complex workarounds within modern technology implementations.
- Multi-Cloud Environments
While cloud is ‘the way to go,’ vendor decisions for their cloud of choice result in multi-cloud environments for organisations implementing multi-faceted technology environments. The safety of having an external network, a demilitarised zone and an internal network is something of the past, and new ways of thinking are required to ensure the security and performance of the multi-cloud. Considerations include load balancing and monitoring across environments while maintaining multiple private connections between all the different environments.
- Legacy Integration Patterns
An event-driven microservices architecture is an excellent idea because of the agility it provides to the technology environment. However, within a legacy outer environment, the batch jobs and SOAP calls remain and need to be catered for. Also, in a large technology environment, the data transformations required for integrating various systems and partners—each with its data dictionaries and canonical models—are complex. And then, of course, the integration performance of the different systems can only be managed using queues and async designs.
- Deployment Pipelines
It seems straightforward to think of the deployment pipeline for all environments as moving from DEV to SIT, UAT, PRE-PROD, and PROD. However, in real life, every system has a unique set of environments, which may include multiple DEV and SIT environments, which at face value is quite acceptable – until the actual integration and testing starts. Then, schedules are required to map the different environments, and specialised routing is necessary to ensure the integration environment knows where traffic comes from and where it needs to end. Then, we get to PROD, where all these routing configurations are no longer required, and the routing code is obsolete.
- Test Data complexity
Test data—Each system in the architecture has its own depersonalised test data, which doesn’t align with the test data in any other system and belongs to different business units and partners. However, for end-to-end testing, a data set that will work across systems is essential and needs participation from multiple parties for whom a single program’s priorities may not match their own.
- Large Training Initiatives
After creating a beautiful technology transformation, thousands of users on hundreds of sites must be trained – some of whom are used to working on mainframe systems. Therefore, change specialists must socialise the change before the training starts.
- Data Migrations
Migrations are part and parcel of any digital transformation. However, resolving bad data quality and transforming incompatible data formats can take up just as much time as the whole program itself. Therefore, the process must be planned carefully and given adequate execution time.
Procurement considerations
- Vendor ‘Bright Sparks’
Sometimes, the bright spark becomes the weakest link. Vendors would like to sell their latest and greatest innovations, but unknown to the buyer, the actual development of the innovative functionality has often only been an MVP. Excellent demos and promises are made at the sale stage, but the wheels soon come off during the actual development, which was supposed to have been configurations, especially within the time constraints of a much larger programme. Apart from skills shortages at the vendor side, their ability to design for large implementations is questionable, and the solution ends up as an “ad-hoc development” fraught with errors – exacerbating not only the amount of time required for testing but the project’s timeline delays the timelines becomes a real and impactful risk.
- Language Barriers
Globalisation and the need to use the world’s up-and-coming ‘Silicon Valleys’ are real. However, the ability to communicate intricate business requirements to people for whom English is their third or fourth language is a challenge—the consequences of which are only realised during testing when functional deliverables don’t perform as per provided requirements.
In conclusion, large-scale digital transformations are not easy, but they are non-negotiable for large businesses wanting to stay competitive in a fast-changing world. I hope the abovementioned considerations will help prepare you for the journey ahead!