Freitag, 8. Mai 2009

Was SOA von der Objekt orientierten Programmierung lernen kann! (Teil 1)

Es war einmal eine Zeit, in der die Objektorientierung in Mode kam. Die OO Technologie wurde für Ihre Produktivität und Flexibilität gepriesen. Nicht wenige hielten Sie für einen Erlöser, der die Wiederverwendung und den Weltfrieden mit sich bringen würde. Viele hofften auf die Wiederverwendung und auf Entwurfsmuster die die Kosten auf wundersame Weise reduzieren sollte.
Bald schon wurden ehrgeizige Projekte von tapferen Architekten und Projektleitern gestartet. Mit kleinen Anwendungen und Pilotprojekten für den Aufbau von Erfahrungen wollte sich kaum jemand abgeben. Mit C++ oder sogar Java sollten unternehmenskritische Mainframe Anwendungen abgelöst werden. Für Ordnung und Struktur sorgten mächtige Prozessmodelle und Vorgehensweisen. Detaillierte Pläne für die zu erstellende Software wurden mittels der UML gezeichnet.
Große Horden mit zahlreichen furchtlosen Analysten, Softwaredesignern und Architekten nahmen die ehrenvolle Mission in Angriff. Viele von Ihnen hatten ganz genaue Vorstellungen aber noch wenig oder gar keine Erfahrung mit der neuen Sprache, mit den Werkzeugen und Plattformen. Auf halbem Wege fragten sich einige, ob die Systeme an denen Sie arbeiteten jemals fertig oder stabil und schnell laufen würden. Die anderen bleiben standhaft und haben alles gegeben um erfolgreich zu sein. Aber langsam gingen die Budgets zu Ende und die Abgabetermine waren schon lange verstrichen. Schließlich kam die Ernüchterung und die Objektorientierung, Java und die Mehrschichtenarchitekturen wurden in Frage gestellt. Oft hörte man Sätze wie „Java ist zu langsam“ oder „Entity Beans performen doch nie“.
Nicht alle haben sich von diesen Fehlschlägen entmutigen lassen. Einige haben mit Ihrer Erfahrung aus den erfolglosen Großprojekten neue kleinere Projekte gestartet. Die Methoden wurden entschlackt und reduziert. Praktikablere Vorgehen wurden entwickelt und neue Vokabeln wie Agil oder Extreme Programming wurden eingeführt. Zum Einsatz kamen immer häufiger ganz simple Java Klassen, die man Pojos nannte. Auch die Server wurden von Version zu Version schneller und stabiler. Die Entwickler, die sich nicht entmutigen ließen, fanden neue Tools, die Ihnen viel Arbeit und Mühe abnahmen. Die fleißige Ameise half Ihnen bei Bau der Software und im Schatten der Sonnenfinsternis schrieben sie Ihren Code. Nach den ersten erfolgreichen Miniprojekten wurden mittlere Projekte und schließlich größere in Angriff genommen. Getragen vom Erfolg stieß man in immer mehr Bereiche vor und befreite die IT Landschaft um gefürchtete Altsysteme.
Was genau wurde bei den neuen erfolgreichen Projekten anders gemacht, als bei den erfolglosen?
- Iteratives Vorgehen:
Anstatt ein komplexes System im Stück zu planen und zu realisieren wird ein Projekt in mehrere kleine Iterationen aufgeteilt, bei denen immer eine lauffähige Version erstellt wird, die Iteration für Iteration erweitert wird.
- Vor dem eigentlichen Projekt wird ein Prototyp erstellt.
Der Prototyp soll Hinweise zur Machbarkeit liefern und dient zum Sammeln von Erfahrungen. Der Prototyp kann in die Iteration übergehen. Idealerweise sollte ein Prototyp jedoch nicht weiter entwickelt werden. Das Projekt sollte mit den Erfahrungen von Neuem starten.
- Schlanker Prozess:
Beispielsweise wurden anstatt alles haarklein mit der UML zu beschreiben nur so viel wie nötig modelliert. Oder wie beim XP auf UML verzichtet.
- Teamgröße:
Die Teamgrößen wurden reduziert. Anstatt mehreren Dutzend Entwicklern haben die Teams oft weniger als 10 Mitglieder.
- Bestehende Tools und z. B. Infrastruktur verwenden:
Anstatt eine eigene Persistenz Engine zu entwickeln wird auf fertige Tools wie z. B. Hibernate zurückgegriffen.
Im zweiten Teil werde ich in einem späteren Posting beschreiben, was man von den Erfahrungen und Lektionen der Objektorientierung auf die SOA übertragen kann.

Keine Kommentare:

Kommentar veröffentlichen