Mit guter Prozessdokumentation kann man das Problem einschränken. Hier gibt es keine festgeschriebenen Standards. Ein SOA-Bestandteil ist zwar das Veröffentlichen der Schnittstellen in einem Verzeichnis – zum Beispiel auf UDDI-Basis. Aber die so abgelegten WSDL-Beschreibungen (siehe Seiten 20, 21) eignen sich kaum als verständliche Darstellung der verfügbaren Dienste. Entsprechend sollten hier grafische Tools zur Prozessmodellierung einbezogen werden.

Der Nutzen, die Architektur komponentenbasiert aufzu-bauen, kann zum Fluch werden: Der Gedanke, Eigenentwicklungen einzubeziehen, ist verfüh-rerisch. Dennoch ist es der erste Schritt, um selbst für Altlasten zu sorgen, die mit der Zeit zu Schwierigkeiten führen, wenn es um Updates, Weiterentwicklungen und den Wissenstransfer unter Entwicklern geht. Denn mit SOA bahnt sich ein Paradigmenwechsel an, die Anforderungen an das IT-Personal verändern sich. Es geht nicht mehr darum, ein einzelnes System zu betreuen, sondern viele verschiedene Komponenten unterschiedlicher Hersteller. Hier mangelt es Firmen an Erfahrungen. Außerdem muss darauf geachtet werden, dass das Prozess-Know-how im Unternehmen nicht verloren geht. Oft läuft das gesamte organisatorische Prozesswissen beim Organisationsleiter zusammen, der auch für die IT zuständig ist. Wenn die DV sich hier zu- rücknimmt, muss eine neue Position geschaffen werden, die diese Prozessabläufe im Blick hat.