Rating

In the Rating section, enter subjective measurements that reflect the business view of the application. These measurements are relative to the overall enterprise application portfolio.

Users assigned one or more of the following roles can view the data in this section: Business Owner, Technical Owner, Respondent (when more information is requested), or SME. Users assigned one or more of the following roles can edit the data in this section: Business Owner, Technical Owner, or Respondent (when more information is requested).

Figure A-8. Application Rating section

Table A-8. Application Rating fields

Field

Description

Relative Cost

The total cost of the application compared to other applications in the portfolio (including licenses, underlying hardware costs, minor enhancements, and support).

  • 0 - Least expensive

  • 1 - Inexpensive

  • 2 - Less than average

  • 3 - More than average

  • 4 - Expensive

  • 5 - Most expensive

Relative Size

The size of the application compared to the size of the typical application in the portfolio.

  • 0 - Extra small

  • 1 - Small

  • 2 - Smaller than average

  • 3 - Larger than average

  • 4 - Large

  • 5 - Extra large

Operational Stability

The reliability and dependability of the application during required operational hours at required locations.

  • 0 - Most unstable

  • 1 - Very unstable

  • 2 - Slightly unstable

  • 3 - Fairly stable

  • 4 - Very stable

  • 5 - Always stable

Maintainability

The upkeep of the application compared to other applications in the portfolio.

  • 0 - Impossible to maintain

  • 1 - Very difficult

  • 2 - Some difficulty

  • 3 - Occasional difficulties

  • 4 - Easy to maintain

  • 5 - Simple to maintain

Complexity

The complicatedness and intricacy of the application compared to other applications in the portfolio. Complexity may be related to objective measurements such as the size of the application or the number of connections to other applications.

  • 0 - Extra simple

  • 1 - Simple

  • 2 - Simpler than average

  • 3 - More complex than average

  • 4 - Complex

  • 5 - Extra complex

Change Frequency

The number of times the system changes relative to the amount of change requests and incidents.

  • 0 - Very rarely

  • 1 - Infrequently

  • 2 - Less than average

  • 3 - More than average

  • 4 - Frequently

  • 5 - Excessively

Functional Completeness

The satisfaction of business requirements.

  • 0 - Needs the most work

  • 1 - Needs some work

  • 2 - Needs a little work

  • 3 - Has many features

  • 4 - Has most needed features

  • 5 - Has all needed features

Flexibility

The ability to modify the application when requirements change (for example, changes to standards, compliance, or regulations).

  • 0 - Rigid

  • 1 - Great effort to adapt to changes

  • 2 - Significant effort to adapt to changes

  • 3 - Some effort to adapt to changes

  • 4 - Little effort to adapt to changes

  • 5 - Adapts to changes through configuration

Interface Complexity

The changes needed to integrate the application with other applications.

  • 0 - Self contained (standalone)

  • 1 - Few and simple

  • 2 - Some with average complexity

  • 3 - Some more complex

  • 4 - Many

  • 5 - Many or most complex

Documentation

The completeness of the user documentation.

  • 0 - None

  • 1 - Little

  • 2 - Some features

  • 3 - More features

  • 4 - Most features

  • 5 - Complete

Scalability

The ability of the application to support fluctuations in demand.

  • 0 - Cannot scale to expected needs

  • 1 - Great effort to scale to expected needs

  • 2 - Some effort to scale to expected needs

  • 3 - Little effort to scale to expected needs

  • 4 - Scales to expected needs

  • 5 - Meets expected needs

Performance

The ability of the application to meet performance goals (for example, response time under maximum load or time to completion).

  • 0 - Never meets goals

  • 1 - Seldom meets

  • 2 - Meets less than average

  • 3 - Meets more than average

  • 4 - Usually meets

  • 5 - Always meets goals

Availability

User accessibility of the application during required operational hours.

  • 0 - Not available when needed

  • 1 - Not available when many need it

  • 2 - Not available when some need it

  • 3 - Available when some need it

  • 4 - Available when many need it

  • 5 - Available when needed

Meets SLAs

The ability to meet service level agreements or implicit expectations and needs.

  • 0 - Never meets

  • 1 - Seldom meets

  • 2 - Meets less than average

  • 3 - Meets more than average

  • 4 - Usually meets

  • 5 - Always meets

Size of User Base

The number of users compared to the number of applications in the enterprise.

  • 0 - Extra small

  • 1 - Small

  • 2 - Smaller than average

  • 3 - Larger than average

  • 4 - Large

  • 5 - Extra large

Data Consistency

The alignment of the application's data model with enterprise and industry standards.

  • 0 - Uses custom data formats and definitions

  • 1 - Mostly custom

  • 2 - Some custom

  • 3 - Some standard

  • 4 - Mostly standard

  • 5 - Uses enterprise standard data formats and definitions

Data Integrity

