Applications\Tools Modernization Critical Aspects

Being a major aspect of IT ecosystem transformation, applications\tools modernization requires a major attention from our daily mundane tasks list.

Note: For ‘applications” I will be using “apps” in short form in rest of my article.

With closing daily mundane major tasks like:

1. Support to Pre-Sales(e.g. in terms of IP establishment and demo to client, solutioning basis RFP, service catalogs update, standard documentations on design etc),

2. Support to Practice(e.g. in terms of design, test and readiness validations of new IPs for organization we work for, planning for automation in every possible services aspect from an app deployment to environment to documentation deliveries to clients, strategically aligning services offering with organization policies while keeping eye on tradeoffs, taking team together activities(from skill to personality), refining m&m (migration & modernization approaches and service models updates),  etc),

3. Support to BAU(e.g. in terms of searching business opportunity in existing pool of services in active contract in form or services optimization, cost optimization and even redesign possibilities etc ),

4. Aligning with organization expectations along social contributions, and many more to do on lists, trying to focus on “modernization” aspects in this article.

What are apps\tools modernization in IT Industry?

Under the umbrella of IT Transformation, “Modernization of apps\tools” reserve a special place as it brings direct realization to business in terms of business apps\tools gets upgrade\enhancement and seen as modernized. Usually, modernization of IT resources can be categorized as below:

1. IT apps\tools modernization
2. Business apps\tools modernization

“IT apps\tools modernization” covers all infrastructure & platform related apps & tooling services. For example, services like monitoring, high availability services, backup, securing resources, networking, storage services, asset management services to name a major IT\Infrastructure\Platform serving apps & tooling.

“Business apps\tools modernization” covers all business-related apps & tools which brings direct business realization of capitals availability for organization. Business drives all major aspects of technological enhancements, so modernization of business apps\tools is always requiring deep analysis and reasoning for its upgrade or in other terms do the modernization.

Modernization of apps\tools refer to upgrade in apps\tools in terms of its:

1. Application layer enhancement in terms of: UI, UX changes, workflow, business-logic, authentication\authorization from windows to cloud or mobile\alwaysOn directory services, cache solution, high availability, faster to markets and many more.
2. Data layer enhancement in terms of: Database offering alignments among, SQL (e.g. RDBMS, DBMS), NOSQL (e.g. Jason files, Open files), NEWSQL (Traditional DBMS + New features), Bigdata (Data lakes). “To and Fro” data processing requirements between OLTP and OLAP, alongside by normalization and denormalization of data and so thousands of tools to pick from to suit business needs.
3. Platform layer enhancement in terms of: Datacenter to cloud, intra cloud, apps tiers technologies alongside apps architecture alignment.
4. Network layer enhancement in terms of: Usage of latest networking solutions and ensuring apps architecture alignment. Why is apps\tools modernization required?

With traditional model, there were multiple challenges experienced like and not limited to are, which pushed modernization of not only datacenter to cloud, however changes at segment and enterprise layers:

1. Legacy challenges: Resistance to change, approaches to legacy system modernization, knowledge skills shortage, legacy system, outdated technologies, no persistent support from vendor, costly solution to maintain.
2. Business challenges: Rebranding issues, modernization costs, getting all stakeholders for apps releases-based downtime.
3. BAU aspects: Poor performance, security issues, costly maintenance, cloud computing, skills shortage.
4. Modernization challenges: Incremental modernization.
5. Technologies challenges: Data migration along with alignment with cloud computing, growing tech-debt to management.
6. IT & Development staffs adamant for changes: IT staff departments inside organization fights to keep hold of resources, keeping too wide window for resources deployment, and limitations on technologies awareness.

 What are pre-contract phases for apps\tools modernization?

Following are activities being performed during pre-contract phases for apps\tools modernization:

