How to create an inventory of your current state

Creating an Application Inventory requires collaboration across IT, security, compliance, and business units and a regular update process to stay current.

Understanding the difference between "applications" and "tools" is an essential initial decision. Applications are larger, complex programs designed for end-users to perform various tasks and meet specific needs, often including multiple tools. Tools are simpler programs focused on specific functions, making tasks easier within applications or systems.

Documenting each application involves collecting information on:

• Name, purpose, version and Installation date
• License details, vendor and support info
• Criticality
• Dependencies
• Types of users, business, and IT owners
• Environments and hosting
• Compliance, security and access controls
• Disaster recovery, backup procedures, and documentation location

Additionally, understanding the application's functional and technical fit, data handling practices, quality, integrations, risk factors, cost details, and dependencies on IT components is crucial for establishing Application Portfolios and using this information to identify rationalization opportunities.

Deciding on Applications vs. Tools

When making a list of the software you use, it's important to know the difference between "Applications" and "Tools." Even though teams often use these words like they mean the same thing, they can mean different things depending on the situation. Sometimes, what you call a tool in one case might be called an application in another, especially as software gets more complex and does more things.

An "Application" is a bigger program or set of programs made for users to do many tasks or functions. These are usually more complex and made to meet specific needs, like for work, school, or personal use. Examples are programs for managing supply chains, customer relationships, managing clients’ financial portfolios, e-commerce sites, etc. Applications can include many tools to help with a specific need.

A “Tool" is a simpler program made for a specific job or a few jobs. Tools help make working with applications, systems, or other tools easier. They can be on their own but are often part of a bigger application or set of software. Tools focus on helping with specific tasks, like editing, finding errors, analyzing, or managing data. Examples include text editors and file converters.

The main differences are:

• Complexity: Applications are more complex and do many things in a certain area. Tools focus on one task or a few tasks.
• What they do: Applications have many functions for different needs. Tools have specific functions to help with certain tasks.
• How you use them: Applications have lots of ways to interact with them, for many different users. Tools have simpler ways to use them because they're for more specific tasks.
• Being part of something: Tools can be part of applications to help them work better. Applications are usually on their own but can use many tools.

Application Core Information

Here are the key pieces of information you should consider collecting about each application to make your inventory useful:

1. Application Name: The official name of the application.
2. Application ID: A unique identification for this application. Ideally a GUID so as not to overlap with the Application’s ID in other systems.
3. Purpose/Functionality: A brief description of what the application is used for within the organization.
4. Version: The specific version(s) of the application in use.
5. Lifecycle Stage: The lifecycle stage indicates whether an application is under development, maturing, or nearing its end of life, each carrying different implications for resource allocation and strategic planning.
6. Installation Date: When the application was first installed or deployed.
7. End-of-Life Date: If known, when the application is expected to be retired or replaced.
8. Status: whether the application is still active or no longer in use.
9. Predecessors / successors – if this application is replacing an older application or being replaced by a newer application.
10. License Type: Whether the license is open source, commercial, or custom-built. Include details about any usage restrictions.
11. License Expiry Date: If applicable, when the license needs renewal.
12. Vendor/Developer: The name of the company or individuals who developed the application.
13. Support Information: Contact information for support, whether internal or external, and maintenance contracts.
14. Criticality: How critical the application is to business operations.
15. Dependencies: Other applications or services that this application depends on to function properly.
16. Users: The user groups or departments that use the application
17. Types of users: types of users for this application (E.g. customers, vendors, internal staff)
18. Business Owners: People in the organization that manage the application business and operational aspects
19. IT / Technical Owners: People in the organization that manage the application IT/Technology aspects
20. Environment: Information about the environment(s) where the application runs (e.g., production, development, testing).
21. Host Information: Details about the servers or devices on which the application is installed, including operating systems and hardware specifications.
22. Compliance Information: Any relevant compliance standards the application needs to meet (e.g., GDPR, HIPAA).
23. Security Information: Details about security measures in place, including encryption and authentication methods. Also, note any known vulnerabilities.
24. Access Control: Information on how access to the application is controlled and who has administrative rights.
25. Disaster Recovery: the current level of disaster recovery for this application.
26. Backup and Recovery Procedures: Details on how data is backed up and how the application can be recovered in case of failure.
27. Documentation Location: Where to find the documentation related to the application.

