The CyberEnterprise business model
- Real objects and terms: the actual business objects
- Principles of modelling
- Business objects as functional modules
- Basic mechanisms of business applications
- Dynamization of the model through transactions
- The Transaction Manager
- Special objects of the CyberEnterprise
The corporate model is the focus of the considerations. It is necessary - independent of a specific application functionality - to define the basic building blocks with which real enterprises can be virtually modelled in all their complexity: The implementation of a cybernetic enterprise, a CyberEnterprise.
For this purpose, real business data and processes must be reduced to a few, different structures or abstracted. Recurring data structures and calculation algorithms must be prepared in such a way that they can be used as building blocks for any business application.
The basic building blocks obtained in this way then form - due to their arbitrary combinability and expandability - the diversity of corporate information and processes. As part of the CyberEnterprise architecture, they enable the efficient programming of complex business applications.
The following sections describe the structure of the model from "top to bottom", from the more complex actual business objects to the very specific basic objects. This approach should make it easier to understand the abstraction of real, business realities.
The static image of companies is described by the real objects: partners and things. These objects represent data entities that appear and are the same for all parties participating in the economic process.
The information and characteristics of real objects relevant from the point of view of the company (client) to be modelled are represented by terms that are directly related to a real object: e.g. the term "customer" describes the role of a partner who receives goods or services from the client in return for payment. The descriptive attribute "customer" contains only the data that is necessary for this business relationship. Other terms (or property objects) can be assigned to the same partner, such as the term "vendor". The same terms can also be assigned more than once to a real object (for example, different "customer" property objects with different conditions for different product groups or projects).
Different terms are assigned to a real object at the same time - usually for purely accounting purposes. Furthermore, terms also represent all organizational units, such as cost center, order or balance sheet item. Terms or accounting objects can be understood as semantic aspect classes for the real business objects.
During the development of the CyberEnterprise the following - partly competing - objectives were considered:
- high abstraction (reusability of the objects)
- easy expandability (clearly structured model)
- high flexibility (any combination of objects)
- broad functionality (intelligent objects)
- Great clarity (not too many object types)
- good readability (easy to understand model)
- Low memory requirements (lean, high-performance objects)
According to the above order, the CyberEnterprise enterprise model is based on the high abstraction and easy extensibility of its elements as the most important principles.
The C++ classes for the business objects from the CyberEnterprise enterprise model are therefore designed with a high demand on generality and contain only the essential data fields and methods. They are nevertheless suitable as building blocks even for very individualized requirements, since
- they can be extended by dynamic data fields of any type (so-called slots)
- by means of these dynamic data fields any relations between objects can be established
- the calculation rules and selection rules are moved from the program code to various objects
- the interaction of the objects can be controlled in various ways with InstantView instructions
- special algorithms can also be formulated with InstantView instructions.
In the following sections, the different types of business objects in the CyberEnterprise enterprise model are discussed, and a summary of the principles for enterprise modeling is provided in the form of a grammar.
Within the CyberEnterprise there are three levels of objects of different complexity:
- Basic objects encapsulate information about date, time and values; they are objects of very specific and limited functionality.
- Information objects process attributes or characteristics of e.g. parts, store surcharges or discounts for e.g. prices, define allocations (bills of material or routings), manage calendars, contain transaction management objects and monitors (accounts and multidimensional data cubes), etc. From a functional point of view, this level contains the most modules.
- Business objects then only use these basic and information objects to manage their own data and methods. This type of business object is most comparable to the entities of traditional business software.
In addition, there are various tool classes, classes for print output, for the import and export of data, classes for COM objects, XML classes, especially for .docx and .xslx Office support, etc.
Each building block (C++ class) of the CyberEnterprise Enterprise Model also defines its behavior for
- the arithmetic operators (+, -, *, /).
- the comparison operators.
- the conversion into a string.
- the import of a character string.
- access to data fields, binding of data fields to variables.
- the addition of further data fields and references to other objects.
- the call of methods.
The basic and information objects of the CyberEnterprise introduced above provide a number of basic properties to facilitate the modeling of business conditions. In the following some special properties are listed as examples:
- Unit arithmetic A class (CX_VALUE) is available for
calculations, which calculates with a tuple of numerical value and dimensional specification (represented internally as a prime number). The program code does not specify which units are used for calculations in an application. This unit arithmetic is a basic prerequisite for the formula objects mentioned in the following point. The user can define his or her own units and conversion rules.
- Calculation rules, condition tables Calculation rules
and condition tables should not be part of the program code, but data to be defined by the user. A formula object (CX_FORMULA) and an object for condition tables (CX_CONDITIONED_BAG) based on it are available for this purpose.
- Amounts If
there are amounts in the business objects (price, quantity, ...), it should not be determined from the outset whether the value is fixed, whether it is to be calculated or whether it is to be searched for in a table. To keep all these and other possibilities open, the class CX_AMOUNT exists, which treats the amount as a polymorphic abstraction.
- free definition of characteristics Orders
, products, and so on, are often described by characteristics that must be defined by the user1. Objects of type CX_ATTRIBUTE solve this problem. With the formula and conditioned bag objects mentioned above, calculations and selection algorithms can be made dependent on the characteristic values.
- Default values Often
a value is only explicitly specified if it deviates from a standard specification. The default value can be a property of the data field; however, it is also possible that the value is to be taken from a logically superordinate object - a construction that can extend over any number of hierarchy levels. CyberEnterprise supports semantically controlled access to data elements.
- Enumerations Traditional
applications work with a multitude of keys and abbreviations and expect the user to know them. In the CyberEnterprise system a translation table can be registered for such data fields. The user interface then always displays the term in the currently set language. The translation tables are maintained by the user.
- Aspects A
relationship between two objects often has a meaning that is inherent only in that relationship, but not in the two related objects: The referenced object is seen by the referencing object under a certain aspect. CyberEnterprise provides objects of type CX_DESCRIPTIVE_REF for descriptive references.
- Overwrite values When transaction data is generated
from master data, you often cannot use a reference to the master object because the newly generated data has different values in some data fields. In such cases, an overwriting reference (CX_OVERWRITING_REF) avoids a copy. With this construct, the value of a data field of an object depends on the navigation path used to reach this object.
- Conditional references For
relations between objects that are subject to certain conditions, the CyberEnterprise provides objects of type CX_CONDITIONED_REF.
- Loose coupled references For
loose coupling of information, e.g. if it is in other databases or provided by an external service, references can be set up which automatically call up freely definable program sequences at the time of the information request.
- Validity of an object Sometimes
, different objects stand for a subject, one of which is always valid at a certain time or under a certain condition. These objects can be combined in a cluster, and a reference to an object in the cluster is automatically redirected to the object that is currently valid.
- Searching for objects under any name Often
the same things are called by different names in different areas of a company (e.g. technically oriented - sales oriented). Business objects can be entered and retrieved in a Dictionary object under any number of names (multilingual).
- Number ranges Almost
all documents in a company are numbered consecutively for organizational reasons. It is also useful to assign a unique identification (number) to master data (for example, articles). CyberEnterprise provides counter objects that can be addressed via identifiers.
- COM objects For the
seamless integration of Office or other OLE based applications, COM objects can be stored directly in the CyberEnterprise database and connected to business objects as required using dynamic data fields. All functions that a COM object provides via the DISP interface can also be called with InstantView.
1 as they are not yet known at the time of programme development
Every activity in a company which - for reasons of organisation and more efficient design - is to be represented by means of IT, is described by transaction objects. Usually, such transactions are accompanied by documents, such as order confirmations, delivery notes, invoices, material withdrawal certificates, posting documents in accounting or outgoing orders.
These activities or transactions always lead to a (status) change of business objects. An order confirmation increases the order stock, possibly reducing the available stock of an ordered stock item. You can also use transaction objects to edit individual data fields (changing an article description) in order to obtain a complete history of business processes (in this example: maintaining article data).
In addition to the data of each individual transaction (date of the order confirmation, amount of the invoice, quantity of an article withdrawn), the cumulation of individual values is usually of interest, and this with certain dimensions (e.g. incoming orders per month and sales area). This is referred to as a multi-dimensional data view: The value "incoming orders" should be stored in the combination of period and sales area, e.g. 412,350.-€ incoming orders in July 2014 in sales area North.
Multidimensional data is stored in so-called data cubes or cells, in our example the incoming orders with the two dimensions period and sales area. In this way, parallel processing of OLTP with OLAP (online analytical processing) takes place.
Which data of which business objects should be changed or which values should be saved with which dimensions is controlled by entries in a transaction manager. Each transaction has its own transaction manager.
The automatically generated data cubes - one-dimensional (if the period is not counted!) usually called accounts - register the flows of quantities and values generated by transactions. All dimensions of the desired data cubes (e.g. the revenue account) must be uniquely identifiable from the data within the transaction (e.g. from the article).
Consolidation paths within dimensions (sales statistics also per customer group and year) are at the discretion of those who describe a transaction with the transaction manager and are not automatically generated. Even if higher aggregated data cubes are not updated immediately with every transaction, this data can be determined at any time by cumulation. Complete drill-down or roll-up is guaranteed.
In the CyberEnterprise any data fields can be defined dynamically and additionally stored in each business object (dynamic data fields or slots). A definition of these data fields is usually done by the system administrator, in connection with the extension of the applications or screen masks from which these new data fields can be maintained.
Dynamic data fields are used like normal variables defined in the classes and define only the data type. For the user, the meaning of the data field only results from the prompt on the screen or the title on a printout.
An object of the class CX_SLOT_ATTRIBUTE encapsulates a dynamic data field and thus allows the user to add further information to this slot: for example, a multilingual name, a default value, or even a validity area. These attribute objects can also be added to business objects as often as required.
For example, an article can be additionally provided with the attributes or characteristics for color, diameter or weight. A standard color can be provided or a maximum weight can be defined. These specifications are also possible without changing or extending applications or screen masks.
The management of several CX_ATTRIBUTE objects is handled by the class CX_ATTRIBUTE_SET, which is an extension of a business object. Such a CX_ATTRIBUTE_SET object can also be accessed via a CX_CONDITIONED_BAG, if different attribute value spaces are to be modeled depending on certain conditions.
The class CX_FORMULA_ATTRIBUTE always determines the value of a dynamic data field only by calculation with a formula, for example, for the attribute "area" from the attributes "width" and "length". This calculation always takes place when the value of this attribute is queried.
If a dynamic data field has values that depend on certain conditions, you can use an object of the class CX_CONDITIONED_ATTRIBUTE. These conditions can be values of other attributes. (Example: If mounting point = right or mounting point = both sides, then length_right = length; if mounting point = left or mounting point = both sides, then length_left = length).
Classification characteristics (part type, article or customer groups) are stored as independent structure objects and are no longer sort criteria within the objects. All business objects can be assigned as often as required, and an identity can be created by overwriting or describing references.
Structure objects themselves can be assigned hierarchically.
The functionality of the business objects can be called up hierarchically and additively throughout an entire structure (for example, sales sorted by customer group).
Allocations are to be understood as (auxiliary objects for) quantitative distribution and/or allocation structures.
At its core, an object of the class CX_SINGLE_ALLOCATION consists of the tuple of a reference to an object and a set: The referenced object is "used" in a certain set. The set is of type CX_AMOUNT (see above). The referenced object can itself have an allocation assigned, which can result in hierarchical allocation trees.
If an object of the type CX_SINGLE_ALLOCATION is referenced from another object, it is represented as a "resource".
Class CX_CONDITIONED_ALLOCATION allows you to display conditional allocations (variant processing).
Objects of type CX_SET_ALLOCATION manage quantities of allocations and thus represent BOMs, routings, but also cost assessments. When you explode such allocations, the quantities at the nodes are represented by CX_PRODUCT_AMOUNT objects. Changing a quantity at any node immediately corrects all quantities of lower-level allocations.
Relationships or relationships between business objects can be managed individually with objects of classes CX_DESCRIPTIVE_REF, CX_OVERWRITING_REF, CX_CONDITIONED_REF and CX_LOOSE_REF.
The class CX_COM_OBJECT allows you to store any COM objects in the database (it has its own implementation of the interface ILockBytes). All functions of the DISP interface can be called with InstantView, just like any other function of a business object.
Classes derived from CX_COM_OBJECT for certain COM objects - for example, Microsoft Word documents - use the C++ interface of the special COM object and can therefore perform certain operations with higher performance.