Der Sinn und Zweck computergestützter Anwendungen birgt viele Aspekte. Hauptsächlich sind Anwendungen Hilfsmittel, um das Geschäftsmodell des eigentlichen Geschäftszwecks der Firma zu implementieren. Das Geschäftsmodell ist so der zentrale Fokus der Software-Entwicklung, nicht die Tools oder Technologien, die benutzt werden, um eine Anwendung zu implementieren. Der Fokus geht also zurück auf das Geschäftsmodell, auf die Geschäftslogik. Es ist die Kernfrage zu stellen, wie die Geschäftslogik effizient, kostengünstig und flexibel in Anwendungen abgebildet werden kann. Die Object Management Group (OMG) hat eine neue Methode erarbeitet, um Anwendungen zu entwickeln. Diese Methode wird MDA (Model Driven Architecture) genannt. MDA kann hier am besten als ein Konzept beschrieben werden. Mehr konzentriert auf Anwendungen als auf Plattformen, die das Zentrum der Interoperabilität sind, fordert MDA Folgendes: Das Modellieren der Geschäftslogik und der Domänen-Elemente ist die beste Methode der Software-Entwicklung – unabhängig von der Middleware, die das Design implementiert.

Schön und gut – das sagt die OMG, aber warum sollte man sich als Entwicklungsleiter mit diesem Ansatz auseinandersetzen? Uns interessiert in erster Linie die effektive Umsetzung der Anforderungen, die uns die Anwender stellen und weniger die strategischen Überlegungen eines unabhängigen Konsortiums. Warum also MDA? Was sind die Vorteile?

Menschen haben die enorme Fähigkeit, komplexe Systeme zu verstehen, wenn sie ein Modell der Objekte entwickeln und sich veranschaulichen, wie diese miteinander zusammenhängen und wirken. Das ist es, was objektorientiertes Design so mächtig macht: Es zieht Nutzen aus einer inhärenten Fähigkeit, wie wir die Welt um uns herum zu verstehen haben. Dieser modellbasierte Ansatz erlaubt uns, die grundsätzliche Geschäftslogik, die hinter einer Applikation steckt, von der spezifischen Middleware, auf der sie im Einzelfall implementiert ist oder wird, zu trennen.

Wenn man sich Gedanken über die Art der Software-Entwicklung macht, darf man den menschlichen Faktor nicht außer acht lassen. Es existiert ja das Team, das die bisherigen Applikationen entwickelt hat. Dieses Team verfügt über hervorragendes Know-how über die Prozesse des Unternehmens und die Umsetzung dieser Prozesse in Software. Dieses Know-how gilt es zu erhalten. Das Management muss also beurteilen, inwieweit das existierende Team zu motivieren ist, sich in neue Technologien einzuarbeiten. “Eine Person, die mit Windows umgehen kann und ein Basisverständnis für objektorientierte Entwicklungskonzepte hat, benötigt ungefähr 45 Tage, an denen sie sich bei Vollzeit, unter Einsatz eines Mentors, mit dem Tool beschäftigt. Ohne Mentoring, aber unter Nutzung des Standard-Education-Angebotes, könnte es annähernd 75 Tage dauern, bis diese Person wieder so produktiv entwickelt wie zuvor.”

Mentoring, der begleitende Einsatz eines erfahrenen Entwicklers in der neuen Technologie, wurde übrigens auch in der Gartner-Studie berücksichtigt und als ein Kosten und Zeit sparendes Mittel propagiert. Und eins darf auch bei der Kostenbetrachtung nicht unter den Tisch fallen: Nach dieser Lernphase erhöht sich die Produktivität des Entwicklers, insbesondere dann, wenn diese Umgebung Werkzeuge zur Unterstützung von Teamentwicklung beinhaltet.

Als dritten und letzten Aspekt, den es zu berücksichtigen gilt, betrachten wir den Status quo. Was haben wir für eine gewachsene Anwendungslandschaft? Wir fangen ja nicht bei Null an und machen alles neu. Stichwort EAI (Enterprise Application Integration), die Integration der bestehenden Anwendungen und Systeme in neue Technologien ist ein Muss. Auch eine künftige Art der Software-Entwicklung – egal mit welchem Ansatz – muss dem Entwickler die Möglichkeit bieten, auf vorhandene Daten (-banken) und Anwendungsmodule oder -Programme zuzugreifen.

Warum also moderne Software-Entwicklung? Damit man aktuelle und künftige Technologien zusammen mit der vorhandenen Anwendungslandschaft unterstützen kann. Wie sollte diese moderne Software-Entwicklung aussehen? Sie sollte uns die Möglichkeit bieten, uns auf unsere eigentlichen Aufgabe zu konzentrieren: die Implementierung des jeweiligen Geschäftsmodells mit der entsprechenden Geschäftslogik. Die technischen Details der jeweils zu Grunde liegenden Technologie(n) sollte uns die Entwicklungsumgebung gekapselt zur Verfügung stellen, und das für das heute Verfügbare und für das morgen Aktuelle. Und das Ganze, ohne dass der Entwickler jedes Mal den Technologiesprung in den sich immer häufiger drehenden Technologiezyklen mitmachen muss.

AD Solutions AG

D–40789 Monheim

Telefon: (+49) 02173/1675-280

www.adsolutions-group.com