BCG Platinion Case: Digital transformation of an entire corporation

Suggestions for the candidate to discuss the case:

1. Think of the actual goal of such an assessment in the broader case context

• In this case the goal of the assessment is to identify the most relevant areas in the IT landscape and to prioritize the pain points that need to be addressed more urgently
• Focus on the most relevant information - it is sufficient to capture the main dimensions (a detailed assessment is neither required nor requested)
   

2. Keep in mind to whom the results would be presented and adapt the communication style accordingly

• The CIO would probably not be interested in minor details, while other senior stakeholders on the client side might lack a deep technical knowledge
• Focus on the high-level view and convey the key messages first; deep-dive on selected topics afterwards (if needed). A structured framework can be leveraged to provide a holistic view and at the same time to help break-down the analysis

Exemplary solution (other answers are possible):

1. Define the framework to drive the assessment

• Mapping of IT applications to the industry value chain and business function provides a holistic view
• Relevant dimensions of analysis on the applications could be:
  • "Impact" (business critical or not)
  • Severity (high/medium/low) of the identified issues in terms of stability, scalability, high TTM (time-to-market)
  • Type of application (e.g., custom vs. standard software)

2. Describe the approach you would take to conduct the assessment

• Analyze available documentation (e.g., application map/inventory, incident reports to identify stability issues)
• Conduct interviews with key stakeholders (e.g. CIO, Head of IT Ops, selected BRM²/BU³ leads) to complement the information

3. Define the drivers to prioritize deep-dives and recommendations

• Focus on business-critical applications that present high severity issues and handle the rest by exception

Suggestions for the candidate to discuss the case:

1. Define assumptions to reduce the scope of analysis

• Given the limited information (and time) available it is key to define upfront plausible hypotheses to guide the analysis
• Validate these hypotheses with the interviewer and adjust your approach depending on the feedback received

2. Tackle the pain points one by one and be coherent

• Describe the technological levers that could address each pain point, one at the time, explaining the main reasons behind the recommendation
• Do not mix-up topics and keep in mind the assumptions that have been validated upfront

Examplary solution (other answers are possible):

Pain point “Stability”

• Hypotheses on root causes
  • Buggy/Badly written custom code (e.g., due to various changes over time) with limited or no documentation
  • Outdated/out-of-support applications
  • Excessive customization of packaged SW
• Suggested technical lever
  • Refactoring of custom applications into a modular and de-coupled architecture: Adjusting current applications would be too complex. It might be easier to re-write entire/pieces of custom applications using new technologies and most importantly with a modular approach (e.g. "microservices architecture") that enables easier isolation of failures, allowing unaffected functionalities to carry on working, hence increasing overall stability

Pain point “Scalability”

• Hypotheses on root causes
  • Overall IT architecture constraints
  • Outdated/"capacity constrained" IT infrastructure
• Suggested technical lever
  • Cloud solutions: PaaS (Platform-as-a-Service) cloud solution can be leveraged for new/refactored custom developments to overcome on-premise infrastructure capacity constraints.
    Likewise, SaaS (Software-as-a-Service) solutions applications can be considered to serve "commodity"/non-differentiating functionalities

Pain point “time-to-market”

• Hypotheses on root causes
  • Overall IT architecture constraints
  • Dependencies due to highly integrated/ coupled IT applications landscape
  • Complex and highly manual SW release management procedures
• Suggested technical lever
  • Refactoring custom applications with modular and de-coupled architecture: Besides higher stability, modularization also allows faster implementation of functionalities as each single module can be changed and deployed independently
  • SW development lifecycle automation: Along with refactoring, introduction of new SDLC approaches such as DevOps that imply a strong push on automation (e.g. automated testing, continuous deployment etc.) would allow faster release cycles

Suggestions for the candidate to discuss the case:

1. Prioritize and start by describing the most relevant dimensions

• Don't feel rushed to provide a complete list of applicable dimensions, take your time to structure the answer
• Challenge yourself to identify topics that are not immediately obvious

2. Examples are a good way to reinforce the concepts but make them as specific as possible

• Consider the case/client context if you want to give examples; e.g., ERP might be a good example of a business critical application in many cases, but not if the client is an insurance company

Exemplary solution (other answers are possible):

• Refactoring to Microservices (Modular & De-Coupled Architecture)
  • Relevance for the business and specific requirements: The effort to reimplement in-house with a custom development makes sense for business critical differentiating functionalities (trade-off with functionalities covered by package SW alternatives might not be suitable)
  • Expected frequency of changes: Applications that will have high-frequency of changes and releases of new functionalities (e.g., due to business priority or legal/regulatory requirements) will benefit most from the enhanced time-to-market
  • Heterogeneous scalability requirements: Refactoring of applications that have high scalability requirements only
    for selected functionalities would allow high efficiency in scaling single modules (rather than the entire monolithic application)
• Introduction of Cloud Solutions
  • Usage patterns: Applications with a dynamic usage pattern (i.e. peaks & valleys vs. flat) would benefit the most from the elastic scalability enabled by cloud solutions (e.g. applicable to PaaS solutions in combination with new microservices implementation)
  • Technological compatibility: Some technology stack (e.g., Cobol, z/OS) are hardly suited for cloud migrations (although it would be transparent in case of SaaS implementation)
  • Latency sensitivity: Applications that are highly "latency sensitive" might be negatively impacted by the additional latency introduced by cloud options compared to on-premise solutions

Suggestions for the candidate to discuss the case:

1. Guide your interviewer through the steps to demonstrate your approach

• If needed, declare explicitly and discuss assumptions with the interviewer
• Write down important information and intermediate steps of your calculation to be clearer in describing the approach, lay out levers that lead to cost reduction

2. Train your mental calculation skills

• This type of question is intended to show your quantitative skills and how comfortable you are with numbers without using calculators

Example (your answer could include the following steps):

• Within change the business (CtB) the company spends 4.3% more money than their peers
• Reason for that can be higher costs for building new software in a complex and entangled landscape, which totals of 11.4% the overall IT cost
• To optimize IT spend the company can have a look into the project portfolio and reduce costs by utilizing categories in the portfolio
• Assumption that projects that are not regulatory are 60% (based on hint of 40% regulatory projects within provided analysis overview) of the project portfolio and can be reduced totally
• The portfolio costs can be reduced by cutting 60% which leads to reduction of €48M (€80M CtB * 60%) in CtB, yet a full cut of all non-regulatory spend will limit the company in implementing new products, modernization or innovation projects

In conclusion, Change the Business (CtB) can be reduced but also maintenance in RtB should be investigated by reducing tech debt (modernizing of the core) and external cost by renegotiation and reducing amount of externals (e.g., through portfolio reduction)