In the navigation panel, go to Applications to open the data workbench for applications.

Add a new application. Click the New button to open the wizard.

Edit an existing application. Select the checkbox   for the application you want to edit and click the Edit    button to open the wizard. The Go to Step ​ field displayed at the bottom of the wizard should show Basic Data so that you can capture the mandatory information about the application.

Define the application's basic data. Define the following fields in the wizard and click OK or Next to save your data. All mandatory fields must be defined to create the application and save it.

• 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: (Mandatory) 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.
• Start Date and End Date: (Mandatory) 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: (Mandatory) The object state describes the use of the application in the real word. 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 and used now. The active period begins with the application's start date and ends 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 Retire when the application's end data is reached.

• Release Status: (Optional) 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.
• Recommendation: (Optional) The strategic recommendation regarding future investment for the application. This information is used in TIME (Tolerate, Invest, Migrate, Eliminate) analyses. Possible values are:
  • Tolerate: Invest in the application.
  • Invest: Consider the application as a migration candidate.
  • Migrate: Sundown the application.
  • Eliminate: Discontinue the application.
• Architecture Type: (Optional) 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.
• Development Type: (Optional) 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.
• Authentication: (Optional) 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 Authorization: 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.
• Pace-Layered Governance: (Optional) 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: (Optional) Specify the planned strategy for the application regarding its migration to the cloud. Possible values are:
  • Retain/Retire: The application supports a business capability that is relevant to the business but cannot be migrated to the cloud immediately. Or the application is at the end of its lifecycle and is about to be retired.
  • Rehost: The application is SaaS-enabled but is either outdated or would require rehosting to the cloud platform.
  • Refactor: The application requires some changes in code to be eligible for migration to the cloud. The application can be a modular or self-contained application with services that can easily be refactored.
  • 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.
  • 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.
  • Migrated: The application has been migrated to the cloud successfully.
  • Unknown: The cloud migration strategy is unknown for the application. This may be the case for applications for which the Architecture Type attribute is not set to Cloud-Based.
• Subject to Compliance Regulation: (Optional) Select the checkbox if the application is bound to compliance regulations. This is relevant for migration analytics.
• Strategic Application: (Optional) Select the checkbox if the application is strategic for the company.
• Authorized Access tab: The user who creates the application is the authorized user per default. This can be changed. Select one or more authorized user groups that shall have write permissions to the object. All users in the authorized user group can edit the application.

  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 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.

In contrast to the concept of an authorized user or authorized user group which grants read/write permissions to an object, roles which are fulfilled by people or organizations may also be specified for an object. The role definition specifies the functional relationship or responsibility that a user or organization has to an object. The specification of a role is primarily for documentation purposes and provides additional information about stakeholders interested or responsible for the object. A person assigned to have a role for an object will not have read/write permissions based on the role definition. If the user shall have read/write permissions, they must be assigned to an authorized user group specified for the object.

Alfabet FastLane provides out-of-the-box role types that enable you to understand who is responsible for your IT assets in your IT portfolio. Additional role types that are relevant for your company can also be added.

Assigning users and organizations to roles is critical to understanding responsibility for assets in the IT and is required to answer the business question Who is responsible for our assets?.

To define the users and organizations that have a role for an application, either:

• Click the Edit button to open the wizard and select Responsibilities in the Go to Step field
• In the data table, click the navigate  button of the application you want to define. Click Overview and scroll to the Responsibilities page and open it.

Define the users that have a role for an application. In the toolbar, click Person to associate a user with the application. The user can have one of the following roles or a custom role added by your company:

• Application Manager: A person who is the subject matter expert for an application from a functional and technical point of view.
• Architect: A person who is responsible for the governance of the application.
• Business Owner: A person or organization that owns the application and is responsible for managing the functional requirements.
• IT Owner: A person or IT organization that owns the application and thus typically responsible for approval decisions.
• Stakeholder: A person or organization that has an interest in the application and therefore requires read-only access permissions.

In the selector, find the user to assign the role to and click OK.

Define the organizations that have a role for an application. In the toolbar, click Organization to associate an organization with the application. The user can have one of the following roles or a custom role added by your company:

• Business Owner: A person or organization that owns the application and is responsible for managing the functional requirements.
• IT Owner: A person or IT organization that owns the application and thus typically responsible for approval decisions.
• Operations: An IT organization responsible for the operations of the application.
• Stakeholder: A person or organization that has an interest in the application and therefore requires read-only access permissions.

In the selector, find the organization to assign the role to and click OK.

An evaluation is a measurement of the performance of an application. Preconfigured indicator types and possibly custom indicator types added by your company are available to evaluate and are used in various analyses in Alfabet FastLane. Some indicator types are automatically computed by the system and others must be manually defined.

