February 29, 2004
Rationelle Software-Produktion
Seit meinem Eintritt in die innoQ habe ich immer wieder vorgeschlagen, dass wir zu einem Systemhaus werden sollten: einem Unternehmen, das nicht beim Kunden vorort in Projekten mitarbeitet, sondern sie für den Kunden im eigenen Haus durchfürt. Ich habe einmal von einem Projektleiter, der nachweislich über 40 Projekte mit durchschnittlich 40 PJ erfolgreich abgeschlossen hat, den Ausspruch gelesen: "Die Welt ist voll von Entwickler-Teams, die sich jeweils für das beste Team der Welt halten."
Es gibt beispielsweise dieses bekannte Open-Source-Projekt, das damit wirbt, dass einige der intelligentesten Menschen unserer Zeit daran mitwirken. Nun, ich kann so etwas nicht glauben. - insbesondere nicht, weil diese Leute nur hinterher programmiert haben. Persönlich finde ich Selbstbeweihräucherung nicht gut. Trotzdem schlage ich nun in die gleiche Bresche: bei aller Bescheidenheit weiss ich, dass jeder einzelne unserer Mitarbeiter seinen Wert in den unterschiedlichsten Projekten bereits unter Beweis gestellt hat. Um so schwerer verständlich, dass wir nicht in der Lage waren, gemeinsam die Projekte intern umzusetzen.
Endlich haben wir eine kleine Korrektur unserer Ausrichtung vorgenommen: innoQ wird sich mittelfristig als der Partner für Rationelle Software-Produktion etablieren. Die Ausrichtung stützt sich weiterhin vollständig auf dem bisherigen Selbstverständnis und den Kernkompetenzen in Technologie und Methodik. Wir sehen enorme Vorteile in der eigenverantwortlichen Umsetzung von Projekten, weil es beispielsweise keine politischen Diskussionen um den Einsatz und die Auswahl von Werkzeugen mehr gibt. Wir haben ein Portfolio an Werkzeugen, die die Software-Entwicklung drastisch verbessern können. Wir kennen die Methoden, mit denen diese Werkzeuge best-möglich eingesetzt werden können. Wir verstehen deren Funktionsweise so genau, dass wir nicht strikt an irgendwelche starren Prozesse gebunden sein müssen.
Die Ausgangsvoraussetzungen sind sehr vielversprechend. Organisatorisch richten wir uns gerade neu aus. - Alles mit der Ruhe und Gelassenheit, dass diese Veränderungen Zeit haben und wir "natürlich rein wachsen" werden. Allerdings zeigt mir die Klarheit einiger Entscheidungen, dass alle wissen, wohin die Reise geht.
Welche Rollen spielen dabei Service-orientierte Architketuren und Model Driven Architecture? Diese Frage ist nicht rhetorisch sondern stellt sich wirklich. Service-orientierte Architekturen als eine Modeform der Software-Technik ist nicht viel anders als das Paradigma der Komponenten-Basierung. Service-orientierte Architekturen erfordern einen anderen Ansatz und einen ganz anderen Fokus, um nicht einfach nur "das Gleiche in grün" zu sein. Für mich persönlich ist der Fokus der Service-Orientierung ist sehr viel weiter weg vom Code als bei der Komponenten-Orientierung. Wie auch immer das funktionieren kann, ist derzeit nur sehr individuell im Unternehmen feststellbar. Das Etablieren von Service-orientierten Architekturen erfordert Weitblick, denn Services sind von der Philosophie her tendenziell "weiter sichtbar" als Komponenten das sein müssen. Dadurch besteht die erhöhte Chance, des starken Zusammenwachsens der System-/Service-Landschaft, welches sich zu einem Wartungsalbtraum entwickeln kann.
Diesem Vorzubeugen, ohne dabei die unmittelbare Handlungsfähigkeit zu verlieren, ist eine der Herausforderungen in der Entwicklung von Service-orientierten Architekturen. Die Problemstellung ist also weniger technisch als eine Frage der Methodik und der Organisation. Um unsere Fähigkeiten in diesem Bereich noch weiter auszubauen, werden wir weiter hin auf die Mitarbeit und Beratungstätigkeit bei (Groß-)Kunden angewiesen sein, weil wir - auch mittelfristig - nicht in der Lage sein werden, eigenverantwortlich entwickelte System selbst service-orientiert zu bauen. (Wir könnten es zwar so nennen, aber de facto gäbe es keinen Unterschied zur komponenten-basierten Entwicklung - ausgenommen vielleicht die technische Infrastruktur.)
Mit der Model Driven Architecture verhält es sich da ganz anders. Wir sehen darin einen wichtigen Baustein für die Rationelle Software-Produktion. Seit Jahren - bereits bevor es den Namen "Model Driven Architecture" gab - haben wir in dem Umfeld der Entwicklung unternehmensweiter, geschäftskritischer Anwendungen den modell-getriebenen generativen Ansatz empfohlen - und eingesetzt, wenn möglich. Der Nutzen bislang immer sehr groß und Investitionen amortisierten sich schnell. Genau aus diesem Grund haben wir in diesen Bereich investiert und werden uns hier noch weiter verstärken. Unsere Erfahrung in diesem Bereich sehen wir als einen zentralen Baustein.
Weitere Bausteine werden folgen.
Posted by Phillip Ghadir at 8:47 PM
Sotograph
Am Freitag haben wir eine eindrucksvolle Demonstration des Sotographen erhalten. Der Sotograph ist ein Analyse-Werkzeug, das meiner Einsch�tzung nach in keinem (Java-)Entwicklungsprojekt fehlen sollte. Er analysiert bestehenden Code und legt die gewonnenen Informationen �ber den Aufbau und die Struktur in einem Repository ab, �ber das im Anschluss Analysen und Abstraktionen gefahren werden k�nnen. Als ich auf der OOP darauf aufmerksam wurde, dachte ich sofort �ber eine m�gliche Partnerschaft mit Software-Tomography nach.
Das Potenzial ist riesig, au�erdem verspreche ich mir einen gro�en Nutzen davon in der t�glichen Projektarbeit.
ObjectBrowser auf SourceForge
Es ist soweit. ObjectBrowser ist auf SourceForge verf�gbar. Der erste Schritt ist getan.
Jetzt m�ssten wir noch eine Projekt-Seite einrichten und ein paar Kleinigkeiten nachziehen.
February 23, 2004
Marketing: Views on a real world event?
Frank Bruch hat in eine sehr nette Geschichte von einem Autounfall ausgegraben, den drei Autohersteller ausgeschlachtet haben. Die Geschichte ist auf englisch.
Frank Bruch has found this funny little story of a car accident, which was exploited by three large car manufacturers.
Posted by Phillip Ghadir at 9:19 PM
February 14, 2004
Naked Objects vs. ObjectBrowser
Es war ein harter Kampf, aber nun ist ObjectBrowser endlich auf dem Weg, Open-Source zu werden. Mit dem ObjectBrowser haben wir Mitte 2002 begonnen, eine Anwendungsplattform zu implementieren, mit welcher - in Kombination mit iQgen - Stammdatenpflege-Applikationen vollst�ndig generiert werden k�nnen. Wir wollten mit dem ObjectBrowser ebenfalls die Technologieunabh�ngigkeit des MDA-Ansatzes demonstrieren. Deshalb sind verschiedene Persistenzmechanismen implementiert. Zu guten Zeiten: Objekt-Serialisierung, Castor/JDO und EJB-CMP 2.0.
Allerdings wirkte die EJB-L�sung aufgesetzt und passte nicht wirklich zur ObjectBrowser-Architektur, die eher auf Standalone-Anwendungen zugeschnitten war. Die Persistenz mittels EJB haben wir deshalb einschlafen lassen, und ein neues internes Projekt daf�r aufgesetzt.
In den ObjectBrowser ist beachtlich viel Aufwand hineingeflossen und dennoch haben wir nie etwas ernsthaftes damit gemacht. Ich sah es schon kommen, dass er noch einige Zeit in unserem CVS-Repository herumd�mpelt, bis ihn jemand entsorgt.
Dank des Aufsehens um Naked Objects ist uns die Bedeutung des ObjectBrowsers allerdings wieder sehr bildhaft vor Augen gef�hrt worden. Im Prinzip entsprechen gleichen sich die Philosophien von ObjectBrowser und Naked Objects. Selbst das Look-and-Feel ist sich �hnlich. Beide Ans�tze haben unterschiedliche Schwerpunkte: ObjectBrowser ist f�r die Generative Software-Entwicklung entworfen. Deshalb ist die manuelle Verwendung des Frameworks etwas aufwendiger als bei Naked Objects. Allerdings funktioniert die Entwicklung meiner Menung nach genauso einfach, wenn f�r ObjectBrowser mit den entsprechenden Transformationen aus iQgen heraus generiert. Dann k�nnen "beliebig gro�e" Applikationen in kurzer Zeit gebaut werden.
Ich bin froh, dass der ObjectBrowser nun endlich freigegeben wird. In k�rze werden wir ein Tutorial herausgeben, dass die modell-getriebene Software-Entwicklung mit iQgen demonstriert. Als Basis werden wir nun den ObjectBrowser nehmen, weil der keine Installation von Laufzeit-Komponenten wie z.B.: Applikationsserver oder Datenbank erfordert.
After some struggle ObjectBrowser is becoming open source. Starting mid 2002 to create an application platform in order to provide the usual CRUD actions for arbitrary objects by using iQgen for fully generating. ObjectBrowser was intended to demonstrate platform independence of the model-driven approach. Therefore we've implemented several strategies of object persistency: Java's object serialization, Caster/JDO, and EJB-CMP 2.0.
Unfortunately the EJB persistence was not that conformant to ObjectBrowser's architecture, which was primarily designed for standalone applications. That's why we dismissed the EJB persistence and launched another internal project for that.
We've spent some effort in developing ObjectBrowser, although we didn't make any use of that. I wasn't sure, whether we would ever use ObjectBrowser before someone removed it from our CVS-repository.
Due to the Naked Objects hype we realized that there's a certain use case for applications like ObjectBrowser. Naked Objects and ObjectBrowser have some basic similarities regarding user experience. But both approaches have different focusses: ObjectBrowser ist designed as a framework especially for supporting a model-driven generative development approach. That's why handcrafting an application with ObjectBrowser and without a software generator requires more effort than handcrafting an application with Naked Objects framework. But using iQgen's ObjectBrowser transformation enables the same simple development experience allowing the generation of arbitrarily large applications in short time.
Publishing ObjectBrowser as open source software is good. Soon we'll publish a tutorial that'll demonstrate the model-driven software development with iQgen using ObjectBrowser. ObjectBrowser is suited perfectly well because it doesn't require any runtime components - like RDBMS or application servers - installed.