application planning techniques · project portfolio management information provision authorities,...

Investment planning methodology

Application planning techniques

Gather applications

This section provides specific techniques for gathering applications.

Example information asset register

The table below provides suggested attributes for an information asset register to support the investment

planning process.

Application asset register attributes

Attribute Description

Application name The name of the application

Application purpose What the application does in terms of business functionality

Supporting

technologies

What technologies underpin the application, for example operating system, database, web

server software

Number of users Number of users of the application will equate to the number of direct users exposed to the

application via its native user interface.

It is not the number of concurrent users possible for an application.

It does not include the number of indirect users who access the functionality of the application

through an application programming interface (API) or web services.

The organisation should attempt to provide the number of users, even if this is an estimate.

If an application’s primary purpose is to provide online services, it can be difficult to estimate

the number of users. The following indicators can be used:

State-wide (Queensland) use

Country-wide (Australia) use.

Number of ICT

support staff

Number of ICT staff supporting the application. Where an application is supported externally,

include the number of external staff as well as any internal staff involved in support. Where

staff support multiple applications or technologies, apportion the number of staff between the

applications/technologies. Support staff should also include the number of help desk staff.

QGEA PUBLIC Application planning techniques

Final draft | v3.0.1 | October 2014 PUBLIC of 21


Organisational

coverage

This is a controlled list consisting of :

single site metro

single site non-metro

multi-site metro

multi-site including non-metro.

Scope of use Measures how widely the application is used within the organisation. It can be used by:

an individual, single business unit, or small number of individuals

more than one unit within a division

one division

multiple divisions

all divisions (but not every person in the division)

every person in the organisation.

Scope of use is used in the assessment of Business Impact conducted during assess

activities.

Anticipated end-of-life The date (month, if available and year) in which the application is expected to be at the end of

its useful life. Where the application is likely to be used beyond the end of its depreciation

cycle, the date in which it will last be used should be calculated. However, where such

information is not available, the date in which the application will be written off can be used.

Base product name This is the commercial name by which the off the shelf product is known in the market. For

example, a customer relationship management application configured for your organiation may

be known as CLIENT but the base product is Siebel CRM.

The following estimated costs should also be gathered for each application in the application portfolio.


Capital value/

estimated

replacement cost

Estimated replacement cost (for purchasing and/or building the application) if the application

were to be replaced. If this is not available, the original capital value of the application can be

used.

Operational costs The costs resulting from the day-to-day running of an application, including electricity, air-

conditioning, floor space (where these are available), technical staff, support and operations

staff, but does not include depreciation, licensing or maintenance.

Depreciation costs The costs related to the decrease in value over time of an asset (i.e. for a tangible item of

capital expenditure over its useful life). In calculating the annual estimated cost of operation of

an item of ICT equipment, the amount by which the value of the item has decreased during the

financial year should be taken into account.

Licensing costs Annual charge made by a vendor for the use of an application by the organisation

Maintenance costs The costs associated with the maintenance of any facility, equipment or asset. It includes the

cost of support staff involved in problem identification and repair. It does not include the costs

associated with the development of new functionality and performance enhancement




Development and

enhancement costs

Costs specific to develop new functionality, including performance enhancements, for an

application. This aspect of cost is separated from maintenance costs which relate to existing

functionality.

Annual estimated cost

of operation

This is a derived cost from aggregating operational costs, depreciation costs, licensing costs,

maintenance costs and, development and enhancement costs.

This information may already exist in one or more application portfolio databases, in which case this activity is

one of simple extraction of the data, and validation and completion where necessary. The information required

for this methodology will be a subset of a typical application portfolio.

Classify applications

This section provides techniques to support the classification of applications to a standard application

classification framework. In addition, it provides information that supports the understanding of the implications

of this classification.

When an application is classified to a domain within the Queensland Government application classification

framework (other than the line-of-business service delivery domain), an estimated percentage of usage should

be documented. For an application that is classified under one domain only, the estimated percentage of

usage should be 100%. For example, if application A is classified under the domain of general ledger only, the

assumption can be made that application A is used 100% of the time for general ledger only.

