An Approach to Application Modernization: Discovery and Assessment Phase

Modernization is a journey, and it starts with the user experience in mind. It must draw a parallel between the organization’s future and its operational complexity.

By Ernese Norelus, Sreeni Pamidala, and Oliver Senti

Creating a business case for an application modernization project: business requirements change, and businesses need to transform towards a digital model to realize opportunities that were never obtainable before the emergence of the cloud. These days most relevant companies build their entire business strategy around cloud capabilities to capture their market share, building capability around customer experience, usability, accessibility, and are taking things further and using customer data to personalize outreach. Users expect apps and systems to be simple and easy to use; they want better access to information and excellent user experience, thus a need for redesigning a legacy system.

Figure 1: Application Modernization

It’s a constant battle for enterprises to remain relevant. The speed of technology is becoming an impediment for most companies in the new era. The performance of applications must continuously align with rapidly changing software platforms, faster time-to-market requirements, new performance and compliance demands, and technology redundancies.

Legacy application modernization is like the old adage about how to eat an elephant “one small bite at a time.” In our experience, a successful application modernization strategy starts with the business need in mind and not from a technological point of view. No matter from which angle you look at it, modernizing a legacy application is a considerable undertaking that can’t be taken lightly. Your best approach is to begin the journey with baby steps.

There are different application modernization techniques and approaches to consider, and which strategy is best suited for you will depend on your maturity level and business needs. In this blog, the prescriptive approach is from the angle of User eXperience (UX), Architecture, Infrastructure, Delivery, and Governance. Stay tuned for more details on the upcoming blogs.

Modernization is an organizational decision that involves business and IT to make this a successful journey.

• What are your drivers for application modernization?
  - Update the user’s experience
  - Understanding users’ needs and behaviors
  - Improve and enrich user experience (UX)/demands
  - Enable new business opportunities
  - Delivery applications and features faster
  - Reduce the high cost of new features
  - Urgent capacity needs
  - Software hardware refresh
  - Software end of support
  - Comply with regulations
  - Datacenter contracts expiring
  - Address security threats
• The opportunity cost of modernization:
  - User satisfaction
  - Cost-Effectiveness
  - Quality of UI/UX remodel
  - Reduce redesign & development time
  - Reduce training time and onboarding
  - Reduced cost for impact analysis
  - Elimination of legacy risk and technical debt
  - Better information governance
  - Connectivity and Integration are essential to building modern applications.
  - Performance can be an issue
  - Resiliency

Application Modernization, in its purest form, is the process of organizing existing functionality into applications, microservices, and development teams around business capabilities and domains “a sphere of knowledge or activity” (Domain-Driven Design). The main goal of application modernization is to decompose an existing monolith or legacy system into small units following the principles of the 12 Factor apps. Decomposition from a business perspective to achieve this, you need a very knowledgeable team capable of defining application modernization and supporting use cases that motivate a modernization effort with a journey outlined.

In the next blog titled “An Approach to Application Modernization: Planning & Design Phase,” we will elaborate on the composition and the need for cross-functional squads, such as:
- Build squads
- Infrastructure Operations build squads
- Database squads
- DevOps squads
- Platform run squads

Discovery and Defining the application modernization strategy

Modernization must begin with an understanding of current and new user needs and wants, followed by an understanding of your inventory and technology stack. What is the user experience you want to achieve? What you have, what are the apps to upgraded, retired, or move to the cloud. Asking the right questions ahead of legacy system modernization, employ tools and automated processes to modify code is crucial. Here is a good list of items that will help understand better and assess the current portfolio:
- User research
- Code remediation of existing application
- Security and Compliance
- Performance
- Integration
- Reports and Analytics
- DevOps (includes Develop and Test and Deliver)
- Data migration
- Service Management & Operations
- Resiliency (HA / Backup / DR)
- Infrastructure Delivery (Networking)
- Serviceability

User research

• Run user experience workshops to focus on the essentials of what, why and for whom.
• Understand the user’s pain points and behavior.
• Describe how users use a particular feature of the application.
• Look at how users interact with the app, including the steps users take to accomplish each task.
• Identify user frustrations and problems with the application through one-on-one sessions where a “real-life” user performs tasks on your app.
• Perform user interviews
• Determine where are the apparent or potential pain points.

Code remediation of existing application

