Application: Code that executes the logical steps necessary to automate a business process, scientific experiment, educational activity, game, personal productivity activity, or other general-purpose function. In theory, the application includes the code to (1.) present and/or monitor the machine or user interface, (2.) manipulate or compute, and (3.) store or present the results. In practice, the term application increasingly refers only to the code that manipulates or computes (called the "logic") because user/machine interface, data storage, printing, and other functions are handled by special-purpose code (servers or "services") that support multiple sets of diverse logic. These other codesets are accounted for in the IDC software taxonomy as portals, database management systems, print servers, and so forth. An application can be packaged and used by from hundreds up to millions of users in exactly the same way, or developed in-house or by a consultant specifically for a single purpose and a single user organization. In the IDC software taxonomy, the term application primarily applies to packaged business applications, software that is "touched" by anyone in an organization or enterprise, in contrast to application development and deployment software (typically only "touched" by a professional developer or highly trained knowledge worker) and infrastructure software (typically only "touched" by a systems administrator or, ideally, never "touched").

Architecture: A word that has already made one of the leading American English dictionaries to mean (among other things) "the manner in which the components of a computer or computer system are organized and integrated." In the IDC software taxonomy sense, architecture almost always refers to the way that software is organized and integrated by the enterprise using it (e.g., according to the client/server architecture, service oriented architecture, J2EE architecture, and so forth); architectures are not mutually exclusive.

Best of breed: See point product.

Business process: The word process in business process means "a series of actions or operations conducing to an end" (although that meaning of process is not even the primary meaning of the word in an English dictionary). Business process is therefore a series of "business" actions or operations conducing to an end. A key concept in the IDC software taxonomy sense of the term is that a business process is made up of multiple steps (and, in turn, multiple business processes can be thought of as "business process sets"). Also, in the IDC software taxonomy there are other types of processes, such as manufacturing processes, IT life-cycle processes, and so forth.

Client: Has various meanings throughout IDC research. In the IDC software taxonomy sense, client most commonly refers to a module of packaged or embedded software code, almost always including the user interface but also often including some logic that runs on a desktop or laptop PC or mobile device. Also, from a computer science sense, client means the requesting side of a client/server architectural relationship irrespective of whether the requestor is a user, a device, another server, and so on and irrespective of where it physically resides.

Collaboration/collaborative:In the IDC software taxonomy sense, the sharing (communication, coordination, and so on) of information and processes among humans, as in "Collaborative applications enable groups of users to work together by sharing information and processes." Collaboration includes both asynchronous (email, unified messaging, calendaring, team workspace) and real-time (instant messaging, Web conferencing) technologies and processes.

Components: Reusable sets of code, no matter how coarse, but not intended to stand alone. Components are like modules, but modules often stand alone. In the IDC software taxonomy, a framework dependency, no matter how minimal, is assumed.

