und weiter ?

nach dem abschluß des erpOS projektes habe ich eine zeitlang als consultant für eine java-basierte ERP - webanwendung gearbeitet und bin daher anfang 2006 nach rosenheim umgezogen.

allerdings hat es nach einiger zeit wieder gekribbelt und als der anruf eines alten geschäftsfreundes kam, war es soweit: es wird wieder modelliert, designed, generiert, programmiert... basierend auf den ergebnissen des erpOS projektes leite ich jetzt die entwicklung einer erp-anwendung für die entsorgungsbranche. dieses projekt ist dann gleich das muster für die entwicklung verschiedener produktfamilien basierend auf erpOS als "workbench".

natürlich hat sich die java-welt weiter entwickelt und der toolsupport, sowie die projekte um eclipse haben gravierende fortschritte gemacht. das hat auch auswirkungen auf die konzepte von erpOS ... lassen sie sich überraschen - es gibt aber erst anfang 2008 genaueres zu erfahren.

es ist mal wieder eine spannende zeit...

nachdem ich 25 jahre lang anwendungsprogramme aus den bereichen ERP, warenwirtschaft, auftragsabwicklung programmiert habe, wollte ich die erfahrungen in ein open source projekt fliessen lassen: erpOS - ERP Open Source Software

natürlich nicht nur zum vergnügen ;-) das business liegt im professionellen support rund um das erp system. nähere infos unter: www.erpos.com.

die erfahrungen der letzten jahre sind in die neue architektur eingeflossen. anstelle einer rein web-basierten anwendung liegt der schwerpunkt auf einem rich-client, der mehr komfort bietet. es kam uns zugute, dass eclipse gerade in den letzten zwei jahren sich auch als eine plattform für rich clients entwickelt hat.

im vorigen projekt begeisterte uns die objektorientierte datenbank (oodbms) fastobjects  von poet: performant, stabil, sicher, und: kein "bruch" (mismatch) zwischen der objektorientierten sprache (java) und der speicherung der persistenten objekte.

bei erpOS haben wir uns doch wieder für eine "klassische" relationale datenbank entschieden. warum ? oodbms haben sich nicht durchgesetzt und mit hibernate ist ein de-fakto-standard für das mapping der objektstrukturen auf tabellen der datenbanken entstanden. als datenbank haben wir die maxdb gewählt. maxdb ist die ehemalige sap db, ist open source, wird von mysql mit vertrieben und weiterhin von sap gepflegt. maxdb ist sehr gut geeignet für anwendungen mit vielen transaktionen.

die server-architektur haben wir auch in gute hände gegeben: das übernimmt das springframework. als servlet-engine arbeitet weiter der zuverlässige tomcat. wir benötigen keinen j2ee server, da wir auch unsere rich clients per http anbinden. springframework bietet da sehr gute remote-unterstützung. daher reicht uns  der tomcat für die rich clients, die web-clients und auch web-services. das macht die architektur besonders für mittelständische unternehmen überschaubarer.

da wir im letzten projekt die vorteile eine modellgetriebenen anwendung (mda) kennengelernt haben, wollten wir da auch jetzt nicht drauf verzichten und setzen den openArchitectureware generator ein. openArchitectureware ist sehr flexibel und erlaubt die definition eigener dsl's (domain specific languages)

es war also auf jeden fall sehr spannend, die architektur auszuarbeiten und das dazugehörige businessmodell ! wir haben auch an businessplan wettbewerben teilgenommen, um unser projekt einer kritischen jury zu stellen. beim IT Wettbewerb im Herbst 2004 von start2grow erzielten wir den prämierten 4. platz, beim münchner businessplan wettbewerb im juli 2005 waren wir in der real bizz stage nominiert.

als nächstes hatten wir einen bei bayernkapital akkreditierten betreuungsinvestor überzeugt, der unser projekt zur förderung durch den seedfonds einbrachte. leider wurde dieser antrag von der ebenfalls involvierten KfW aufgrund des schwierigen marktumfeldes für erp-anwendungen im oktober 2005 nicht angenommen.

