A guide to Application Digital Transformation ( Cloud & On-Premise) — Part 1, 2

Digital Transformation & Cloud are the buzz words in IT for last 4–5 years and after COVID, the Remote way of work (Infrastructure and Resources), the momentum increases multi-fold. The pandemic resulted organizations to think modernizing their online capabilities and that too at a scale which were never imagined before invention of the Cloud.

So, with the above context, let’s begin.

In this article, I will break the Application Digital Transformation Journey in 3 Parts and majority of the topics are applicable for both on-premise and Cloud.

Part 1 (“Preparation”) and Part 2 (“Program Management”)are covered in this blog.

Part 3 (“Solution Architecture”) is covered in the next post.

I remember 8 years back, in Jan 2013, when I started my journey of application modernization (“Digital Transformation” term was not coined then ), I was very excited to learn something new / deliver something great. I feel the same excitement to share my learning / experience with you all.

Digital Transformation Segments

Part 1 — Preparation for Transformation

1. Identify Reason for Transformation (Objective / Business Driver)
2. Describe the Enterprise and Identify Key Stakeholders
3. Identify Business / Technology Capability Assessment
4. Identify Business / Infrastructure / Technology / People Gap
5. Prepare Roadmap for transformation

Part 2- Program Management

1. Find out Program execution methodology
2. Prepare detail execution plan
3. Scope Detailing
4. Time & Budget
5. Build a resilient Team
6. Reporting / Tracking

Part 3 — Technical / Solutions Architecture

1. Sample Web Solutions Block Architecture
2. When to use what services
3. Cloud Best Practices and Principles
4. Azure / AWS Comparison

Cloud Transformation Drivers in high level -

• Rehosting — Also known as “lift-and-shift” involves moving applications without changes from on-premise to Cloud without making much changes. The main driver here Scale i.e. Increase CPU / Memory / Network capacity of the inline infrastructure when user load increases
• Replatforming — Also known as “lift, tinker, and shift,” involves making a few cloud optimizations to realize a tangible benefit. Optimization is achieved without changing the core architecture of the application. Here is also the driver is Scale / Performance
• Refactoring/re-architecting — Refactoring (also known as re-architecting) involves reimagining how an application is architected and developed by using cloud-native features. Refactoring is driven by a strong business need to add features, scale, performance or Improve User Experience that would otherwise be difficult to achieve in the application’s existing environment.
• Repurchasing — Repurchasing involves moving from a traditional license to a software-as-a-service model. For example, a business might choose to implement the repurchasing strategy by migrating from a customer relationship management (CRM) system to Salesforce.com.

Our discussion will be revolved around Refactoring/re-architecting.

Let’s Dig Dipper……………………………………….

Part 1 — Preparation for Transformation

Business Driver / Objective of the transformation

Let’s assume, a popular e-retailer (Forest.com) launched their application in 2004, written in ASP.NET and hosted in their own data center. With time the application / technology became dated to satisfy customer need in terms of feature, Availability, Performance. To stay in business it’s inevitable to Re-Write the applications. How Forest.com proceed with the transformation? Let’s start the journey.

Key Stakeholders in the enterprise

As per TOGAF 9 guideline, below is the stakeholders Map.

For simplicity, let’s identify some key stakeholders and place them the below table.

Business Capability Assessment Output

• Identify business capabilities
• Baseline state assessment of how each capability is realized
• Future state aspiration for how each capability should be realized
• Assessment of likely impacts to the business organization resulting from the successful deployment of the Target Architecture

For our example, let’s consider below as a sample output -

Business Capabilities

The typical business capability model looks like below -

Hmm, Lot of work, huh… Let’s refer below table to make it simple for our example -

Now, it’s time for Gap Analysis with Current State and Future State of the capabilities -

Sample Maturity Definition

Sample Gap Analysis Template

Based on the business assessment, decision has to be made if current infrastructure / Enterprise Architecture can support the business demand or need Technology transformation as well. For the sake of simplicity and to be focused on execution, let’s assume the below -

1. Enterprise has already chosen Azure as the platform for development and deployment
2. Angular / HTML / CSS is chosen as the front end Technology for Responsive / Fast user experience
3. Microservices and Cloud native implementation are to be developed in order to archive the performance goal set by non-functional requirement
4. Service Bus / Topics to be used Asynchronous communication and Azure SQL, Blob, CosmosDB to be used for Data Storage

Transformation Roadmap

