Application Rationalization
An application is a:
Software which serves a business purpose.
Applications are a must for any business. They enable business functions, automate tasks, provide a platform for implementing processes, deliver business information and insights, and help organizations meet their needs. Your organization may have hundreds of applications in many different categories, including but not limited to channel, core, business integration and data applications.
Applications are deployed on one or more Stacks. There are several types of stacks e.g. middleware, database.
Application Lifecycle
An application goes through many phases in its lifecycle. These are as follows:
Plan - developing a detailed business case for application
Phase in - gradual induction of the application
Active - when application is fully phased in and being used for the intended business purpose
Planned phase out - when a business case is developed to discontinue using the application
Phase out- when application is being withdrawn from service
Decommission - when application is fully withdrawn from service. An application may be moth-balled for later use (stop using but keep it in good condition so that it can readily be used again) or archived to a less frequently used infrastructure.
This is often called 'cradle-to-grave' application lifecycle management.
Application Categories
Application can be categorized by the type of function they support. An example of categorization is below:
Channel Applications - Points of interaction with customers – physical and digital
Sales and Service Applications - Understand the needs of the customers and build business relationships
Business Integration Applications - Enable business, operations and IT to speak the same language; critical for interconnections between other layers in the model
Assembly Applications - Package price and present banking products and services through Sales and Services layer
Manufacturing Applications - Define and maintain the Bank’s products and services, and handle transaction processing
Corporate Core Applications - Support business applications, shared services and enterprise resource planning
Customer Information Applications - Complete view of customer and involved-party information, which is structured, complete, and current
Reporting and Analytics Applications - Regulatory and Business reporting capabilities
Data Management Applications - Seamless flow of information within and between business units within the Bank as well as external parties
Technical Applications - Non business facing IT applications supporting above layers
Additional application categorization approaches include pace layers as follows:
System of Innovation
System of Differentiation
System of Recored
Another approach to categorize applications is below:
System of Engagement - systems designed to interact with Customers, Employees and Partners
Business Hub - layer that decouples systems of engagement from the limitations or systems of record
Data Hub - layer that enables efficient management of increasing data –structured and unstructured
System of Record - store and process core business data
Integration Hub - supports standardized modes for interchange of data and services among internal, external parties as well as business partners
Analytics Hub - provides foundation to understand client needs
Application Reference Architecture
Application reference architecture provides a template solution for an application architecture for a particular domain. For example reference application architecture of banking industry provides a template for application types in that industry.
Application Rationalization
Investment in information technology is steadily increasing in many organizations, leading to an increase in the number of applications deployed. As the application portfolio grows and consumes an ever-increasing portion of IT 's budget, the organization must assess whether these applications meet business needs and whether they are running on the right technology stack. This process is called application rationalization.
the action of making IT more efficient, especially by dispensing with superfluous spending on applications
Application Rationalization process steps:
Select eligible applications, such as applications in a portfolio or applications that relate to a business capability.
Define criteria for business and technical evaluation.
Identify stakeholders to respond to the questionnaire.
Determine the total cost of ownership (TCO)
Evaluate the business fit score
Evaluate the technology fit score
Prepare the matrix
Triage applications based on degrees of urgency to solve the issues
The end result of Application Rationalization process is presented as a matrix as follows:
Some common Decision Frameworks are below:
Continue to Invest
Invest
Retain
Reward
Revisit from Business Perspective
Tolerate
Re-fresh
Review
Revisit from Technical Perspective
Migrate
Re-Tool
Refresh
Not required
Eliminate
Replace
Remove
Following are some of the application Refresh or Migration approaches:
Do Nothing - maintain the status quo. Existing pain points
Modify Target System
Extend - build new capabilities in the target system using same code base and architecture
Re-host - lift and shift or move the application as it is to cloud. No code changes are done
Re-platform - lift and reshape the system for a new platform, typically cloud. Minimal code changes are done and code structure and features are maintained.
Refactor - leverage cloud to renovate target system to improve adherence to NFRs. Significant code restructuring and optimization is usually required to remove technical debt with minimal changes in external behavior
Rearchitect - or reengineer the application. Significant transformation in application architecture and code to fully exploit the capabilities of new platform, typically cloud.
Append - add solutions from third party vendors into the target system
Consolidate - merge two or more platform into one
Replace Target System
Re-Build - build from scratch as cloud native MSA based application while maintaining its scope and specifications.
Buy COTS - on a best of breed or best of brand strategy, typically a SaaS product
Rent - migrate to a commercial vendor product with white labeling
Engine 1 vs Engine 2
Engine 1 is your current business model and current capabilities, and it should be continuously improved and risk should be carefully managed;
Engine 2 is the platform for new growth opportunities and business models that are separate from Engine 1. Its purpose is often digitization involving experimentation, agility, and creativity. Typically a cloud based option.
Guidelines
Define clear scope and focus on business, IT and cost perspectives
Engage business and technology stakeholders: collaboration is the key
Be aware of time and budget restrictions: be efficient
Focus of out-of-date applications, those with quality issues and technical debt, and hight total cost of ownership
Deep dive in only those applications that need active intervention
Perform regular review of applications: it is not a one-time activity
Burning Platform
The term 'Burning Platform' is often used for applications with certain urgent problems. It originates from the Piper Alpha oil platform accident in the North Sea in 1988. The main cause of the accident was the failure to address system problems in a timely manner, which were ignored for over a decade. The purpose of application rationalization is to detect burning platforms and address the problems before they get out of control.
Application Hosting
Application can be hosted on variety of different infrastructures. Some of them are below:
Desktop - on user PC, laptop or device
On-Site - in organization's own datacenter
Hosted - in a third-party datacenter
Private Cloud - on the cloud dedicated to the organization
Public Cloud - on the cloud which is shared with other organizations
Hybrid Cloud - on a combination of both private and public cloud
Software-as-a-Service (SaaS) - on the software service providers cloud
Managed Service - when managed by a managed service provider
Application Total Cost of Ownership (TCO)
TCO is a forward-looking concept based on cash outflow. It is typically calculated as the total projected outflow of funds for application selection, implementation, maintenance, and modification. The time horizon for TCO is usually 5 years. These costs include the following:
Selection costs - costs associated with the conceptual and discovery phases of the project. They include the cost of professional services for project managers, subject matter experts, business analysts, and architects, as well as time spent by stakeholders and cost of performing a proof-of-concept.
Implementation costs - costs associated with the design, development and implementation phases of the project. They include the professional services mentioned above as well as software development, testing, implementation costs, software license acquisition costs, hardware or infrastructure costs.
Support costs - costs related to the operational or operating phase of the application's lifecycle. This includes license support or subscription costs, support staff labor costs, or managed services costs.
Change costs - costs associated with ongoing changes. They include costs similar to implementation costs.
Application Licensing Models
Rent - a periodic subscription fee is paid for using the software. SaaS applications are generally licensed under this model
Buy - a one-time upfront payment is made to purchase the licenses and a periodic, usually annual, support payment is made to ensure support and upgrades
further reading License types
Technical Debt
Last updated
Was this helpful?