Wo sind die SOA-Architekten?
- Architekten bzw. SOA-Architekten sollen die Schnittstelle zwischen Fachabteilungen und IT bilden.
- Bisher sind nur wenige solche Experten in den Unternehme aktiv .warum?
- Welche Qualifikationen brauchen sie und wie können Unternehmen sie aufbauen?
Alles hoch aktuelle Fragen
Eine Architektur braucht Architekten. Da bildet SOA keine Ausnahme. Da es sich beim Thema Serviceorientierung um einen IT-Ansatz zur besseren Unterstützung von Anforderungen aus den Geschäftsstrategien eines Unternehmens handelt, sind zu diesem Thema doch wohl zunächst die IT-Architekten eines Unternehmens gefragt. Also müsste die erste Frage eigentlich lauten: “Leisten sich Unternehmen solche IT Architekten?” und wenn ja: “Befassen sich diese IT-Architekten mit dem Thema SOA?”
Hierzu mache ich die Beobachtung, dass sich eben viele Unternehmen diese IT-Architekten nicht mehr leisten und oft wird mir erzählt, dass man sich den IT-Elfenbeinturm nicht mehr leisten könne. Einfache Schlussfolgerung meinerseits: “Wo kein Architekt, da auch keine Architektur!” Ich wünsche diesen Unternehmen viel Spass mit dem Thema SOA!
Dort wo solche Architekten in Lohn und Brot sind, kenne ich keinen Fall in dem sich der/die verantwortliche Architekt/in oder das Architektenteam nicht mit dem Thema SOA beschäftigt oder beschäftigt hat. In allen Fällen wurde zumindest die Relevanz für das jeweilige Unternehmen geprüft und in nur wenigen Fällen wurde das Thema als nicht relevant eingestuft. Ein IT-Architekt, der dieses Thema ignoriert, sollte es einen solchen geben, macht einen Fehler.
Ich kenne keinen seriösen Kollegen, der sich als SOA Architekt bezeichnen würde und das ist auch gut so, denn Serviceorientierung ist ein Thema, das alle Bereiche einer IT Architektur tangiert, diese aber nicht ablöst.
Woran kann es dann liegen, dass der Eindruck entsteht, es seien zu wenige solcher Experten zum Thema SOA aktiv? Nun, nicht jeder IT-Architekt, den ich kenne, verfügt über die kreativen Spielräume oder Kompetenzen um das Thema in seinem Unternehmen entsprechend sichtbar zu machen und zu treiben. Diese Spielräume und Kompetenzen sind auf der anderen Seite aber unbedingt erforderlich um SOA zu einer erfolgreichen Basis oder Strategie für die IT in einem Unternehmen zu machen. Ich will es bei dieser Aussage belassen, denn oft sind Rollenkompetenzen in den Unternehmen starken politischen Einflüssen unterworfen und das macht die Sache hoch individuell und komplex.
Sehr wichtig erscheint mir die Frage nach der Qualifikation und dem Aufbau dieser Qualifikation.
Nach meiner Überzeugung, gewonnen durch viele Jahre Erfahrung als IT-Architekt, wird man dies nicht allein durch ein erfolgreiches Studium sondern einzig und allein durch langjähriges Praktizieren. Ein IT-Architekt ist kein IT-Architekt wenn er möglichst viele Bücher zum Thema studiert hat, sondern wenn er sich in mindestens einer oder möglchist zwei Disziplinen (z.B. Anwendungsentwicklung, IT Infrastruktur, Informationsmanagement, …) die Finger auch “schmutzig” gemacht hat. Dazu gehört es dann auch, dass ein Unternehmen Mitarbeiter systematisch zu IT-Architekten aufbaut und stetig weiter entwickelt.
Bei IBM gibt es z.b. eine solche systematische Entwicklung und Zertifizierung zum IT-Architekten. Dabei spielt Ausbildung eine wichtige Rolle, jedoch ist ein entprechendes Mentoringprogramm, bei dem erfahrene Kollegen den weniger erfahrenen Kollegen mit Rat und Tat zur Seite stehen, nach meiner Überzeugung ausschlaggebend für den Erfolg. Die Zertifizierung erfolgt dann auch nicht durch Managementkremien, sondern durch zertifzierte Architekten. Diese übernehmen damit die Verantwortung für die Qualität der Architektenpopulation.
Welche Rollen sollte ein erfolgreicher IT-Architekt einnehmen können?
Wir haben 5 Rollen identifiziert:
- Lösungsdesigner
- Technolgieberater
- Methodenberater
- Moderator
- Projektcoach
Als Lösungsdesigner ist der IT-Architekt in der Lage, die Brücke zwischen fachlicher Anforderung und der angemessenen IT-Implementierung zu schlagen.
Als Technolgieberater ist er bei der Selektion der entsprechenden Technolgien in einer führenden Rolle.
Als Methodenberater sorgt er für die Adaption und Anwendung der passenden Methode(n).
Als Moderator ist er für die Kommunikation aller Beteiligter als Initiator, Katalysator und “Übersetzer” verantwortlich.
Als Projektcoach sorgt er dafür, dass der eingeschlagene Weg erfolgreich bis zum Ende gegangen wird.
Zusammenfassen möchte ich sagen, dass Serviceorientierung und somit SOA die Aufgabe für die jeweiligen IT-Architekten in den Unternehmen ist. Dazu brauchen sie die nötigen Spielräume und Kompetenzen. Ein erfahrener IT-Architekt wird beim Thema SOA keine unüberwindliche intelektuelle Hürde vorfinden. Das Thema ist Bestandteil seines Aufgabengebiets und wenn er verstanden hat wo sein Unternehmen hin will wird er einen Weg definieren, der zum Unternehmen passt und der auch erfolgreich begangen werden kann.
Vielen Dank für diesen recht schönen Beitrag. Er zeigt deutlich auf, was der erfahrene IT-Berater (bei mir im Umfeld Enterprise Content Management) schon lange in der Praxis erlebt – den Wandel vom reinen Technologieberater zum Strategie- und Lösungscoach. Technik und Technologie spielt zwar weiterhin eine zentrale Rolle – der Anwender und meist auch die IT-Verantwortlichen – können massive Unterstützung gebrauchen, um Herausforderungen möglichst optimal zu lösen. Da für jeden Themenbereich aber neben Methodenwissen auch fundiertes Fach-Know-how notwendig ist, lohnt sich nur selten der interne Aufbau einer solchen Ressource.
Da hat Herr Krüger ja seine Person schön glänzen lassen, allerdings vermisse ich etwas inhaltliche Essenz in seinem Schmeichelbeitrag. Scheint sich wohl die Hände nicht oft “schmutzig” machen zu müssen im “Enterprise”-Umfeld. Zeigt mal wieder, dass SOA ganz schön viel heiße Luft ist.
Fakt ist doch, dass nicht alle Unternehmen sofort einem neuen Trend hinterherstolpern können und wollen, nur der Mode wegen. Es gilt nämlich neben dem IT-Schönheitspreis zu gewinnen, auch noch bestehende Anwendungen zu pflegen und ganz nebenbei das oft recht harte Alltagsgeschäft abzuwickeln. Das scheinen “Berater” gern zu vergessen, kann man doch mit dicken Schlagworten viel Kohle einfahren. Dem Kunden ist dabei kein Stückchen geholfen.
Und viele Software-Lösungen sind doch in den Firmen bereits im Wandel begriffen – von Host-Anwendungen zu Desktop-Anwendungen oder von Desktop-Anwendungen zu Web-Applikationen, von dateibasierten Programmen zu Datenbank-orientierten Satelliten-Clients. Aber
das geht nicht von heute auf morgen, sondern es ist ein steter Prozess. Und eine laufende Umstellung wird doch keiner einstampfen.
Auch muss SOA nicht die Lösung für alles sein – das hängt immer von der Situation ab. Ganz konkret manifestiert sich SOA doch schließlich als Client-Server-Architektur. Setzt man zum Beispiel
eine Applikation als Intranet-Lösung um, so entsteht oft kein konkreter Vorteil mit SOA, weil der Server in diesem Falle die
Orchestrierung bereits vorgibt – der Client ruft nicht die Services des Servers in einem Workflow von sich aus auf, sondern der Server steuert bereits den Ablauf. Und meist gibt die Fachabteilung die Orchestrierung bereits fix vor, der IT bleibt nur die (oft stupide) Implementierung.
SOA halte ich für dann angebracht, wenn ganz neue Projekte angegangen werden, oder wenn eine bisher versteckte Funktionalität einen deutlichen Mehrwert bei der Entwicklung anderer Software einspielt. Dann kann man über definierte Schnittstellen wie z.B. SOAP einen Service mit einem anderen “sprechen” lassen und so wertvolle Doppelentwicklung sparen. Aber im Grunde ginge das auch oft ohne SOA…
Und wer weiß, wann nicht schon wieder der nächste Trend wartet?