Mein erster eigener Computer, betrieben an einem reparierten S/W Fernseher vom Sperrmüll und selbstgebauter Datasette (Kassettenrecorder-Chassis, selbstgeätzte Platine mit einem 741 Operationsverstärker). Beliebtes Tätigkeitsfeld war die Modifikation von Programmen, damit sie benutzerfreundlicher wurden. Dafür programmierte ich einen Monitor mit Dissassembler, der auch die illegalen Opcodes des 6510 kannte. Aber ich schrieb auch sinnvolle Anwendungen, in Assembler und Basic: Adressverwaltung für meine zahlreichen "Geschäftsbeziehungen", Softwareverwaltung, Grammatik-Analyzer für Latein sowie das kommerziell erfolgreiche Projekt "TNC" (ein Paket von Berechnungsmodulen für Bahnsteuerungen von Fräsmaschinen). Ein Maschinenhersteller kaufte es mir ab und legte es seinen Maschinen zusammen mit der tragbaren Variante des C64 bei. Meine Klassenkameraden Hans-Jürgen Brändle, Jochen Hamma und Guido Henkel dagegen wurden in der Spielebranche sehr erfolgreich. Schon damals achtete ich auf die Work-Life-Balance, was sich darin zeigt, daß die schulischen Leistungen nicht zu sehr litten (Abi-Schnitt Mathe/Physik 1,4) und Sieg im Triathlon, obwohl ich ein 3-Gang Rad fuhr.

Mit dem 68000 (orthogonaler Befehlssatz!) kamen 8 MHz und 16 Bit Busbreite, 1 MB linear adressierbares Ram (musste man damals selbst auflöten), grafische Benutzeroberfläche GEM. Auch hier griff ich beherzt zu Lötkolben, legte die Anschlüsse an der rechten Seite nach oben, baute die Platine samt einem flachen Netzteil und 2 Floppy Laufwerken in einem Plastikboden zusammen. Tastaturkabel wurde verlängert und so passte das ganze in einen Alukoffer und ich hatte einen Laptop. Das war geschickt, denn man musste viel herumreisen zum Midi-Maze spielen. Später nahm ich ihn mit zur Bundeswehr für die dort anfallenden Organisations- und Schreibarbeiten im Batterietruppführer-Zimmer. Der ST ging auch mit ins Manöver.

Zu programmieren war der ST ein Traum. Für GEM gab es einen Resource-Editor. Natürlich blieb ich bei Assembler (GEN ST), baute wiederverwendbare Libraries und jede Menge Tools, darunter Mailbox-Software und die Steuersoftware für einen universellen EPrommer. DatexP und BTX waren auch spannende Betägigungsfelder, dann kam UUCP dazu, welches Rodney Volz auf den ST portierte.

Während meines BA-Studiums kam ich mit der Grossrechnerwelt in Kontakt, da mein Ausbildungsbetrieb (die damalige Landesgirokasse) eine IBM 3055 unter MVS betrieb. Dort programmierte ich so spannende Sachen wie zwei Bänder gegenlesen und auf ein drittes Band schreiben (in Cobol). Schnell eigenete ich mir Assembler, IMS und JCL an, das war schon besser, vor allem die Macro-Fähigkeiten des AS/360. Damit baute ich mir eine Macro-Bibliothek, die es mir ermöglichte, wie mit C zu programmieren. Dennoch brauchte es für eine einfache Dialoganwendung (Satz lesen, an Bildschirm bringen, speichern) einen Monat. Das einzig gute waren die schnellen Drucker. Folglich programmierte ich heimlich einen Banner-Generator für überdimensionale Spruchbänder.

