Samstag, 25. November 2006
Thema: Anforderungen
Ein spannender Kommentar von Rolf Götz zum Artikel "Was und Wie" regt zum Nachdenken über Service-orientierte Archtektur (SOA) und Requirements Engineering an.
Ich denke, bei SOA sind Anforderungen für verschiedene Kontexte wichtig.
Zum einen im Kontext des Unternehmens, fokussiert auf die Geschäftsprozesse, zum anderen im Kontext jedes einzelnen Services.
- Unternehmenskontext: Welche Anforderungen ergeben sich durch die Geschäftsprozesse im Unternehmen an eine IT-Landschaft? Eine SOA hat den expliziten Auftrag, die Geschäftsprozesse duch Komposition verschiedener Services zu unterstützen.
- Service-Kontext: Die SOA zerlegt die Anforderungen des Unternehmens in verschiene Services und bildet die Anforderungen auf jeden einzelnen Service ab.
Die SOA beantwortet das "Was" der Anforderungen des Unternehmenskontexts durch ein "Wie" aus der Kombination von Services. Für jeden Service ergeben sich neue Anforderungen "Was".
Rolf: diese Kontexte sind andere Ebenen als die Abstraktionsebenen. Innerhalb eines Kontexts können Anforderungen auf allen Abstraktionsebenen formuliert werden.
In meinem (bislang einzigen expliziten) SOA-Projekt entwickelten wir eine modellbasierte Definition von Prozessen zur Bearbeitung von elektronischem Belegverkehr. Auf oberster Ebene bilden die Prozesse für Kunden sichtbare Verarbeitungsprozesse ab. Die einzelnen Schritte des Prozesses bestehen wiederum aus (technischeren) Prozessen. Prozesse rufen tiefere Prozesse, bis am untersten Ende Code-Routinen über Webservices gerufen werden. Die Tiefe der Aufrufhierarchie ist nicht im Voraus festgelegt.
Die IT stellt Services zur Verfügung, die von den Beratern vor Ort zu kundenspezifischen Verarbeitungsprozessen zusammengestellt werden.
Unsere Leistung war es, die möglichen Strukturen zu definieren, wie Prozesse und Webservices in Zusammenhang stehen können. Wir erstellten außerdem den Editor, mit dem die Prozesse erstellt und konfiguriert werden können.
In dieser Lösung gibt es die Geschäftsprozess-Sicht, deren Anforderungen durch die Berater beim Kunden definiert werden, sowie die Service-Sicht, die durch die Techniker in der IT zur Verfügung gestellt werden.
Für mich als Business Analyst ist SOA eine Besinnung auf die Regel, dass jede Software letztlich den Geschäftsprozess unterstützen muss. Die gesamte Software eines Unternehmens muss im Rahmen der Geschäftsprozesse nützlich sein und dazu zu einer Gesamt-Unterstützung für das Geschäft komponiert werden. Die IT hat den Auftrag, die Arbeit des Unternehmens zu unterstützen.
Die zahlreichen Artikel der Computerwoche zum Thema SOA und CIO haben genau das zum Thema, z. B. im Artikel "Prozessorientierung statt Produktionstiefe".
Ed Yourdon hat in seinem Blog im Artikel "CIO Insight’s predictions of 30 top IT trends for 2007" eine interessante Studie kommentiert, deren Top 1 Trend "Process improvement will be job No. 1" und Top 8 Trend "The division between IT and business will diminish" klar die Ausrichtung auf das Geschäft beschreiben.
Scheint so, dass mein Job als Business Analyst immer spannender und wichtiger wird :-)
Ich denke, bei SOA sind Anforderungen für verschiedene Kontexte wichtig.
Zum einen im Kontext des Unternehmens, fokussiert auf die Geschäftsprozesse, zum anderen im Kontext jedes einzelnen Services.
- Unternehmenskontext: Welche Anforderungen ergeben sich durch die Geschäftsprozesse im Unternehmen an eine IT-Landschaft? Eine SOA hat den expliziten Auftrag, die Geschäftsprozesse duch Komposition verschiedener Services zu unterstützen.
- Service-Kontext: Die SOA zerlegt die Anforderungen des Unternehmens in verschiene Services und bildet die Anforderungen auf jeden einzelnen Service ab.
Die SOA beantwortet das "Was" der Anforderungen des Unternehmenskontexts durch ein "Wie" aus der Kombination von Services. Für jeden Service ergeben sich neue Anforderungen "Was".
Rolf: diese Kontexte sind andere Ebenen als die Abstraktionsebenen. Innerhalb eines Kontexts können Anforderungen auf allen Abstraktionsebenen formuliert werden.
In meinem (bislang einzigen expliziten) SOA-Projekt entwickelten wir eine modellbasierte Definition von Prozessen zur Bearbeitung von elektronischem Belegverkehr. Auf oberster Ebene bilden die Prozesse für Kunden sichtbare Verarbeitungsprozesse ab. Die einzelnen Schritte des Prozesses bestehen wiederum aus (technischeren) Prozessen. Prozesse rufen tiefere Prozesse, bis am untersten Ende Code-Routinen über Webservices gerufen werden. Die Tiefe der Aufrufhierarchie ist nicht im Voraus festgelegt.
Die IT stellt Services zur Verfügung, die von den Beratern vor Ort zu kundenspezifischen Verarbeitungsprozessen zusammengestellt werden.
Unsere Leistung war es, die möglichen Strukturen zu definieren, wie Prozesse und Webservices in Zusammenhang stehen können. Wir erstellten außerdem den Editor, mit dem die Prozesse erstellt und konfiguriert werden können.
In dieser Lösung gibt es die Geschäftsprozess-Sicht, deren Anforderungen durch die Berater beim Kunden definiert werden, sowie die Service-Sicht, die durch die Techniker in der IT zur Verfügung gestellt werden.
Für mich als Business Analyst ist SOA eine Besinnung auf die Regel, dass jede Software letztlich den Geschäftsprozess unterstützen muss. Die gesamte Software eines Unternehmens muss im Rahmen der Geschäftsprozesse nützlich sein und dazu zu einer Gesamt-Unterstützung für das Geschäft komponiert werden. Die IT hat den Auftrag, die Arbeit des Unternehmens zu unterstützen.
Die zahlreichen Artikel der Computerwoche zum Thema SOA und CIO haben genau das zum Thema, z. B. im Artikel "Prozessorientierung statt Produktionstiefe".
Ed Yourdon hat in seinem Blog im Artikel "CIO Insight’s predictions of 30 top IT trends for 2007" eine interessante Studie kommentiert, deren Top 1 Trend "Process improvement will be job No. 1" und Top 8 Trend "The division between IT and business will diminish" klar die Ausrichtung auf das Geschäft beschreiben.
Scheint so, dass mein Job als Business Analyst immer spannender und wichtiger wird :-)
... kommentieren