Application Hierarchy

1. Application Name and Overview: The overall name of the application and a brief description of its purpose and functionalities.
2. Modules/Sub-Applications: A list of all modules or sub-applications, including their names and brief descriptions of their functions.
3. Hierarchy Structure: A diagram or description showing how the modules or sub-applications are structured and how they relate to each other within the main application. Include parent-child relationships and any dependencies between modules.

Business Value and Technical Fit

When assessing software applications for your inventory, evaluating both their functional fit and technical fit is crucial to ensure they meet the organization's needs and integrate well with the existing IT infrastructure and to make informed decisions about which software applications to adopt, retain, or retire. This approach ensures that the software inventory not only supports current operations efficiently but is also strategically aligned with future growth and technology trends.

Here's what you should consider collecting about each application to evaluate its Business Value and Technical Fit:

Business Value

1. Business Requirements Match: How well the application meets the specific business needs and requirements it was acquired to address. This includes the scope of functionalities and processes the software supports.
2. User Adoption: The level of acceptance and use of the application by its intended users. High user adoption indicates a good functional fit, as it suggests the application meets the users' needs and is user-friendly.
3. Flexibility and Customizability: The ability of the application to adapt to changing business processes or requirements. This includes the ease of customization and whether it can be done in-house or requires vendor support.
4. Scalability: Whether the application can scale to meet future business growth in terms of users, data volume, and transaction throughput without a significant increase in cost or performance degradation.
5. Integration Capabilities: How well the application integrates with other systems and software in use, in terms of both functionality (completing business processes across systems) and data consistency.
6. Support and Training: The availability and quality of support and training from the vendor or developer, can significantly affect how well the application meets functional needs over time.

Technical Fit

1. Architecture Compatibility: How well the application fits into the existing IT architecture, including compatibility with existing hardware, software, and network infrastructure.
2. Security Compliance: Whether the application meets the organization's security standards and compliance requirements, including data protection, user authentication, and authorization protocols.
3. Performance Requirements: The application's impact on system performance and whether it meets the performance criteria necessary for its role within the organization.
4. Maintenance and Support Requirements: The level of effort and resources required to maintain the application and keep it operating efficiently, including the availability of technical support.
5. Disaster Recovery and Business Continuity: How the application fits into the organization's disaster recovery and business continuity plans. This includes considerations for data backup, system redundancy, and recovery procedures.
6. Technology Stack: The technology stack of the application and how it aligns with the organization's standard technology stack or IT strategy. This can affect long-term maintenance, support, and integration efforts.

Data Handling

Data handling is about capturing information about how a software application collects, uses, stores, and transmits data, especially sensitive or personal data. Its important to focus on aspects that ensure data integrity, security, and compliance with relevant regulations.  

Here's a detailed breakdown of what to consider:

1. Data Collection Methods: How the application collects data, including the types of data collected (e.g., personal, financial, operational) and the sources of this data (e.g., user input, sensors, third-party integrations).
2. Data Processing: How the application processes data. This includes any transformations, calculations, or analysis the application performs on the collected data.
3. Data Storage: Details about how and where the application stores data, including the use of onsite servers, cloud storage solutions, and any encryption methods employed to protect data at rest.
4. Data Access: Information about who can access the data within the application and under what conditions. This includes access controls, authentication mechanisms, and user permission levels.
5. Data Sharing and Exports: How the application shares or exports data to other systems, including the formats supported for data export and any controls or restrictions on data sharing.
6. Data Retention: The application's data retention policies, including how long data is kept before it is archived or deleted, and how these policies comply with relevant data protection regulations.
7. Data Security: The security measures in place to protect data from unauthorized access, alteration, or breach. This should cover both technical safeguards (e.g., encryption, firewalls, anomaly detection) and organizational measures (e.g., staff training, access policies).
8. Data Privacy: How the application ensures compliance with data privacy laws and regulations, such as GDPR in Europe or CCPA in California. This includes mechanisms for user consent, data subject access requests, and data erasure.
9. Data Backup and Recovery: The processes and technologies used to back up data and restore it in case of loss or corruption. This should include the frequency of backups, the storage location of backups, and the estimated recovery time after a data loss event.
10. Data Audit Trails: Whether and how the application maintains logs or audit trails of data access and changes, which can be crucial for security monitoring, compliance, and forensic analysis.
11. Data Quality Management: The measures and processes in place to ensure the accuracy, completeness, and consistency of the data handled by the application.
12. Compliance and Certification: Any compliance standards or certifications the application meets related to data handling, such as ISO 27001 for information security management or SOC 2 for data protection.