Update computed indicators. Click the Calculate button to update computed indicators via the Calculate button. The indicators will be recalculated based on the current. Please note that computed indicators that are calculated based on the current data.

Select an indicator type and click Edit Indicator or click Group Edit to open a dialog where all indicator types can be edited that are not automatically computed by the system.

Define the application's indicators. To do so, either:

• Click the Edit button to open the wizard and select Evaluations in the Go to Step field
• In the data table, click the navigate  button of the application you want to define. Click Overview and scroll to the Evaluations page and open it.

The application lifecycle describes the succession of stages that the application goes through over time. Alfabet FastLane allows all stages of an application's lifecycle to be documented from its phase-in to its phase-out of the organization. This can include any or all stages from the application's identification, planning the build and deployment, putting it into production, and sundowning it. A robust application lifecycle management includes versioning and planning for successor applications to ensure that IT continues to support critical business areas.

Not all company's document their application lifecycles and it is not mandatory in Alfabet FastLane. However, robust application lifecycle management is key to the health to the business and helps you to understand identify and manage lifecycle conflicts. By documenting the lifecycles of the applications in your application portfolio, you will be able to identify which applications are approaching end-of-life but have no defined successor applications. Furthermore, you can understand whether relevant technologies are in place during the lifecycle of an application. With this insight, you can plan, communicate, and take corrective action for applications that are at risk and ensure the availability and reliability of applications for the company.

In Alfabet FastLane, an application lifecycle consists of the following stages:

• Plan: The application has been identified and evaluated for possible use in company
• Pilot: A test system has been set up and the application is undergoing detailed testing.
• Production: The application is being used in company.
• Sundown: The application is still available but it is not intended to be used for daily work.
• Retire: The application should no longer be used but could be temporarily restored if urgently needed.

The object state specifies the operational status of the application in the enterprise. The object state Active corresponds to the start and end dates of the application.

Gantt reports that visualize the application lifecycle will also reflect the application’s active period which is when the application is actually being used in the enterprise. This object state typically corresponds to the application’s start and end dates and should be set to Active when the active is in use.

The active period usually corresponds to the lifecycle phases that represent when the application is in production, but this will depend on your company's lifecycle management methodology. For example, the active period could begin when the lifecycle phase Pilot starts and end when the lifecycle phase Production ends. Or it could be that the active period begins when the lifecycle phase Production starts and ends when when the lifecycle phase Production ends.

Define the application's lifecycle. To do so, either:

• Click the Edit button to open the wizard and select Lifecycle in the Go to Step field
• In the data table, click the navigate  button of the application you want to define. Click Overview and scroll to the Lifecycle page and open it.

• Add lifecycle phases to the application lifecycle. Include lifecycle phases by setting a checkmark in the checkbox for the lifecycle phase in the left pane. Only lifecycle phases that are selected can be defined.
• Set the start and end of a lifecycle phase. In the timeline, select a lifecycle phase (colored bar) and drag the handles to define the start and end dates for the lifecycle phase. Select the Keep Phases Duration checkbox to retain the current definition in the adjacent lifecycle phases . If you do not select the Keep Phases Duration checkbox, the adjacent lifecycle phases will increase or decrease proportionally.
• Set the start and end of the active period. Click the red bar for the active period and drag the handles to define the start and end dates for the active period. The selected object’s start and end dates will change correspondingly.
• Align the start and and of the active period with the lifecycle phase. Click Align Active Period to automatically align the start/end dates of the active period with the start/end dates of the lifecycle phases that begin and end the active period.

Ideally your company has documented its business capabilities. Business capabilities must already be in the repository in order to define the business capability that the application provides. Some business questions in Alfabet FastLane can only be answered if the relationship between applications and business capabilities is defined. business capability A business capability is a high-level description of what is done in a company to meet its business objectives. Market development, product development, and support and services are examples of business capabilities.

Applications support the company to realize its business capabilities. For each application, you should define the business capabilities that the application provides in order to understand how the business may be at risk due to IT failure.

• Click the Edit button to open the wizard and select Provided Business Capabilities in the Go to Step field
• In the data table, click the navigate  button of the application you want to define. Click Business Portfolio and scroll to the Associated Domains page and open it.

Click New > Add Associated Domains. In the selector, select one or more business capabilities that the application provides. Note that the selector shows both business capabilities and IT capabilities. Ensure that the prefix of the ID is BCAP and that Business Capability is displayed in the Stereotype column. Click OK.

