Creating an integrated business and technology strategy
How do you create a technology strategy? The conventional approach suggests you start with your current state, determine your future state and build the roadmap to get there. But there is a nuance in that approach that isn’t quite right. What often results from following this is a big wish list of all the things that could be done. A powerful technology strategy is as much about what is left out as it is about what is included. Furthermore, technology strategies are often created in isolation, separate from business or product strategies. They are commonly created after the business strategy has been agreed upon. The result being infeasible business strategies which can not be achieved without considerable cost or time.
The challenges with this conventional approach shouldn’t be too surprising. After all, if you were to build a health strategy your doctor wouldn’t start with a full body scan and tell you how to fix all the symptoms. They would start with your health objectives and the outcomes that you are after, then investigate if your body was capable of achieving your goals, and if not put a remediation plan in place.
I would like to challenge this conventional approach to creating technology strategies, and offer up a different way to create yours. Start with the objectives and outcomes of your organisation. As the organisation considers the different strategic directions that they could traverse to achieve the goals, follow specific lines of inquiry to investigate if your current environment is capable of achieving the proposed strategic direction. The recommendations that result from the different investigations inform the feasibility of that direction, and can be used to formulate a remediation plan. Additionally, because technology is considered as the business strategy is being formed, technology itself can be the driving force behind ideas for new revenue streams. In doing so, your technology strategy will be integrated with the business strategy because it is born together with the business strategy.
How to use this article
In this article, we look at eleven prevalent strategic directions that organisations traverse, grouped into four broad categories.
| Section | Strategic Direction |
|---|---|
| Growing the business | Expand to complementary products |
| Expand to new markets or regions | |
| Expand customer segments | |
| Inorganic growth | |
| Building a strong foundation | Accelerate time to value with improved efficiency and productivity. |
| Increase customer satisfaction with improved product quality | |
| Reduce Cost and Minimize Operational Risk | |
| Enhanced competitive advantage by enabling data driven decision making | |
| Supporting the people | Culture |
| Internal and back office systems | |
| Responding to the ever changing future | Emerging technologies and market trends |
For each strategic direction identified, we provide examples of the lines of inquiry that you can use to investigate how feasible the strategic direction is. We also provide activities that you can do to help answer the lines of inquiry. Many activities span across many lines of inquiry, which allow you to concentrate your efforts into the synthesis of the activity rather than the activity itself.
Here’s the format we use for these directions:
Direction
This is the implication on technology for this strategic direction
Key Business Questions
- Any questions that you should ask the business to inform the decisions you make
Name of the line of inquiry
Description of the investigation
Questions about the topic – click to expand
Some questions to ask that will guide your investigation
A description of things to look out for
Activities: Activities that may help the investigation
Questions about other aspects – click to expand
More questions to ask that will guide your investigation
A description of things to look out for
Activities: Activities that may help the investigation
By selecting the relevant line of inquiry, and using the example questions as a springboard to guide your investigation, you will be one the right tack to creating your own integrated business and technology strategy.
Growing the business
There are just a few key avenues for business growth:
- Offering complementary products: This involves selling additional products or services to your existing customers. This can be a great way to increase revenue and customer loyalty.
- Expanding into new markets: This involves selling your products or services in new geographic regions or to new customer segments. This can be a great way to grow your business, but it can also be a challenge. It is important to carefully research new markets before expanding into them.
- Attracting new customer segments: This involves identifying new groups of people who could be interested in your products or services. You can do this by conducting market research, analyzing customer data, and identifying trends in your industry.
Organizations typically focus on one or two of these growth strategies at a time, while maintaining and growing their existing business. This is often achieved through organic growth, but at times, the growth is accelerated through mergers and acquisitions, joint ventures or other strategic alliances (ie inorganic growth), which accelerates value realization along one or more of these growth strategies.
Expand to complementary products
Offering new products to your customers could result in significant changes throughout your systems, from the customer buying experience to shared-service backend systems such as payments and invoicing, distribution and warehouse management, and business reporting. How different the product is from your existing product suite will impact how large the change needs to be.
Key Business Questions
- How different are the two product types? Will business processes need to change?
- What business capabilities can be shared across products? Eg Payments, Distribution, Inventory.
- What are undifferentiated capabilities that require significant changes? What products exist on the market today that meet the needs of these undifferentiated capabilities?
- Do you need a single customer view over the products?
- What is the opportunity cost to the existing product with expansion a complementary area? Will investment dilute across the products, degrading the experience of the original product?
Product representation
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.
Questions about product representation
How are product categories represented in systems?
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.
Activities: Code inspection • Database inspection • Domain modeling
Changes to business processes
Business processes may not be suited for future products under consideration. As a result, expanding into complementary products might necessitate larger system changes. If the blast radius is wide, how easy is it to make large changes through the system?
Questions about spread of change
How many other systems need to change if a product change occurs in one system?
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
Activities: Business process mapping
Shared Capability
As you add complementary products to your offering, you will need to identify which capabilities should be shared across the products and what special treatment is required to shared capabilities. Moving toward a digital platform architecture will allow you to reuse shared capabilities if you expose them via APIs.
Questions about shared capabiltiies
What capabilities are shared across product types? How do shared capabilities need to change to support new products?
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.
Activities: Business capability mapping • Business process map
Questions about build or buy capabities
Should you build or buy the capability? Are there newer products on the market that can replace the undifferentiated capabilities that require significant change?
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.
Activities: Business capability mapping • Vendor product scan • Operating Model Quadrant from Enterprise Architecture as Strategy • Build vs buy analysis
Expand to new markets or regions
As you expand into new geographies, you will be faced with the challenges of running a global platform that needs to cater for regional differences brought about by different local integration’s, differing buyer personas, and different processes. Some capabilities will need to be provided in a global platform, others need to have flexibility to allow for these regional differences.
You will also need to contend with government regulation requirements such as GDPR, data sovereignty and regulatory compliance like SOX and APRA. This impacts where your data is processed and where it is stored. It also might introduce new features to handle compliance requirements.
Key Business Questions
- What are the differences between the customers in each market?
- What are the regulatory compliance requirements for the new market?
- Do you need to change language, unit formats or factor in time zone conversions? Are there any cultural differences that require UI changes (eg the colour black has different interpretations in Korea than North America)?
- Do you need to introduce new tax calculations or additional reporting requirements?
Diversification or Rationalisation of capabilities
As you expand into new geographies, you will be faced with the challenges of running a global platform that needs to cater for regional differences brought about by different local integrations, differing buyer personas, different processes. Some capabilities will need to be provided in a global platform, others need to have flexibility to allow for these regional differences.
Questions about different capabilities
How does your platform support different capabilities? How do they change across the markets?
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.
Activities: Business capability mapping • Operating Model Quadrant from Enterprise Architecture as Strategy
Regulation and compliance
You may need to contend with government regulation requirements such as GDPR, data sovereignty and regulatory compliance like SOX and APRA. This impacts where your data is processed and where it is stored. It also might introduce new features to handle compliance requirements.
Questions about infrastructure and deployment
How easy is it to replicate your infrastructure?Do you have one-click deployment of your infrastructure-as-code?
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.
Activities: Deployment strategy • Infrastructure as code
Questions about data centres
Does your infrastructure run in data centers or the cloud? How long will it take to commission a new data center in a new country?
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.
Activities: Infrastructure architecture diagrams • Data storage
Questions about third party system compliance
How do your third-party systems handle data? Will they make you non-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.
Activities: 3rd party inspection, review of OLAs and SLAs
Internationalisation
Expanding into new markets may introduce internationalisation changes such as languages, time, money and units. There may also be taxes to consider, and new timezone or daylight saving changes to be factored into.
Questions about language and unit conversion
How easy is it to translate language files and unit formats?
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.
Activities: Code inspection
Questions about time, money and units
How easy is it to introduce new tax calculations, or date/time conversions? What assumptions does the code make about the units or the currency it uses?
Look for well factored code bases that isolate changes.
Activities: Code inspection
Questions about language translations
What is the process to translate the content? How does this process impact continuous delivery?
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?
Activities: Path to production • Value stream mapping
Expand customer segments
Ideally, offering your existing product to new customer segments should see little changes through your system. However, at times new customer segments could introduce new operational processes, new customer journeys or new channels experiences. For example, a bank that expands existing credit cards into the sub-prime market introduces completely new operational processes to manage increased risk around debt, regulatory issues due to responsible lending, new way of doing collections (due to higher numbers and earlier interventions) and new marketing strategies. Where as a move from B2C to B2B might mean introducing a new API customer channel. Expanding to more mobile customers might need move to a native mobile experience.
You might want to gather different customer insight as you move, including customer sentiment, adoption and usage so you might add new reporting requirements or alter existing reports to also report on the new segments.
Key Business Questions
- What are the differences between the customers segments?
- What operational process changes are required to support the new customer segment?
- Are you moving between B2C and B2B?
- What are the different expectations of interaction for the new customer segment?
Customer journey changes
A new customer base might need new customer experiences. If their customer journey differs from your existing customer journey, you will need to make changes to your system
Questions about front end code
How easily can you offer a new experience, new pages, new navigation or new portal?
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.
Activities: User experience debt • Front end code inspection • Test coverage
Questions about front end testing
How is the front end code tested?
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.
Activities: Test coverage
Channel strategy
A new customer experience might also open the need for different customer channels. Moving from a B2C to a B2B offering may provide you with an opportunity to streamline your experience behind customer-centric APIs. Expanding into partner networks will require integration into the networks.
Questions about different UI experiences
Will you need to offer a different mobile or website experience?
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.
Activities: Architecture design
Inorganic growth
Inorganic growth through mergers and acquisitions (M&A), joint ventures, or other strategic alliances is often a faster way to accelerate the growth of a business along the three aforementioned axes. It in itself drives a different line of investigation.
Key Business Questions
- What were the value drivers for the acquisition? How are you protecting these?
- What is the long term view of the acquisition – are you merging it into the business over time, or keeping it separate?
- What are the long term plans for the acquisition? Will you divest this asset once your company grows?
Independently run businesses
This is the case where the acquired businesses continues to run independently to the organisation. This might be the first phase of the acquisition, or it might be to enable an easy sale of the asset in the future. While the technology organisations and the systems remain separate, there is value in loose-coupling (e.g. via restful APIs) to integrate the two running systems.
Questions about shared business capabilities
What business capabilities need to be integrated? Are these capabilities exposed through APIs?
Do the APIs expose the inner workings of the systems, or are they nice facades which describe the behaviour?
How stable are the APIs? Public-facing APIs should be as stable as possible, because of the large amount of coordination (and work) across the partner ecosystem.
How secure are the APIs?
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.
Activities: Business capability mapping • API strategy review and inspection of existing APIs
Tight integration independently run
This is the case where you have two businesses running independently but you want tight integration between the two so that you can amplify the customer value created.
Questions about API strategy
What is the API strategy? Are different integration options available than publicly-facing APIs?
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.
Questions about common domain models
How different are the domain models? Is there alignment across the two, or is there significant work required to represent similar concepts across the systems? Are identifying entities such as customers the same across organisations? How can you connect the two entities? How will data be replicated across the systems?
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.
Activities: Domain modeling and consolidation
Questions about user experience across SSO or unified dashboards
Can you offer a seamless user experience to your customers by offering single sign-on, or dashboard views of the acquired company within your own systems?
Can you get better or more transparent intelligence for support teams across the two systems?
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.
Activities: Customer journey mapping
Complete merge
This is the case where the acquired systems will be first class systems within the ecosystem. This results in the rationalisation and consolidation of systems, migration of systems into the one system, integration into the runtime system, and merge of operational systems for observability and monitoring. It might also introduce different data archiving mechanisms
Questions about business capabilties
What capabilities now exist within the organisation?
Which systems need to be rationalised? Common examples are CRM, CMS and payment 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.
Activities: Business capability mapping
Questions about data migration and security
How do you migrate the acquired systems into your technology stack?
What is the security posture of the acquired systems? Will there need to be work done to update the runtimes and libraries?
What data needs to be migrated into the new system?
What data can be archived? What data can be deleted?
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.
Questions about operational aspects
What operational aspects need to be consolidated?
How do you migrate log data into the new systems?
Do you need to update log formats?
What runtime information should be surfaced for improved observability?
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.
Activities: Cross functional requirements • Review instrumentation used to operate the systems