For an application that is classified under more than one domain, an estimated percentage of usage should be

documented. For example, if application B is classified under the budgeting domain and receipting domain, the

usage of this application for each domain may be estimated at 40% of the time for budgeting and 60% of the

time for receipting. This estimate may be calculated based on the proportion of application B’s users in each

domain, frequency of use for each domain or any other appropriate estimation technique developed by the

organisation. All assumptions and techniques used to calculate estimates should be documented.

When an application is classified to a line-of-business service delivery domain, no estimated percentage of

usage is required.

Percentage of usage assists in allocating costs across domains. This information helps the organisation analyse

costs per domain for identifying areas of high expenditures. Cost management strategies can then be put in

place.

Understand application classifications

During development of the application profile classifications of applications to a standard application

classification framework are analysed to develop a course of action which may ultimately lead to initiatives.

The classifications are only preliminary indicators for the organisation in the development of the investment

plan. Outlined in the table below is a description of the possible interpretations and the potential actions that

should be considered for a given set of classifications. It should be noted that actions resulting from domain

analysis of applications may not directly result in initiatives.



Application classification assessment guideline

Classification Classification type Interpretation Course of action

Applications to

the application

classification

framework

Coverage -

Distribution of

applications across

the domains of the

application

classification

framework.

Applications are evenly distributed across the domains

in the application classification framework. The portfolio

of applications assets demonstrates reasonable support

for both the line of business and business imperatives

of the organisation.

No action required.

Applications are concentrated in business domains that

heavily support business imperatives or other domains

that do not directly support the line of business of the

organisation.

Identify opportunities to rationalise applications in

domains that do not directly support the line of

business. Investigate opportunities to replace specialist

applications with applications that have been classified

to a larger number of similar domains or more generic

service delivery domains. Specific investment planning

actions should be documented in the application profile.

Gaps - Domains in

the Application

classification

framework where no

applications have

been classified.

Gaps may be valid - the organisation may not require

applications in every domain.

No action required.

Gaps in particular domains may be more relevant than

others. Gaps are more relevant in domains that directly

support the line of business and business imperatives of

the organisation.

Look for opportunities to increase investment in

domains that directly support the line of business or

business imperatives of the organisation. This may

result in new initiatives.

All new initiatives should be documented in the

application profile.



Duplicates - Multiple

applications have

been classified to the

same domains in the

application

classification

framework.

Duplication in application domains indicates

opportunities to rationalise a portfolio of applications.

Look for opportunities to replace specialist applications

with applications that have been classified to a larger

number of similar domains or more generic service

delivery domains. This may result in rationalisation

initiatives.



Spend per domain -

Proportion of

investment in

applications in each

domain of the

application

classification

framework.

Spend per domain is considered appropriate given the

line of business and business processes conducted by

the organisation. The level of spend per domain is also

appropriate given the value of the applications assets to

the organisation.

No action required.

Spend per domain is low given the high value of the

applications to the organisation.

Invest in strategies to maximise the availability of

application and ensure a high standard of conditions.

Management strategies should focus on minimising the

risk of the application to the business.

Spend per domain is high given the low value of the

applications to the organisation.

Look for opportunities to replace specialist applications

with cheaper applications that have been classified to a

larger number of similar domains or more generic

service delivery domains. Look for alternative platforms

to deliver the application service more cheaply. This

may result in a new initiative.





Charts can be used to analyse classifications. The figure below provides an example of application spend by

domain.

Application Domains by Total Spend

$0 $200,000 $400,000 $600,000 $800,000 $1,000,000 $1,200,000 $1,400,000 $1,600,000

Registrations and Inspections

Information Submission

Inventory Management

Library Management

Public Safety and Emergency Response

Investigations Management

Research

Contract Management

Planning and Governance

Customer Service and Support

Project Portfolio Management

Information Provision

Authorities, Licences, Permits and Aw ards

Scheduling and Bookings

Document and Records Management

Sales Automation

Enterprise Asset Management

Infrastructure and Housing

Sourcing and Procurement

Human Capital Management

Fleet Management

General Ledger

Design and Engineering

