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.
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
Building a strong foundation
Any business that wants to grow needs to be built on strong and stable foundations. Oftentimes, technology strategies focus singularly on the ways that technology leaders can improve and continue to build a strong foundation, and so this section may feel familiar to technical readers. However for an integrated business and technology strategy to be successful, business leaders also need to understand how this focus will enable and support the business to grow. It is important that the improvements to the engineering organisation and the platforms they look after align with the themes that resonate with the rest of the organisation. These themes are:
- Accelerate time to value with improved efficiency and productivity. A good technology foundation can help businesses automate tasks, streamline processes, and improve communication. This can lead to significant improvements in efficiency and productivity, which can free up time and resources for other areas of the business.
- Increased customer satisfaction with improved product quality. A strong technology foundation can help businesses provide better customer service, offer more personalized experiences, and make it easier for customers to do business with them. This can lead to increased customer satisfaction, which can lead to increased sales and revenue.
- Reduce cost and minimize operational risk. A good technology foundation looks to reduce costs of the technology systems if the business need is to contain costs. Effective operational risk management helps companies prevent or minimize losses and safeguard their operations and reputation.
- Enhanced competitive advantage by enabling data driven decision making. A strong technology foundation can help businesses stay ahead of the competition by giving them access to new technologies, data, and insights. This can help them develop new products and services, improve their marketing and sales efforts, and gain a competitive edge in the market.
Accelerate time to value with improved efficiency and productivity.
Accelerating time to value reduces the time it takes to deliver measurable benefits or achieve desired outcomes from a particular initiative, product, or project. It focuses on maximizing the efficiency and effectiveness of the value creation process. Three areas that negatively impact time to value include the inability to easily and confidently change code, poor developer experience and waste within the delivery process.
Key Business Questions
- Is the current pace of delivery keeping up with the pace of customer demand?
Code quality
Well written and structured code, supported by appropriate test coverage is easy to modify to new feature requests. Teams can go at a rapid pace when they are confident that changes they make will not inadvertently introduce hidden defects.
Questions about code structure
Is the code well structured? Does the code follow the common patterns and practices of the language? Is it at least internally consistent?
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.
Activities: Code toxicity analysis
Questions about test strategy
Are there tests? Do the tests follow the test pyramid? If not, where are the gaps? If you change the code, does this also break the tests, is it possible to run unit and integration tests independently? Are more advanced techniques like parameterized or mutation testing being used?
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
Activities: Test code coverage • Build times, failures, historic data
Questions about defects
Where are defects found?
Defects caught in pre-prod or prod have exponentially higher cost to remediate and disrupt the flow of value added work
Activities: Build times, failures, historic data
Developer experience
Developer Experience and experience is key to engineering excellence leading to desired business outcomes and organisational performance. Developer experience (DX) encompasses all aspects of a developer’s interaction with an organisation, its tools and systems. Engineering platforms, that provide self-service capabilities help automate and streamline every stage of software development journey from ideation to go-live and collecting customer feedback leading to excellent developer experience
Questions about feedback loops
How quickly can teams get feedback on changes they make?
Look for long feedback loops such as long build times, validating cross functional requirements are upheld
Activities: Value stream map
Questions about access to knowledge
How easy is it to find the right information at the right time? How do new team members learn about the code? Is the code well documented?
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.
Activities: Documentation inspection
Questions about developer productivity accelerators
What accelerators, starter kits, paved roads are available? How long does it take a new team member to become productive?
Sensible defaults, convention over configuration, safe guard rails and good onboarding documentation improve the speed to productivity for new team members.
Activities: Measure time to productivity for the last batch of new hires
Questions about cognitive overload
How much cognitive overload do people face? How often do people need to context switch? What is the cost of misunderstood integrations, abstractions, and data?
Cognitive taxes create quality issues, slowing delivery significantly.
Activities: Value stream map
Delivery Process
Remove the waste that exists within your delivery process. The waste is negatively affecting your speed to market. Waste may be in handoffs between groups, approval boards that slow down continuous releases, or rework in the system.
Questions about waste
Where is the waste within the delivery process? How many digital or human interactions are needed to in the delivery process? Do systems add to or detract from the optimum flow of the role being played?
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.
Activities: Value stream map • Measure lead and cycle times • Measure flow metrics
Questions about developer friction
Where do our teams face friction in delivering on our big bets? How easy is it to make a code change?
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.
Activities: Value stream map
Increase customer satisfaction with improved product quality
Improving your product quality increases customer’s satisfaction and can have a big impact on customer retention. Product quality is impacted by the build quality itself, but is also impacted by performance issues, technical debt and complexity which results in increased reliance on call centres. There are often dangerous parts of systems that teams are reluctant to change due to the technical debt and lack of a safety net around it. If any feature development needs to be done in those areas, it will be slower and deployment will be riskier unless you tackle that debt. Maybe now is the time.
Key Business Questions
- Why do customers stop using your product? What are customer retention rates?
Address build quality issues
Unfortunately, IT systems have notoriously been buggy which impacts the overall product quality. Modern agile software delivery practices have significantly increased the build quality of modern codebases. Nevertheless, systems continue to have areas which have defects, or are difficult and complicated to understand which makes changes in these parts risky.
Questions about defect rates
What areas have the highest defect or incident rates?
A heatmap of defect rates for the components can show the most significant areas to improve first.
Activities: Incident and defect reports
Questions about risky parts of the codebase
Where are the riskiest parts of the codebase? Which parts do teams fear changing? What upcoming features need to change these areas? What is the cost of change in relation to cost of permanent improvement fix?
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..
Activities: Interview with teams • Analysis of historical velocity of changes through different components • Feature improvements, business initiative review
System performance under increased load
It will increase the number of site visits to your website and increase your customer load. How capable is your system today of performing with the anticipated new load?
Look for signs that your system is struggling under regular days as well as irregular events such as Black Friday sales. Identifying the breakpoints on these days gives you clues to what needs to be addressed for any additional load.
Questions about handling expected loads
How far can you scale up? Can you handle your peak expected volumes today? What is your equivalent of Black Friday sales? How does the site currently handle the increased load?
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.
Activities: Incident and performance log inspection • Performance, load and soak tests • Chaos engineering testing • Experimentation to determine bottlenecks and headroom in volume • Tests around dynamic scaling of infrastructure
Call center complaints
To uncover areas for improving product quality that will make the biggest impact on your customers, consult your customer support team. They often hold valuable insights into where your systems are falling short of customer expectations. However, be cautious of survivorship bias, similar to the WW2 planes returning with bullet holes – it’s important to consider not only customer complaints, but also where and why customers drop out of your funnel to get a comprehensive understanding of the issues.
Questions about call centre patterns
Which product features receive the most call centre interactions? What do the call centre staff spend the majority of their time doing?
Look for patterns in the call centre data. Match any patterns in this data with a heatmap across the product defect list.
Activities: Interview with call centre teams • Review of call centre data analysis
Address technical debt
Technical debt is a metaphor for choosing an easy solution now that will make it harder to make changes or add new features later. It is often incurred when developers choose to use quick hacks or workarounds instead of taking the time to write clean, well-organized code. The technical debt that is building up in your system can have significant impact on the quality of the product.
Questions about user experience debt
Where is your User Experience debt? What improvements could be made to improve your product quality?
Activities:
Questions about how code changes
How frequently is code changed? How many people are touching the code and how often (ownership / knowledge)? Has the code been recently changed?
Look for the components which frequently change together which imply they are tightly coupled. Hotspots of change indicate a high churn rate.
Activities: Git commit log analysis
