Creating an integrated business and technology strategy

The representation of product types in the code base can have a big effect on how easy it is to add new ones or adjust the categories as new products appear. Look for assumptions in other systems for the product line information. Product codes may be hard-coded elsewhere, some systems may only assume certain kinds of product. Look for changes throughout the stack, from the UI as you offer different customer experiences and navigation through your site, to new entries in your domain model and potentially new table structures in your database.

Business processes may not be suited for future products under consideration. Changes may be need to be made to shared-service back-end systems such as payment and invoicing systems, distribution and warehouse management systems and business reporting

Sharing capabilities across products allows you to focus on the value added differentiators of the new product. Consolidating the shared capabilities improves speed to market. However, be watchful over mandating the sharing of capabilities where the processes differ between product offerings as it may result in needless complication and debt within the capability.

Capabilities that don't add to product differentiation can safely be assigned to packaged software, either installed or SaaS. Developing a list of such capabilities can drive considering current vendor offerings. Changes in product line can help clarify what capabilities are important to product differentiation. Re-examine the vendors offering suitable products, both due to changes over time and from reevaluating differentiating factors.

Identify the capabilities that can be diversified, replicated, unified or coordinated across the markets. Diversified and replicated capabilities can exist for each market, where you want to look to offering unified capabilities through a global platform.

If you need to host your infrastructure in the new market due to regulatory, compliance or even performance reasons, you need to make deployment repeatable across your systems. This reduces inconsistencies across regions, which leads to high triage times when a fault occurs. It's too common for organizations to set up separate teams to customize and operate each region, resulting in configuration drift / snowflakes as code, and manual maintenance. Equal emphasis needs to go to maintenance - cost, staff effort, and results (things are patched, consistent, old versions retired, fixes of all sizes rolled out quickly and comprehensively). The running costs to scale geographically becomes near-linear, and improvements and fixes are not distributed quickly or consistently.

Commissioning new data centers in new markets in order to be compliant may take a long time. If there is no repeatability in the process, and it takes a while to commission, you could consider a move to the cloud. Cloud-based infrastructure will be easier to adhere to data sovereignty requirements in new markets but you may need to look at ways to partition your database to be compliant.

Look for any third-party systems which make you non-compliant by passing regulated information outside the country. This might include an examination of OLAs and SLAs.

Look for UI frameworks that enable this by default. Retrofitting internationalisation into UIs can be a tiresome process. Content length can change across languages. Look for dynamic UI elements that can accommodate longer or shorter text elements. If the UI framework has already been configured for translation files, a nice experiment to run is to change all translations to something small like “XXX”, and to something very long to see how the page responds.

Look for well factored code bases that isolate changes.

Will you need to add time into your development process to allow for an agency to translate your files? This extra wait time can affect your small feedback loops. Alternatively, will you need to introduce the translation process as part of the design process?

Front end code which is difficult to change will make it challenging to offer new customer experiences. Look for hard-coded navigation elements, difficult to change front end code, and lack of front end tests.

Untested code, especially untested JavaScript, will make it risky to change the experiences. Front ends which are only tested through slow (and flaky) end-to-end tests will increase the time it takes to develop new experiences.

When incorporating a new UI experience, such as extending your website to a native mobile app, consider how your digital platform accommodates and integrates core business functionalities while providing flexibility for various front-end interactions. If you have a microservice or micro front-end website in place, what architectural adjustments such as BFF (Backend For Frontend) mobile adapters are required.

Even though the acquired businesses continues to run independently, there is an assumption that some business capabilities need to be integrated (e.g. Finance) but possibly not all. A business capability map is a quick first step to illustrate the cross-over at a business level before dropping to the API. API Strategy is a way to unlock existing business capabilities by building an API ecosystem to allow innovation at scale. It helps reduce time to market, by creating an ecosystem of APIs that are easy to operate, integrate and consume. APIs differ from traditional approaches that focus on system integration. By focusing the integration of the businesses through well defined APIs you will increase your ability to innovate into the future.

Investigation into the API strategy applies as equally in the independently run case as it does in this case, however there are a few other levers that you can take advantage of. For instance, you could share event streams or take advantage of shared storage.

As you look to work closely with the acquired business, you will need to look to consolidate across domain models. If you focus on getting this alignment in the domain model, the data matching and integration of systems will become easier to configure.

