Introduction
Enterprise Applications Rationalization is a process to create business-driven application system architecture. That demands continuous input and collaboration across business, technology, and operations. We often find that enterprises lack support from business owners for the Enterprise Applications Rationalization. The Applications Disposition Strategy from applications architectures and runtimes only is a recipe for disaster down the line.



So What?
Enterprise Applications Rationalization is the mission-critical journey for any enterprise. Not doing it can put an enterprise in the same boat as Aol and Yahoo in a matter of time. The III-Phase approach enables an enterprise to stay relevant in the marketplace with the end-to-end alignment from a business model to the application runtime.
Phase-I:
Identifies Initiatives to adopt technology innovation to prepare for startup disruption and improve the competitive landscape.
Phase-II:
Build roadmaps for Business, Applications, Systems, and Enterprise Architecture for delivering Phase-I initiatives and issues solutions.
Phase-III:
Enterprise Applications Portfolio mapping into Retire, Retain, Replace, Rehost, Replatform, and Rewrite (SixR) in alignment with the objectives established in the previous Phases.

The Cloud Native Application Architecture is the leading mainstream application architecture to stay relevant for 2020 & beyond. The key business drivers for Cloud Native Application Architecture are:

• Speed of Deployability of Everchanging Users Needs and Industry Innovation
• Economical Application Experimentation and Operations & Maintenance
• Ability to Utilize Best of Breed Technology, Platform and Framework and Adopt Next One Leading in Industry

The Cloud Native Application Architecture Pillars are identified in the diagram below to develop and deliver an Enterprise Could Native Application Architecture Strategy and Solution.

• Micro Services - Services based application design pattern that creates end to end loosely coupled services also known as micro services to build an application. Each micro service is expected to bind by the service contract of the function it delivers at agreed performance and availability. Micro Service Owner is empowered to pick the best of breed technology, platform and framework suited for delivery of the function. Each service maintains its own independent software release cycle and run time environment for end to end autonomy. The end to end Autonomy is the key to receive true benefits of the Micro Services and may require Enterprise Architecture changes not just implementing an application utilizing fine grain services.
• Serverless & Containers First - Lightweight run time environment and/or compute resources are mission critical for successful Micro Services based Application Design and Delivery. It is cost prohibitive to live with traditional run time environments that can deliver micro services autonomy. One must think Serverless & Containers first or have business justification to pick compute deployment model otherwise as a leading practice. Enables portable deployments that are not tide to an operating system and server platform.
• Everything as Code - In other words, plug-in automation everywhere just not for software release. Mutable deployments are critical for an efficient cloud native application architecture. Package everything as code in one package for infrastructure, application run time, application deployment, testing, user acceptance, security & compliance, and monitoring to deploy and scale application services at the cloud speed economically.
• DevOps and Continuous Integration & Continuous Delivery (CI/CD) - DevOps is all about bringing end to end software release cycle under single leadership at the first line manager and automation to deliver the software to end users. This may require changes to Organization Structure and Enterprise Architecture. It is a leading practice to create CI/CD pipeline for each micro service of an application to provide Micro Services Autonomy. The first line manager now got the ownership and team with skills that can design, build, deliver and support the application service at the cloud speed.
• Application Programming Interface (API) Economy - Expose organization's digital services and assets through API in a controlled way for ease of integration between partners and applications, minimize duplication and develop & deliver new capability at the cloud speed.
• Artificial Intelligence for IT Operations (AIOps) - Use the team human resources to perform high value services then spending cycles for typical mundane task that could be automated to maintain and support your application operations. Send logs and events into a system that can analyze, learn and identify issues reactively, proactively and predictively, and has the ability to perform the resolution for the mundane repeatable tasks by augmenting intelligence to your team supporting application operations.

Disaster Recovery (DR) Deployment Models Convergence is an expected change with the innovation in Cloud and Automation. In traditional implementations, the DR deployments options are Fault Tolerant, Auto Failover, Coordinated Fail-over and Backup & Build. The Cloud Native Applications Disaster Recovery will be either Fault Tolerant or Backup & Build.

The Auto Failover will converge into Fault Tolerant and the Coordinated Fail-over will converge into Backup & Build Deployment Model(s). Any Digital transformation is incomplete without the Disaster Recovery (DR) Deployment Models Convergence.

Brief overview of the Disaster Recovery (DR) Deployment Models can be found at https://secure.baghel.com/index.php?itemid=129.

Release Automation

• Continuous Integration, Deployment and Delivery - Blue Green and Canary Deployment, and A/B/C Testing
• Testing Automation - Unit, QA, Performance and UAT, and Security & Compliance

Resource Provisioning

• Procure and Retire of IT Services
• Baseline Builds and Configurations

