Data Object : ArchiMate

Data structured for automated processing. A data object should be a self-contained piece of information with a clear meaning to the business, not just to the application level. Typical examples of data objects are a customer record, a client data set, or an insurance claim. The name of a data object should preferably be a noun.

Course of Action : ArchiMate

An approach or plan for configuring some capabilities and resources of the enterprise, undertaken to achieve  a goal. A course of action represents what an enterprise has decided to do. Courses of action can be categorized as strategies and tactics. It is not possible to make a hard distinction between the two, but strategies tend to be long-term and fairly broad in scope, while tactics tend to be shorter-term and narrower
in scope.

Contract : ArchiMate

A formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product and establishes functional and non-functional parameters for interaction. The contract element may be used to model a contract in the legal sense, but also a more informal agreement associated with a product. It may also be or include a Service-Level Agreement (SLA), describing an agreement about the functionality and quality of the services that are part of a product. A contract is a specialization of a business object. The name of a contract is preferably a noun.

Communication Network : ArchiMate

A set of structures that connects devices or system software for transmission, routing, and reception of data. A communication network represents the physical communication infrastructure.

Capability : ArchiMate

An ability that an active structure element, such as an organization, person, or system, possesses. Capabilities focus on business outcomes. They provide a high-level view of the current and desired abilities of an organization, in relation to its strategy and its environment. They are realized by various elements (people, processes, systems, and so on) that can be described, designed, and implemented using Enterprise Architecture approaches. Capabilities may also have serving relationships, such as to denote that one capability contributes to another. Capabilities are often used for capability based planning; i.e., to describe the evolution of capabilities over time. To model such so-called capability increments, the specialization relationship can be used to denote that a certain capability increment is a specific version of that capability. The name of a capability should emphasize “what we do” rather than “how we do it”. Typically, it should be expressed as a compound noun or gerund (-ing form of verb); e.g., “Project Management”, “Market Development”, “Product Engineering”, etc.