A unified customer experience across the two products will increase customer satisfaction and improve retention. It will also enable the amplification of the value that both businesses together provide your customers, as the customer doesn't face the burden of working across two disjointed systems.

The Operating Model Quadrant from Enterprise Architecture as Strategy, is relevant for organizations wanting to unify capability across their group of companies, or when addressing consolidation of inorganic growth.

Successful acquisitions dedicate resources and people to integrating the businesses. As a technology leader your input maybe required to help the integration efforts understand how the systems will be integrated. Runtime environments may need to be consolidated, data might need to be migrated into the new system, or archived for compliance reasons. A security review of the systems may highlight security remediation that needs to happen within the system before the migration. The systems themselves may need consolidation as libraries and frameworks are unified across the technology stack, to improve the developer experience moving across products.

Streamlining and consolidate the operational aspects of the systems reduces the operational cost and time it takes to manage across multiple disparate systems. You may need to change how running systems are observed, which could include changing the logging information, frequency or changing severity level of logs.

Does it mirror the domain? Consider this at multiple levels: within classes or files, all the way to component boundaries. How do they interact with each other? (consider domain modeling). Dimensions to assess the code against are: size, complexity, coupling, cohesion.

Test coverage is easy to measure but won't always give a good indication of the test quality - other things to look at include number of tests; flakiness; execution time; consistency/ structure of tests; naming; and coupling to code

Defects caught in pre-prod or prod have exponentially higher cost to remediate and disrupt the flow of value added work

Look for long feedback loops such as long build times, validating cross functional requirements are upheld

What documentation exists, is it up to date, is it relevant / well organized / easy to find, does each repo have clear documentation about purpose of code and how to test and run it.

Sensible defaults, convention over configuration, safe guard rails and good onboarding documentation improve the speed to productivity for new team members.

Cognitive taxes create quality issues, slowing delivery significantly.

Teams are often caught up on building a lot of things that are non-essential to business value. Examples of waste within the delivery process include cognitive load/context switching, ability to find the right information at the right time, friction in the development experience and slow quality feedback loops. Look for developer ecosystems that are fragmented with a need to navigate into multiple places and systems to get the job done. Measuring the size of work queues between stages of workflow is a good way to quantify bottlenecks. Look at flow metrics and cycle and lead times.

Measure time to put a single line code change into production. Long lag times for small changes discourage frequent updates, leading to larger, riskier updates and reduce responsiveness to business opportunities.

A heatmap of defect rates for the components can show the most significant areas to improve first.

If future feature development is planned for the risky parts, it might be more effective to properly fix this area. Typically architectural changes are required to address the root cause of these areas..

Look for periods where you are reaching capacity and notice patterns over time. If you are nearing capacity at the anticipated loads after growth you will need to start addressing system performance now.

Look for patterns in the call centre data. Match any patterns in this data with a heatmap across the product defect list.

Look for the components which frequently change together which imply they are tightly coupled. Hotspots of change indicate a high churn rate.

With the move to the cloud, some financial controllers and technology leaders alike have lost the financial visibility that they once had over infrastructure bought and run in data centres. Infrastructure buying centres have moved from the procurement office to the engineers keyboard, with credit cards stored on file with cloud vendor accounts. All too often, financial offices are only seeing the cloud spend once the bill arrives at the end of the month. There is a disconnect between the engineers who are spinning up new infrastructure and the controllers of the budget.

Democratising the financial decision making around cloud spend to the engineers that are responsible for instantiating the cloud components needs to be done with the right financial controls and alerts in place. Influencing the culture of the organisation to operate on the cloud is important to help optimise cloud costs with governance and collaboration as a discipline. Tagging infrastructure and surfacing the spend on operational dashboards, alongside uptime and usage metrics and alerting, will provide the right balance between financial control and governance.

Retiring or sunsetting systems that you are no longer using is the fastest way to reduce your cloud bill. Take a critical look at everything that appears on the bill to make sure that you are still getting value from it.

Data governance refers to the overall management, control, and protection of an organization's data assets. It encompasses the processes, policies, and standards that ensure the quality, integrity, availability, and security of data throughout its lifecycle. Data governance aims to establish a framework that governs how data is collected, stored, used, and shared across an organization.

