Automatisierte Software-Entwicklung sichert Arbeitsplätze hier
Schneller, besser und billiger als Handarbeit in Niedriglohn-Gebieten (Offshore-Outsourcing)

Martin Wagenleiter (Geburtsname: Rösch)

BeratungCoachingObject AcademyMDA Academy

Nichts
bremst Menschen
so sehr
wie ihre Vorurteile
über das,
was "nicht geht".

Martin Wagenleiter ist unter seinem Geburtsnamen Rösch bekannt geworden durch seine Rolle als früher Pionier der Objektorientierung in Deutschland und durch sein Engagement für Präzision und Automatisierung in der Software-Entwicklung.

Das von ihm 1987 gegründete Unternehmen Rösch Consulting ist heute ein Geschäftsbereich von General Objects LTD. Martin Wagenleiter ist

  • Rationalisierungs-Berater für die Software-Entwicklung,
  • Berater für die MDAutomatisierung der Software-Entwicklung,
  • Trainer und Coach

Die allgemein gültigen Grenzen des Möglichen hat er noch nie akzeptiert. "Selber denken macht schlau" ist deshalb einer der Grundsätze, die er aus der Schulzeit mitgenommen hat. Seinen Lehrern am Humboldt-Gymnasium in Düsseldorf ist er dankbar für die humanistische Ausbildung und die Auflockerung des Griechisch- und Lateinunterrichts durch Diskussionen über das Gelesene. Denn die Originaltexte von Aristoteles (Sokrates und Platon) und Cicero waren für ihn eine wirklich schwere Kost.

