Specify the application's attributes

Once an application is in the repository, you can define more details about the applications in the Applications data workbench.

Or you can select an individual application and navigate to its content area and specify and analyze the application in detail. In the data workbench, click the Navigate   button to open the application's content area. Go to the Overview page.

Define the application's basic data.

• Name: (Mandatory) Enter a name for the application that is known to end users. The application's name is typically different than the name of the vendor delivering the application. You can add an abbreviation (3-4 letters) of the name in the Short Name field to use in diagrams and other visualizations.

  vendor

  A vendor is a supplier of components.

• Version: Enter a version number for the application. It is recommended that you document major and minor release versions (<MajorVersion.MinorVersion>). For example, version 2.1 (<MajorVersion.MinorVersion>). You could document patch releases (<MajorVersion.MinorVersion.PatchRelease>) if your organization requires this level of detail.
• Release Status: This is an approval status and typically indicates the level of quality of the information about the application. The release status determines whether an application can or cannot be deleted. Possible values are:
  • Draft: The application has only mandatory data defined.
  • Under Review: The application is documented and being reviewed. An application with this release status cannot be deleted.
  • Approved: The application has been approved by the responsible stakeholders. An application cannot be deleted when it has an approved release status. An application with this release status cannot be deleted.
  • Data imported: The data regarding this application has been imported from an external system. Additional changes may be required to improve the data quality. An application with this release status can be deleted.
  • Trash: The application is no longer valid and can be deleted.
• Authorized User: The user who creates the application is the authorized user per default. This can be changed.

  authorized user

  An authorized user has primary responsibility to maintain the data for an object. Typically this is the user that has created the object. The authorized user as well as members of authorized user groups have write permissions to objects they are responsible for.

• Authorized User Groups: Select one or more authorized user groups that shall have write permissions to the application. All users in the authorized user group can edit the application.

  authorized user group

  An authorized user group is a set of users that have been granted write permissions to an object. More than one authorized user group may be specified for an object.

Define the architecture attributes.

• Architecture Type: The type of architecture infrastructure of the application. Possible values are:
  • Client-Server: The application divides tasks or workloads between the providers and consumers of a resource or service.
  • Cloud-Based: The application runs on SaaS cloud environments. The cloud infrastructure could be local or remote to the organization.
  • Distributed: The application runs on multiple computers within a network. The network boundary can extend from private intranets to public clouds.
  • External Webpage: The application is an external resource represented through a web link.
  • Mainframe: The application is used by large organizations to carry out critical processing tasks such as bulk processing of data, transactions, planning or statistical activities.
  • Stand-Alone: The application is a self-contained application that does not rely on external entities to complete a task.
  • Unknown: The architecture type has not yet been assessed.
• Authentication: The authentication method used for the application. Possible values are:
  • Autonomous: The application supports autonomous methods such as Direct Autonomous Authentication (DAA) for authentication. This can be carried out through mobile or remote authentication systems.
  • Basic Access: The applications support basic authentication based on a username and password. Protocols and layers such as HTTPS, SSL. or TLS could be used to enhance security, but these are not mandatory.
  • Multi-Factor: The application requires more than one method of authentication from independent verification sources to verify the transactional identity.
  • Multi-Factor & SSO: The application supports both multi-factor authentication (MFA) and single sign-on (SSO) authentication methods.
  • No Authentication: The application does not support authentication.
  • Single Sign-On: The application supports the use of a single ID and password to gain access to several related or unrelated systems.
  • Unknown: The authentication mode has not yet been assessed.
• Development Type: Development information about the application. Possible values are:
  • Bespoke: The application was created specifically to address a unique use case.
  • COTS - Configured: A commercial off-the-shelf application that has been configured or supports configuration to fulfill the requirements of the enterprise and is fully supported and upgrade-stable.
  • COTS - Customized: A commercial off-the-shelf application that is customized or contains organization-specific code/programming to suit the requirements of the enterprise.
  • Unknown: The application development type has not yet been assessed.
• Pace-Layered Governance: Classification of application according to the Pace-Layered Application Strategy to categorize, select, manage, and govern applications to support business change, differentiation, and innovation. Possible values are:
  • System of Differentiation: The application enables unique company processes or industry-specific capabilities. The application has a medium-length lifecycle (one to three years) but needs to be reconfigured frequently to accommodate changing business practices or customer requirements.
  • System of Innovation: The application is built on an ad-hoc basis to address new business requirements or opportunities. The application typically has a short lifecycle (zero to 12 months) using departmental or outside resources and consumer-grade technologies.
  • System of Record: The application is an established packaged application or legacy homegrown system that supports core transaction processing and manages the organization's critical master data. The rate of change is low because the processes are well-established and common to most organizations and often are subject to regulatory requirements.
• Cloud Migration Strategy: Specify the planned strategy for the application regarding its migration to the cloud. Possible values are:
  • Rehost: The application is SaaS-enabled but is either outdated or would require rehosting to the cloud platform.
  • Rebuild: The application could be made cloud ready but would require a change in the build process to ensure seamless delivery. The concepts of CI/CD (continuous integration/continuous delivery) could be leveraged for these applications.
  • Rearchitect: The application requires additional effort to make it cloud enabled. For example, this might be due to application health monitoring, application security, data backup and policies, scalability and replication zones, disaster recovery, network utilization, multi-channel communication, or identity management.
  • Refactor: The application requires some changes in code to be eligible for migration to the cloud. The application can be modular or a self-contained application with services that can easily be refactored.
  • Retain/Retire: The application supports a business capability for which the Business Relevant indicator is set to Business Enabling or Business Operating and the application cannot be migrated to the cloud immediately. Or the application is at the end of its lifecycle and is about to be retired.
  • Unknown: The cloud migration strategy is not specified for the application.
• Subject to Compliance Regulation: Select the checkbox if the application is bound to compliance regulations. This is relevant for migration analytics.

Define the lifecycle attributes. All attributes in the Lifecycle attribute group in the application's content area should be specified before you specify the application's lifecycle phases. Click here to learn about specifying the application's lifecycle phases.

• Start Date and End Date: The start and end date captures the period when the application is actively running and can be used in the company. This is also when the Object State attribute should be specified as Active. Click the calendar icon to select the date or enter the date in the date format Month/Day/Year. For example: 4/30/2023
• Object State: The object state describes the use of the application in the real world. This can be understood as the operational status of the application. Possible values are:
  • Plan: The application is proposed to be used and still in the stages of planning and building.
  • Active: The application is currently being used. The active period begins with the application's start date and stops with the end date.
  • Retired: The application is no longer used.

  The object state should be changed from Plan to Active once the application's start date is reached. It should be changed to Retired when the application's end data is reached.

• Recommendation: The strategic recommendation regarding future investment for the application. This information is required for TIME (Tolerate, Invest, Migrate, Eliminate) analyses and is used in many business questions. Possible values are:
  • Tolerate: Invest in the application.
  • Invest: Consider the application as a migration candidate.
  • Migrate: Sundown the application.
  • Eliminate: Discontinue the application.
• Strategic Application: Select the checkbox if the application is strategic for the company.
• Successor: The next application that will follow this application version.