Jan Burse, created Jul 02. 2009
„Everything is in a state of flux“ of it already spoke the Greeks. And by this we do not mean our drops of sweat in summer. Rather the sentence reminds us of the constant change of things. Neither excluded by this are the products that are offered through a sales system, nor the contract objects that bring together partners and products. Representation of this change in information systems is called historization. In the following we would like to present the historization pursued in our sales system.
Belonging to historization we find simple logs that record events. But only when logs are carefully connected to objects linear versions of object states and relationships emerge. Among the objects with linear versions we find the orders of the sales system. An order undergoes its own lifecycle. The cycle starts with the entry of the first product and ends with the activation of all products. The historization in our system starts with the release of the order.
The architecture of the sales system envisages different roles and correspondingly different views of the historization. We contemplate that the customer only sees the newest version of the order and performs operations on it. These are the functions of the front system. The relationship manager on the other hand can view the whole history, and perform advanced operations on it. These are the functions of the back system. We consider message exchange for the synchronization of the front- and back system.
For the sake of simplicity the prototype is not distributed over front- and back system. Besides the historization of the orders we find logs for the payments and the activations. The prototype further supports already linear versions of the items of an order, although we do not yet make use of it. Orders, items, payments and activations are the important things that do have a history and which are also directly visible to the customer. Besides that the system must also meet the demand of historization of templates, zones, tariffs and articles.
For the representation of linear versions on top of relational database there is no unique solution. We often find a representation by means of a VALIDFROM and a VALIDTO column, nevertheless we pursue a representation with a VALIDFROM column only based on an example by Max Vetter. Our resulting system is developed as far as that we can generate any document for any time point, and that we could do in principle without the expensive archiving of documents.
To what purpose the whole effort? Do we only want to assure traceability? Not at all! The historization is not only to the advantage of the relation ship manager when he works on a case. It is also an interesting instrument for the shaping of offerings. By means of the historization we can enforce conditions of licenses, e.g. only one evaluation license per partner and product. And we will be able to define interesting products, e.g. discounts on upgrades.