Bei meiner nächsten Firma (GAI) lernte ich die AS/400 in Gestalt einer B10 kennen. Ich war sofort begeistert. Man konnte sich alles mit F1 erklären und prompten lassen und selbst aneignen. Das objektbasiernde Betriebssystem war ganz darauf ausgerichtet, produktiv auf relativ hohem Abstraktionslevel Dialoganwendungen zu entwickeln. Es war ein wirklich rundes, vollständiges und gut durchdachtes Anwendungssystem (im Gegensatz zu einem Betriebssytem). Mit Physical Files, Logical Files, Display Files und Printer Files hatte man alles konsistent zur Hand. Die Befehle der CL Sprache ließen sich aus 3-Buchstaben Tokens herleiten. Mit RPG/400 entwickelten wir eine Waschanlagen-Service Anwendung.

Nach dem Projekt wurde die Niederlassung geschlossen und ich wechselte zur CAS, ein renommierter PPS Anbieter auf der AS/400. Kurz darauf wurde die CAS mit Steeb unter der Regie der SAP vereinigt, um im Mittelstand ein Bein auf den Boden zu kriegen, was aber nicht klappte. Die CAS wurde irgendwann wieder rausgelöst und von der biw aufgesogen. Ich machte hauptsächlich Standardentwicklung in den Modulen RTG, PRD, erweiterte die hauseigenen Entwicklungstools (XREF) und betreute Kundenprojekte, oft vor Ort, erstellte invidivuelle Anpassungen. Mit der Zeit wurden Schnittstellenprojekte häufiger. Ich baute Anbindungen an Leitstände, Qualitätssicherungssysteme, CAD, Unix-Rechner, OS/2 (Dataqueues!) und Windows-PCs. Das Thema Unix wurde immer wichtiger, wir testeten Portierungen. Auch grafische Benutzeroberflächen wurden gefordert, Client-Server Architektur und der PC als Terminal kamen in Mode. Ich wurde beauftragt, in einem Evaluierungsprojekt alle relevanten Architekturen und Entwicklungsumgebungen auf ihre Eignung für Unternehmenssoftware abzuklopfen. Einige hatte ich ja schon privat in meinem Rechnerzoo, darunter eine NeXT-Station und verschiedene Unix-Derivate, auch das erste Linux von DLD.

In 1993 kam das Betriebssytem des NeXT als OpenStep entbündelt auf die Intel-PCs, HP- und SUN-Workstations. Damit war die neue Plattform gefunden: portabel, grafisch, objektorientiert, unerhört produktiv, mit guter Datenbank-Anbindung, performant, von sehr hoher Qualität. OpenStep gibt es übrigens heute noch als Mac OSX auf den Apple-Rechnern, nachdem Apple NeXT aufgekauft hatte. Wir machten einige erfolgreiche Individual-Projekte mit OpenStep, auf Messen waren das die schillernden Technologie-Aushängeschilder. Ich selbst programmierte für die Karl Dungs GmbH eine Vertriebsunterstützung/Produktionsplanung. Leider kam aber aus verschiedenen Gründen eine Migration des Hauptproduktes "BRAIN" nicht in Gang, so daß ich mich 1997 selbständig machte und es in Eigenregie versuchte. Ausserdem waren da noch SAP-Episoden. Eine davon: Wir bekamen die Entwicklerschulungen in Walldorf und wurden abgestellt, das R/3 Release 3 zu testen, was wir ausgiebig taten. So lernte ich das R/3 auch unter der Oberfläche kennen. Später wurde die ganze Gruppe der R/3-kundigen von SAP weggekauft. Aber da war ich schon weg.

Zunächst konsolidierte ich meine Erfahrungen in einem Business-Framework. Mein erster Kunde war 1997 die Beneficial-Bank (heute CreditPlus Bank). Unter Einsatz des neuen Frameworks und zum erstenmal mit WebObjects erstellte ich eine individuelle Consumer-Banking-Software. Sie bietet alles vom AIBD-Rechenkern unter Einsatz des Newtonverfahrens über Produktkonfigurator, Online-Kreditkalkulation/Druck/Einreichung, PostIdent, FaxBack, Inhouse-Kredit-Verwaltung über Schufa und EScore-Schnittstellen, XML-Schnittstellen für Partner, Offline-Schnittstellen bis hin zur Übergabe ans Core-Banking System, Operating-Tools, Auswertungen.
Dieses Projekt sollte mich mit Unterbrechnungen bis 2005 immer wieder beschäftigen.

