Und nicht jede x-beliebige Beschreibung von IT-Systemen ist schon eine Architektur.

2. Auf der technischen Ebene laufen die Bullets im Blog auf einen Vergleich zwischen RESTful “Services” und einer (vollen, echten) “SOA” hinaus.

3. Web 2.0 ist deswegen SICHER KEINE SOA, weil es keine von der Komponente, die das Service implementiert, unabhängige MASCHINENLESBARE DEFINITION eines Services gibt, mit der ich eine andere Software Komponente dazu zwingen kann, das Service auch zu “konsumieren”.

4. Web 2.0 – vor allem über die Browser/JavaScript Integration – ist LEDIGLICH DAS BEKANNTE KOMMPONENTENORIENTIERTE Programmieren. Hatten wir schon in den 1990er Jahren.

5. Das es kein Transaktionskonzept im Web 2.0 gibt ist NICHT RICHTIG. Bestellungen etc. sind durchaus transaktional (sogar rechtlich-juristisch).

6. Die SOA Architektur-Graphik ist – soweit ich mich erinneren – von der OPEN GROUP “ausgeliehen”. Sie ist auch GENAUER als der Blog und unterscheidet – richtigerweise – einen PROCESS LAYER (für Humanprozess) und einen SERVICE LAYER, wo machine-2-machine Kopplung ohne Userinteraktionen statt findet. Ein Bullet im Blog unterstellt, dass es keinen Workflow im Web 2.0 gäbe. Das ist wohl richtig für Web 2.0, aber FALSCH für eine SOA, die einem Unternehmen etwas bringen soll.

7. Die Unternehmen, die auf “klassische” SOA mit ESB und BPMS setzen, gehen KEINEN FALSCHEN Weg, weil sie EXISTIERENDE Applikationen integrieren müssen und nicht, wie die typische Web 2.0 Applikationen, auf der GRÜNEN WIESE etwas Neues hinstellen können. Natürlich würde man heute ein Provisionssystem, ein Kreditantragsmanagement-System oder ein Ticket-System (siehe aber Punkt von vorneherein service-orientierte programmieren mit den im Blog angesprochenen Schnitttstellen. Aber wer kann sich das heute leisten – auch von der Zeit her?

8. Der ÖBB Personenverkehr macht das im Übrigen heute schon so, dass er seine neue Ticket-Applikation, ticket4all, gleich service-orientiert neu baut.

-cfs