Ap

plicati

on

Do

main

Annual Total Spend

Example application domains by total spend

Map applications

This section provides an overview of the element mappings conducted in the application profile and also

includes techniques for analysing the results of these mappings.

The following mappings are undertaken in this stage.



Application mappings

Activity Mapping Used Purpose

Profile

application

Business goal -

application

No Business goals are achieved through activity (business processes) and

underpinned by inputs and outputs (information). Business processes and

information assets are both mapped to business goals. This highlights any

gaps in the overall level of support for business goals. Applications are

subsequently mapped to business processes and information assets. No

additional value can be determined by mapping applications to goals. For

this reason this mapping is no longer used. In previous versions of the

methodology this mapping was used as a proxy for information asset to

goal.

Business strategy

- application

No Strategies are implemented through the implementation of business

processes and information assets. Both of these elements are mapped to

business strategies. Gaps are identified when applications are mapped to

information assets and applications. No additional value can be determined

by mapping applications to strategies.

Business

objective -

application

Yes To validate application support for achieving business objectives.

Objectives are achieved through activity (business processes). Mapping

applications to objectives only adds value if there is insufficient information

collected regarding business processes. This can occur when the scope of

the application artefacts collected is broader than the scope of the

business processes collected.

Business process

- application

Yes To validate application support for business processes or identify business

processes that are not currently ICT enabled.

Information asset

- application

Yes To validate application support for information assets (in either a creates or

uses the information asset capacity) or identify information assets that are

not currently ICT enabled.

Understanding application mappings

The table below provides possible interpretations and courses of action as a result of application mappings.



Application profile mapping assessment guideline

Mapping Mapping type Interpretation Course of action

Business objective –

application

Gap - Objectives

without application

support

This is an indication that some applications may

have been overlooked during the gather phase. This

may be further substantiated by gaps in other

mappings such as application to business process

and application to information asset.

Investigate gaps to ensure that applications have not

been overlooked.

Include any additional applications in the mapping that

were discovered as a result of the investigation.

Gaps may be valid if certain business units and

associated business applications were considered to

be out of scope for the purpose of investment

planning.

Investigate the scope of the applications included in

the gather activities.

If the scope of the business applications and

objectives collected are different, document the gaps

in the application profile and discuss the impact of the

missing applications.

Alternatively, adjust the application artefacts collected

in the mapping so that the scope of the business

applications and objectives collected are aligned.

Gaps may indicate that the objective is a legacy and

the organisation no longer conducts activity to

support the objective.

Investigate gaps to ensure that objectives are not

legacy objectives.

Remove any objectives discovered as a result of the

investigation from the mapping.




Gaps are a likely indicator that the organisation may

have failed to invest in applications that could

provide real strategic value to the business. The

business application to business objective is

important where limited or no business process

information is available. A large proportion of gaps

would indicate a poor level of alignment between the

portfolio of applications and the business strategies.

The organisation may not be able to realise the

objectives with the current portfolio of applications

and investment to shift the alignment of applications

may be required.

Look for opportunities in which investment in new or

existing application support might enhance or

streamline the business processes and functions.

These opportunities may result in new application

initiatives.

Supported –

Objectives supported

by only one

application

This is a normal case. No action required.

Hog – Objectives

with multiple

application support

This is an indication that the organisation may be

investing in applications or application components

that could be retired. Look for ways in which some

applications might be extended to subsume

functions of other applications thereby reducing the

number of applications in the overall applications

portfolio.

Only those applications that support an excessive

number of objectives could be considered hogs.

Before any rationalisation action is considered it is

necessary to investigate the similarities in the

business functions and business processes that these

applications support.

Orphan –

Applications that

support no

objectives


investing in applications that are providing no

strategic value to the business. Unless such

applications are providing operational support (for

example HR and Finance), they should be

considered for retirement.

A high proportion of orphans would generally indicate

a poor level of alignment

Before any retirement action can be considered,

further investigation into the supporting business

functions and business processes is required.




Where the application supports a business

imperative (for example HR and Finance) it may not

necessarily map to a business objective.

Record the orphan application in the application

