The basics of CyberEnterprise

Basics of CyberEnterprise


In general, one would expect a chapter on the basics of architecture to be written at the beginning of a paper on architecture. This is also the case here, and this chapter should also give you a first overview of the structure of the architecture.

With this writing however a special Business Information Technology (BIT) architecture for a generally valid modeling of enterprise solutions is presented, this chapter should be seen therefore against the background of a very abstractly held enterprise model.

However, before taking a closer look at the model, it might be helpful for a better understanding to discuss some of the basic ideas for modelling that had already been formulated during the first conceptual phase as part of the Concept classix.

The CyberEnterprise architecture stands under the primacy of flexible enterprise solutions, at the same time it is the basis for a possible abstraction.

Modular principle

There are reusable components1 - at different levels of complexity - with almost unlimited combination possibilities.

The CyberEnterprise architecture is object oriented throughout. The business conditions of a company are modeled as (business) objects. These are the elementary building blocks from which, together with components for the user interface, reusable parts of an application are built (module). An application is created by combining these modules, which are also object-oriented.

The modules are created using the InstantView RAD Framework, which is an integral part of the architecture. InstantView also refers to the script language of the application modules and the runtime of the overall system.

The application modules are managed in the AppsWarehouse and, as best practices, represent a reference model for your own enterprise modeling.

This step-by-step structure corresponds to a software architecture with several, clearly separated levels.

1 A basic requirement is a high level of abstraction of the components, i.e. exactly the opposite of a collection of program code for as many problems as possible, which is controlled by parameters and activated/deactivated with switches.

Multi-tier architecture

An important feature of the CyberEnterprise architecture is the strict separation between model and interface, i.e. between business objects and visualization (MVC concept).

The CyberEnterprise model classes are a collection of C++ classes. The instances of these classes - the business objects - are the data of a company and are stored directly in an object-oriented database (ObjectStore®).

In the InstantView software layer we find the components that organize the interaction of business objects with each other and with the user. InstantView presents itself to the outside world as a simple programming language that dynamically describes the desired business functionality. This also includes a declarative GUI for modeling the application solution.

The name "InstantView" is meant programmatically: Without much effort, mini-applications can be created for the moment (a specific view of the data) in order to solve operational tasks quickly or to be able to create enterprise solutions faster and more target-oriented in the context of rapid prototyping.

Parallel to this there is the MorphIT layer for ergonomic design of the user interface. This layer communicates with the application components via WebServices and is completely decoupled from the logic of the enterprise model.

message bus

The communication between the components is exclusively via - dynamically definable - messages. These are exchanged with each other via a message bus. The connection of events of the user inputs of the InstantView layer, of external events (e.g. CORBA), as well as of WebServices also takes place via the message bus.

runtime system

The system parameters and the program instructions of the application modules of the InstantView software layer are dynamically executed by the runtime system at runtime.

By the dual division of program execution, method calls in the C++ classes of the CyberEnterprise combined with dynamically executed statements of the InstantView code, a performance sufficient for dialog programs is achieved.

After sufficiently formulated abstraction, the relocation of functionality from the InstantView code to the C++ classes is an ongoing process.

The runtime system is the actual guarantor of a high degree of flexibility and also allows very fast customizing.


The object-oriented standard components - be it the business objects from the CyberEnterprise enterprise model or the application modules from the AppsWarehouse reference model - are structured in such a way that they can be individualized as required: The algorithms and program parts that represent stable knowledge of an application domain can be separated as far as possible from those parts of a component that differ from application to application or even from user to user and are subject to adaptation to constantly changing conditions.

For this purpose, the CyberEnterprise architecture supports dynamic data fields (slots) and dynamic inheritance of business objects (pseudo-classes) and of application modules, properties that will be discussed in more detail later.
Within the CyberEnterprise architecture, an application solution is created by

  1. ideally suitable modules are selected and compiled from the AppsWarehouse
  2. a not quite fitting application module is extended by inheritance
  3. an application module is written from scratch using InstantView code
  4. if required, the CyberEnterprise can be extended by new C++ classes

Normally you are in the range of 1. and 2., but the architecture allows any extension. A clearly defined interface is also available for the connection of foreign C++ libraries.

Customizing in CyberEnterprise is organized in such a way that release capability is maintained throughout.

There are no fixed data formats to enable Customizing at data level as well. Therefore the object-oriented database ObjectStore® is integrated transparently by default.

Object oriented database

Stored objects are only accessed via references (addresses) in the database, a fixed organization in tables does not exist. This allows individual objects to be nested together as required, the basis for format-free storage of data.

When working with persistent business objects, all storage and transaction management is done automatically. Due to this abstraction of data storage, there are no explicit read or write commands.

The storage of objects can be logically divided into layers, domains and lists (collections), e.g. to separate data from different clients.

Objects are initially only logically deleted in the database, i.e. they are moved to a 'trash can' from which they can be reactivated.


The user interfaces of InstantView and MorphIT as well as the data of the application (the business objects) can be set up in any number of languages. This also applies to error messages and help texts. The operating and/or data language can be changed at any time during runtime.

Locales are comprehensively supported. Each application client can be set up according to regionally valid characteristics: local currency, language, time zone, units of measurement, number and date formats, public holidays, (school) holidays, etc. The regionalization can be nested as deeply as desired (country, state, city, company, plant, ...).


The InstantView layer can be distributed over application servers. The CyberEnterprise architecture also provides its own server process, for example to run queries on the database server. This means that only the result of a query is transferred via the network to the client or application server.