In kleinen Schritten zur besseren Entwicklung

Wie wird die Applikation betrieben und welche Architektur muss ich umsetzen

Nachdem die Organisation sichergestellt hat, dass nur freigegebene Technologien oder Artefakte innerhalb des Projekts verwendet werden dürfen, könnte in einer zweiten Stufe festgelegt werden, wie eine optimale Infrastruktur für ein Projekt bereitzustellen ist und wie die ausgelieferte Applikation in den Gesamtbetrieb integriert werden kann. Dabei handelt es sich jedoch nicht nur um
einen Produktkatalog (also eine namentliche Auflistung von Web- oder Application-Server-Produkten, die im Unternehmen zum Einsatz kommen). Vielmehr handelt es sich um eine vorgefertigte und verbindliche Zusammenstellungen von Produktinstallationen (Webserver, Application-Server, Datenbankserver etc.), deren festgelegte physikalische Verteilung sowie die Benutzung von Protokollen zur Kommunikation untereinander, die unter bestimmten Rahmenbedingungen aufgesetzt werden. Bevor näher darauf eingegangen wird, möchten wir das am Beispiel der klassischen Softwareentwicklung verdeutlichen, bei dem dieses Verfahren bereits praktiziert wird. Der Kerngedanke des Architekten oder Entwicklers hierbei ist, für bestimmte Probleme nicht eine eigene Lösung zu evaluieren. Vielmehr bedient er sich bewährten Lösungsschablonen, die bei wiederkehrenden und daher bekannten Problemen vielfach verwendet wurden. Genau diese Methodik könnte für den Aufbau von Infrastrukturmustern adaptiert werden. Als Herausforderung stellt sich hierbei die Identifizierung und Bewertung der Rahmenbedingungen und Kriterien dar, die zur Erstellung eines solchen Musters benötigt werden. Als Kriterien könnten z. B. die Skalierbarkeit oder Verfügbarkeit der Applikation definiert und bewertet werden.

Betrachtet man das jetzige Ergebnis, ist der Architekt im Besitz von Informationen über die zukünftige Infrastruktur, in die die Applikation ausgerollt wird. Trotz der Informationen können immer noch falsche Entscheidungen beim Entwerfen der Architektur getroffen werden. Um dem etwas vorzubeugen, sollte jedes erzeugte Infrastrukturmuster um Informationen ergänzt werden, die zumindest einen verbindlichen Architekturansatz vorgeben. So könnte z. B. die Vorgabe der Anzahl von logischen Schichten in Abhängigkeit der bewerteten Kriterien eine Lösung darstellen. Wenn eine stärkere Ausprägung gewünscht wird, ist es auch denkbar, dass z. B. zu jeder Schicht eine Technologie (z. B. Struts auf der Präsentationsschicht und EJB auf der Geschäftsschicht) verbindlich zugeordnet wird. Dadurch erhält der Architekt die Vorgaben bezüglich der Rahmenbedingungen einer Architektur und muss sich innerhalb dieser bewegen. Es muss jedoch darauf geachtet werden, dass die Vorgaben der Muster (Produkte und Technologien) sich konform zu der geführten Whitelist verhalten.

Wie findet der Zugriff auf die Systeme statt

Betrachtet man die Anzahl der individuell entwickelten Applikationen im Enterprise-Umfeld, die nicht mit dem Systemumfeld einer Organisation interagieren oder kommunizieren, kann diese durchaus als sehr gering angesehen werden. Architekten und Entwickler stehen oftmals vor der Herausforderung, interne Systeme der Organisation an die Applikation anzubinden, ohne Informationen über diese zu besitzen oder ihr internes Verhalten zu kennen. Verschärft wird die Problematik durch einen möglichen Einsatz von proprietären Strukturen einer Organisation, also einer Anbindung an Systeme, die individuell für ein Unternehmen entwickelt wurden. Ein weiteres Problem stellt die Menge der Art und Weise einer Anbindung dar. Bedenkt man, dass in einem Unternehmen in der Regel eine große Anzahl an Applikationen entwickelt wird, entsteht dadurch eine Vielzahl an Lösungsansätzen für ein und dasselbe Problem, da jeder Architekt und sein Entwicklerteam den Zugriff unterschiedlich realisieren. Neben den steigenden Entwicklungskosten entsteht auch ein erhöhter Testaufwand (was sich wiederum negativ auf die Kosten auswirkt), da nicht nur die umgesetzten Kundenanforderungen getestet werden müssen, sondern auch der eigentliche Zugriff und die Routinebehandlung der angebundenen Systeme – pro Applikation. Ergänzt wird die Problematik dadurch, dass in diesem Lösungsansatz die Applikation selbst für Ihr Verhalten bezüglich der Laufzeitumgebung zuständig ist. Der Entwickler muss somit innerhalb der Applikation Parameter oder Routinen definieren und diese bezüglich der Umgebung zur Laufzeit abfragen, damit die Anwendung entsprechend unterschiedlich reagiert (kommen die Daten aus dem Produktivsystem oder aus Mock-Objekten?).

Abb. 2: Zugriff über die Applikation
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.