![[GOOGLE PICASA]](./themes/speexx/images/picasa32x32.png "Sascha@Picasa"){kind=small}
![[GOOGLE PLUS]](./images/icons/plus48.png "Sascha@Google+"){kind=icon}
![[TWITTER]](./themes/speexx/images/twitter_newbird_white.s.png "Sascha@Twitter"){kind=small}
![ATOM FEED]](./themes/speexx/images/feed-icon-14x14.png "Atom 1.0 Feed"){kind=icon}
![[EMPHASIZE]](./images/icons/emphasize.80x15.gif "Martin Hartnagel"){kind=icon}
Am Donnerstag war ich mit einem Kollegen bei einem Workshop der Firma microTOOL zum Thema MDA mit dem Tool objectiF. Zuerst gab es eine kleine Einführung in MDA. Nichts viel Neues, aber es zeigte sich, dass es bei dem vorgestellten Produkt eigentlich um MDD geht.
Im Kernbereich des Workshops überzeugte das Tool bei der Demonstration nicht. Das lag weniger am UML Editor, als vielmehr an einem ziemlich undurchsichtigen Geschäftsmodell. objectiF selbst ist in einer hochpreisigen Liga, 2.300 € für eine Node-Lock Lizenz. 1.600 € mehr für eine Floating-Lizenz, anzusiedeln. Teuerer wird es, wenn es darum geht die MDA und MDD Fähigkeiten des System auszunutzen. Diese Fähigkeiten werden über sogenannte Transformatoren erreicht. Diese Transformatoren sorgen für Umwandlung des PIM ins PSA und dieses wiederum in den Plattformcode. Dies selbstverständlich auch zurück für den Roundtrip.
Nach dem Kommentar eines Workskopteilnehmers von RAD4.NET wird die Dokumentation der Transformer API in der Version 5 von objectiF noch mitgeliefert. Nicht aber in der aktuellen Version 6. Die Dokumentation dieser Schnittstelle muss man jetzt als Consulting- und Trainingsdienstleistung einkaufen. Laut eines Vertriebsmitarbeiters sind hierfür mindestens 10 Tage a 5.000 € fällig. Die Transformer kann man in einer der .NET-Sprachen entwickeln.
Im Entwicklungsprozess entsteht hierbei eine weitere Rolle, die des Transformer-Entwicklers. In kleineren Unternehmen sieht microTOOL diese Rolle beim Architekten angesiedelt. Dabei wurde nicht ganz klar, wo der Architekt im Model angesiedelt ist. Im PIM oder im PSM. In den Handoutfolien wird dies nicht komplett klar. Dies scheint mir auch eine weitere Schwäche der Herangehensweise a la microTOOL zu sein. Es impliziert, dass der Architekt sich nicht nur in seinem Domänenmodell auskennen muss, sondern auch im Modell der Transformerentwicklung. Und dabei muss er auch noch für eine stabile Sourcecodegenerierung sorgen. Das anwesende Team von microTOOL gibt zwar an, dass dies in relativ wenigen Personenwochen (2-12) möglich ist. Dies allerdings dann pro Layer, also Präsentation, Business und Persistenz. Der Domänenexperte z.B. für Abrechnungssysteme muss demnach auch für alle Layer Experte sein. Auch gibt es einen Technikbruch, wenn er in einer .NET-Sprache für einen J2EE Transformatoren entwickelt. Hinzu kommt, dass nicht ganz klar war, welche technischen Plattformen microTOOL von Haus aus unterstützt. Zumindest bei der Präsentation waren es Struts, Hibernate und JBoss. Kein JSF, kein BEA Weblogic oder IBM Websphere. Diese sind zwar angedacht und der Workshop dient hier auch als Feedback aus der Entwicklergemeine. Es wirkte aber irgendwie schwach.
Wir haben überschlägig kalkuliert, dass die Einführung von objektiF in unserem Entwicklungsprozess ca. 100.000 € kostet. Dafür holt man sich einen fulminanten Vendor Lock-In ins Haus. Irgendwie war das alles nicht so überzeugend. Und ich hatte den Eindruck, dass nicht wenigen der anwesenden Teilnehmern ebenso ging.
Preise:
Die vorgestellten Transformatoren sind kostenlos in objectiF ab Version 6.1 enthalten.
Unsere Berater kosten definitiv nicht EUR 5.000 am Tag.
Architekt vs. Transformationsentwickler:
Ob der Architekt diese Rolle übernimmt, sei mal dahin gestellt - das hängt von vielen Faktoren ab. Fakt ist, dass eine der wesentlichen Leistungen in der Festlegung einer DSL auf Basis von UML liegt. Diese DSL ist für das Mapping von PIM auf PSM unerlässlich. Die Zielarchitektur mal verbindlich zu definieren ist allein schon ein Vorteil dieser Vorgehensweise.
Das Durchsetzen von Architekturen ist nun kein Traum mehr - und das auf eine im Handling so leichtgängige Art und Weise, dass es im Team auch Spaß macht. Spätestens im Wartungsfall tritt hier schon im ersten Projekt ein kräftiger ROI ein
Dömanenexperten:
Die DSL (also das UML-Profil) muss natürlich fachlich verträglich mit den Fähigkeiten der Domänenexperten sein. Wobei ein Dazulernen auch für Domänenexperten eine normale Sache ist.
Die vorgestellte Modellierung war gedacht für Domänenexperten, die nicht dauerhaft mit Business Entities und Aktivitätsdiagrammen Probleme haben. Also aus unserer Sicht für den Normalfall :-)
Transformatoren:
Diese müssen definitiv nicht in einer .NET-Sprache entwickelt werden.
Lange Rede, kurzer Sinn:
So ein Workshop kann zwar ein paar Eindrücke vermitteln. Über die gewonnenen Erkenntnisse sollte man aber mal reden ;-)
Frage: Ist es effizienter (qualitativ, monetär und zeitlich) wenn 10 ausgezeichnete und erfahrene codezentrierte Entwickler das das Projekt stemmen oder wenn nicht ganz so ausgezeichnete Entwickler den modell getriebenen Ansatz fahren, bzw. wo ist hinsichtlich der Teamqualifikation der "Break-Even" für den ein oder anderen Ansatz?
Gutes Anforderungsmanagement ist auch im Vorlauf eines MDD-Projektes unerlässlich.
Textuell vorliegende Anforderungen sind ein Normalfall im Projektalltag. Daraus ein Modell abzuleiten und dieses bidirektional nachvollziehbar zu haben, darum geht es ja auch.
Einer der Gründe, warum unser UML-Tool objectiF oft integriert mit unserem Werkzug in-Step für das Anforderungsmanagement genutzt wird :-)
Wo auch immer Sie 10 ausgezeichnete Entwickler herbekommen haben sollten, halten Sie sie gut fest. Vor allem, wenn Sie denen heutzutage noch stereotype Fleißarbeiten wie das Auscodieren einer festen Architektur zumuten ;-)
Nach unseren Messungen ist man in einer typischen Projektsituation mit unseren MDD-Transformatoren ca. 40 % schneller.
Der Break Even hängt immer vom Automatisierungspotential und vom realisierten Automatisierungsgrad ab.
Unsere Erfahrungen gehen dahin, dass der schlussendliche Wettbewerbsvorteil der MDD-Anwender mehr im Faktor Zeit als im Faktor Geld gesehen wird, auch wenn diese Aspekte nicht zusammenhanglos sind.
Aber es ist nun mal Fakt, dass man mit doppelt so vielen Entwicklern nicht doppelt so schnell entwickelt. Also lieber mit der gleichen Teamgröße mehr Performance. Schneller liefern oder aber mehr Feautures in der gleichen Zeit, wie auch immer.
Das Thema "gutes Anforderungsmanagement" ist sicher von sehr wesentlicher Bedeutung, aber es gilt natürlich weiterhin: Die Kette ist nur so stark wie das schwächste Glied in ihr. Ein schlechter Architekt, ein schlechter Transformationsentwickler und ein schlechter, sagen wir, Codierer ist für das Gesamtprojekt auch sehr übel. Ganz besonders tragisch wird es bei einem schlechten Testmanagement. Übergeordnet ist dabei nicht das Tool das Thema, sondern die Methodik. Weder Tool noch Mensch sind aktuell ausreichend qualifiziert um UML 2.0 vollumfänglich zu unterstützen. Selbstverständlich weiss das die OMG und wir reden dort auch über Reifegrade. Selbstverständlich arbeiten Toolhersteller auch massiv daran UML 2.0 vollumfänglich zu unterstützen. Also da ist der Weg sicher gut geebnet.
Wann Entwickler gut sind oder nicht ist auch eine nicht sonderlich leichte Frage. Hier sehe ich persönlich auch eine "Baustelle". Wie vergleicht man Embedded Entwickler mit J2EE Entwicklern? Kann man es einfach über Komplexitätsmetriken (wie McCabe oder Halstead) in Verbindung mit Zeit- und Fehlermetriken?
Leider stehen auch mir keine 10 guten Entwickler zur Verfügung. Das muss ich zugeben. Nur mit dem MDA Ansatz wird das nicht wirklich besser. Die Produktqualität wird nicht besser, wenn schlechte Entwickler modellgetrieben arbeiten. Bedenken Sie nur, wie der weit verbreitete Stand ist. Mehr als 90% der Entwickler haben UML bisher zur Codevisualisierung verwendet. Klassendiagramme, im Embeddedbereich sind Zustandsdiagramm hipp und dann noch ein wenig Sequenzdiagramme. Sicher ist einer der Ursachen auch gewesen, dass UML 1.x in einigen Belangen unzreichend war. Nun kommt mit UML 2 aber eine Menge. Action Sematics, OCL 2 usw. usf. sind neben teilweise sehr mächtigen Konstruktionsmöglichkeiten ein gewisses Neuland für viele Entwickler. Es ist eine neue Abstraktionsebene. Nun ist auch Java, C usw. eine Abstraktionsebene, ein Modell. Und es gab Zeiten da hat man sich den Output der ersten C Compiler nach angesehen, weil man ihnen nicht vertraut hat. Etwas ähnliches entwickelt sich jetzt.
Ich halte den MDD Ansatz für sehr vielversprechend und es ist auch nachvollziehbar das entsprechende Toolhersteller diese Strömung stark vorantreiben, da es nach wie vor um ökonomische Interssen geht. Es ist auch klar - um dem vorzubeugen - dass gute Lieferanten in der IT gelernt haben, dass ein reiner Lizenzabverkauf keine langfristige Kundenbeziehung und schon gar keine Win-Win Situation schaffen. Die Roadshows der Anbieter erwecken aber immer noch den Eindruck, dass alles schon machbar ist und die ganze Welt so arbeitet nur die Zuhörerschaft noch nicht. Da ist mehr Realitätssinn gefragt. Das Thema Migration wird vollkommen unzureichend betrachtet.
Auch wir arbeiten daran, UML 2.0 über den kompletten Softwarelifecycle einzuführen. Da von Transformationen und tollen Automatisierungen zu sprechen ist noch ein wenig "Irrsinn". Das ist etwas für die "guten Entwickler". Aber dem Rest muss erstmal die Methodik nahe gebracht werden. Bedenken sie die kulturellen und sozialen Auswirkungen in Unternehmen. Der Entwickler, der seit Jahren mehr oder weniger codiert hat und bisher Vision für ein gutes UML Werkzeug hielt um das Management mit Bildern zu versorgen soll nun modellgetrieben arbeiten. Und das womöglich in einem Umfeld, in dem es gar noch SA/SD Entwicklungen gibt neben OOA/OOD. Es entstehen zwei Lager. Die Kritiker und die Befürworter. Und jeder überdenkt, wann und ob der vom Lager der Kritiker zum Lager der Befürworter wechselt. Ist es ein Hype oder ist es eine ernst zu nehmende zukünftige Entwicklung. Ähnliches durfte Java durchmachen. Auch heute gibt es noch Menschen, die Java kritisieren. Im sicherheitkritischen Bereich (safety, nicht security) auch -bedingt- noch gerechtfertigt.
Ich zweifele nicht Ihre Aussagen an. Verstehen Sie mich nicht falsch. Sie sind jedoch eine gewisse Vereinfachung. Es ist noch eine Menge Arbeit zu tun. Ihre Ausführung ist mehr ein idealisiertes Bild, ein Ziel oder eine Vision (bin mir da nicht ganz sicher) von dem was da ist. Auch wir haben die Vision "MDD" mit einer entsprechenden Strategie. Denn wir glauben auch an die Steigerung der Durchlaufzeiten.
Bei dem "schneller" oder "mehr Features" fehlt mir ein weitaus wichtigerer Punkt: "weniger Fehler". Denn auch hier gibt es gute Ansätze bei ausführbaren Modellen Verifikationen durchzuführen, Modelle zu testen oder aus Modellen heraus Testszenarien generieren zu lassen.
Ich danke euch beiden für die Beiträge. Ich bin selbst auch der Meinung, dass der Zug in Richtung MDD fährt. Alerdings darf man auch dabei nie einen Satz vom leider verstorbenen David Wheeler vergessen:
«Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem.»
Selbstverständlich berührt er keine menschlichen Probleme. Technik kann diese niemals lösen. Wer immer das glaubt unterliegt sowieso einem fundamentalen Irrtum und wird irgendwann in der Sackgasse landen. Da halte ich es dann wieder mit Weizenbaums Macht des Computers und der Ohnmacht des Menschen :-)
Allerdings werde ich deinem letzten Satz einen eigenen Eintrag widmen.
Mag gar sein, dass einer meiner Kollegen auch auf dem Workshop war. Er brachte mir allerdings eine weitaus eingedampftere Form wieder. Bei seiner Kurzzusammenfassung konnte ich ObjectiF durch RSA und MicroTool durch IBM austauschen. In einem Vorgängerprojekt war ich schon sehr erstaunt über das Lizenzmodell von ObjectiF. Sie hatten Nutzungsstunden verkauft. Man konnte das Tool also beispielsweise 1.000 Stunden im Jahr nutzen. Ich fand die Idee ungewöhnlich aber originell.
Letztendlich finde ich die Bezeichnunt Tool für solche Umbegungen eigentlich unpassend. Ich verstehe unter einem "Tool" etwas kleineres. Aber die MDD/MDA Werkzeuge haben eine Komplexität, die weit darüber hinausgeht. Und du sprichst einen interessanten Punkt. Nicht, dass es noch nichteinmal überhaupt ein paar mehr oder minder etablierte Prozesse zur System- und Softwarearchitektur gibt, da kommen Werkzeuge, die schon gegen proprietäre Prozesse den Kampf antreten wegen neuer Rollen und Aktiviäten. Das macht es uns nicht eben leichter. Denn das größte Problem ist doch erstmal den "Architekten" Architektur beizubringen.
Der RSA ist überigens nicht so übel.