Application Portfolio

From MIKE2 Methodology

The Application Portfolio documents major systems and their functionality from a high-level perspective. The Application Portfolio is defined during the Organisational QuickScan for Information Development Activity. It is defined at a systems level and any detailed work is done in the Application Development workstream – an Application Portfolio for building new application functionality or rationalizing systems will often be far more comprehensive. it is only explained below in the context of its significance for Information Development. Some of the key information that should be gathered is listed below.

Contents 1 Application Portfolio Model 1.1 Description 1.2 Platform 1.3 Level 1 & 2 Functions 1.4 Application Complexity 1.5 Divisions 1.6 Inter-Divisional Complexity 1.7 Issues & Limitations 1.8 Application Life Expectancy 1.9 System Owners 1.10 Comments

Application Portfolio Model

Instructions

Populate the model Application Portfolio against each of the the criteria described below. Populate this model in a progressive fashion and ideally store content in a tool that can be query and reported against.

Description

Brief statement that gives an overview of the system

Platform

Technologies the system consists of – application, database, operating system, programming language

Level 1 & 2 Functions

This attribute maps the application to the end-to-end process model for both Level 1 (Functions) and Level 2 (Processes). For systems that are repeated across the business, this attribute is repeated for each instance.

Application Complexity

A rating on the complexity of each application. The ratings used are as follows:

• Low - These systems are relatively simple, use a simple database or small number of files and are reasonably well documented. Low complexity systems may also include "black box" systems where support and documentation is provided by a vendor, the product is stable (with infrequent new releases), and there is little to no customisation. These black box systems would generally apply more to areas such as production than to customer-facing or financial systems.

• Medium - These systems are generally more substantial in functionality than low complexity systems or are reasonably simple in functionality but are poorly documented and/or use a number of related databases or files. Off-the-shelf vendor products may be classified as Medium complexity systems if they are generally well documented with some customisation. This classification may also represent a grouping of multiple low complexity applications.

• High - Highly complex systems that use complex data structures, require trained staff to configure and support. It would also include those that are poorly documented and difficult to maintain, whilst containing a significant amount of business functionality. Major off-the-shelf vendor systems that have been heavily customized, have been tailored by the vendor to divisional requirements or for which upgrades would be difficult would likely be classified as High complexity.

Divisions

Divisions/business clusters supported by the system

Inter-Divisional Complexity

Rates the inter-divisional complexity that occurs due to variations in the multiple instances of systems supporting different divisions. This is particularly relevant for organisations that have multiple instances of systems across divisions.

The ratings used are as follows:

• Low – the system is used in 1 division or in exactly the same way in 2 or more
• Medium – there are multiple instances of the system but the differences between divisions are largely configuration changes.
• High – there are multiple instances of the system and there are significant differences in code and configuration of these systems.

Issues & Limitations

Key problems associated with the system

Application Life Expectancy

This attribute may contain the envisaged life expectancy for the system – e.g. whether it will be decommissioned or be part of the strategic architecture.

Ratings may also be assigned to the system in terms of application life expectancy, using the following model:

• Null - Unknown
• Low - This system will be replaced in the near term (< 2 years)
• Medium - This system will be replaced in the long term (2 – 5 years)
• High – Strategic, long-term application (>5 years)

System Owners

Key contacts from a business ownership, technology architecture and operations perspective

Comments

Additional comments related to the system – e.g. point-of-contact, open questions. Ideally, this content is stored in a structured repository as opposed to an unstructured document form. Enterprise Modelling Tools are often used for storing this information. Time for this task may vary greatly depending on the existing artifacts.