Data Integrations and Interface Information

When managing data integrations within your software inventory, it's important to document how applications exchange data and work together to support business processes. Collecting detailed information about these integrations can help you understand data flows, identify potential bottlenecks or vulnerabilities, and make informed decisions about software purchases, upgrades, or retirements.

Here’s what you should consider collecting about each data integration:

1. Integration Name/ID: A unique identifier or name for the integration.
2. Source Application(s): The application(s) or system(s) from which data originates.
3. Target Application(s): The application(s) or system(s) that receive data from the source.
4. Integration Type: The method or technology used for the integration (e.g., API, direct database access, file transfer, webhooks).
5. Data Format: The format in which data is exchanged (e.g., JSON, XML, CSV).
6. Data Fields: Specific data fields that are being transferred, including any transformations that occur during the integration process.
7. Frequency: How often data is transferred (e.g., real-time, batch processing, scheduled intervals).
8. Purpose/Use Case: The business reason or use case for the integration (e.g., synchronizing customer data, aggregating analytics).
9. Security Measures: Security protocols and measures in place to protect the data during transfer (e.g., encryption, authentication methods).
10. Compliance Considerations: Any compliance requirements that affect the integration (e.g., GDPR, HIPAA) and how they are addressed.
11. Performance Metrics: Key performance indicators (KPIs) or metrics used to monitor the integration's efficiency and reliability (e.g., latency, throughput, error rates).
12. Error Handling Procedures: How errors or exceptions are managed and communicated during the integration process.
13. Integration Owner/Stakeholder: The person or team responsible for managing and maintaining the integration.
14. Documentation Location: Where to find detailed documentation on the integration, including technical specifications and operational guidelines.
15. Costs: Any costs associated with establishing, maintaining, or operating the integration, including software licenses, development resources, and third-party services.
16. Lifecycle Stage: The current stage of the integration's lifecycle (e.g., development, deployment, maintenance, retirement).
17. Dependencies: Other integrations, systems, or services that this integration depends on to function properly.
18. Recovery Procedures: Steps to recover the integration in case of failure, including backup and restore processes.

Risk Information

Capturing risk information about software applications and their components is crucial for understanding potential vulnerabilities, compliance issues, and operational challenges that could impact your organization. When capturing risk information, it’s important to assess the likelihood of each risk occurring, as well as the potential impact on the organization.

Here’s a comprehensive list of risk-related information you should consider capturing:

1. Security Risks: Known vulnerabilities in the application or its dependencies. Risks related to data security and privacy, including potential for data breaches or loss. Risks from inadequate authentication, authorization, and encryption measures.
2. Compliance Risks: Potential violations of regulatory standards (e.g., GDPR, HIPAA) due to the application’s data handling practices. Licensing compliance risks, including the use of unauthorized, pirated, or obsolete software.
3. Operational Risks: Risks related to application availability and the potential impact of downtime on business operations. Performance risks, including issues that could arise from scaling up or handling peak loads. Dependency risks from external services or libraries that could affect the application's stability.
4. Financial Risks: Costs associated with addressing security vulnerabilities and operational issues. Potential fines or penalties for non-compliance with regulations. Unanticipated expenses from software maintenance, upgrades, or license fees.
5. Reputation Risks: The potential impact on your organization’s reputation from security breaches or compliance failures. Customer trust issues arising from application performance problems or data handling concerns.
6. Technical Risks: Risks associated with outdated technology or software that may no longer be supported. Challenges related to integrating the application with existing systems or future technologies. Risks from insufficient documentation or lack of expertise in maintaining or operating the application.
7. Project and Implementation Risks: Risks related to the deployment and integration of new applications, including potential delays and budget overruns. training and adoption risks, considering how easily users can adapt to the application.
8. Legal Risks: Risks from potential legal actions due to non-compliance, licensing issues, or data breaches.
9. Environmental Risks: For data centers and IT infrastructure, consider risks related to physical location, including susceptibility to natural disasters.
10. Data Integrity and Loss Risks: Risks associated with data corruption, loss, or improper backup and recovery processes.

