By Lizette Robbertze, Organization Optimization Architect and Digital Strategist
Technology Transformation is often identified as a critical requirement in any business, whether for stability, scalability or modernisation. However, technology transformation journeys are usually very intrusive and costly, without an ultimate endpoint – as technological innovations constantly change the requirements and the environment we must deliver. So how do we do it in a manner that the non-technical managers can understand and support?
Also, in real life, architects are often given the transformation goal in a complex technology environment with large amounts of legacy systems, coupled with modern components – held together with sticky tape because the actual system functionalities were never documented, and the original developers are long gone. And then, apart from designing and implementing the transformation, they are also subjected to pressures from the Business to deliver frequent changes to the legacy systems because of disruptive instabilities or urgent business functional needs. In such situations, how does one plan transformation?
We can use reference architectures to ensure the completeness of the defined technology landscape. We can use modern technology patterns such as modularity and loose coupling to enable future flexibility. But how do we achieve an optimal architecture for the Business we serve?
Enterprise architecture frameworks prescribe using a set of principles to guide and align all architectural decisions within a particular environment. But how does one get to that set of principles, and how does it help to achieve some desired end state?
Still, I believe in principles – chosen at the right time, using the proper context. They are much like having values in life – they allow you to test and focus decisions in complex environments; and also, provide a mechanism to explain technology decisions to business people.
As principles guide decisions for future actions, they must ensure achievement of the transformation goals. But how does one determine the starting point in a complex environment, and how does one define the endpoint in the ever-changing landscape?
I found these questions very perplexing until I realised that the success of a technology architecture is not about using any specific system/solution – but more about the CHARACTERISTICS of the environment – required by the Business to grow, prosper and achieve its strategic objectives.
Technology Transformation is, therefore, about achieving a technology architecture with previously decided upon characteristics – and herewith a 5-step approach using technology principles.
Step 1: Starting the Technology Transformation Journey Using Characteristics
Design Thinking tells us to “Start with the END in Mind”. Therefore, what characteristics would you like your technology environment to be known for? Personally, I find the following three characteristics are critical: Resilience, Agility and Modern.
Resilience
A technology environment can only be resilient if it is both Business- and Technology “fit.”
It is Business “fit” if:
- It supports all functionality required to sell and run the Business – therefore, all front-office and all back-office functions.
- Its information processing capabilities allow for sales behaviour predictions, ensuring excellence in customer servicing, and, operational optimisation.
- It can scale stably in situations of varying performance requirements.
- It enforces the controls required to maintain operational risk within acceptable boundaries.
It is Technology “fit” if:
- It is supportable – which can mean many things, best left for definition by each architect.
- It is secure and can recover in disaster situations.
- It is possible to integrate different components in a loosely coupled manner.
- Environmental changes are governed to ensure compliance with the technology vision; and, future supportability.
Agility
The backbone of agility is simplicity, with loosely coupled modularity.
Simplicity goes hand in hand with the removal of legacy components and functional duplication; and, standardising business rules. Also, high levels of governance are usually required to ensure the principles used to ensure agility is complied with.
Modernised
Components in the environment should either have the latest technology capabilities or should be able to integrate/utilise such capabilities.
Step 2: Identify the Principles – those technology decisions that will guide you to an environment with the chosen Characteristics
The characteristics of an environment depend on the decisions made during the transformation journey – therefore, choose principles that align with the to-be characteristics carefully.
The following is an example of a set of Principles chosen for my three to-be Technology Environment Characteristics, as selected above:
Resilience:
- Principle 1: As-Is Understanding– Always use the strengths of the current environment to your advantage and eradicate weaknesses.
- Principle 2: Holistic Design– Ensure that all required functional and non-functional requirements are considered in planned changes. Also, avoid unpleasant surprises by comparing all possible solutions for their impact on the current environment.
- Principle 3: Data as Foundation– A comprehensive and quality data set is an asset and can be a competitive advantage for every Business. Any technology change should therefore focus on creating a solid data foundation for the Business.
- Principle 4: Supportability– All change plans must include input validations, maintenance and error-handling considerations to ensure that expectations for performance and availability are met.
Agility:
- Principle 5: Simplicity– The more “simple” the architecture, the more predictable the success of any change. Changes should therefore focus on eradicating functional duplication, unaligned business rules and design patterns, and replacing legacy technology components.
- Principle 6: Modularity & Cohesion– In fast-changing environments, it makes sense to structure the architecture layers with replaceable modular components rather than using large monolithic solutions that provide functionality across functional layers. Modular components must be functionally cohesive to reduce their dependency on other components within the layer.
- Principle 7: Golden Sources– While data is used by many components in the various architecture layers, there should always be one and only one golden source for every data type – changes must always maintain the data quality in these sources.
- Principle 8: Loose Coupling– The integration patterns used between modular components will affect the ability to replace those components and, must therefore, always be loosely coupled.
Modernised
- Principle 9: Controlled Modernisation– Choose modern technologies only when they fulfil a defined business need, while considering their impact on the whole architecture.
- Principle 10: Optimised Integration– Ensure the integration layer contains the functionalities required for integrating with all modern type technologies as well.
- Principle 11: Best of Breed– Never try to build critical components, available from Vendors, that can ensure support for well-researched and fault-tolerant solutions.
- Principle 12: Automation for Efficiency– Use automation only where there are transparent and standardised business rules, thereby preventing unexpected operational results that may harm the business long term.
Step 3: Identify the strengths and weaknesses of the current environment
Now that we have the decision-making principles required to achieve the to-be environmental characteristics, it is possible to measure the strengths and weaknesses of the current environment by defining metrics for each of the principles.
Metrics can be high-level enough for easy evaluation using a consistent scoring mechanism. In the example below, I scored all metrics on a 1 – 5 scale, with five indicating a strength and one a weakness.
Some examples of metrics:
Resilience:
- Principle 1: As-Is Understanding– Is a knowledge base with updated architecture diagrams and functional descriptions maintained for the system?
- Principle 2: Holistic Design– Can the system perform all the functional and non-functional needs defined by the Business?
- Principle 3: Data as Foundation– Is data quality one of the key attributes of this system?
- Principle 4: Supportability– Are regular maintenance procedures and checklists defined and used?
Agility:
- Principle 5: Simplicity– Is this a legacy system still supported by its creator/vendor?
- Principle 6: Modularity & Cohesion– Is the functionality of this system contained in one of the architectural layers?
- Principle 7: Golden Sources– Is this system considered to host the most accurate data in the architecture?
- Principle 8: Loose Coupling– Can this system function without a dependency on other systems?
Modernised
- Principle 9: Controlled Modernisation– Have customisations been contained so that it is easy to upgrade the software to the latest version?
- Principle 10: Optimised Integration– Can modern integration patterns be used (e.g. Rest APIs) for this system to communicate with other systems in the architecture?
- Principle 11: Best of Breed– Do the system vendors continuously update the system functionality to ensure that it accommodates the needs of visionaries in the industry?
- Principle 12: Automation for Efficiency– Does the system use any innovative technologies (e.g. AI&ML) to assist with the automation of manual tasks?
Figure 1 below presents a screenshot of my Strength and Weakness evaluation sheet.
Figure 1: Example of a Strength and Weakness Evaluation Sheet
Step 4: Evaluate all systems within the chosen architecture layers against the Metrics
Use the scores to evaluate all systems within each architectural layer against each other to identify the strengths and weaknesses in the architecture.
Figure 2 below shows and example of a Strength and Weakness evaluation and the identification of weaknesses that should be prioritised for remediation.
Figure 2: Example findings of the systems within a single architectural layer
Step 5: Plan the Transformation Strategy
Consider the following points during the planning of your transformation strategy:
- For each of the architectural layers – Identify the scale of change required. The minimal change would include configuration changes, whereas significant changes would replace all components within a layer.
- Prioritise the layers that contribute to most of the weaknesses in the architecture and plan the changes based on the MSCW (Moscow) strategy – First, implement all Must Haves, then all the Should Haves while placing all Could Haves and Would Haves to a future phase.
- Comply with your Principles!