Ideally your company has documented its business processes. Business processes must already be in the repository in order to define the business processes that the application supports. Some business questions in Alfabet FastLane can only be answered if the relationship between applications and business processes is defined. business process A business process is a set of activities that represent work required to achieve a business objective. Marketing services, selling products, delivering services, distributing products, invoicing for services, and accounting for money received are examples of business processes.

Applications provide functional support to the company's business processes. For each application, you should define the business processes that the application supports in order to understand the operational support that applications provide in the as-is architecture.

In the data table, click the navigate  button of the application you want to define. Click Business Portfolio and scroll to the Business Processes page and open it.

Click New > Add Business Processes. In the selector, select one or more business processes that the application supports. Note the Level ID column to understand where the business process is in the business process hierarchy. Click OK.

Ideally your company has documented its organizations. Organizations must already be in the repository in order to define the organizations that use the application. organization An organization describes an administrative or functional unit in the enterprise.

Applications are used by organizations. For each application, define the organizations that use the application. In the data table, click the navigate  button of the application you want to define. Go to the Business Portfolio tab and open and scroll to the Organizations Using Application page and open it. Click New > Add Organizations Using Application. In the selector, select one or more organizations that use the application supports and click OK.

Information flows exchange business data between applications. For each information flow, one application is considered the source of the information flow and the other application is considered the target of the information flow. The number of information flows that an application is associated with helps the application architect determine the complexity of the application, potential redundancies among applications, and the effort involved in migrating or replacing an application.

An application can be a source of an outgoing information flow and the target of an incoming information flow. The naming convention for information flows is: <Source Application> > <Target Application>. The source and target applications of an information flow cannot have the object state set to Retired. The application may have an unlimited number of incoming and outgoing information flow.

In the data table, click the navigate  button of the application you want to define. Go to the Information Portfolio tab and open and scroll to the Information Flows page and open it. You can do one of the following:

• Click New > Add Incoming Information Flow if the application you are working with is the target of the information flow.In the selector, select the application that is the source of the information flow and click OK.
• Click Add Outgoing Information Flow if the application you are working with is the source of the information flow. In the selector, select the application that is the target of the information flow and click OK.

Specify the basic data about the information flow. In the Information Flow wizard, the names of the source and target applications will be automatically entered in the From or To fields. Define the following fields and click OK to save your data. All mandatory fields must be defined to create the application and save it.

• Short Name: (Optional)Define a short abbreviated name to display on the information flow in diagrams and business graphics.
• Version: (Mandatory) Enter the version number. The version number should be unique.
• Object State: (Optional) The object state describes the use of the information flow in the real word. The information flow's object state may only be defined as active if its source and target applications also have an active object state.The information flow must have a retired object state if either the source or target application has a retired state. Possible values are:
  • Plan: The information flow is proposed to be used and still in the stages of planning and building.
  • Active: The information flow is currently and used now. The active period begins with the information flow's start date and ends with the end date.
  • Retired: The information flow is no longer used.
• Release Status: (Optional) This is an approval status and typically indicates the level of quality of the information about the information flow. The release status determines whether an information flow can or cannot be deleted. Possible values are:
  • Draft: The information flow has only mandatory data defined.
  • Under Review: The information flow is documented and being reviewed. An information flow with this release status cannot be deleted.
  • Approved: The information flow has been approved by the responsible stakeholders. An information flow cannot be deleted when it has an approved release status. An information flow with this release status cannot be deleted.
  • Data imported: The data regarding this information flow has been imported from an external system. Additional changes may be required to improve the data quality. An information flow with this release status can be deleted.
  • Trash: The information flow is no longer valid and can be deleted.
• Start Date and End Date: (Mandatory) The start and end date captures the period when the information flow 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
• From (Source) and To (Source) (Optional): You can change the source or target of the information flow to a (local) component that has been defined for the source or target application. The component name will be displayed in parenthesis behind the application in the information flow name.

  component

  A component is a reusable block of functionality that provides technical functionality to the application or to the platforms that an application runs on. Components do not usually provide functionality to end users. Typical components are operating systems, database management systems, or application servers.

• Connection details: (Optional) Specify the connection type, connection method, connection frequency, and connection data format for the information flow.

  connection type

  A connection type describes the mode of transfer used by a specific information flow when transmitting business data between two associated applications or their respective components. Examples include batch and online.

  connection method

  A connection method describes the method of transfer used by a specific information flow to transfer business data between the two associated applications or their respective components. Examples include TCP/IP, file transfer, message queue.

  connection frequency

  A connection frequency describes how often a specific information flow is used to transfer business data between the two associated applications or their respective components. Examples include daily, monthly.

  connection data format

  A connection data format describes the data format used for the transfer of business data via a specific information flow. Examples include ASCII, XML.

