Suggestions for the candidate to discuss the case:

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

1. In this case the goal of the assessment is to identify the most relevant divisions in the IT landscape and to prioritize the pain points that need to be addressed most urgently
2. 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

1. The CIO would probably not be interested in minor details, while other senior stakeholders on the client side might lack a deep technical knowledge
2. 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 Business Relationship Manager/Business Unit Leads) to complement the information above

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

1. Given the limited information (and time) available, it is key to define plausible hypotheses upfront to steer the analysis

1. Validate these hypotheses with the interviewer and adjust your approach depending on the received feedback

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

1. Describe technological levers that could address each pain point, one at the time, explaining the main reasons behind the recommendation

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 standard software
• Suggested technical lever
  • Refactoring of custom applications into a modular and de-coupled architecture: Adjusting current applications would be too complex. It is likely to be easier to re-write custom applications, using new technologies and most importantly a modular approach (e.g., "microservices architecture"). This enables easier isolation of errors and continued operations of unaffected functionalities, resulting in increased overall stability

Pain point “Scalability”

• Hypotheses on root causes
  • Overall IT architecture constraints (e.g., monolithic approach, which requires scaling of the whole application (even if only single functionality is affected by increased volume of requests), potential bottlenecks (e.g., Enterprise Service Bus, databases))
  • Outdated/"capacity constrained" IT infrastructure
• Suggested technical lever
  • Cloud solutions: PaaS (Platform-as-a-Service) cloud solutions can be leveraged for new or refactored custom developments to overcome on-premises infrastructure capacity constraints. Likewise, SaaS (Software-as-a-Service) solutions can be used for standard/non-differentiated functionalities

Pain point “time-to-market”

• Hypotheses on root causes
  • Overall IT architecture constraints (e.g., monolithic approach, which requires scaling of the whole application (even if only single functionality is affected by increased volume of requests)
  • Dependencies due to highly integrated/coupled IT application landscape (each release of new functionalities in an application could have dependencies on multiple other applications)
  • Complex and highly manual software release management procedures
• Suggested technichal lever
  • Refactoring of custom applications into a modular and de-coupled architecture: Besides higher stability, modularization also allows faster implementation of functionalities since each single module can be changed and deployed independently
  • Replace existing custom applications with standardized commercial-of-the-shelf applications
  • Software development lifecycle automation (SDLC): 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.) to 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 re-implement in-house with a custom development makes sense for business-critical differentiating functionalities
  • 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 for selected functionalities allows high efficiency in scaling single modules (rather than the entire monolithic application)
• Introduction of cloud solutions
  • Usage patterns: Applications with dynamic usage patterns (i.e., “highs & lows” compared to a constant load) would benefit the most from the dynamic 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