Why Application Owner interviews are important

History in it’s broadest aspect is a record of man’s migrations from one environment to another – Ellsworth Huntington  Article written by Owen Sherring

Why are SME interviews important to you? 

To undertake major change initiatives can often be daunting for several reasons, firstly, will anything break and/or not function as expected and required the change is applied and will the project ever realize the desired outcome. The key from our experience is firstly having a trusted data source to start with. The Towers Associates process has been designed and refined to ensure we have an effective and resource sensitive approach to achieving this. 

Through our “Discovery” process, we ingest both existing data from multiple sources of record, enriched in some cases with discovered asset information, into a central platform to create the best of all-in-one place. Doing this provides a great starting point, and often a better view of a customer’s environment at this point. But there remains one concern “Is this data correct, and do the application / business owners agree with it?” This is where our interview process comes in.  

*Image shows an example screen used during an application SME interview displaying the already captured information 

What is an SME Interview? 

Many people have a predefined expectation around SME interviews. They imagine the time needed with busy application owners will be more onerous than reality. Our team are extremely conscious of this and therefore are looking to validate, not discover in these sessions. 

Simply put… Rather than our consultants arranging a call with an application owner, only to arrive with a blank sheet of paper and ask the customer to explain how their application works, what infrastructure supports their applications and any other dependencies we should be aware of, we instead come to these sessions having done our homework, cleansed all available data sources and be able to clearly display our findings… Therefore, we ask for confirmation, which results in a much better experience to the application owner, and far less time required to achieve their sign-off that we have captured the information correctly. 

Information we’re looking to validate: 

• Name: The name by which the application is known within the organization. 
• Environment: Specific instance environment (Production, Test, Development, etc.). 
• App Owner: The manager responsible for the application, usually the system owner. 
• SME1: Application Manager, i.e., lead subject-matter expert, usually responsible for any application-related tasks in the migration process. 
• SME2: The backup or partner SME to the SME1.  May share application-related tasks or fill in as necessary. 
• Retire Date: Date (if any) by which the application is expected to be retired (decommissioned). 
• User Count: Approximate number of end users of the application. 
• Shutdown By: If application services need to be shut down before servers can be brought down and migrated, this is the resource that will complete that work in the move process. 
• Shutdown Duration: Approximate time, in minutes, required for the app shutdown task 
• Startup By: If application services need to be restarted after the servers are migrated and brought up in the new location, this is the resource that will complete that work in the move process. 
• Startup Duration: Approximate time, in minutes, required for the app startup task 
• Testing By: Resource who will conduct the post-migration smoke testing of application functionality. 
• Testing Duration: Approximate time, in minutes, required for the app testing task 
• Lifecycle Status: At what stage of the lifecycle is the application currently? 
• App Org: Which business organizations(s) use the application? 
• End User Supp Org: Which organization(s) is (are) responsible for end-user support?  
• Solution Type: is the app custom-built or COTS? 
• Svr type / middleware: Which unique server types and middleware components are used by the application? 
• Move Block Periods: For scheduling, identify calendar periods that are not available for moving the application. 
• Other compliance: Are there any other compliance considerations that need to be noted (examples include HIPAA and IFRS)? 
• Data Risk Classification: What level of data sensitivity applies (Public, Low, Medium, Medium+, or High). 
• Personal data: Does the app process personal data? 
• Sensitive personal data: Does the app process sensitive personal data? 
• Data subject location: Where do the data subjects reside (customers, patients, etc.)? 
• Business Criticality: How important is the application? 
• Licenses used: Does the app require non-OS licenses that may need to be updated before the move? 
• Vendor support: What is the existing vendor support model? 
• Specific HW: Does the app require specific hardware? 
• On-prem required: Are there technical or business reasons why the app must remain on premises? 
• Office supp application: Does that app provide specific functionality to an office location that requires it to remain close to the office? 
• Load balancer / HA: Does the app use load-balanced servers or a high-availability configuration? 

What is something changes between the time we do the interview and any change activity? 

As part of the data phase, the team keeps a heartbeat with trusted data sources, meaning if a new virtual machine is spun up and brought into an application, or a device is retired, we have processes in place to cater for this change. That’s the first point. 

Secondly, prior to any change, simulation events are run with all stakeholders and a way to ensure everyone is aware of what will happen, who will be doing what, and when activities will need to take place. This serves as a catch point to ensure the application teams have an opportunity to make changes as required. This doesn’t happen too often, but certainly when the change is upon them, the level of attention to details increases. 

If you’re about to undertake a major transformation or migration initiative, reach out to the team to understand this process better and explore how the team might be able to accelerate achieving confidence in your data.