1 — is already covered
2 — Skipped in this article
3 — We decided to go for Re-Factoring and chosen Azure as the platform
4 , 5, 7, 8 — We will now discuss that in next segment
6 — We will skip this

There are various great article of Digital Transformation Roadmap, links are below for interested minds -

https://www2.deloitte.com/rs/en/pages/strategy-operations/articles/brief-roadmap-for-digital-transformation-leveraging-business-architecture-to-achieve-superb-results.html

Building a Successful Digital Transformation Roadmap

Part 2 — Program Management

Program execution methodology

Program of this scale should go in agile way. So, this is almost No brainer to choose the methodology as Agile — Scrum.

Prepare detail execution plan

Caution — If the project costing is “Fixed Bid” or “Fixed Price”, Agile-Scrum may not be the right choice. Kanban, Waterfall (Phased approach) could be better choice

Performance / Load testing should be done at least at the end of every MVP, if not during every sprint with production like data. “Performance testing is the last thing of a project” is a wrong concept

Discovery Phase Activities

1 Identify list of features to be implemented in the new application

• Functional Requirements in terms of Epic and Features
• Non-Functional Requirements
• Set Priorities and break them in MVPs

A sample below for our “Forest.com” requirement –

(Responsible — Product Team i.e. Product Owner, Product Manager)

2 Build PODs and Shared Team

• Every POD should have a core Team with members from all Techno — Functional streams like BA, UX, UI, Microservices, DB, QA
• Create specialist horizontal Team who will be Agile and move to the POD where there are Technical challenges or need more capacity
• There will shared Governance, Program Management and BAR Team

3 Onboard Team

• Onboard Governance, Program Management Team
• DO NOT Onboard the entire Team at the beginning rather some key players
• Onboard rest of the Team MVP1 onwards based on volume and clarity of the work. This will help factoring non-utilization at the beginning of the project in turn keep cost under control
• All business / customer / vendor stakeholders should be identified and onboard

Do not Onboard the entire Team at the beginning rather onboard only some key players. Onboard rest of the Team based on volume and clarity of the work. This will help factoring non-utilization at the beginning of the project in turn keep cost under control

4 Infrastructure Readiness

• If the Chosen Platform is Decided, like here Azure, The subscription, Development environment, DevOps Pipeline (Repo, Build / Deployment Pipeline setup) should be ready
• Code Review Checklist first draft / Automated Quality Check plan / Tool should be configured

5 Governance

• Set Escalation Hierarchy ( Including Vendors , if Vendors are involved )
• Create DOR (Definition of Ready) and DOD (Definition of Done)
• Established important Roles in the Program and their collaboration protocols like Weekly status Meeting, Daily Leadership Standup etc

6 Microservices Domain Decomposition and User Experience Framework

Refer Technical Architecture section for details..

Scope Detailing

• Refer Table 2 in Discovery Phase and this has to be detail enough to come up with initial ballpark estimate for Budget
• For Agile-SCRUM Execution the requirement Change is part of process but the Requirement Change should come as part of Quarterly Release Review / Feedback
• All the features should be ordered and MVP #(Most Valuable Product) alignment should be done in Discovery phase itself

FOR Fixed Bid Project — Any Change in Scope during actual execution should be documented and estimated for change management discussion

Time & Budget

Please Refer Scope Details Section which will determine Budget and timing should be derived by business decision and IT readiness

Build a resilient Team

Few points to consider to build a resilient Team keeping budget on check –

1. Team should have right experience mix, location mix (Onshore / Offshore), technology mix with proper onboarding plan as discussed in Discover Phase (Onboard Team) section
2. Let’s look at the sample Resource Mix and their onboarding plan –

Tracking and Reporting

Now this is an ongoing activities, some important points –

• Avoid having multiple tracker, use the Scrum board tool to do tracking and generating reports out of it.
• Since we are using Azure, Azure Scrum Board is an excellent tool to achieve this goal. Few pointers –
• Create Feature / Stories and Due Date field to track feature completion
• Tag phases like “MS / UX Design”, “UI/MS Development” to track stages of the features in case a feature cuts across multiple iterations
• Use Status “Block” and Tag the reason i.e. “UX Wireframe” to indicate a story / feature is blocked due to unavailability of wireframe. “Tag” is an excellent feature though which a lot can be achieved
• Use Devops Board Query / Charts to generate WSR or any on-demand reports for Management / Stakeholders

Use tags wherever possible, Tag is an excellent feature to generate reports

A sample graphical report generated out of Azure Devops Scrum Board

Please refer Part 3 (“Technical Solutions”) to read the complete blog.