• Description: Enter a meaningful description that will clarify the purpose of the information flow.
• Authorized Access: As the creator of the information flow, you are automatically defined as the authorized user per default. The authorized user of the information flow can be changed. You can also define any authorized user group that should have Read/Write access permissions to the information flow.

  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 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.

Specify the responsibilities and indicators for the information flow. You can continue through the wizard and define the roles and evaluate indicators for the information flow. Click Next to save the data for each step.

An application can be a source of an outgoing information flow and the target of an incoming information flow. The information flow transfers the business data that applications either create, read, update, or delete (CRUD). Business data must already be in the repository in order to define the use of the business data by the application.

In the data table, click the navigate  button of the application you want to define. Go to the Information Portfolio tab and open and scroll to the Business Data page and open it.

Create business data. Click New > Create Business Data and define the business data's basic information or click Add Existing Business Data to select a business data that is in the repository. Click OK or Next to save the data.

• Name: (Mandatory) Enter a unique name for the business data. The use of a comma (,) in the name business data is not recommended. To assure correct handling, the comma (,) will be replaced by a period (.) in conjunction with the display of business data in the CRUD matrices.
• Version: (Mandatory) Enter a version number for the business data. The name and version number of the business data should be unique.
• Data Category: (Mandatory) Assign the business data to a data category. The business data is typically the instantiation of the data category.
• Business Capability: (Recommended) Select the business capability that the business data is relevant for.

  business capability

  A business capability is a high-level description of what is done in a company to meet its business objectives. Market development, product development, and support and services are examples of business capabilities.

• Data Classification: (Recommended) Classify the business data based on data protection requirements. Possible options are: Confidential - Non-Personal Data, Confidential - Personal Data, Restricted, Unrestricted, and Unknown 
• Description: (Optional) Enter a meaningful description that will clarify the purpose of the business data.

Specify the usage of the business data by the application or the information flow. In the Business Data page, click the Business Data Usage button to open the editor to define how the application operates on the business data. Select all checkboxes that are relevant for the application and click OK to save the specification.

• Create: Select if the business data can be created by the application.
• Is Input: Select if the business data can be used by any of the application's incoming information flows.
• Read: Select if the business data can be read by the application.
• Is Output: Select if the business data can be used by any of the application's outgoing information flows.
• Update: Select if the business data can be updated by the application.
• Delete: Select if the business data can be deleted by the application.
• Processing: Select if the application processes information pertaining to the business data. Processing indicates that the business data is handled in the context of the relevant object without the data being altered, created or deleted. The data is typically kept locally so that a desynchronization results between the processed business data and the system(s) of records for the business data.

  Typically, it is not the raw data that is processed but some aggregation or abstraction of the business data (for example, data in an operational data store or an OLAP-based reporting solution).

• Business Data Usage Comments: (Optional) Provide additional information about the business data usage.

An application platform describes the technical architecture in terms of the assembly of local components that a specific application runs on. This assembly is based on a platform template and ideally has standard components incorporated in it.

In the data table, click the navigate  button of the application you want to define. Go to the Technology Portfolo tab and open and scroll to the Platform Architecture page and open it.

The application platform is displayed as a matrix. The X-axis shows the platform tiers used to classify components according to their role in a client / server architecture. The following platform tiers are defined:

• Client / Mobile: Includes the components that implement the part of the application that directly interacts with the user.
• Presentation: Includes the components that define and support the presentation / GUI of the applications.
• Business: Includes the components that primarily implement business / application logic or support the execution of such logic.
• Integration: Includes the components that are allowed for integration of (transfer of data between) components within or across platforms.
• Resource: Includes the components that provide resources for or are resources to other components.

The Y-axis shows the platform layers that classify components according to their technical abstraction level. The following platform layers are defined:

• Business Layer: Includes the components that focus on implementation of business logic and generate the business value.
• Software Layer: Includes the components that are required by the application and support components in the business layer but do not directly implement business logic.
• Infrastructure Layer: Contains logical instances of device software that "run" components or transport data between components.

Define the application's platform. To assemble a platform for the application, add individual components in the platform matrix, thus structuring the selected platform component by component. Click in a cell and click New > Create New Local Component or click the Create as Copy button to select a component to copy. Give the component a name, version and start and end dates. The local component exists only in the context of the application and cannot be reused by other applications.:

Applications are deployed on either virtual servers or physical servers. The virtual servers are usually running on top of physical servers which are located in different locations around the world. Virtual servers are typically application servers or web servers.

In the data table, click the navigate  button of the application you want to define. Go to the Technology Portfolio tab and open and scroll to the Servers page and open it. Click New > Add Servers. In the selector, select Virtual Server or Physical Server in the Physical / Virtual field to find the server that deploys the application.