A  Business Process is a set of Business-Process Steps performed by Org-Units and/or by automated systems (Business Systems) to produce a Business Outcome Event. It is depicted as a series of Business-Process Steps, controlled by Business Events and conditions.

Business-Process Steps are carried out by the involvment of Org-Units and system resources (often Applications) as participants in the process (Participant Business Agents).

During its course of action, a  Business Process consumes or produces  Business Objects.

1) It may memorize or access  Business Objects from its Process Store.

2) It may receive  Business Objects at its boundary: Business Outcome Consumption.

3) It may signal the production of  Business Objects at its boundary: Business Outcome Production.

The course of actions of a  Business Process is constrained by the application of rules ( Business Rule Enforcement) that define how to react to what is allowed and not allowed to do,

A  Business Document is a document whose lifecycle can be synched to the MEGA repository content: it may be attached to mega objects and a document version bound to a mega object timestamp in the Time Machine. This document can be of any given file format.

The  Business Document versions are managed within the MEGA repository and the document storage file in the file system can be cyphered.

A  Business Rule is a rule that is under business jurisdiction.

A rule’s being under "business jurisdiction" means that it is under the jurisdiction of the community that it governs or guides - that the community can opt to change or discard the rule. Laws of physics may be relevant to an Enterprise; legislation and regulations may be imposed on it; external standards. These things are not  Business Rules from the company’s perspective, since it does not have the authority to change them.

The company will decide how to react to laws and regulations, and will create  Business Rules to ensure compliance with them. Similarly, it will create  Business Rules to ensure that standards or best practices are implemented as intended.

A  Business Capability is a conceptual Capability that benefits to Customers (internal or external) of the enterprise. It expresses an ability to produce Conceptual Outcome Events.

A  Business Capability is defined by its intended Enterprise Outcome Events and the conditions (Condition Property) under which the production of the Enterprise Outcome Events shall be proceeded.

The actual Condition Scale Values for a given Business Capability at different stages of Enterprise Initiatives is given by their exhibition (Exhibited Capability).

A  Concept is the representation of any tangible or intanglible entity that is of interest to understand the enterprise, its data, resources and activities.

A  Concept is defined through its essential characteristics which can be:

1) A  Concept Property that represents some an immutable factual characteristic such as "name", "amount".

2) A Concept Relationship that represents relationships to other  Concepts.

An  Information Entity is an Information Asset that is not fundamentally defined by its attributes, but rather by its continuity.

An  Information Entity evolves over time and has states.

For instance a person is an  Information Entity. Employe is a state of a person.

An  Information Entity has relationships to other  Information Entitys and can have  Information Propertys.

A  Directive is an authoritative declaration that indicates how Agents and their Behaviors should be (or should not be) in the enterprise.

Specifically, a  Directive defines, constrains or liberates some aspects of an Agent and its Behaviors. As such,  Directives shall be considered as constraning  Asset Propertys.

 Directives are intended to assert agent structures or to control or influence their Behaviors.  Directives are stated in declarative form.

A  Location is a geopolitical location anywhere on the earth.

Examples:

- France

- Paris

- Washington DC

- Cairo

- Buenos-Aires

- Asia

A  Logical Data Entity is a logical structure of a Data Entity. As any Data Entity, it has an independent existence and can be uniquely identified.

A  Logical Data Entity is characterized by Logical Relationships it has with other  Logical Data Entity(ies) and by its Attributes.

A  Concrete Hardware System is a man made tangible artifact which exposes  Hardware Capability(ies) and can produce and react to Physical Outcome Events.

A  Concrete Hardware System performs System Processes and participates to System Processes or to Business Processes.

A  Concrete Hardware System can embed Computing Systems. Together with its embedded Computing Systems, a  Concrete Hardware System can also produce and react to Information Outcome Events.

A  Concrete Hardware System may be based on a set of Hardware Technology(ies).

Examples:

- Connected Drone with Online Payment App.

- 3D printer.

- Automated Guided Vehicles (AGVs)

- Connected fridge providing an ordering  Functionality and of course a freezing  Hardware Capability.

- Production equipment in an assembly line (metal forging machine)

- Car

A  Condition Property is a possible value of a Condition Property Type such as a delivery time of 30 minutes, a weight of 20 kg, a high level of confidentiality, stormy conditions.

A  Condition Property is either a single measure (Measure Property: a weight of 20 kg), an Environmental Property (stormy conditions.) or a Set of Condition Propertiess.

 Condition Propertys are used to constrain Asset Blocks in the context of non-functional requirement analysis and Value Proposition analysis.

Examples:

. Cost of 100€

. Delivery time of 30 minutes.

. Weight of 20 kg.

. Temperature of 18 degree Celcius.

A  Department Type is a Mezzo Org-Unit which serves as an administrative unit template in both government and business Organizations.

Examples:

- Sales department;

- Finance department;

- Logistics department..

An  Organizational Position is a type of position held by people when part of a Department Type.

Examples:

- Sales representative

- Developer

- Storekeeper

- Architect

A  Relational Entity is a relational data structure that is either a Table or a Table View.

A  Relational Entity is accessible by means of a primary key, and if necessary foreign keys; it is described by an ordered sequence of Columns.

A  Behavioral Rule is a Directive intended to guide the Behavior of Agents, in compliance with enterprise Policy(ies) or regulations.

Often, a  Behavioral Rule is derived from a Policy.  Behavioral Rules are enforced in Processes and Agents.

A  Functionality is a Business Resource Capability offered by Business System Assets (software or hardware) and aimed at delivering Information Outcomes.

A  Functionality describes WHAT a software or hardware system can provide.

 Functionality(ies) are used to express the Business System features required by people when performing their job (see Job-to-be-done).

For internal customers, these jobs correspond to Business-Process Steps described in Business Process (see Instrument)

For enterprise Customers, these jobs correspond to Job-to-be-done in the context of Customer Journeys.

A  Skill is an ability of a human resource to produce Business Outcome Events.

 Skills are acquired and refined through training and practice.

An  Application is a Business Software System that provides a set of  Functionality(ies) that End Users see as a single unit.

Essentially  Applications are architectural constructions resulting from the combinaison of the following four criteria:

1) A group of  Functionality that End Users see as a single unit.

2) A managed asset (Managed Application) associated with a budget line in the context of an Application Portfolio.

3) A body of code that is seen by developers as a single unit.

4) A group of deployable software units (Deployable Application Packages) that must be installed together on one or multiple execution nodes (Computing System).

 Application is a Mezzo enterprise asset  that sits between Application System and Application Component in the decomposition of Business Software Systems.

Example: " Payroll" is an  Application that is part an " HR System" which is an Application System.

The "Payroll"  Application includes, among other things, the "Salary and Wage Calculation" Application Component.