Zwischenzeitlich hatte sich die biw doch dazu durchgerungen, unter dem Arbeitstitel "Amarante" eine neue Softwaregeneration zu erstellen. Da machte ich zusammen mit der SCM GmbH als Externer mit, steuerte mein Framework bei und half, die Anlagenbuchhaltung als Fat-Client Desktop-Anwendung damit zu programmieren. Diese wurde dann auch inhouse eingesetzt sowie bei einigen Kunden.

In 1999 gerate ich in die Möbelbranche. Ralf Engelhardt, den ich in einem Projekt kennengelernt hatte, steuert sein langjähriges Möbel-Know-How und den ersten Kunden bei, ich mein Framework. Heraus kommt "Moebel 2000", eine umfassende Branchenlösung auf Desktop-Basis. Anfang 2000 gründen wir die "seat-1 Software GmbH" und kümmern uns softwaretechnisch um die bei Coburg ansässigen Polstermöbelhersteller.

Das Nachfolgeprodukt "seat-1 ERP" gestalten wir branchenneutraler und setzen es mit WebObjects als Server-Applikation auf. Es bietet jetzt auch einen Web-Shop, den einige Kunden in Verbindung mit der Variantentechnik nutzen. Zunehmend gewinnt Scripting an Bedeutung: statt harter Programmierung mit anschliessender Compilierung werden Bereiche besonderes hoher Varianz als Scripts ausgelagert und kundenspezifisch ausgestaltet. Ein weiteres wichtiges Architekturkriterium ist die Mandantenfähigkeit. Es gibt einen globalen Bereich und für jeden Mandanten einen individuellen mit identischer Struktur. Zur Laufzeit wird jeweils zuerst geschaut, ob es spziellere Mandantenlogik gibt. Wird etwas gefunden, wird sie verwendet, ansonsten erfolgt ein Fallback auf den Standard. Damit erreichen wir eine saubere Trennung, halten eine Installation releasefähig und haben doch alle Freiheiten, kundeneigene Abläufe zu bauen. Von "seat-1 ERP" leiten wir einige abgespeckte Produkte wie "seat-1 WAWI" (ohne Fertigung) und "seat-1 MVS" (Mandantenverwaltungssystem für Versicherungen) ab.

2004 gehen wir mit "IntarS" und GNUstep auch in den Linux-Bereich, wobei uns David Ayers unterstützt. Gleichzeitig wird unsere Software OpenSource und wir rufen das Partnermodell ins Leben. IntarS ist im Standard ohne spezielle Möbelmodule. Scripting spielt in Form von "IntarScript" eine zentrale Rolle, alternativ ist aber immer noch die harte Programmierung von Kundenfunktionen in ObjectiveC möglich. Der funktionale Standard ist schmaler als in "seat-1 ERP". Wir haben nur noch das dringelassen, was bei den bisherigen Projekten sich als harter Kern entpuppt hat und nennen das Hybrid-Architektur (Kombination aus Standard- und Individualsoftware). Aus den Erfahrungen früherer Projekte waren wir bestrebt, die Möglichkeiten der Individualprogrammierung zu stärken, sie effizienter zu machen. Mit schnell und einfach zu individualisierenden Lösungen macht man Kunden glücklich. Der Standard darf dabei kein Klotz am Bein sein.

2006 Nach ca. 100 IntarS-Installationen habe ich das Bedürfnis, der Software eine weitere Überarbeitung angedeihen zu lassen. Ich verabschiede mich aus dem Tagesgeschäft, beginne unter dem Arbeitstitel "Aprica" eine Universal Application. Die Ziele:

2007 Nach 3 erfolgreichen Aprica-Projekten wird die Weiterentwicklung offiziell als IntarS Version 5.0 freigegeben.

2008 Max 21 AG steigt als Invenstor ein und unterstützt uns bei der Vermarktung. IntarS Version 5.1 vollzieht den Schritt zur Universal Application.

2009 Wir stellen auf der Cebit aus.