profile.

Discuss the reasons why the orphan mappings have

been accepted in the application profile.

Unique –

Applications that

support only one

objective

This is a normal scenario however the organisation

should ensure that the portfolio of applications offers

some flexibility and potential for reuse.

Look for other more generalised applications that

might provide this and other functionality and thereby

allow highly customised or specialised applications to

be eliminated from the portfolio.

Mule – Applications

that support many

objectives

This is an indication that the organisation has a key

dependency on this application.

The way in which these assets are managed is

important to ensure that business exposure of these

applications is minimised. The condition and business

impact of these applications should be thoroughly

investigated to ensure that sound management

practices are adopted.

Business process –

application

Gap - Business

processes with no

application support




mappings such as application to business objective

and application to information asset.


been overlooked.






planning.



If the scope of the business applications and business

processes collected are different, document the gaps

in the application profile and discuss the impact of the

missing applications.



applications and business processes collected are

aligned.




This is an indication that the organisation may have

failed to invest in applications that could provide real

operational value to the business.

Look for opportunities in which investment in new or

existing application support might enhance or

streamline the business processes. These

opportunities may result in new application initiatives.

Supported -

Business processes

supported by only

one application

This is a normal case. No action required.

Hog - Business

processes with

multiple application

support


investing in applications or application components

that could be retired. Only those applications that

support an excessive number of business processes

could be considered Hogs.

Investigate opportunities to rationalise the portfolio of

applications. Before any rationalisation action is

considered it is necessary to investigate the

similarities in the business functions and business

processes that these applications support.

Orphan -

Applications that

support no business

processes

Orphans are likely to occur if the full scope of

business processes has not been collected.

Review the scope of business process artefacts

collected to verify that business processes have not

been overlooked.

Include any additional business processes in the

mapping that were discovered as a result of the

investigation.

If orphans are genuine, this may indicate that the

organisation may be investing in applications that

are providing no business or operational value to the

business. Unless such applications are expected to

provide future strategic value, they should be

considered for retirement.

Investigate opportunities to rationalise the portfolio of

applications by retiring assets with no business

dependencies.




Unique -

Applications that

support only one

business process

Applications that support only one business process.

This is a low priority area, however applications will

generally support more than one business process.

Look for other more generalised applications that

might provide this and other functionality and thereby

allow highly customised or specialised applications to

be eliminated from the portfolio.

Mule - Applications

that support many

business processes

This is an indication that the organisation has a key

dependency on this application.

The way in which these assets are managed is

important to ensure that business exposure of these

applications is minimised. The condition and business

impact of these applications should be thoroughly

investigated to ensure that sound management

practices are adopted.

Information asset –

application

Gap – Information

assets which are not

supported by any

applications




mappings such as application to business objective

and application to business process.


been overlooked.






planning.



If the scope of the business applications and

information assets collected are different, document

the gaps in the application profile and discuss the

impact of the missing applications.



applications and business processes collected are

aligned.

Gaps may be acceptable if the asset is not

electronically dependent.

Record the gaps in the application profile.

Discuss the reasons why the gap mappings have

been accepted in the application profile.




If the gap is genuine there may be opportunities to

invest in new or existing applications to support the

information asset.

Identify opportunities to further support information

assets with applications. This may result in new or re-

use application initiatives in the application profile.

Supported -

Information assets

which are supported

by only one

application

This is acceptable. The application may be a single

point of failure for the information asset. Ensure

proper back-up processes are in place. This could

also be an opportunity to become a single source of

truth for the organisation.

The management of the application is important in

these circumstances. The business impact of the

information asset and the applications should be

investigated. The condition of the application should

be investigated to determine appropriate management

practices to ensure that the risk to the business is

minimised.

Hog - Information

assets which are

supported by many

applications

This scenario may indicate multiple sources of

creation and use for the same information asset.

Implement information synchronisation strategies to

ensure that information remains consistent and up-to-

date across all applications in an agreed manner.

If the asset is created in many applications,

consideration should be given to developing a

management strategy for the information asset that

focuses on a single source of truth.

Orphan -

Applications that