• Provide a brief description of the app and use cases
• Business driver(s) to consider moving to the Cloud
  - a) Cost — Capex reduction, OpEx preference?
  - b) Success criteria for a move to the Cloud?
  - c) Anything else?
• What language(s) is the application written in?
• Is this a multi-tier application? Describe the tiers.
• What platform/OS does the application run on currently?
• Is the existing application managed by your company or a 3rd party?
• How frequently is the application updated?
• Are all external system and service dependencies documented? Please provide a system context diagram
• What middleware products is the application utilizing? App server, messaging, …
• What are the communication protocols supported/required by the application?
• Does the current application use non-HTTP(S) ports?
• Does the application directly use OS native functions?
• Is the current application distributed over multiple nodes? Please specify what are the distributed application components
• Does the application contain batch jobs/scheduled tasks?
• Does the current application rely on access to files?
• Is there a set of test cases and test data for application? How many of the test cases are automated?
• What is the use case for this app?
• Who is the target audience (persona) of this app?
• What is the call flow? (some end-to-end scenarios)

Security and Compliance

• What Identity Management system is used by the existing application?
• How are Security and Access roles/groups defined and managed currently?
• How are keys managed by the current App?
• Is someone else managing security for you? If so, who?
• How are application code and containers currently being tested for vulnerabilities and threats?
• Authentication mechanisms used for downstream services (on-prem and external)?
• What part of the application needs compliance?
• Is any specific compliance required:
  - a) PCI (Payment Card Industry)
  - b) HIPAA (Healthcare Information Portability and Accountability Act)
  - c) CJI (criminal justice information) etc.

Performance

• Do the application deployment and rollout plan take into account expected changes to capacity and resource measures?
  - a) What are the phases of the rollout plan?
  - b) What are the trigger conditions that drive the continued rollout?
• How are business capacity and resource consumption characteristics being measured, logged, analyzed and reported (through notification)?
  - a) During system test?
  - b) During runtime?
• What are the testing tools being used for performance (load) testing?
• How many users are currently (or estimated) registered to the app?
• What is the maximum number of concurrent active users (or estimated)?
• What are the maximum (peak) and the average number of requests/second the application should support?
• What is the allowed latency per request for the application?
• What are the range (peak, low) and average data size related to requests?
• What is the threshold time to scale for the application?
• What is the threshold refresh rate for the application?

Integration

• What on-prem services/applications do the current application have integrations with?
• How are these services invoked and what kind of data is exchanged?
• What external services does the application have integrations with?
• How are these external services invoked and what kind of data is exchanged?

Reports and Analytics

• Describe any reports that the current app produces.
• Describe any dashboards that the current system produces.
• Are the reports interactive or run automatically on a schedule?
• Are these reports distributed via email or any other mechanism? Please describe
• External reporting/analytics solution integration (Splunk, other)?
• Clickstream analytics (Tealeaf, other)?

DevOps (includes Develop and Test and Deliver)

• What tool do you use for Collaborative development (e.g. Slack)?
• What tool do you use for Track & Plan (e.g. GitHub Issues and Projects)?
• What tool do you use for Edit Code (e.g. Atom, Sublime)?
• What tool do you use for Source Code (e.g. GitHub, )?
• What tool do you use for Build (e.g. The Build & Deploy pipeline in IBM Cloud)?
• What tool do you use for tests (e.g. Sauce Labs)?
• What tool do you use for Continuous Integration (e.g. DevOps Services)?
• What tool do you use for Artifact management (e.g. IBM Cloud DevOps Services)?
• What tool do you use for Release Management (e.g. IBM UrbanCode Release)?

Data migration

• Can all the data be exposed to the public access network paths?
• Is a VPN sufficient security?
• Does any data need to be migrated to the cloud? Amount of data and timeframe of migration.
• Amount of data to be stored in the cloud?
• Are the data format(s) known, common to Cloud and defined (structured, JSON, …)?
• Do the attributes/schema of data the solution is based on change frequently?
• Are there regulations, business requirements, or uses that require the availability of the data to be retained increase the amount of data to be stored.
• Are there requirements for limiting/auditing access to the data?
• Is the expected response time for retrieval of data less than a millisecond?
• Is the expectation for the time from creation to availability to use less than minutes?
• Is the data needed for the solution from multiple sources that have proven integration approaches and paths?
• Are there regulations or business requirements that require defendable proof of removal/deletion of data?
• Will the solution require metadata to be captured for data assets and data flows?
• Can all the data be exposed to the public access network paths?