End-of-life (EOL) software versions are no longer supported by the software vendor. This means that the vendor will no longer provide security updates, bug fixes, or new features for the software. As a result, using EOL software can pose a number of risks to businesses, including security vulnerabilities, performance problems, compliance issues and data loss. EOL versions provides an opportunity for a current market scan to migrate onto newer technologies that can enable the next growth phase.

By having backup plans in place in case of disruptions, companies can reduce the impact of disruptions on their operations. Use technology to improve visibility into the supply chain. By having real-time data on the location of goods and materials, companies can identify and respond to disruptions more quickly.

Define data architecture to cater to the analytics use cases. Design and execute data platforms based on best practices from data engineering, software engineering and continuous delivery. You want to be able to scale with ease with different data sources and users, enabling analytics use cases leading to richer insights.

Easy access to the data may not be as useful to the organisation if the data is a disconnected bunch of facts. Build curated views and governed datasets with data from various sources for analytics, machine learning, services, applications, etc.

A strong leader should have a clear vision and purpose, communicating it effectively to inspire others. Emotional intelligence is vital, as is acting with integrity and ethics. Decisiveness, empowerment, adaptability, collaboration, and team-building are essential traits for fostering a positive work environment. Accountability, resilience, and a focus on results are also indicative of effective leadership. Additionally, good leaders prioritize mentorship and development to ensure the growth of their team members, contributing to the organization's long-term success. Look for leaders that promote diverse and equitable culture that promotes inclusion.

Look at incentives, recognition or promotions that encourage knowledge sharing behaviours.

Look for systems that are in place that are easy to access, navigate and contribute back into.

Look at retention data and exit interviews to see if there are recurring patterns

Shorten the turn around time of systems access requests so that employees can get back to value-added tasks

Measuring the size of work queues (inventory) between stages of workflow is a good way to quantify bottlenecks. Supporting many communication channels increases costs, and many channels adds confusion as people aren't sure which ones to use. Handoff points typically create friction

Some systems need differences due to country-specific regulation and cultural differences. But many systems are developed locally while having substantially the same behavior as the rest of the world. Local business units often can't wait for features to be prioritized globally, but this results in many similar systems which are inefficient to sustain.

Chat comments can be an indicator for employee satisfaction with systems and processes. Sentiment analysis tools are often used for customer comments, they can also be used to assess internal systems.

Systems that get an inordinately high number of support tickets should be reviewed for enhancement or replacement

If staff vote with their feet for external systems, then we should review whether the internal systems are worthwhile.

Old, tired systems not only wear down on employee sentiment towards your organisation but can also can harm productivity. In the same way that you want to focus on compelling customer experience, treat your employees as customers of your internal products, and provide them with the necessary modern tools to achieve their goals. It is important to treat these systems with the same care as you do customer facing products. That means treating your internal users as the customers of these systems and applying the same product thinking approach, customer research and customer service that you do to your products.

The Thoughtworks Looking Glass report and Technology Radar are two publications that can help inform a technology leader on current and emerging technologies, alongside analyst reports like Gartner and Forrester. However, be careful with new technologies. New and shiny technologies should not be chosen for technology's sake. There should be clear value creation to either customers or employees. Some organisations adopt innovation tokens. The concept of innovation tokens is very simple: You get three innovation tokens. Every time you innovate (i.e. do something other than what's standard) you spend one of those tokens. Once you've spent them all, you're out, and you don't get to innovate anymore.

Ensure the use of reliable data sources and historical data, focusing on relevant metrics aligned with business objectives. Segment the market and consider external factors like economic conditions and technological advancements. Make comparative analyses with industry benchmarks and competitors, seek input from industry experts, and validate assumptions. Continuously monitor trends, visualize data, and adopt a forward-looking approach to anticipate future developments and align business strategies accordingly.

Considering these broader issues allows you to adapt quickly to rapidly developing situations. For example, we recently completed a technology strategy for a client in the travel industry. We used travel insight data and our own customer research to explore how the shape of travel has changed post Covid-19 induced lockdowns. Ease of canceling and rebooking has become an important factor as people have returned to travel in uncertain times. The technology strategy therefore included a focus on improving the capabilities for cancellations, notifications and back office integrations. We also identified good examples where ML would help predict the likelihood of cancellations, so we included the introduction of ML and data engineering into the technology strategy to help customers return to travel and reduce the load onto customer support teams. Shiny technology solving an actual problem, not for the sake of using shiny technology.