support no

information assets

This indicates an incomplete information asset

register. In some circumstances, scoping

inconsistencies between planning phases may

cause this anomaly.

Investigate the information asset artefacts collected to

ensure that all relevant information assets have been

collected.

Include any additional information artefacts identified

as a result of the investigation.

Unique -

Applications that

support only one

information asset

This scenario is acceptable. This mapping indicates

that the application has specific and defined

boundaries in the information it stores.

No action required.




Mule - Applications

that support many

information assets

This is acceptable, however be aware of possible

monolithic applications. There may be opportunities

to become a single source of truth if the application

and the information assets are in good condition.

Mules indicate a high level of dependency on the

asset. The way in which these assets are managed

is important to ensure that business exposure of

these applications is minimised.

The condition and business impact of these

applications should be thoroughly investigated to

ensure that sound management practices are

adopted.

Opportunities to use the application and associated

information assets as a single source of truth should

be investigated.



Assess applications

This section provides specific techniques for assessing the business impact, future business value, condition

and scaled cost of applications.

Assess business impact of applications

The dimensions and recommended assessors of the business impact of applications are shown in the table

below

Recommended assessors: application business impact

Dimension Recommended assessor

Political/legislative impact of unexpected outage or failure Business

Operational impact of unexpected outage or failure Business

Fit for current purpose Business

Frequency of use Business

Scope of use Business or technical

Support arrangements Technical

Specific evaluation criteria and related scores for each dimension in relation to the business impact of

applications are described below.

Evaluation

category

0 1 2 3 4 5

Political/legislative

impact of

unexpected outage

or failure.

No legislative or

legal impacts.

Unlikely to be

noticed outside of

staff. No external

impacts.

Impacts on

external

organisation or

partners business.

Risk of legal

action. Low risk of

government or

ministerial

embarrassment if

outage is long.

Legislative

requirements

unable to be met.

Legal action highly

likely. High risk of

government or

ministerial

embarrassment.



Evaluation

category

0 1 2 3 4 5

Operational impact

of unexpected

outage or failure.

Failures are often

not reported and

only discovered

accidentally. No

impact on client

service.

Help desk receives

one or two calls for

support when

unexpectedly fails.

A few calls logged

with the help desk

when

unexpectedly fails

or calls come in

slowly. Occasional

disruption to client

service.

Many calls logged

with help desk in

first hour when

unexpectedly fails.

Significant

problems

delivering a

service if

unavailable. Client

service slows

somewhat.

Unexpected failure

causes inability to

deliver a single

service, or

significant

problems in

delivering multiple

services. Client

service slows

significantly.

Unable to deliver

multiple services if

unavailable. Client

service ceases.

Fit for current

purpose (of this

application with

respect to the

scope of the

business area it

addresses, not the

scope of the entire

organisation's

business)

Essentially does

not meet business

functionality

requirements.

Meets some

business

requirements, but

not many or does

so poorly.

Meets a

reasonable

number of

functional

requirements, but

needs manual

supplementation

or workarounds.

Meets majority of

business

functional

requirements, but

some functional

areas poorly or not

at all supported.

Reasonably

complete

functionality

(90+%). No

significant

functionality holes

- only bells and

whistles missing.

Full set of

functionality.

Meets all business

needs. No

improvements

required.

Frequency of use Used very

infrequently.

Used regularly but

not every business

day (e.g. only at

month end)

Used each

business day but

not in constant use

- used for small

periods of each

business day.

Used business

hours only.

Used business

hours and public

holidays /

weekends, but not

24 x 7.

Used every day -

weekdays and

weekends. 24 x7.

Scope of use Small Unit or

Individuals.

Multiple units

within a division.

Only one division. Multiple divisions

use it.

Every division of

the organisation

has some use.

Every person in

the organisation.

Support

arrangements

No formal support

arrangements in

place. Staff do

what they can.

Supported by

technical staff, but

is low priority or

best efforts only.

Supported by help

desk and technical

staff business

hours only. No

contingency plans

in place.

Supported by help

desk and technical

staff business

hours only.

Contingency plans

are in place.

