Category: General
Posted by: bagheljas
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.

03/30: SixR

Category: Buz Words
Posted by: bagheljas
Enterprise Applications Rationalization (EAR) produces an Applications Disposition Plan (ADP) for starting or continuing an enterprise Journey 2 Cloud(J2C). The Applications Disposition Plan refers to the following SixR:
  • Retire: Either the Business Function can be served by another Application in the Portfolio or Not in Use
  • Retain: Presently Optimized keep As is or Not in Scope or No Business Value in Changing Deployment
  • Rehost: Lift-n-Shift or Tech Refresh to Infrastructure As a Service(IaaS) Deployment
  • Replace: Replace the business function with Software As a Service(SaaS) Deployment
  • Replatform: Replace the systems architecture with Function As a Service(FaaS), Platform As a Service(PaaS), or Container As a Service(CaaS) Deployment
  • Rewrite: Rewrite with Cloud Native, or Open Source Architectures and Technologies
Category: General
Posted by: bagheljas
Category: General
Posted by: bagheljas
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.
Cloud Native Application Architecture Pillars
  • 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.
Category: Buz Words
Posted by: bagheljas
infrastructure Technology Outsourcing Partner (iTOP) - Partner works with the enterprise infrastructure owners to co-create the standard infrastructure Technology services for the enterprise.

infrastructure Services Innovation Partner (iSIP) - Partner takes a multi-step approach. First, baseline the business roadmap. Second, baseline the roadmap of the applications in alignment with the business roadmap. Then, the partner develops the enterprise infrastructure services catalog in collaboration with business, applications, and infrastructure owners for business agility. The catalog is either composite in nature built using standard infrastructure services or custom-built services enabling business innovation and agility.
Category: Technologies
Posted by: bagheljas
RedHat OpenShift availability on IBM Z opens up the Economical door for the Enterprise Applications Modernization with IBM Z. RedHat OpenShift capability of deploy once and run anywhere provides the opportunity to the CIOs to deliver the flexibility to Switch Economically either Server Platform or Cloud providers as industry evolve. In next 10 years, we will experience and benefit from the brand new usage of the IBM Z Server platform.

First, deploy distributed workloads on IBM Z that needs unmatched uptime and performance that is not economical on x86 server platform. Second, let the IBM Z provides the side by side deployment capability to deploy Windows and Linux Virtual Machines and Containers workloads using RedHat OpenShift on IBM Z for the economical iterative application modernization.

The core feature "Deploy Once and Run Anywhere" of the RedHat OpenShift enables users to switch to the industry leading platform providers anytime and anywhere.
Category: General
Posted by: bagheljas
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.
Category: General
Posted by: bagheljas
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)

Enterprise Automation Journey

Category: Technologies
Posted by: bagheljas
Microsoft Azure Architect Technologies & Design
Category: General
Posted by: bagheljas
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.

Cloud Responsibility Model

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.