1. Activities streaming across “sourcing & vetting leads”, “pitching to customers”, “following up to close a deal”.
2. Finally giving a demo to new client on “organization & solution”, just before signing contract.
3. Few more clarifications sync on solutions as well as technical clarifications on solutions with possible few more demo.
4. Specific app base detail analysis and brainstorming sessions with client to showcase vendor capabilities in certain areas.

 What are phases for apps\tools modernization post contract signature completion?

Following are usual phases executed during app modernization:

1. Organization business goal assessment: Prioritizing client main business requirements with brainstorming session to identify major pain points: cost saving, performance improvement, enhanced security, simplified management, lack of agility, lack of flexibility/scalability/data insights, lack of control on compute requirements.
2. Assessment & Discovery: Presents with report with identified issues\problem, reporting complete inventory with graphical zoom in zoom out options, mapping of infrastructure to platform and app, identifying data regulations misalignment, identifying poor code practices, code allowing code injection, suggestions for changes in app code with team and effort sizing details, identifying app treatment plan with app disposition details, recommended infrastructure, platform and application related changes to be performed, “AS IS” & “TO BE” diagrams, business and technology quotient matrix details, categorizes them with criticality & project them with customer for approved changes to be done.

Application major dispositions identities are:

Retain, Retire, Repurchase, Relocate: On-Premises, Infrastructure platform and applicable apps

Rehost, Replatform: IaaS, Infrastructure platform, "Lift+Shift" model

Refactor: App modular changes in terms of components of PaaS, containers, serverless, database platform changes, application platform changes from on-prem to cloud hosting services.

Re-architecture: Major app design, architecture, code changes, and depending infrastructure and platform services renewed requirements.

Application disposition reasoning:

In what case Retire, Retain, Repurchase, Relocate, should be tagged to apps:

Retire disposition should be tagged to app when app from business perspective is no more bringing any value and as per its life cycle, it should retire. There must be verification data present, on business as well as usage of the resources provisioned to app and those clearly shows of 0% consumption for long time vis a vis cost it attracts.

Retain disposition should be tagged to app when app from business perspective is still bringing value to business and as per its life cycle definition, it shouldn’t be marked for retirement. Some app are required to be retained as due to legacy aspect where app still needs to be reviewed for redesigning, app can’t be retired due to uncertainty on technology stacks from vendor and requirement on IT ecosystem still and at the same time same app can’t go through migration.

Repurchase disposition should be tagged to app when app is suitable to move to SaaS platform for example SRM to salesforce.com, a HR system to Workday so on.

Relocate disposition should be tagged to app when infrastructure used for it moves to a virtual environment for example from on-prem to cloud.

Certain scenarios clarifications more:

In what case Rehost, Replatform should be tagged to apps:

Rehost disposition is tagged to app which are of legacy nature and business doesn’t have time to keep it live on on-prem, so they do “lift+shift” of its virtual machine layers to cloud. They normally have plan to refactor or re-architecture in cloud latter on.

Replatform disposition should be tagged to app where its few of tiers might go through change like changing database platform to cloud native or other. App tier might be changed to cloud native app hosting services like app service in Azure from on-prem hosting platform.

In what case Refactor, should be tagged to apps:

Refactor disposition should be tagged to app where along with replatform of app tiers like database platform changing, application authentication\authorization solution, app data logging solution, app file transfer solution, app email solution, are changed. These changes must also be supported by cost saving projections of data based on operations stats of the existing app hosting at on-prem or cloud to compare with. Another reason for it, is existing infrastructure layer is not able to support app from capacity, incidents.

In what case Re-architecture, should be tagged to apps:

Re-architecture disposition should be tagged to app where existing infrastructure is not able to match app requirement in terms of compute, ram, storage solutions, & network congestion. Another various reason are app is built with very old technologies and no skills are there to support. App is very big and complex and is a monolithic now where all changes require app to go down which impacts business prospect badly. App workflow and business logic are too old in practice and attracts optimization along with coding practices from best practices aspects where issues like memory leak issues, too many cpu cycles are wasted or too overwhelming which needs optimization at code layer. App makes call to its internal module in unstructured and unoptimized manner.