24 hour out of

hours support is in

place.

Contingency plans

are in place.

Designed and

implemented to be

resilient of failure.

24 x 7 support.



Assess future business value of applications

The dimensions and recommended assessors of application future business value are shown below.

Recommended assessors: application future business value


Functional utility Business or technical

Business objective support Business

Business imperatives support Business

Legislative and political support Business

Enhanced service delivery Business

Future measurable benefits Business

Future risk reduction Business

Future organisational innovation, change and growth Business

Future fiscal benefit Business

Specific evaluation criteria and related scores for each dimension in relation to application future business

value are described below.

Evaluation criteria and scoring: application future business value

Evaluation

category

0 1 2 3 4 5

Functional utility The application is currently fully utilised with no expectation or requirement for additional future utility.

The application is under-utilised with no identified expectation or requirement for the unused functions.

The application may have additional utility and could be exploited within the organisation.

The application may have additional utility and could be exploited by the organisation or whole of government.

The application has additional identified utility and can be exploited within the organisation.

The application has additional identified utility and can be exploited by the organisation and whole of government.

Business objective support

The application is not linked to business objectives.

The application is linked to less than 25% of business objectives.

The application is linked to between 25% and 49% of business objectives.

The application is linked between 50% and 75% of business objectives.

The application is linked to between 75% and 100% of business objectives.

Business imperatives support (government and legal obligations)

The application is not linked to any business imperatives.

The application is linked to some business imperatives.

The application is linked to most business imperatives.

The application is linked to all business imperatives.



Evaluation

category

0 1 2 3 4 5

Legislative and political support

The application supports no political or legislative requirements.

The application provides some short term support of current political and legislative requirements.

The application fully supports current political or legislative requirements.

The application is required to support expected future political or legislative requirements.

The application is required to support documented future political or legislative requirements.

Enhanced service delivery

The application contributes to decreased delivery of services to customers.

The application is not expected to enhance the current delivery of services to customers.

Quantitative evidence exists to demonstrate that the application may enhance the delivery of services to internal customers.

Quantitative evidence exists to demonstrate that the application may enhance the delivery of services to both internal and external customers.

Quantitative evidence exists to demonstrate that the application significantly enhances the delivery of services to internal customers.

Quantitative evidence exists to demonstrate that the application significantly enhances the delivery of services to both internal and external customers.

Measurable benefits

The application is not expected to provide additional realisable benefits in the future.

The organisation and stakeholders are currently realising some residual benefit from the application.

Anecdotal evidence exists to demonstrate that the application may deliver some realisable benefits for the organisation or whole of Government.

A Benefits Plan or similar assessment exists to demonstrate that the application will deliver future realisable benefits for the organisation and stakeholders.

Risk reduction The application will not contribute to the reduction of business risks.

The application will significantly delay the likelihood of business risks occurring.

The application can be used as mitigation against a business risk occurring. Some residual risk remains.

The application completely eliminates the likelihood of a business risk occurring.

Organisational innovation and growth

The application does not enable change or innovation.

The application provides limited support for enabling change or innovation.

The application enables individuals or business units to quickly respond to opportunities, changes in the operating environment and the changing needs of stakeholders.

The application enables individuals or business units to immediately respond to opportunities, changes in the operating environment and the changing needs of stakeholders.

The application enables the organisation to quickly respond to opportunities, changes in the operating environment and the changing needs of stakeholders.

The application enables the organisation to immediately respond to opportunities, changes in the operating environment and the changing needs of stakeholders.

Improved fiscal outcomes

The application decreases revenues and increases operating costs.

The application is not expected to increase revenue or reduce operating costs in the future.

Qualitative evidence suggests that the application may increase revenue or reduce operating costs.

Qualitative evidence suggests that the application may increase revenue and reduce operating costs.

Quantitative evidence demonstrates that the application either increases revenue or reduces operating costs.

Quantitative evidence demonstrates that the application both increases revenue and reduces operating costs.



Assess condition of applications

The dimensions and recommended assessors of application condition are described below.

Recommended assessors: application condition


Organisational architecture alignment Architect or technical