Meilensteine
  • Altsprachliches Abitur
  • Diplom-Informatiker
  • Arthur Andersen
  • Cincom Systems
  • Rösch Consulting
  • Object Academy
  • Objects 9000
  • Components 9000
  • Software-Roboter
  • General Objects
  • MDA-Academy
  • Den Ausgleich brachten Mathematik und Physik, doch weil ihm die zu theoretisch erschienen, studierte er nach der Bundeswehrzeit die damals, 1973, noch ganz neue Informatik, mit BWL und später Marketing als Nebenfach.

    Dass er beim gemeinsamen Warten auf die Druckausgaben im Rechenzentrum die Meinung vertrat, schon bald würden ganze Computer in eine Aktentasche passen, wurde von den Umstehenden mit Kopfschütteln quittiert: wie sollten denn da ein Kartenleser und eine Tastatur hineinpassen, ganz zu schweigen vom Bildschirm und den anderen Bestandteilen eines richtigen Computers?

    Während seines Studiums kamen die ersten Mikrochips und er schrieb seine ersten Programme für Intel 8008, Motorola 6800 und Mostek 6502. Doch eine Diplomarbeit mit diesem Thema wollte zuerst niemand betreuen, da keiner wusste, was ein Mikroprozessor war. Rückfrage eines Professors: "Sind das die kleinen Dinger mit den silbernen Beinchen?". Ja, das waren sie.

    Weil er während des Studiums eine relativ komplette Bibliographie zum Software-Engineering erstellt und dank der GMD-Bibiothek auch alles hatte lesen können, konnte er bei Arthur Andersen & Co. (heute Accenture) direkt als Senior-Berater beginnen, obwohl er eigentlich noch richtig grün hinter den Ohren war.

    Seismograph und Pionier
  • 1979: "PCs einführen"
  • 1991: Business-Objekte
  • 1994: Fehlerfreie UML
  • 1998: MDA-Generator
  • 2000: 4 Projekte 0 Fehler
  • Das zeigte sich zum Beispiel daran, dass er 1979 dem IT-Leiter der König-Brauerei auf dessen Frage nach der Zukunft der IT (damals noch "EDV") im Namen von AA&Co. schriftlich gab, dass er auf jeden Schreibtisch einen PC (damals noch Apple bzw. Commodore) stellen sollte, zwei Jahre vor der Einführung des IBM-PC: Kopfschütteln.

    Die nächste Station war Cincom Systems, damals ein Unternehmen mit erstklassiger Technik, das heute eher als der Bewahrer von Smalltalk gilt (ein DB-System von Cincom fliegt z.B. in jedem Awacs mit).Dort stellte er 1984 den ersten, für DM 26.000 selbstgekauften PC mit COBOL-Compiler auf und begann mit Database Marketing.

    Sieben Jahre nach dem Diplom war es dann so weit: die eigene Firma. Sie half zunächst IBM, in einem Riesen-Projekt bei der Telekom einen guten Eindruck zu machen, bei Aufbau und Betrieb einer Entwicklungsumgebung für bis zu 500 Programmierer. Seine technische Neugier brachte ihm hier schon bald zwei Sonderaufträge ein: Zuerst die Prüfung der künstlichen Intelligenz auf Anwendbarkeit für das Riesen-Projekt und dann die Prüfung von AD/Cycle mit demselben Ziel. Beide negativ.

    Zusätzlich privat die Prüfung der Objektorientierung in Form von C++ und Smalltalk: ebenfalls negativ. Der Grund: die Objekte waren auf den PCs "eingesperrt" und entstanden bei jedem Programmstart neu, jedes Mal mit anderen IDs.

    Dann DIE Chance: Hermann Schmitt, 1991 Interims-IT-Chef des Landschaftsverband Rheinland (LVR) und heimlicher Smalltalk-Fan, stimmt einer Software-Architektur zu, die im Sommer 1991 noch revolutinär war, aber kurz darauf unter dem Namen CORBA bekannt werden sollte. Mit einem erstklassigen Projekt-Team (Reimund Riebschläger, Klaus Stock, Christian Platter, Hans-Joachim Liertz, u.a.) wurde in nur vier Monaten ein Konfigurations-Management-System (CM-System) aus dem Boden gestampft, das zusätzlich zu seiner CORBA-Architektur langlebige Objekte implementierte, die systemweit sichtbar waren. Es war zwar "nur" mit C und DB2 erstellt worden, doch es hatte bereits richtige - wie man heute sagen würde "persistente" Business-Objekte.

    Obendrein integrierte das CM-System ein normales, eingekauftes, Standard-Software-System mit Hilfe einer Messaging-Technik nahtlos in die Objekt-Welt. Schlicht, einfach, elegant - und das Beste: diese "Legacy"-Integration von CA Endevor lief von Anfang an problemlos und mit guter Performance.

    Auszeichnungen
    Object Applications Awards von OMG und CW:
  • 1992 in San Francisco
  • 1994 in Frankfurt
  • Jetzt überschlugen sich die Ereignisse, denn auf einmal war das kleine Unternehmen welt-bekannt: nach Meinung der Experten hatte Rösch Consulting das "beste Objekt-System, das ohne objektorientierte Tools erstellt worden war", gebaut, und Hermann Schmitt nahm 1992 für den LVR in San Francisco einen silbernen Aschenbecker mit gleichlautender Inschrift (natürlich in Englisch) entgegen.

    Vorträge auf den Object World-Konferenzen 1993 in Boston, San Francisco sowie auf zahlreichen Kongressen in Deutschland dokumentierten Interesse der Fachwelt wechselten sich ab mit "Neugier"-Beratungsaufträgen ("Wie geht denn so etwas?"): für die R+V Versicherung, für Daimler, für das IBM-Labor in Böblingen, für die Telekom und die Software-Entwickler von SAP (um nur einige zu nennen). Sie führten jedes Mal zur Überzeugung der Experten: Ja, Objekte sind der richtige Weg, und ja, es müssen Business-Objekte sein.

    1994 erhielt er die Einladung zum Fachbeirat von OBJEKTspektrum, dem er bis 2008 angehörte. Die meisten seiner 18 Artikel wurden - obwohl ausschließlich Erfahrungsberichte - zum Zeitpunkt ihres Erscheinens mit Skepsis betrachtet, doch vieles ist heute bereits akzeptiertes Allgemeingut. Ein Beispiel: der Artikel von 1996 über Generierungstechnik für die Implementierung von Business-Objekten beschreibt die Anfänge von MDA.

    Innovations-Bremsen
  • Wenn es so einfach wäre, würde es jeder machen. Macht nicht jeder --> ist nicht so einfach
  • Hannemann, geh Du voran, Du hast die größeren Stiefel an
  • Das machen wir nicht, weil wir damit keine Erfahrung haben. Wir haben damit keine Erfahrung, weil ...
  • Doch der Frust war endlos: weil IBM den IT-Chefs noch erzählte, die Objektorientierung sei noch nicht reif, trauten sich lange Zeit nur wenig IT-Manager, wirklich Nägel mit Köpfen zu machen und zu handeln. Die Erfahrungen des Landschaftsverbands Rheinland (LVR) wurden zwar neugierig aufgenommen, doch sie wurden nur selten umgesetzt, vorwiegend in der Schweiz. Der "große Kanton im Norden" (D) dagegen ließ sich Zeit und verharrte mit IBM in Reglosigkeit.

    Dass IBM aber zu der Zeit bereits selber ein objektorientiertes System im Produktkatalog hatte (Application Services Manager (ASM) aus dem Atlanta Lab), schien ein gut gehütetes Geheimnis im IBM-Vertrieb zu sein. Ein offizielles IBM-Produkt, das in Deutschland aber keiner kannte - außer Rösch Consulting. Verkehrte Welt: Immer wieder Überraschung bei IBM-Verkäufern und Handlungsstau bei den Kunden. Grrr.

    Da war es zunächst nur ein kleiner Trost, in den "Biografien" anderer Unternehmen zu lesen, dass es ihnen ähnlich ergangen war: Friedrich Krupp hatte sein Unternehmen auf der Suche nach "Gusseisen englischer Qualität" (i.e. Stahl) praktisch ruiniert und dabei das geerbte, reichliche Familienvermögen verheizt: erst sein Sohn Alfred sollte das Glück haben, zur richtigen Zeit am richtigen Ort um 1850 als Erster und lange Zeit auch Einziger Eisenbahnreifen anbieten zu können. BMW blieb anfangs auf seinen Flugzeuge und Motoren sitzen, weil der kaiserliche Generalstab nichts kaufen wollte, was schwerer war als Luft (Zeppelin lässt grüßen). Und die Gebrüder Wright wurden in den USA erst ernst genommen, als sie in Europa schon zu Stars geworden waren.

    Doch 1990 waren zum Glück einige Amerikaner wacher: so hatte z.B. MCI mit seinem Angebot "Friends & Family" 1993 dem alten US-Telekom-Platzhirsch AT&T eine ganze Milliarde Dollar Umsatz abgeluchst - weil MCI mit flexiblen, weil objektorientierten Abrechnungssystemen Anrufe bei Freunden und Familienmitgliedern kundenindividuell abrechnen konnte. Heute, 2004, ist dies selbstverständlich, doch damals war es 1 Milliarde Dollar wert.

    Die weiteren Themen erst einmal als Stichworte. Später folgen hier mehr Details:

    • 1993 R+V Versicherung - Dr. Höddinghaus - Wie kann man CORBA auf CICS implementieren? H. Soran: Wie werden Objekte weltweit registriert - Vorwegnahme von UDDI.
    • 1994 Gebäudeversicherung Baden-Württemberg - das erste verifizierte UML-Klassendiagramm - nachweisbare Erfüllung aller Anforderungen = fehlerfrei? Der Anfang von Objects 9000
    • 1995 Credit Suisse - Schweizersche Kreditanstalt - Erst CORBA-Training, abgebrochen und sofort weitergeführt als Training zur Anforderungsaufnahme, denn sonst fehlt das Fundament. Warum sind die Schweizer so viel ausgeschlafener und handlungsbereiter als die Deutschen?
    • 1995 SAP - Wieviel Objektorientierung ist in R/3 bereits enthalten? Ergebnis: ziemlich viel, an vielen verschiedenen Stellen. Heute hat SAP die damalige Empfehlung im Business Object Repository umgesetzt, denn SAP bietet einen dritten Zugriffsweg an: Objektzugriff über CORBA, zusätzlich zu den alten Zugriffswegen Remote Procedure Call und Messaging.
    • Cheops-Projekt bei RWE: Gut aufgesetzt, aber schon bald wurden Empfindlichkeiten wichtiger als Fakten. Sehenden Auges daneben stehen und zusehen, wie Fehler, die grade bei anderen Kunden (zum Glück in fremden Projekten) gemacht worden waren, wiederholt werden? Nein. Dann schon lieber die Fakten auf den Tisch legen und die Vertrauensfrage stellen. Ok, wer notorisch unpünktlich ist, bietet Angriffsflächen, aber wenn das wichtiger ist als die 100+ Millionen DM, die da versenkt worden sind: Was kann ein kleines Beratungshaus bewegen? Hätten wir zum RWE-Vorstand gehen sollen? Immerhin hat Knud Norden in seiner Stellungnahme zum Projektende eins der beiden von RC vorgeschlagenen Themen genannt: Anforderungsmanagement. Das war zum Projektbeginn abgelehnt worden, weil es "zu aufwendig" sei. Das andere von Thema war eine klare und performance-optimierte Software-Architektur. Lieber rausfliegen als mit den Wölfen heulen.
    • 1996 Signal-Versicherung - Lohnt es sich, auf Object COBOL umzusteigen - Antwort: nein, denn die Hersteller sind so zerstritten, dass sie sich nicht auf eine gemeinsame Sprachbibliothek einigen können. Und das zu einem Zeitpunkt, wo grade Java zeigt, wie wichtig die standardisierte Bibliothek ist. Sie macht bei Java über 95% des Nutzens aus. Empfehlung: Objekte ja, aber nicht "im Kleinen" in der Programmiersprache, sondern "im Großen" als richtige langlebige Geschäftsobjekte in der Software-Architektur. Also mit dem alten COBOL und mit CORBA-Schnittstellen, nicht mit dem neuen ObjectCOBOL, weil das nur neue Abhängigkeiten bringen würde.
         Erstellung eines Prototypen mit 3 Klassen: 153 Programme, davon 151 generiert. Generierungsquote: 97% des Source-Code. Bei der Vorstellung des Prototypen wird ein Programmierer weiß wie eine Wand: "und was machen wir dann noch?". Die Angst um den Arbeitsplatz steht ihm ins Gesicht geschrieben. RC-Mitarbeiter Wolfgang Fahl (heute GF bei BITPlan) langweilt sich zuhause, weil er ein Gipsbein hat und baut eine erste Version eines Generators, der später Software-Roboter heißen wird.
    • 1997 PTT Bern: Integration der "Vertrag"-Aspekte von 18 Systemen in 1 zentrale Vertrags-Komponente. "Wer nicht weiß, was er will, muss sich nicht wundern, was er kriegt". H. Moresi, H. Schwendimann, ..., Born Informatik.
    • 1997 Sparkassen Informatik, Duisburg. Das erste Projekt, in dem (a) die Verifikation nach Objects 9000 verwendet wird UND (b) die Generierungstechnik "Software-Roboter". Außerdem ist der Kunde in der Lage, nach anfänglichen Trainings und Coaching das Projekt ohne weitere Unterstützung durch Rösch Consulting zu Ende zu führen.
    • 1999 DePfa Systems. Bis 2002 übernimmt RC drei von ca. 50 Teilprojekten. Alle drei werden mit Garantie für Fehlerfreiheit angeboten und durchgeführt. Es wird nicht ein einziger Fehler gefunden.
    • 2003-2006: Langsam dämmert die Erkenntnis: Software ist eine Form von Wissen. Wer Software entwickelt verwandelt das Verfahrenswissen der Fachleute in Anweisungen für Computer: Software-Entwicklung ist Wissens-Verarbeitung.
    • Die fachliche Anforderungsaufnahme ganz am Anfang von Software-Projekten (oder besser noch: vor ihrem Start) ist nach dieser Erkenntnis die wichtigste Tätigkeit im ganzen Projekt. Alles, was danach kommt, verarbeitet nur noch das Wissen, das vorne im Prozess dokumentiert worden ist. Und das, was vorne nicht dokumentiert oder falsch verstanden worden ist, fehlt nachher bei der Projektarbeit. Es lohnt sich also, bei der Anforderungsaufnahme auf Vollständigkeit und Korrektheit zu achten. Doch Vorsicht!!! Für Software-Entwickler ist die Dokumentation von Wissen eine ungewohnte Tätigkeit. Allzu schnell fallen sie zurück in alte Gewohnheiten: Denken in Programmen und Datenbanken. Hier heißt es: UMLERNEN!
    • 2008 VW Financial Services, Braunschweig. Entwicklung einer neuen Veriante des Verfahrens Objects 9000: Die Anforderungsaufnahme löst sich vollständig von der Implementierung des alten Systems und konzentriert sich ausschließlich darauf, das Fachwissen der hausinternen Kunden zu dokumentieren. Skepsis bei der IT, Begeisterung beim Fachbereich. Der Vorteil des Verfahrens: Keine Missverständnisse mehr zwischen Fachbereich und IT - jedenfalls nicht dort, wo das Verfahren zum Einsatz kommt.
    • BeratungCoachingObject Academy


      Die Software-Entwicklung automatisieren - mit General Objects


      Webmaster • Copyright 2008 by General Objects LTD • Kontakt • info@generalobjects.com