Software Technologies Inventory and Attributes

Overview

Every software technology in the inventory should be classified so that it can be found, governed, and reasoned about as part of a larger set rather than in isolation. Classification is what lets an enterprise ask which technologies serve its data tier, which are approaching end of support, or which fall under a particular oversight regime. This chapter provides the value set for that classification: a representative, two-level taxonomy of categories and subcategories.

The taxonomy is deliberately representative, not exhaustive. No vendor-neutral list could enumerate every category of software technology in existence, and this one does not try. What it provides is a framework — a starting structure, defined in governance terms, from which an enterprise builds the comprehensive taxonomy it needs. The value is in the method and the starting point, not in a claim of completeness.

Categories are named generically and without reference to any vendor or product. A category names a kind of software technology by what it does and why it matters to govern — Relational Database Software rather than any particular database engine. This keeps the taxonomy durable as products come and go, and keeps the focus on governance rather than procurement.

Software technologies and applications overlap at the edges, and always will. A development environment, a low-code platform, or a data platform with a rich administrative interface can each reasonably be governed as a software technology, as an application, or as both. This document does not attempt to resolve that boundary. It takes an infrastructure-and-technology-layer view — the technologies applications are built on, run within, or depend upon — while recognizing that where exactly the line falls is a governance decision each enterprise makes for itself.

The Representative Category Taxonomy

Data Software — Technologies that persist, serve, move, transform, and manage enterprise data. Governed because they hold the enterprise’s information, often carry the heaviest licensing costs in the portfolio, and are the technologies whose end-of-support dates most frequently force application remediation.

• Relational Database Software

• Document Database Software

• Key-Value and Cache Software

• Graph Database Software

• Data Warehouse and Analytics Database Software

• Extract, Transformation, and Load (ETL) Software

• Other / Enterprise-Specific Data Software

Infrastructure and Platform Software — The foundational runtime layer that other software is installed on and runs within. Governed for patch currency, end-of-support exposure, and configuration integrity, because everything layered above inherits both their vulnerabilities and their lifecycle.

• Operating System Software

• Virtualization Software

• Container and Orchestration Software

• Web and Application Server Software

• Other / Enterprise-Specific Infrastructure and Platform Software

Integration and Messaging Software — Technologies that connect systems and move messages, events, and transactions between them. Governed because they create dependencies between otherwise independent systems, and because data in transit through them carries the same protection obligations as data at rest.

• Message Queue and Streaming Software

• Enterprise Integration and Middleware Software

• Application Programming Interface (API) Gateway and Management Software

• Other / Enterprise-Specific Integration and Messaging Software

Development Software — Technologies used to write, compile, build, test, and deliver software. Governed for software supply chain integrity and open source license obligation, because whatever enters the toolchain propagates into everything the enterprise builds.

• Programming Language and Runtime Software

• Compiler and Build Software

• Source Control Software

• Continuous Integration and Continuous Delivery (CI/CD) Software

• Code Quality and Testing Software

• Other / Enterprise-Specific Development Software

Security Software — Technologies whose primary purpose is protecting the enterprise, its systems, and its data. Governed for coverage and currency, because a control the enterprise believes it has but cannot account for is more dangerous than no control at all.

• Endpoint Protection Software

• Vulnerability and Compliance Scanning Software

• Identity and Access Management Software

• Secrets and Key Management Software

• Other / Enterprise-Specific Security Software

Operations Software — Technologies that run, observe, and automate the operating environment. Governed because the enterprise acts on the signals they produce and the changes they make, so their reliability and configuration are operational risk in their own right.

• Monitoring and Observability Software

• Logging and Log Management Software

• Infrastructure Automation and Configuration Software

• Other / Enterprise-Specific Operations Software

Artificial Intelligence and Machine Learning Software — The foundational AI and machine learning technology layer that AI capabilities and AI agents are built on and run within. Governed for AI oversight, model and data provenance, and regulatory alignment, and because it is the layer the enterprise’s governed AI agents depend upon.

• Machine Learning Framework Software

• Model Training and Serving Software

• Vector and Embedding Store Software

• Artificial Intelligence Compute and Acceleration Software

• Other / Enterprise-Specific Artificial Intelligence and Machine Learning Software

Other / Enterprise-Specific Software — A deliberate top-level slot for categories an enterprise recognizes that this representative framework does not name. Its presence is a standing reminder that the taxonomy is a starting point to be extended, not a closed set.

Adapting This Framework to Your Enterprise

A cloud-native enterprise with no data center may collapse Virtualization Software into Infrastructure and Platform Software, or drop it entirely, while splitting Container and Orchestration Software into finer subcategories that reflect where most of its estate actually sits.

A regulated financial institution may split Security Software into separate categories for preventive and detective controls and add a Cryptographic Software category, because its examiners assess those controls separately.

A manufacturer with significant operational technology may add an Industrial Control and Operational Technology Software category that this framework does not name at all, since its governance obligations differ materially from those of enterprise IT software.

A software product company may find Development Software to be the largest part of its estate and split it into several top-level categories, while treating all of Data Software as a single group.

The taxonomy above is where an enterprise starts, not where it finishes. IF4IT provides a representative framework; the reader uses it to build a comprehensive, enterprise-specific taxonomy suited to their own technology landscape and industry. The following prompt is a practical way to do that work with the help of an AI assistant.

I am developing a Software Technologies Inventory for my enterprise, following the best practices published by the International Foundation for Information Technology (IF4IT). Three IF4IT documents guide this work:

1) The ‘Software Technologies Inventory and Attributes’ ([inventory URL]), which defines a framework of attributes and a representative starter taxonomy of Software Technologies categories and subcategories;

2) The ‘Enterprise Inventory Management Best Practices’ ([EIM URL]), which defines the broader inventory governance methodology these categories align to; and

3) The ‘IF4IT Enterprise Model and Modeling Best Practices’ ([EM URL]), which defines the broader purposes, visions, and goals of managing such constructs.

My enterprise operates in the [industry] sector.

Starting from IF4IT’s representative category framework described in the ‘Software Technologies Inventory and Attributes’ ([inventory URL]), and staying aligned with the Enterprise Inventory Management principles, help me extend and adapt it into a comprehensive taxonomy for my enterprise by doing the following:

A) identify additional generic categories and subcategories relevant across all industries; and

B) identify additional categories and subcategories specific to my industry.

Organize everything into the same two-level (category and subcategory) structure IF4IT uses.

Treat this as a starting point that I and my organization will review, validate, and finalize according to our own needs — and note where I should verify a suggestion against my enterprise’s actual Software Technologies landscape rather than adopting it automatically.

You can work with your enterprise to give the AI even sharper scope for your industry or sector — for example, by pointing the prompt to your enterprise’s own website (or websites) and to those of peer or comparable organizations, all if and where it makes sense to do so. This helps the AI calibrate the taxonomy to enterprises like yours rather than to the industry in the abstract.

This taxonomy is a starting framework, not a finished or authoritative classification for any specific enterprise. Readers and their organizations are responsible for reviewing, validating, extending, and finalizing the categories to fit their own technology landscape, industry, regulatory context, and governance needs. IF4IT presents it as a foundation to build upon, not a standard to adopt unchanged.

How These Categories Bind to the Inventory

Every software technology registered in this inventory carries a Software Technology Category and, where two levels are used, a Software Technology Subcategory. These are classification attributes of the record, and the taxonomy above is the governed value set they draw from. Defining that value set once, in one place, is what keeps classification consistent as the inventory grows and what makes reclassifying a technology a matter of changing an attribute value rather than restructuring the inventory.