Composite: A type of software, primarily applications, that is either packaged or in-house-developed from services or components in multiple tiers with open interfaces and that interoperates (may or may not be based on events). The term prebuilt is often used to modify components in this context to mean that the component is in existence before a "composition process" begins. Composite applications can operate in any kind of component-based framework, like Java Beans or ActiveX/DCOM. (Note that composite applications are a type of — or subset of — component framework–based applications in that components can be used to build applications other than composite applications but composite applications always contain components.) The term open modifying interfaces is meant to avoid the issue of whether the API is proprietary or nonproprietary, or — if nonproprietary — of whether it is a de jure or de facto standard. (If the components' suppliers publish the interface definitions so that others can "write to them," even if others have to pay a fee or royalty, they are "open." Furthermore:
Composite applications can be hierarchical, which means one composite application can be embedded in another composite application (but they do not have to be architected in that way).
Composite applications can be made up of several tasks that could be distributed among several logically separate processes located on several physically separate machine resources (but they do not have to be deployed in that way).
Packaged composite applications are developed by and available from ISVs, while composite applications can be created by internal or external developers or users for specific combinations of business process in advance or on the fly.

• Any type of data source, structured or unstructured, is supported.
• Note: The IDC software taxonomy definition of composite does not imply Web services (or any other specific technology) as a requirement, portals (or any specific number or type of "tiers") as a requirement, or the Web Services Architecture (WSA) or any other architecture as a requirement.

Data: From the mathematical use of the Latin word (data, plural of datum, meaning "given") used to describe a set of values assigned to variables in an algebraic equation in order to perform a calculation. In computer terms, data refers to a set of one or more values provided to a computer program in order to carry out some activity. This word, although plural in form, is often used in the singular to refer to a specific set of data. Typically, the word is not used in its singular form; rather, when one refers to a single value, the preferred term is "data point."

• Data is normally classified in three categories: structured, unstructured, and semistructured:

Database: A collection of persistent (that is, stored) structured data used by a collection of computer programs, typically an application, and usually shared by multiple programs or components; may also be acted upon by users through query tools. The database may consist in a number of files having specific record types, the formats of which are incorporated into the program code that uses the data, or it may be stored and controlled by a database management system, which acts as an intermediary between the database and the computer code and users.

Database management system (DBMS): A collection of one or more computer programs that manages a database. Such management activities include the storage and retrieval of the data and enforcement of any data format and integrity rules and may also include facilities that enforce security rules, provide query and reporting capability, and offer interactive access to multiple processes simultaneously. A DBMS may be relational (that is, applying rules derived from relational data theory including the organizing of data into tables consisting in rows and columns with support for foreign key relationships, and basing access on SQL), but not all DBMSs are relational.

Distributed computing: Literally computing where any one of the system components or resources is remote from other system resource or components. The term dates to the time-sharing systems of the 1960s; however, because almost all computing — with the possible exception of some academic and classified governmental computing activities — has met that definition since approximately 1990, the meaning has morphed in a very loose and imprecise manner to mean a type of computing different from mainframe-based (or host) computing and in which the database and application logic are "distributed" even if only logically. The term distributed computing is often used synonymously with client/server.

Embedded: Software incorporated in limited-function devices and unavailable separate from the device; such products could incorporate machine-level instructions and general-purpose functions to control the operation and use of processor resources.

Engine: Often used as a synonym for server or service.

Enterprise application integration (EAI): Literally any connection between packaged or in-house-developed enterprise applications. The term morphed during the 1990s to mean a market for packaged software, freestanding from the applications themselves that enabled such connections within an organization. In the IDC software taxonomy sense, EAI refers to a type of software that is also called A2A to distinguish it from B2B software (B2B software connects applications among organizations); since 2001, EAI has been a submarket of integration server software platform (ISSP) and has not been measured separately by IDC.

Enterprise information integration (EII): Literally any connection between in-house or third-party data sources. The sources are presumed to be structured, but that is not required.

Enterprise Service Bus (ESB): Literally the message-oriented-middleware (MOM) queue structure that supports the interoperation of services. The IT community has adopted the term more broadly to refer to not only the queue structure but many of the associated services artifacts or modules that attach to the queue, and even the architecture itself (see Worldwide Message-Oriented Middleware 2005–2009 Forecast and 2004 Vendor Shares: The Number of Bus Routes Is Growing, IDC #34156, October 2005); in fact in some cases, ironically, IT suppliers even use the term ESB when no "enterprise services" are involved. In the IDC software taxonomy, the term ESB in its narrowest definition is part of the MOM market and in its broadest definition the functionality is scattered across the software market spectrum.

Environment: See platform.

Event: In the IDC software taxonomy, the term event is used in multiple ways (and not just in the complex event processing sense that has evolved in IT marketing since approximately 2002).

• In the BPA deployment software market definition, we are referring to the fact that a business process is kicked off by an event in the dictionary sense of the word, as opposed to an exception-based or straight-through process kicked off by data. However, the term event should not be considered exclusively related to business processes; an event can be a consumer interaction or even a machine-to-machine nonbusiness interaction. Event in the BPA deployment software market definition is best understood as used in the systems management software and telecommunications senses of the word (the latter appears to be the original source of the term). Event processing within applications may be accomplished using connectors, also called adapters, which allow the events to be filtered or initiated dependent on the fulfillment of a condition, or the event may be a human interaction.
• In the definition of event automation in the taxonomy section, it is by definition something unscheduled.
• In the term event-driven architecture (EDA), event means a change to the state of the system according to the structure by which that structure is managed. If that system is message based, then it could mean the reception of a message. If the system is data based, it could mean a change to a data value for which an event type has been defined. An event may result in the emission of a message to be handled by some component or service (an event handler), or it may result in direct action by the detecting agent (which could be a DBMS, or a stored procedure, or a message systems "listener").

Framework: The term framework tends to be loosely used in the IT industry. To some in the development world, frameworks are code bases that provide a unified structure with underlying support functionality and set guidelines; in this usage, application development tools are built on top of application frameworks that follow architectures such as Microsoft .NET and Java 2 Enterprise Edition (J2EE). In the deployment world, a framework is a type of integration server software platform (ISSP) as defined in the software taxonomy (see above) where the framework provides intelligent routing, message filtering, and transformation (i.e., it is sort of an ESB on steroids) tied to either events or data. (But in the case of a composite application framework, it is an event by the definition of composite application.) A framework does not provide the execution environment for the components themselves but simply the abstraction of that environment. (The execution environment for the components is in the software on which the framework rests, which could be another type of application deployment software such as an application server, a packaged application, or underlying infrastructure software such as an operating system.)

Feature: Characteristic of software typically acting as a market differentiator (as opposed to a function).

Integration: Another one of those all-encompassing terms, like distributed computing, that are so broad and so pervasive as to no longer be useful in defining or modeling IT market sizes or trends. In the IDC software taxonomy, almost all software applications, tools, and infrastructure include integration of some type among their data, logic, and interaction code and among the various physical layers of a computing system/network as represented in the ISO 901/OSI seven-layer model. The term is also widely used relative to other IT technologies such as systems, storage, and telecommunications.

Life cycle: In the IDC software taxonomy sense, refers primarily to the chronology of an application's development and deployment. Known as the IT life cycle, it can be managed in much the same way as business process sets (and, in fact, often the same technology — modelers, content tools, rules engines, and so on — are used). However, as with integration, the term is also used elsewhere in IDC research extensively.

Master data: IDC refers to two general classes of data used by applications: reference data and transactional data. Transactional data is data created and managed during business transactions, and is related to specific business processes. Transactional data is typically created at the beginning of a business process and destroyed or archived at its end. Examples of transaction data include orders, trouble tickets, inventory items (created when something enters the inventory, removed when it is shipped out), and so on. Reference data is data that describes facts about the business that are referenced during the course of business, but have no specific process-determined point of termination. Examples include customers, products, employees, and so on. Such things are removed and archived, but occasionally, and not as a matter of course. Master data is reference data that has been identified as data representing key facts of the enterprise. Master data must be unambiguous; it must be available to all who are authorized to see it, it must reliably reflect the true facts of the enterprise, and its access, including insertion, alteration, reading, and removal, must be controlled and recorded for auditing purposes. Reference data is often managed as master data for legal compliance or general corporate governance reasons.

Master data management: The set of processes to create and maintain a single view of business entities that need to be shared across applications, such as customers, products, locations, or accounts. This includes the policies and procedures for access, update, and overall management of this data (usually through a physical or logical hub) and its coordination with other participating applications across the enterprise or, in some cases, across enterprises. The management of master data may include its compilation from various application databases, control of its access, synchronization of master data with data in various application databases, auditing of access to master data, and archiving of master data regarding things that are no longer an active part of the business. Master data management software includes a subset of data integration software, data security and auditing software, end-user query and reporting software, and some products that are specific to the task of master data management.

Message/messaging: Primarily refers to any form of software or services-based asynchronous or real-time connectivity. By custom, in the IDC software taxonomy, message (as in message oriented) typically refers to connectivity among systems or among components or resources within systems, while messaging (as in email or instant messaging) refers to connectivity between individuals or groups. Technically both work the same way in that they post and or publish and the recipient or subscriber receives whenever convenient (while whatever else is going on proceeds, not dependent upon a response, or at least the timeliness of the response).

Metadata: This term is usually used to refer to data about data. More generally, metadata is data about any aspect of a computer system, including hardware and software that is used to define, manage, and control computer hardware and software. Metadata about data includes data that tells computer programs and database management systems about the location and format of data, data that tells users about the meaning of data, data that is used to insert data definition statements in program code, and so on. Metadata also refers to data that is used by data integration software to merge, or transform, data. Other kinds of metadata include:

• Modeling and design metadata, which describes models of data and processes
  
• Control metadata, which governs the operation of network and operating systems
  
• Catalogs, including user catalogs, system catalogs, and other catalogs that drive system operations and security
  
• Mapping and routing metadata, which governs the ways that messaging and intermediary services map, transform, and route service requests and other messages

Middleware: Formerly defined in IDC's software taxonomy as independent system software, services, and runtime environments that distributed software of all sorts. The term has become so broadly and imprecisely used in the IT industry that it is no longer defined as a market by IDC (see application deployment software in the functional market taxonomy as well as What Is Middleware? IDC #34362, November 2005).

Module/modular: A functional subset of packaged software typically not sold separately but which typically stands alone technically (also see components).

Object: An object is a very specific type of component that follows the de facto and de jure standards associated with object-oriented programming and architectures.

Platform: See framework.

Point product: A piece of software designed for a single function or very limited set of functions that is sold separately, as opposed to a suite.

Procedure: In common software market usage, it refers to the opposite of object. Historically, procedures are the "computational orders" that John von Neumann and others theorized about in the mid-1940s, instructions that could be stored along with data and therefore repeated without having to be hardwired into a special-purpose computing device or recreated each time a function was to be automated in a general-purpose computing device. This theory is considered the principle that spawned the information technology era.

Process: See business process; there can also be scientific, educational, etc. processes.

Product: Simply what an IT technology supplier sells; not limited to just software (e.g., a system or a service offering can be a product); something with a predefined definition and price.

Pure-play: This term is often associated with a software supplier that markets a product that competes in only one or two functional markets.

Real time: The ability for a solution or system to respond in a predetermined time to scheduled activities or interrupt-driven events. Often involves a "live" session for nearly instantaneous information exchanges (opposite is asynchronous).

Server: Various meanings: In the IDC software taxonomy sense, typically a module of or even a disaggregated service within a packaged software product. Servers almost always provide application logic or other services (especially database management) that run apart from a desktop PC. Also, more accurately, server means the serving side of a client/server relationship irrespective of whether the server is desktop PC based, resident on another server, transient, etc.

Server workload: Other research groups within IDC offer measurements of annual hardware systems sales based on server software workload. There is no explicit relationship between the server workload taxonomy and the software taxonomy, but it is possible to devise a rough mapping by comparing the naming. The major issue in comparing the two is that the server workload measurement includes an estimate of both packaged and in-house or consultant-written (i.e., not packaged) application software, whereas all software categorized by the software taxonomy is packaged. Finally, the software taxonomy includes some types of software (e.g., operating systems) not categorized in the server workload taxonomy.

Service: Other than solution and integration, there is probably no word in the software taxonomy with more meanings than service. In the software taxonomy sense, service typically refers to a codeset that performs a set of limited tasks, such as checking identity, controlling access, and so forth, that can be used in many computational situations. Often — but not always — the idea of "contract" or service-level agreement is included. Increasingly, "higher order" software such as packaged applications and applications deployment software is being decomposed into services to eliminate redundancy in such tasks as reconciling charts of accounts (in multiple types of accounting software) or synchronizing application server software (e.g., across multiple physical servers).

• Note that there are certainly many references to service throughout this document where the meaning of the word is more conventional (that is, meaning the opposite of product). Even when this is the case, there is the potential for confusion; for example, maintenance services are included in the definition of software revenue but professional services such as for training or implementation are not.

Service oriented architecture (SOA): An architecture based on the disaggregation described in the definition of service above. For more detail, see the relevant section of the taxonomy.

Suite: The combination of software products, modules, or services to provide a more complete set of software functionality and to eliminate redundant activity. Often, the combination is accomplished in an integrated computer science sense, and just as often the combination is purely on paper in a marketing sense. A suite is the opposite of a best of breed or point product.

Solution: When not obviously used in its English language sense, the word means a combination of systems, software, and services as defined by IDC in its multiple taxonomies. Given its multiple confusing meanings, it is not used very often in the IDC software taxonomy.

Standard: De facto or de jure definitions of industry-specific data sources, languages, protocols, application programming interfaces, data structures, and so forth. Primarily standards support IT software portability, but there are many other uses. The term applies throughout IDC research as well. Note that an architecture can be standardized but does not have to be; also note, IT suppliers are not adverse to calling products or features of their products standard when they are not.

Tool: Software used by professional developers; in the IDC software market taxonomy sense, tools is the short version for the application development and deployment primary market. In general, almost all types of software have tools built in.

Transaction: A coherent unit of processing that typically has to come to complete before some other processing can continue; the opposite of message.

User: Typically a person who interacts with a single specific computing infrastructure on a daily basis, as opposed to a professional developer or systems administrator.

Virtualization: The process of logically removing physical or other limitations in a given set of technologies (that is, virtual memory is not truly unlimited and free from the restraints of the size of RAM but other storage media are manipulated by the operating software to make overall memory appear unlimited). In the IDC software taxonomy sense, virtualization refers to a six-layer model involving 16 individual types of functional software that as a whole hides the complexity and limitations of lower-order technology (system, network and storage resources, infrastructure software) from users and professional developers.

Web services: By IDC's definition, Web services are Internet technology–based machine-to-machine services (in the computer science sense of that word) that are based on what IDC calls the Web Services Architecture (WSA). The WSA is a standardized approach to dynamic component connectivity and interoperability that relies on self-describing components that interoperate at runtime and open connectivity standards including Internet Protocol (IP), Simple Object Access Protocol (SOAP), and Web Services Description Language (WSDL). Other standards, such as eXtensible Markup Language (XML), are evolving to meet operational and business process semantic requirements and, as they mature, will become part of the WSA.

Workflow: Although there can be other types of workflows in addition to business process workflows, theorists use the term workflow to describe all types of business process flows; in common usage it has come to refer primarily to human-centric rather than straight-through flows.