Cost Information

Collecting cost information for each software application in your inventory is vital for effective financial management, budgeting, and making informed strategic decisions.

Here are the key cost-related data points you should consider collecting:

1. Acquisition Cost: The initial cost of purchasing or licensing the software. This should include any one-time fees for installation, customization, or integration with existing systems.
2. Subscription Fees: If the software is offered on a subscription basis, note the periodic fees (monthly, annually, etc.) and what is included in these fees (e.g., updates, support).
3. Maintenance Costs: Ongoing costs for maintaining the software, including updates, patches, and support contracts. This is particularly relevant for commercial software where vendors charge an annual maintenance fee.
4. Operating Costs: Costs related to the daily operation of the software, such as energy consumption for servers, storage costs, and costs associated with data transmission.
5. Support and Service Costs: Fees paid for external support and service agreements, beyond basic maintenance. This can include premium support packages, dedicated account managers, and costs for on-call services.
6. Upgrade Costs: The costs for upgrading the software to newer versions, if not covered under the initial acquisition or maintenance fees. This can include both the costs of the software upgrades themselves and any associated implementation costs.
7. Compliance Costs: Any costs related to ensuring the software complies with relevant regulations and standards (e.g., GDPR, HIPAA). This may include auditing costs, costs for additional security features, or consulting fees.
8. Indirect Costs: These are costs that may not be directly associated with the software itself but are necessary for its operation, such as additional hardware, network upgrades, or increased IT department workload.
9. Cost Recovery: Any revenue or cost savings generated by the application, which can offset its total cost. This could include efficiency savings, reduced downtime, or direct income from the software’s use.
10. Decommissioning Costs: The costs associated with retiring the software, which can include data migration to new systems, removal of installed software, and any contract termination fees.

IT Component Dependencies

Documenting the dependencies an application has on various IT components, including hardware, software, and services, is critical for understanding its operational requirements, troubleshooting issues, and planning for future upgrades or changes.

Here's a comprehensive list of what information to capture:

Hardware Dependencies (for applications that are hosted on-premise)

1. Server Specifications: Details about the servers required to run the application, including CPU, memory, disk space, and network specifications.
2. Client Hardware Requirements: If the application has a client component, specify the hardware requirements for client devices (e.g., PCs, mobile devices).

Software Dependencies

1. Operating Systems: The operating systems (including versions) on which the application can run, both for servers and client devices.
2. Database Systems: Details about any database systems the application uses, including versions and configurations.
3. Middleware and Frameworks: Any middleware or frameworks required by the application, such as web servers, application servers, or development frameworks.
4. Third-party Libraries and Components: List of third-party libraries and components the application depends on, including their versions.
5. Interdependent Applications: Other applications that must be present or operational for this application to function properly, including any integrations or data exchanges.

Services Dependencies

1. External Services: Information on external services the application relies on, such as cloud services, API services, or data feeds.
2. Internal Services: Details about any internal IT services needed, like authentication services, directory services, or network services.
3. Support and Maintenance Services: Required support and maintenance services, whether provided in-house or by external vendors, including service level agreements (SLAs).

‍

What to read next

8. Application Portfolio Management

‍

Copyright License

This license enables reusers to distribute, remix, adapt, and build upon the material in any medium or format, so long as attribution is given to the creator. The license allows for commercial use.

‍