Discussion with Reinhard, Middle of April 2004

Hi everyone

It has been a while since I have been over at Reinhards place with a list of questions. I try to summarise of what we have been talking. The discussion was so good, I had no time to write down all the directions the discussion was heading to, so there is a lot missing here. Sorry about that.

Before I get started: The 2-3 weeks I was playing with the babyerp system and gnue application server, forms and reports, showed me, that its possible to use gnue for a business application. But it also showed me, that it takes a little bit more for a serious business information system than just playing. I could do everything, more or less, but I would not want to give it to someone who has to use it for real. My biggest lack is the experience of what a business application, or a business information system, has to do, exactly. As Reinhard puts it, no book and no 4 hour discussion can give you, what 10 years of experience gives you. But still, for me, a book and a discussion are a good start to get into it. In the babyerp system I saw, that it can get messy very quickly and Reinhard just agreed with this observation. Some good package management and discipline will be necessary.

During the discussion we did not come to the one solution of how to exactly write a gnue application, or a gnue package.

My question if it is possible to reuse other free software or open source solutions, such as a GPL accounting solution, and build upon them, Reinhard thought, that its never bad to look at their schemas but that it might be easier and necessary to start all over again to accommodate for special requirements or the gnue environment.

Whether it is possible to develop a package, such as accounting in a collaborative way, Reinhard thinks, that basically it is possible but it is also possible to have one person running the show. In gnue land, until now, nobody was stopping someone from advancing gnue :) So if someone takes on a task, he/she can go ahead. One person or a package group can work out the overall goal of a package. Then individual developers can take bits and pieces of the overall goal and implement them. 

Actually, Reinhard has been thinking of implementing a gnue accounting package from scratch for too long. With his knowledge of his commercial accounting system he knows what he is doing. I assume, once the application server is coming to a stable and production state, Reinhard might start a new, real accounting package. Real in the sense that the accounting package must work for his real customers. Other developers also expressed the desire to develop a gnue accounting package, so some collaboration will happen.

The accounting package will be one of the first required packages necessary for end users (maybe followed by accounts receivable). When starting with a new package, such as the accounting package, there is the generic (ideal) solution and there is the local (rather pragmatic) solution. There are international accounting standards which could be a base for the gnue accounting package, but again, the maybe local accounting experience and specific user requirements might be the driving forces for a local accounting package. Reinhard considers to concentrate on a central European accounting package first.

As everyone knows, to develop and support a modular gnue ERP system, with for example, different (different types of businesses, local vs international) accounting packages, will become ... a serious major undertaking.

So I was asking what has been done in the current gnue packages so far. Basically the data structures you find in the gnue packages today are the results of thinking of Neil Tiffin and Reinhard and probably others. Neils focus were on the fortune 500 company's where as Reinhards focus was on workplaces with maybe 20 employees or so. We all know, that an open discussion of things will potentially result in better solutions. We also know, that discussions need a lot of time and energy. The current packages and their data structures will help to get started.

This yields the question, whether it will be possible to create THE application, which will work for any organisation, no matter which branch, which type etc. This will become a major organisational task, I think. There will be different versions and different variations and people will depend on gnue systems. I think, the gnue packages  will be end user driven, eg if an organisation X needs feature Y, feature Y will be added to fit organisation X needs. If an organisation Z also needs the feature Y, but in a completely different way ... we have a problem, maybe with two different feature Y implementations. Even more, if another package depends on feature Y, an there are different implementations of feature Y, it will become an organisational and management problem.
It will become complicated. Reinhard illustrated an example of a delivery. First of all, it only take a view days until the inventory in the computer does not represent the real physical inventory ... also, there can be lots going wrong, which have to documented in the inventory or even billing system. I cannot recall all the cases, that can happen which Reinhard listed but ... lots can go wrong.

But, if the first implementations are end user driven, the packages will be useable.

I had the question how to design a reliable package. Reinhard illustrated how he has done a reliable accounting system. Basically there is only one class (here called the Booking class) booking in the accounting package. All other packages, all other classes, all other third party components, who want to make a booking to the accounting package have to go through this one class, no exception. Reinhard calls this class in German a "VorObject" (translated lake a pre-object). This design will prevent other packages to mess around with the accounting data. In his previous implementation, he has a "to be booked" list, so the "Booking" class creates a new booking object and places it in the "to be booked" list. So when a user creates a booking object, it is not booked yet. Then the user can run the booking process, sort of an execute the booking. The booking process goes through the "to be booked" list and handles each booking object. For each booking object, the Booking class performs a thousand test (such as the debit amount and the credit amount must have the same total amount, all accounts exists, etc). Only, if all tests are successful, the booking takes place and the main accounting data are updated. If there are errors, the booking object goes into a "booking error" list. The user then has the possibility to edit the booking objects of the "booking error" list and put them again into back "to be booked" list. This black box makes sure, that the accounting data are consistent. 

This methodology of a black box can also be used for other areas. For example to create an order, there could be a black box Order class. To create an Order object, the default Order object take only a few attributes. The object constructor, if you want, then creates a sophisticated RealOrder object (eg, check the customer, create the auditing information of the order, look up items on stock). If the constructor cannot create a sophisticated RealOrder object, there will be no order and the user has to add more information. The same with the Booking class, an Order can be created in ONE way. This has the advantage, again, that all testing is done in one place. 

Reinhard suggested to me, that when I have an ebXML Business Service Interface, which handles the collaborative business process and there is an incoming order request, the BSI creates such an Order object (with view attributes), and the Order constructor then creates the final, sophisticated RealOrder object.

I have not asked Reinhard of what he thinks of graphical tools, to create business processes, business classes etc.

Thats it. I cannot remember the rest of those 4 hours. I think I will ask Reinhard for anther chat ;)

Sacha