das führte zu der entscheidung, das erpOS projekt zu beenden, bzw. zu "parken". die arbeit daran hat viel spass gemacht und das testen der frameworks und die erstellung von mustern brachten viele neue erkenntnisse, die ich jetzt wieder in die nächsten projekte oder den nächsten job mit einbringen werde.

die interessante aufgabe bei ff-eCommerce bestand in der entwicklung einer in java programmierten web-basierten erp - anwendung.
(ff-eCommerce firmen- und produktbroschüre)
das projekt wurde konsequent unter berücksichtigung von model-driven-architecture (mda) entwickelt. das werkzeug war arcstyler von io-software. die modellierung erfolgte mit rational rose. das web ui wurde mit jsp's realisiert.
als datenbank kam eine objekt-orientierte datenbank zum einsatz: fastobjects von poet (jetzt versant).

das entwicklungsteam arbeitete in deutschland dezentral an verschiedenen orten in home-offices, was eine entsprechend gute organisation des entwicklungs- und build-prozesses erforderte. die arbeit mit diesem team hat viel spass gemacht, besonders unsere schon legendären workshops in dänemark, zorge (wo liegt denn das ?), freiburg oder carolinensiel. tatkräftig unterstützt wurden wir noch von oose.de durch björn stachmann und durch ralf degner (damals poet).

nach vier jahren fast ununterbrochener tag- und nachtarbeit konnte ich mich leider mit dem management von cancom nicht auf gemeinsame visionen verständigen.

über den umfang meiner tätigkeiten gibt das zeugnis auskunft.

etwa 15 jahre lang habe ich an einer erp- / warenwirtschaftslösung gearbeitet, die unter verschiedenen namen am markt war: ff_net_fakt7 und ff-handel. die programmierung erfolgte mit einer 4GL sprache: omnis3, dann omnis5 und schliesslich omnis7. das arbeiten mit omnis hat immer viel spass gemacht und recht schnell zu einer komfortablen anwendung geführt. der grosse nachteil war aber die eigene proprietäre datenbank, deren grössenbegrenzungen fantasievoll umgangen werden mussten ;-)
eine weitere schwachstelle waren die fehlenden standards, keine offenen schnittstellen, kein externer zugriff auf die daten usw.
aber immerhin wurde die anwendung etwa 300 mal installiert. als dann 1999 das angebot meines damals grössten kunden cancom kam (cancom ging zu dem zeitpunkt an den neuen markt) unter ihrem dach eine neue anwendung zu entwickeln, habe ich zugeschlagen und die selbständigkeit aufgegeben. aus meinen omnis-kontakten kannte ich einige gute programmierer, die ich dan ebenfalls mit zu cancom / ff-eCommerce mitgenommen habe. wir haben dann dort die neue java anwendung entwickelt. (s.o.)

da ich hier nur die wichtigsten und grossen projekte meines programmierlebens aufführen möchte, jetzt ein sprung an den anfang. das war 1978 in hannover bei kienzle datensysteme.

der eigentliche auslöser war ja mein erster sohn (lars), der 1978 geboren wurde. ich war auf der suche  nach einer interessanten arbeit. da fiel mir die anzeige von kienzle ins auge: "programmierer gesucht". ich hatte wirklich keine ahnung, was das war, aber es hörte sich interessant an und da ich immer schon gerne mit mathematik und logik zu tun hatte, habe ich mich beworben. und herr matthiesen, der geschäftsführer, gab mir eine chance.
 
zunächst lernte und programmierte ich dort assembler, dann cobol. dann ging alles ganz schnell: aufstieg zum gruppenleiter.

bei kienzle entstand dann auch die erste auftragsabwicklung unter meiner regie: kimas - kienzle modulares auftragsabwicklungssystem. erste erfolgreiche installationen u.a. bei der papierfabrik schleicher & schüll in einbeck. das war eine sehr komplexe lösung und ich bin heute noch stolz darauf. einen bericht darüber finden sie als pdf unter artikel.

zurück zu meine arbeit.

                               (c) 2007 ekkehard gentz ... sitemap ... wichtige hinweise ...