The validity and consistency of data contained in the application. For example, are all dates entered in a mm/dd/yy format and does each date include all attributes?

  • 0 - Data errors and inconsistencies permeate the system

  • 1 - Many data errors enter the system

  • 2 - More than average data errors

  • 3 - Few data errors enter the system

  • 4 - Seldom data errors enter the system

  • 5 - edits and validations ensure consistent data values throughout

Data Redundancy

The profusion of the same data in multiple data sources distributed across the enterprise.

  • 0 - Highly redundant with other data sources

  • 1 - Many redundant elements

  • 2 - Some redundancy

  • 3 - Few redundant elements

  • 4 - Minimal redundancy

  • 5 - No redundancy with other data sources

Vendor Financial Health

The financial soundness of the vendor.

  • 0 - Bankrupt

  • 1 - Questionable

  • 2 - Below average

  • 3 - Above average

  • 4 - Strong

  • 5 - Rock solid

Vendor Competition

The maturity of the competitive landscape and the availability of alternate vendors.

  • 0 - No competitors

  • 1 - Emerging competitors

  • 2 - Some competition

  • 3 - Growing competition

  • 4 - Alternatives widely available

  • 5 - Commodity

Vendor Product Plans

The maturity of the application and if the enterprise affects the design process.

  • 0 - Off maintenance

  • 1 - Maintenance only

  • 2 - Occasionally updating

  • 3 - Actively updating

  • 4 - Plans aligned to needs

  • 5 - Design partner

Business Criticality

The importance of the application to the success and survivability of the business.

  • 0 - Least critical

  • 1 - Slightly critical

  • 2 - Less than average

  • 3 - More than average

  • 4 - Critical

  • 5 - Highly critical

Revenue Impact

The effect of the application, either directly or indirectly, on revenue.

  • 0 - None

  • 1 - Little

  • 2 - Some impact

  • 3 - More impact

  • 4 - Great impact

  • 5 - Highest impact

Competitive Advantage

The gain this application provides compared to other vendor's similar applications.

  • 0 - None

  • 1 - Little

  • 2 - Some advantage

  • 3 - More advantage

  • 4 - Great advantage

  • 5 - Dominance

Customer Visibility

The accessibility of the application to the customer.

  • 0 - Internal facing

  • 1 - Some customer impact

  • 2 - Some customer interaction

  • 3 - Customer facing

  • 4 - Primary customer channel

  • 5 - Global customer dependence

Expense Reduction

The decrease in costs when the application is used.

  • 0 - No impact on expense

  • 1 - Little impact on expense

  • 2 - Some impact on expense

  • 3 - More impact on expense

  • 4 - Expense containment

  • 5 - Major expense reduction

Manual Workarounds Available

The availability of manual processes to accomplish the same business function.

  • 0 - No

  • 1 - Few features

  • 2 - Some features

  • 3 - Many features

  • 4 - Yes

  • 5 - Yes and tested

Security Risk

The liability of the application in regards to access and security.

  • 0 - Conforms to security best practices

  • 1 - Implements standard security practices

  • 2 - Provides some degree of access and data security

  • 3 - Provides some degree of access or data security

  • 4 - Provides little security protections

  • 5 - No security protections

Architecture Risk

The liability of the application in regards to the architecture defined by the organization.

  • 0 - Conforms to architecture best practices

  • 1 - Adheres to enterprise standard practices

  • 2 - Partially adheres to enterprise standard practices

  • 3 - Minimally adheres to enterprise standard practices

  • 4 - Does not adhere to enterprise standard practices

  • 5 - No architecture standards defined

Technology Risk

The liability of the application based on the technology it utilizes.

  • 0 - Runs on modern, proven, standard technology

  • 1 - Runs on standard technology

  • 2 - Runs primarily on modern, proven technology

  • 3 - Utilizes some non-standard technology

  • 4 - Utilizes some obsolete, non-standard technology

  • 5 - Runs entirely on obsolete technology

Skills Risk

The liability of the application in regards to the availability of users with the ability to run the application.

  • 0 - Skills exist in-house

  • 1 - Skills are readily available in the market

  • 2 - Skills are specialized but available in-house

  • 3 - Specialized skills are somewhat available in the market

  • 4 - Specialized skills are in limited supply

  • 5 - Highly specialized skills are scarcely available in the market

Compliance Risk

The liability of the application based on regulatory requirements and compliance validation.

  • 0 - No requirements or independently audited compliance with all requirements

  • 1 - Conforms to all compliance requirements

  • 2 - Non-compliance identified and correction plans in place

  • 3 - Non-compliance identified but no correction plans in place

  • 4 - Unknown compliance requirements

  • 5 -Non-compliance identified that cannot be corrected

Business Continuity Risk

The liability of the application based on data backups and the availability of a business continuity plan (BCP). The liability may be affected by the criticality of the application to the enterprise.

  • 0 - BCP defined, tested, and operational

  • 1 - BCP defined

  • 2 - Data securely backed up and manual workarounds in place

  • 3 - Data backed up regularly

  • 4 - Data backed up irregularly

  • 5 - No BCP or manual workarounds defined