Service Management

• Optimization - Auto Stop, Start and Sizing
• Auto Incident, Change and Problem Resolution - AI Ops (Reactive, Proactive and Predictive)

One needs to carefully plan and understand the Cloud Responsibility Model aka Shared Responsibility Model to ensure that there is no gap in the services needed to run the operations smoothly. The cloud deployments by default doesn't take over all the responsibilities and ownership necessary to run business digitally. The Cloud Responsibility Model below gives you an out of box responsibility framework for a typical deployment model types. It is a leading practice to start with out of box shared responsibility model but build a comprehensive Responsibility Assignment Matrix aka RACI with the Service Provider before going live in the new Cloud and/or Outsourcing Managed Services Model.

The Security Solution needs to account for the solutions for each layer described in the diagram. In specialized cases, one can assume risk but in most use cases, one should identify and implement solutions for the common threats to complete the security solution. Defense in depth is all about having security protection at multiple layers. The Security Model can serve as the point of reference when we are working on the Security Solution Design.

IP Address is also known as Internet Protocol Address. The Internet Protocol Address assignments are managed by the Internet Assigned Numbers Authority (IANA). IANA has divided the IP Addresses into two groups. First named as Public IP Address and second named as Private IP Address. The Public IP Address has to be unique in the whole world. Hence, the Public IP Address is routable to the internet. The Private IP Address is reserved to build a private network controlled by the owner of the private network without coordination with IANA and the Private IP Addresses are not unique in the world. Hence, the Private IP Addresses by default is not routable to the internet.

IANA has reserved the following IP addresses to create a Private Network: Class A: 10.0.0.0 to 10.255.255.255 Class B: 172.16.0.0 to 172.31.255.255 Class C: 192.168.0.0 to 192.168.255.255 The table provides a quick guide for sizing Virtual Networks/SubNets. The Virtual Networks and SubNets are usually configured in Classless Inter Domain Routing (CIDR) notation (x.x.x.x/8, x.x.x.x/16, ... x.x.x.x/24). The largest possible Virtual Networks/SubNets is 10.x.x.x/8 and the smallest possible Virtual Networks/SubNets is 10.x.x.x/30. It is a leading practice to consider that we keep the minimum size of the Virtual Networks/SubNets at 3x plus level. While x is the size for the proposed Virtual Networks/SubNets Go-Live requirements. Please note that hosting or Infrastructure as a Services(IaaS) provider may reserve additional IP Address in Virtual Networks/SubNets that one need to adjust and align for their Private Network Design.

Disaster Recovery Solutions design is driven by the following recovery objectives:

• Recovery Point Objective: Worse case data loss is acceptable for applications for a disaster event.
• Recovery Performance Objective: Application need to perform at the same level as primary site or we can limit user access or ok to have degraded performance for applications if disaster happens.
• Recovery Functionality Objective: Functionality of applications needed at same level as primary site or can they operate with limited functionality.
• Recovery Location Objective: Location characteristics such as power grid, distance relative to primary sites and corporate offices
• Recovery Time Objective: Worse case of Time to recover for applications for a disaster event
• Recovery Redundancy Objective: Defines the redundancy objective for the Disaster Recovery Site such as same as Primary Site or certain layer as production and while others have no redundancy

We often find that these objectives together help us define DR tiers such as Platinum, Gold, Silver and Bronze to fit into a budget to deliver DR capability for an enterprise.

• App to App dependency (Internal and External) needs protocol transformation for cloud deployment
• COTS products current license is not supported for cloud deployment
• Gaps in Application grouping and Sequencing also known as Wave Plan and Detailed Migration Plan for each wave
• IP based configurations that sometime even hard coded in the application code
• Application platform components clustering protocol not supported in the cloud
• App to Infrastructure dependency needs architecture transformation for cloud deployment
• Application platform components and underlying middleware & operating systems has direct binding with the server hardware platform
• Application system architecture needs to be revised for matching the current performance baseline
• User functionality and experience impacts by network latency sometime needs to be addressed by re-design of the application architecture
• Transformation of proprietary implementation of Load Balancers and Security Controls in WAF, Firewall, IPS/IDS etc.
• Transformation of services/systems deployment life cycle management tools and processes such as monitoring, backup and recovery, automation (config, build, patch and deploy), ITIL etc.

Disclaimer

The views expressed in the blog are those of the author and do not represent necessarily the official policy or position of any other agency, organization, employer, or company. Assumptions made in the study are not reflective of the stand of any entity other than the author. Since we are critically-thinking human beings, these views are always subject to change, revision, and rethinking without notice. While reasonable efforts have been made to obtain accurate information, the author makes no warranty, expressed or implied, as to its accuracy.