Queensland Government Enterprise Architecture (QGEA) alignment Architect or technical

Integration Technical

Authentication Security or technical

Maintainability Technical

Portability Technical

Scalability Technical

Availability Technical

Performance Business or technical

Useability Business

Specific evaluation criteria and related scores for each dimension in relation to application condition are

detailed below.

Evaluation criteria and scoring: application condition

Evaluation

category

0 1 2 3 4 5

Organisational architecture alignment

Supports no organisational architecture principles, policies, positions and standards.

Limited support for organisational architecture principles, policies, positions and standards.

Reasonable support for organisational architecture principles, policies, positions and standards.

Meets most or nearly all organisational architecture principles, policies, positions and standards

Queensland Government Enterprise Architecture (QGEA) alignment

Supports no QGEA principles, policies, positions and standards.

Limited support for QGEA architecture principles, policies, positions and standards.

Reasonable support for QGEA architecture principles, policies, positions and standards.

Meets all or nearly all QGEA architecture principles, policies, positions and standards OR if no QGEA standards applicable



Evaluation

category

0 1 2 3 4 5

Integration No support for integration. Manual/paper based.

Minimal - substantial manual intervention required.

Some links, but not complete integration. Integration technology poor.

Some integration, Integration technology sound, OR integration not currently applicable to this application

Reasonable integration, integration technology sound.

Excellent integration support with good integration technology OR Integration will never be applicable to this application.

Authentication No security or audit capability.

Basic password access, no auditing.

Basic password access, some audit capability.

Basic password access, good audit capability OR security not currently applicable to this application.

Better than basic password access. Good audit capability.

Highly secure, biometric access, excellent audit facilities OR Security will never be applicable to this application.

Maintainability Little to no skills available internally or externally. Little to no documentation. If applicable, doesn't comply with corporate coding standards. Difficult to deploy. Manual site-by-site, user-by-user.

Some skills available. Documentation OK. If applicable, some compliance with corporate coding standards. Partially automated scheduled deployment.

High skill levels available internally or externally. Well-documented. If applicable, complies with corporate coding standards. User-initiated or fully automated deployment.

Portability Tightly coupled with supporting technologies. Deploying in another technology environment extremely difficult.

A few components (for example, data source) can easily be deployed in a different technology environment.

Most components can easily be deployed to another technology / environment.

Loosely coupled with supporting technologies. All or nearly all application components can easily be deployed in another technology environment.

Scalability Heavy loads jeopardise system reliability causing significant disruptions to operations.

Cannot easily accommodate heavier loads i.e. new users and/or new sites. Requires total or highly significant investment.

Heavier loads i.e. new users and/or new sites can be accommodated to a certain degree. Pushing beyond threshold limitations lead to performance degradation.

Can easily accommodate heavier loads i.e. new users and/or new sites. Requires little or no significant investment.

Availability Very unreliable - often down or causes data errors. Availability < 95%.

Crashes regularly Reliable, but does require significant outages to maintain.

Reliable and small outages for maintenance. 99.9% or better.

Highly reliable. 99.999% or better.

Performance Significant performance issues.

Occasional performance issues.

Performance is not an issue most of the time.

No performance Issues.



Evaluation

category

0 1 2 3 4 5

Useability Users avoid it whenever they can.

Difficult to use. High number of calls for help from users. Requires significant training.

Moderately easy to use. Moderate number of calls for help from users. Requires training.

Easy to use. Few calls for help from users. Requires minimal training. Help easily accessible.

Easy to use and consistent interface. No or close to zero calls for help from users.

Example application profile template

An example application profile template is located in the IS2 toolbox.

Licence

This document is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0

International Licence. For permissions beyond the scope of this licence, contact [email protected].

To attribute this material, cite the Queensland Government Chief Information Office.

http://www.qgcio.qld.gov.au/products/qgea-documents/547-business/2558-app-profile-template

http://creativecommons.org/licenses/by-nc-nd/4.0/

http://creativecommons.org/licenses/by-nc-nd/4.0/

mailto:[email protected]

application planning techniques · project portfolio management information provision authorities,...

Documents