3. Plan & Design,& approval: Design review with client and approval in agile manner.

4. Track changes: Manage decisions in steering meeting and track changes in agile accepted tool by all stakeholders.

5. Implementation & Execution: Implement approved changes in lower environments first and then production.

6. Follow usual process: Review, identify, plan, design, do to bring CIP (continuous improvement plan).

What are modernization tools we use for modernization?

There are multiple modernization tools used to assess infrastructure, platforms and apps along with its tiers which can be summarized below:

Infrastructure & platform tools: txture, & cloud native assessment tools\services

App tools: CAST, & cloud native assessment tools\services

What are common implementations for modernization?

There are many implementations of apps\tools modernization, however few to name are:

1. App authentication from windows directory services to “alwaysOn” cloud directory services.
2. Fixing apps authentication\authorization using open userid\password stored in app code.
3. Modernizing app data logging services from on-prem to cloud storage services.
4. Modernizing app to use cloud native cache solution.
5. Apps database platform services migration from one technology to another for example, Oracle to MySQL\PostgreSQL, MySQL to NOSQL etc
6. Apps modernize to redesign data architecture to benefit from SQL, NOSQL, NEWSQL & Data Lakes services available on cloud and consuming OLTP aspects alongside OLAP as & when required.
7. Apps modernize to redesign data architecture to offer rich data marts available to app services from structed database system and unstructured database system to accelerate AI and Machine learning aspects.
8. Apps modernize to ensure data availability to customer as their base in cost effective and optimized technology services design.
9. Apps email services modernize to cloud native or third-party email services tools\services.
10. Re-architecture of monolithic apps into microservices.

What are the major issue\challenges & approach to fix across major services during or post modernization?

Following issues\challenges and their fixes can be considered noticing latest technology boom in the market:-

1. How to deal with or what happens with in parallel modernization of applications while going through incremental app modernization?

Challenges:

Getting agreement of all stakeholders for app specific module downtime during app modernization.

Challenges related to new app integration as being deployed in parallel.

Fixing techdebts.

High cost of running parallel infrastructure and platform services.

Maintenance of namespace used for app and labels for deployment.

 Considerations:

              Incremental app modernization is one of the best approach available as of today to support Microservices architecture model.

              Careful planning and designing of app and team awareness activities help with incremental and in parallel on-going modernization for apps help to keep all stakeholders on same page.

1. What kind of issues come when there is mesh architectural\topological model is there?

Challenges:

       Maintaining mesh architectural is in-itself a big challenge as it involves high connections management,

       Costly compared to other topologies like star, bus, point to point.

       High power requirements as all nodes required to be online all the time and load sharing.

       High risk of redundant connections.

       Brings complexity.

Considerations:

      This architecture selection must be thoroughly thought through.

1. What kind of issues come when the application is hosted on Kubernetes?

Challenges:

       Common issues like spiking memory, cpu.

       Pod evictions & container crashes.

       Common shared storage services availability issues.

       Label selector mismatch.

       Cluster fault tolerance solution.

       Misconfigurations at Pods for infra-allocations.

Considerations:

       Enable capacity and incident matrices data collections for short and long time for analytics.

Custom observability solution and usage of Prometheus to check capacity and incidents to plan for permanent solution.

1. What are observability solutions for app?

       Challenges:

              App requirement to function across multiple vendors\clouds and datacenter.

              App specs on multi tech stack

              App consuming multi-infrastructure & platform services provider.

              End to end app observability solutions is limited in market as of now.

       Considerations:

              End to end app observable solutions even though limited, however potentials are more from Dynatrace, Grafana, AppDynamics, Service-Now

Custom observability solution should be developed using custom script, integrating with enterprise solution tools which enable custom workflow and orchestrators with trigger & exit options. Custom script must be standardized and approved organization architecture board. This will enable custom monitoring, logging, storing & analytics abilities for sharp observability solutions.