Loading...
 

Grammar of enterprise modelling

Grammar of enterprise modelling

Introduction

The "grammar" presented here is intended to be a brief, summarizing guide to the CyberEnterprise enterprise model. The individual bullet points should always be seen in conjunction with the previous sections.

Information Models

  • Information models are initially only purely linguistically formed structures of words/phrases.
  • Consequently, information models obey the usual grammatical categories of natural languages. (Example: companies, parts, outgoing invoices, date are nouns, add, subtract, calculate are verbs, earliest, lowest, maximum are adverbs or adjectives)
  • Each information unit of an information model must therefore be able to be described exactly in terms of language.

Data fields, entities and relations

  • Data fields are the smallest information units of an information model.
  • Data (fields) are formed from simple and/or complex data types (objects). (Example: text (STRING, MULTIPLE_STRING), real numbers with or without unit (INTEGER, CX_NUMERIC, CX_FLOAT, CX_VALUE), date (CX_DATE, CX_SPAN_DATE, CX_PERIODIC_DATE))
  • Data (fields) are grouped into semantically related entities (classes). (Example Person CX_PERSON, Part/Article CX_ITEM)
  • Entities can be restricted in their validity depending on their use (validity, security, domains).
  • Entities can be extended by any entities, data (fields) and/or relations (container principle, slots).
  • Relationships between entities are basically to be regarded as mutual (back references), but cannot be implemented in this way for purely technical reasons.
  • Existence or non-existence of data (fields), entities and/or relations in an entity has per se its own information content.
  • Relationships themselves can be extended or changed in their information content (wrapper concept, description of the edge).
  • Entities, their data (fields) and the relations to other entities are defined and manipulated with the help of an IT system.

Company model

  • An enterprise model defines a (technically) fundamental but (business-oriented) limited or expandable network of relationships between entities.
  • The (technical) network of relationships between these (technically) different entities is independent of its use.
  • A use-case only defines the scope of use and the view on data (fields) and their relations among each other, but not its (technical) basic structure.
  • Identical (technical) entities can be distinguished in their (business-oriented) use (concept of pseudo-classes).
  • Entities of an enterprise model are (technically) differentiated into information data (Basis objects), master data (business objects), transaction data (transactions (OLTP)) and accounts (data cubes (OLAP)).

Master data

  • "Master data" is divided into "real things" (material, tangible) and "concepts" (immaterial, non-tangible).
  • "Terms" stand for themselves or have a relationship to "real things". In this context, you have the task of describing the properties/function of real things (role concept). (Example: Company (material)/customer (immaterial), building (material)/warehouse (immaterial))
  • "Real things" can be related to any number of "terms" and/or extended by any number of "terms".
  • "Terms" can(should) only be related to other "terms" if the "terms" are orthogonal to each other. (Example: cost center / warehouse)
  • "Master data" can be categorized/structured. (Example: companies by sales areas, articles by article groups)
  • "Master data" are described in more detail by means of "Information data". (see section Data fields, entities and relations)
  • "Master data" form the focus for "Transaction data".
  • "Master data" can have any number of "accounts" (monitors) defined from different processing aspects, which hold the corresponding "transaction data". (Example: Financial accounting account with journal data, customer sales account with A/R invoices)

Motion data

  • "Transaction data" can be booked and unbooked with rules (business logic).
  • "Transaction data" changes the status and accounts of related "master data" during each posting transaction using the data (fields) accessible via "transaction data" (business process I). (Example transaction (rule) description for goods receipt document: Quantity delivered increases the stock of an article warehouse account)
  • "Transaction data" changes its own status with every posting activity (business process II). (Example: Order status: opened, issued, ordered, cancelled)
  • "Transaction data" has "transaction data" as predecessor and successor (business process III). (predecessors and successors relations)

Accounts

  • "Accounts" have any number of sub-accounts of any dimensions, which are created automatically by means of rules.
  • "Accounts" and their sub-accounts are only posted to using rules, i.e. setting and changing data (fields) and registering or deregistering "transaction data".
  • "Accounts" and their sub-accounts support the "drill-down" up to "transaction data". "Accounts" and their sub-accounts support "roll-up" up to the "master data" they contain.