Service Management & Operations

• Has an operational RACI (Responsible, Accountable, Consulted, and Informed) been developed between IBM, the client and 3rd party service providers, if any?
• What is the monitoring process for the App/Services?
• Has an outage response process been documented and validated?
• What are the outage response time requirements?
• Has the Operations and Application team’s communication plan been documented and validated?
• How often will outage response drills be run?
• What is the response plan to an outage of a client hosted service, the App utilizes?
• What is the response plan to an outage of a 3rd party service utilized by the App, not hosted/managed by IBM?

Resiliency (HA / Backup / DR)

• What is the availability requirement SLOs for the App?
  - a) Are these requirements for the App or individual services?
  - b) What are the 3rd part services on which this application is dependent, which are exclusions from the availability requirements?
• What are the Backup requirements?
  - a) RPO (Return Point Objective)
  - b) RTO (Return Time Objective)
  - c) Residency requirements for backup.
• What are the DR requirements?
  - a) Vital
  - b) Critical
  - c) Important
  - d) Discretionary
• What are the minimum distance requirements for DR?
• Are there data residency requirements for DR?
• Where is the app hosted today?
• What are the failover rules and requirements?

Infrastructure Delivery (Networking)

• What are the network capacity/throughput requirements of the current application?
• What are the IP requirements of the current application?
• Does the current application need access to specific ports?
• What are the Distributed Denial of Service (DDoS) requirements for the current solution?
• What are the internet access requirements?
• What are the VPN access requirements?
  - a) Do you have a preferred VPN provider?
  - b) Do you require more than one simultaneous VPN access path to their Intranet?
• Does the solution require the use of a Global Load Balancer? If so which one?
• What is the latency requirement?

Serviceability

• Does the application create a session and transaction correlation ID to enable traceability?
• Are the application components instrumented to gather business capacity and resource consumption metrics?
• What kinds of log messages are written by the applications and services and do they clearly indicate the triggering condition?
  - a) Informational, typically used to support unit and integration testing?
  - b) Warnings, typically issued when behavior is trending negatively towards an expected SLA boundary
  - c) Errors, when unexpected behavior occurs or SLAs are exceeded?
• Do the services in use forward and record the correlations IDs (see above) in log messages to better enable root cause analysis?
• Do the messages clearly indicate the specific service and where in the service code the condition triggering the message occurred?
  - a) Are the applicable variables used by the service identified?
  - b) Are the applicable microservices called by the service identified?
• Do the messages clearly indicate a remediation that can be done to correct the situation where applicable?
• How are these messages used by the analytics and monitoring tools to alert the appropriate responsible parties?
• Are standards-based logging services being used?
• Can the level of logging be changed dynamically based on the environment and stage of deployment/runtime conditions?

Conclusion

Where does application modernization start? A successful application modernization strategy begins with the client in mind. For that, you need small and highly collaborative teams that work with the customer directly to produce a flexible product, high quality, and that can react to market demand quickly is essential.

In part two of a multi-series blog, we are going to leverage on IBM Enterprise Design Thinking, Event Storming, Domain-Driven Design, and Test-Driven Development. This approach to our Garage Method to enable application modernization projects at scale.

Co-author

• Sreeni Pamidala, Architecture Discipline Leader, World Wide IBM Garage
• Oliver Senti, Practice Manager of IBM Garage Singapore

References

You want to learn more about Application Modernization and its challenges and benefits. Please refer to the links below where you can find many reads on how to master the core concepts that can be adopted quickly and without spending months in trying to figure out “the right way to do stuff”:

• Maps for the Journey
• Where does modernization start?
• Executing Your Legacy Modernization
• Application Modernization Point of View
• Application Modernization: Getting It Right
• A Phased Approach to Legacy Modernization
• The Enterprise Guide to Continuous Application Modernization
• Microservices, Kubernetes, and Application Modernization Done Right
• A Phased Approach to Legacy Modernization Part 3: Testing and Implementing Your Project Webinar

Bring your plan to the IBM Garage.
Are you ready to learn more about working with the IBM Garage? We’re here to help. Contact us today to schedule a time to speak with a Garage expert about your next big idea. Learn about our IBM Garage Method, the design, development, and startup communities we work in, and the deep expertise and capabilities we bring to the table.

Schedule a no-charge visit with the IBM Garage.