Meiner Erfahrung nach funktionieren traditionel geführte Interviews nicht, denn sie beachten nicht die Begabung der Entwickler, in hochkollaborativen und dynamischen Umgebungen zu arbeiten. Résumés und ein standardisiertes Interview decken das nicht ab.

Personalentscheider müssen sich nun die Frage stellen, welche Methode die richtige ist, um herauszufinden, ob der Kandidat das Zeug für ein agiles Team hat.

Eine Variante ist ein praxiorienterter Workshop in dem mehrere Kandidaten in Zweierteams eine Herausforderung bewältigen müssen und dabei beobachtet werden, wie sie kommunizieren, kollaborieren, diskutieren und Probleme bewältigen. Die eigentliche Lösung des Problems steht nicht im Mittelpunkt. Durch die Beobachtung der Kandidaten in der Praxis können qualifizierte Entscheidungen getroffen werden. Anders als im Interview.

Während es sicherlich massive Vorteile gibt, müssen wir uns allerdings auch vor Augen führen, dass der geschilderte Prozess relativ ressourcenintensiv ist. Termine für alle Beteiligten müssen vereinbart, Räumlichkeiten bereit gestellt, ein “Test” muss entworfen und während der Ausführung beobachtet werden. Mittlere bis große Unternehmen lösen die Probleme sicherlich leichter als kleinere, jedoch sind gerade Start-Ups und Shops mit 15 bis 50 Entwicklern besonders von effektiven Recruiting-Techniken abhängig.

Ein ähnlicher Ansatz ist eine interessante Mischung aus einem klassischen Interview und einem sehr individuellen Prozess. Im Gegensatz zur ersten Variante wird das bereits existierende Team (vorausgesetzt es gibt bereits eines) intergriert und läßt sich in fünf Abschnitte gliedern:

1. Vorauswahl: Teil 1 — Es werden künstlich Barrieren für potentielle Kandidaten aufgebaut, so dass nur ernsthaft interessierte Bewerber eingeladen werden. Das kann beispielsweise dadurch erreicht werden, dass bereits in der Stellenausschreibung ein paar Fragen gestellt werden, die in einem kurzen Essay zu beantworten sind. Nachteil ist, dass einige wirklich gute Leute durch die Lappen gehen, weil sie in der Regel wissen, dass sie es nicht nötig haben, mehr zu machen als notwendig.
2. Vorauswahl: Teil 2 — Noch vor dem ersten Interview werden die Essays ausgewertet. Das wird vom Team gemacht, welches die neuen später aufnehmen wird. In einem gemeinsamen Meeting wird über die Qualität entschieden. Gibt es eine Ablehnung, ist der Kandidat ausgeschieden und wird nicht eingeladen. Nachteil: wenn es ungünstig läuft bleibt vielleicht kein geeigneter Bewerber übrig.
3. Das Interview: Teil 1 — Das Team wird den Morgen mit den BewerberInnen verbringen (ich empfehle nicht mehr als Mitglieder als Kandidaten) und sie beispielsweise beim Frühstück in der Kantine und anschliessendem Rundgang im Unternehmen besser kennen lernen. Auf diese Weise können sich alle (auch der Kandidat) einen Eindruck über die Persönlichkeit verschaffen. Nachteil: relativ zeitaufwendig.
4. Das Interview: Teil 2 — Jedem Bewerber wird ein Teammitglied zur Seite gestellt um die tatsächlichen Fähigkeiten des Kandidaten geprüft und ggf. Schwächen und Stärken, welche im ersten Teil untergegangen sind, aufgedeckt werden. Am nächsten Tag wird das Team die Egebnisse auswerten.
5. Das Angebot — Wurden geeignete Kandidaten identifiziert, kann das Angebot durch Personalentscheider unterbreitet werden.

Meiner Meinung nach liefert die zweite Methode bessere Ergebnisse, als die erste, allerdings ist der organisatorische Aufwand ebenfalls nicht zu unterschätzen.

Die letzte Methode, die ich vorstellen möchte kombiniert ebenfalls bewährte Methoden traditioneller Entscheidungsfindung mit einigen Elementen, spezifisch für Agile Umgebungen.

In einem dreiteiligen Interview werden mit jeweils zwei Teammitgliedern (in allen drei Teilen die gleichen) zunächst technische, anschließend prozessorientierte und am Schluss persönliche Aspekte beleuchtet. Der technische Teil des Interviews befasst sich mit harten Fakten, technischen Kenntnissen und Erfahrungen des Bewerbers. Im prozessorientierten Teil wird über Philosophien verschiedener Testmethoden, Qualitätsaspekte, Problemlösungsansätze und Agile Techniken, wie etwa Pair Programming diskutiert. Der Letzte Teil untersucht Aspekte aus den Bereichen Konfliktlösung, Motivationen und mentale Stabilität.

Zusätzlich kann der Vorgang von einem einfachen Fragenkatalog unterstützt werden:

1. Erzählen Sie mir über eine Erfahrung in der Sie sich einer intensiven Meinungsverschiedenheit ausgesetzt sahen.
2. Wie sind Sie mit Entscheidungen des Teams umgegangen, welche nicht in Ihrem Sinne waren?
3. Wie gehen Sie mit Situationen um, in denen Sie Informationen benötigten um eine Arbeit fertig zu stellen, sie aber nicht erhalten haben?
4. In welcher Situation haben Sie es geschafft, den Kurs eines Teams zu korrigieren, von dem Sie sicher waren, dass er falsch ist?

Unabhängig von den angewandten Methoden des Recruiting-Prozesses müssen sich Unternehmen folgendes vor Augen führen:

Jene, die Talente und nicht Fähigkeiten anheuern, eine Umgebung schaffen in der Fähigkeiten erlernt und bestärkt werden, legen den Grundstein für eine dauerhaft fruchtbare Kultur hoher Innovationskraft. In den meisten Fällen wird auf eine exakte Übereinstimmung mit dem Anforderungsprofil geachtet. Bewerbern kann ich nur raten, von diesen Unternehmen Abstand zu nehmen, denn eines ist klar: sie sind nicht willens in Dich zu investieren.

• Business System Development — Als technischer Wissensträger für das Lean Management ist das KPO verantwortlich für die Entwicklung eines Business Systems im allgemeinen, bzw. eines Produktionssystems im speziellen (denken wir beispielsweise an TPS). Darüber hinaus müssen ein Curriculum und die entsprechende Bildungseinheiten um das System entwickelt werden.
• Change Management — Das KPO betreut sämtliche Veränderungen als Berater, Trainer, Betreuer und Katalysator. Es nimmt nicht die Rolle des Initiators an. Es kann lediglich Empfehlungen aussprechen.
• Personalentwicklung — Typischerweise wird ein Unternehmen kurze Zeit nach der Transformation von einem Kaizen-Sensei begleitet, bis es auf eigenen Beinen stehen kann. Das gelingt nur, wenn Kaizen von der gesamten Belegschaft eines Unternehmens verinnerlicht wird. Das KPO beteiligt sich aktiv an der Aus- und Weiterbildung des Personals, sowohl im technischen als auch im organisatorischen Bereich.
• Daily Kaizen etablieren — Der Übergang zum täglichen Kaizen steht dem systematischen Ansatz des Kaizen-Events gegenüber. Ersterer ist eine Frage der Tiefe der Durchsetzung von Kaizen, letzterer ein organisierter Systemansatz des Lean Managements. Beides zusammen ist das ultimative Ziel und verspricht den größten Nutzen der Transformation. Das KPO ist also beim Training der Belegschaft (wichtig hier: Train-the-Trainer) und der Entwicklung von Problemlösungsqualitäten die treibende Kraft. Es ist die einzige Instanz einer Organisation, welche eine echte Kaizen-Kultur auf jeder Ebene schaffen und erhalten kann.
• Kaizen-Events organisieren — Die Organisation von Kaizen-Events ist ganz klar die Domäne des KPO. Als technischer Wissensträger kann nur das KPO die richtigen Themen (Focus Areas), Vorbereitungen und die Nachbearbeitung vollständig organisieren. Das KPO ist hier ganz klar in einer aktiven Rolle.
• Office Management — Das Office im Sinne des Kaizen ist der virtuelle und physische Wirkungskreis des Kaizen Promotion Office. Es dreht sich alles um Informationsaufbereitung und -austausch, Planung von Weiterbildungsmaßnahmen und die Aufrechterhaltung der kontinuierlichen Verbesserungsmaßnahmen durch die jeweiligen Verantwortlichen.

Was braucht’s für einen Kaizen Promotion Office?

Die oben genannten 6 Aufgaben und Ziele des KPO erfordern in weiten Teilen ganz spezifische Fachkenntnisse und Fähigkeiten. Diese unterscheiden sich selbstverständlich sehr stark von der jeweiligen Position, die ein Protagonist innerhalb des KPO einnimmt. Beispielsweise hat ein KP Officer auf Unternehmensebene (meist ein Mitglied der Geschäftsleitung oder Bereichsleitung) einen anderen Focus als der einer Business Unit.

Dennoch lässt sich ein recht gutes Bild von den allgemeinen Kompetenzen solcher Funktionsträger zeichnen. Dazu zählen:

• Fähigkeit zur strategischen Planung und Ausrichtung
• Führungsstärke im Change Management
• Ausgeprägtes Zeit- und Selbstmanagement
• Führungsstärke im Team und die Fähigkeit das Team richtig zu positionieren (im Sinne von Konsensbildung)
• Verantwortung für getroffene Maßnahmen
• Flexibilität
• Das Gespür für Talente und deren Förderung
• Hohe soziale Kompetenz und Kommunikationsstärke

Ganz ohne Zweifel sind einige der genannten Soft-Skills nur sehr schwer zu erlernen (manche haben sie einfach) jedoch können Menschen mit Hilfe intensiven und gezielten Coachings (und nicht zuletzt durch die gesammelte Erfahrung) auf diesen Gebieten große Fortschritte erzielen.

Nun, was die technischen Kenntnisse angeht, quasi all das “was” zu tun ist, so sind es primär die drei Bereiche Lean Principles, Systeme und Werkzeuge (Techniken). Erfahrung ist der beste Lehrer, noch besser ist die Instruktion durch einen erfahrenen Sensei, doch irgendwo muss der Anfang gemacht werden. So bleibt oft nicht anderes übrig, als sich dem Studium des Lean Managements zu widmen.

Es mangelt ganz und gar nicht an Zertifizierungsprogrammen, allerdings wird in den meisten Fällen ein rigoroses Programm abgespult, das einen hohen Zeitaufwand und entsprechende Hingabe abverlangt. Insgesamt sollten auf jeden Fall eine natürliche Neugierde und das Verlangen nach intellektueller Erkenntnis (beides darf ruhig leicht obsessive Züge annehmen) vorhanden sein. Letztendlich bewegen wir uns alle im Kreislauf studieren, anwenden, lernen und leeren. Wissen ist zum Teilen da!

Aufbauend auf den 7 Todsünden der Verschwendung (YouTube) brachen Produktionsleiter mit Kaizen im Rucksack auf zur Suche nach Muda und Eliminierung derselben. Wurde das richtig und gut gemacht, konnten signifikante Verbesserungen in kurzer Zeit beobachtet werden, welche heute noch anhalten.

Heutzutage wird es immer wichtiger die Verwaltungen solcher Produktionsbetriebe ebenfalls einer solchen Aktivität zu unterziehen.

Warum ist das so? Weil Kunden bessere Produkte und Dienstleistungen zu geringeren Preisen möchten, das ganze natürlich auch schneller als üblich. Aus Kundensicht beginnt die Uhr mit dem Absenden der Bestellung an zu ticken und hört erst auf, wenn das Produkt geliefert oder die Dienstleistung erbracht wurde. Somit lohnt sich ganz gewiss ein Blick über den Horizont des Produktionsalltags hinaus.

Muda im Office

In der Produktion ist Lean Management ein alter Hut und bereits sehr gut etabliert. In der Verwaltung und Administration von Organisationen ist das noch nicht der Fall. Ein Grund ist sicher, dass dieser Bereich noch nicht so viel Aufmerksamkeit erhielt wie der Produktionsbereich, nicht zuletzt weil hier die größten Potentiale lagen.

Auf Produktionsseite verarbeiten wie Material und Teilerzeugnisse zu neuen Produkten. Der Fluß ist klar umrissen, wir können mit dem einzelnen Bauteil förmlich durch die Produktionsstufen wandern. Im Büro, mit all den unterschiedlichsten Tätigkeiten, Informationen und Interaktionen ist der Arbeitsfluß ganz und gar nicht so einfach zu durchschauen. Möchten wir unser Büro also von Muda befreien müssen wir einen anderen Blick auf die Prozesses werfen. Diesen Blick kann man sich aneignen. Wie das geht beschreibe ich diesen Blog Post.

Was ist Muda?

Im weitesten Sinne, kann Muda in jeder Operation oder Aktivität gefunden werden, die dem Endprodukt oder der Dienstleistung Mehrkosten auferlegt, ohne erkennbaren Mehrwert für den Kunden zu erzeugen. Betrachten wir administrative Aufgaben und Prozesse, so könnten folgende Aktivitäten potentielle Kandidaten sein:

• die Bewegung und Sortierung von Unterlagen
• Ablage von Unterlagen
• Wiederkehrende Tätigkeiten gleicher Art
• Wiederholung aufgrund von Fehlern
• Warten auf Freigaben von Dokumenten oder Tätigkeiten
• Unnötige Überprüfung getaner Arbeit
• Ineffiziente Workflows
• Veraltete und inadequate Software

Ein strategischer Ansatz zur Beseitigung von Quellen der Verschwendung würde, ebenso wie im Produktionsbereich, zu folgenden positiven Auswirkungen führen:

• Reduzierung der Verarbeitungszeiten, schnelle Antwortzeiten auf Kundenanfragen
• Eliminierung aller unnützen Aktivitäten
• Einfache, logische und schnell zu erlernende Arbeitsprozesse
• Reduzierung von Fehlern und damit verbundener Mehrarbeit
• Ständige Verbesserung durch das Team
• Geringere Kosten
• Hohe Moral und Leistungsfähigkeit des Teams

Wo fangen wir an?

Ein guter Ausgangspunkt sind immer Kernprozesse. Typischerweise gibt es in einem Unternehmen nicht so viele. Beispiele für Kernprozesse könnten die Auftragsbearbeitung oder die Produktentwicklung sein. Diese Prozesse untersuchen wir auf die Erfüllung Deiner subjektiven Erwartungshaltung hinsichtlich Qualität, Kosten und Zeitaufwand.

Zur Unterstützung sollten stets abstrahierte Flußdiagramme zur Hilfe genommen (Du hast doch welche, oder?) und die jeweilgen Prozess Owner (auch die existieren in Deiner Firma, nicht wahr?) hinzugezogen werden. Mit Hilfe der Diagramme besteht für alle beteiligten ein gemeinsames Verständnis für den aktuellen Prozessablauf und welche funktionalen Bereiche verantwortlich für welche Teilprozesse sind.

Anschließend müssen wir nur noch ein messbares Ziel und einen Zeitplan für die Prozessoptimiertung definieren. So etwas könnte beispielsweise lauten: “Beantwortung von 95% aller Kunden anfragen innerhalb von 12 Studen bis zum Ende des zweiten Quartals”.

Techniken und Werkzeuge

Als Kenner des Kaizen möchte ich daher besonderes Augenmerk auf folgende Werkzeuge zur Identifikation von Muda legen:

1. Analyse der Wertschöpfungskette
2. Prozessmodellierung
3. Pareto-Analyse und Fischgretendiagramme
4. Theory of Constraints (von SixSigma)

Zu den empfehlenswerten Techniken zur Beseitigung von Muda gehören:

5. Value Stream Mapping
6. One Piece Flow Processing
7. Prozesse mit minimalen Fehlerquellen (Poka Yoke)
8. Das sog. Cellular Processing

Diese acht Schritte sind der Schlüssel zum Lean Office.

Extrem wichtig ist bei der Implementierung der ausgewählten Strategie, das Du stets den gesunden Menschenverstand anwendest und nicht gegen ihn arbeitest.

Fazit

Das war ein kurzer Exkurs in das Lean Office, welches immer wichtiger wird um den Kreislauf der Optimierungsbemühungen, welche in der Produktion begannen, zu schließen.

Zusätzlich ist es enorm empfehlenswert, zusätzliche Anstrengungen im Bereich der Führungsqualität, der Selbstbestimmung und der Stärkung von Partnerschaften mit Lieferanten zu unternehmen, da hier ganz enorme Verbesserungspotentiale verborgen liegen.

Ausführlicher möchte ich an dieser Stelle ausdrücklich nicht werden, da sich ganze Bücher mit diesem Thema befassen und neben dem Kaizen-Aspekt insbesondere soziale und politische Betrachtungen eine wichtige Rolle spielen.

Momentan ist SOA, die Service-orientierte Architektur, das große Ding. Nach Jahren der Definitionsfindung scheint endlich der Zeitpunkt gekommen, eine SOA implementieren zu können. Und der Zeitpunkt könne nicht besser sein. Unternehmen suchen bereits seit geraumer Zeit nach Möglichkeiten zur Optimierung ihrer Geschäftsprozesse im Hinblick auf die Integration mit IT-Dienstleistungen und -Architekturen. Die wichtigsten Ziele sind hier natürlich Senkung der Kosten und Erhöhung der Flexibilität.

Da SOA auf offenen Standards und Technologien basiert, hilft SOA effektiv, die IT reaktionsfähiger zu machen, indem echte Geschäftsanforderungen und funktionale Aspekte, wie Wiederverwendbarkeit von Code, Vereinfachung der Verwaltung und Entwicklung, sowie Agilität direkt miteinander verknüpft werden.

Warum brauchen Unternehmen SOA?

Ein großes Unternehmen, evtl. mit Niederlassungen und Partnern im Ausland, hat 20 verschiedene Anwendungen, die alle irgendwelche Steuerberechnungsfunktionen benötigen. Dazu kommt, daß jede Applikation den Code dafür im Bauch hat, jedesmal unterschiedlich realisiert, troztdem bringen sie die gleichen Ergebnisse.

Diese Art der Softwareverteilung läßt sich in vielen Bereichen beobachten. So verwenden viele Firmen innerhalb des Unternehmens unterschiedliche Buchhaltungsprogramme und ERP-Systeme. Nachdem viele Jahre in die Dezentralisierung, aber nur selten in eine gute, ausbaufähige, zukunftssichere IT-Architektur investiert wurde, erkennen Unternehmen nun, daß sie ihren Ansatz neu modellieren müssen, bevor neue Projekte realisiert werden können, die in eine SOA passen.

Neben technischen existieren eine ganze Reihe von disziplinarischen Herausforderungen, denn eine neue Organisationsstruktur muß etabliert werden, um die Innovationen in der Informationstechnologie voll ausschöpfen und in ein Geschäftsmodell integrieren zu können. Besonders in Umfeldern, deren Richtungen und Schwerpunkte sich häufig verändern, ist die Einführung auf Diensten ausgerichteten Architektur sehr attraktiv.

Die beschriebenen Probleme und Herausforderungen haben einiges gemeinsam:

• Es geht um die Integration heterogener IT-Systeme.
• Die Anforderungen an die Prozessintegration steigen rapide.
• Der nahtlose Informationsfluß wird immer wichtiger.

Mitarbeiter, Partner, Prozesse, Channels und Anwendungen miteinander zu verbinden um einen integrierte und konsistenten Zugang zu Geschäftsfeldern zu eröffnen und dazu noch die Kosten zu senken ist das Ziel eines jeden Unternehmens. Zur Erreichung ihrer Ziele, etablieren sie die Grundlagen einer SOA, indem sie:

1. Aufbau einer mehrfach nutzbaren (shared) IT-Infrastruktur zur Eliminierung redundater Dienste.
2. Einführung mehrfach nutzbarer unternehmensweiter Plattformen als Fundament für Interoperabilität und verteilte Applikationen.
3. Entwicklung autonomer, wiederverwendbarer Dienste, um beispielsweise Bereitstellungskosten für Kunden, Mitarbeiter und Partner zu senken.

Eine SOA bietet seinen Nutzern einen Satz definierter Dienste, die sie nutzen und in Geschäftsprozesse integrieren können, ganz wie sie sie benötigen. Sie entwickeln Systeme, die sich den geschäftlichen Veränderungen anpassen können.

Das beste an einer SOA ist, daß die Idee dahinter nicht neu oder gar radikal ist. Die schlummerte bereits seit langer Zeit in IT-Umgebungen, jedoch meist als propreitäre, untereinander inkompatible Variationen. Mit der Schaffung von Schlüsselstandards, insbesondere im Bereich der Web Services, wird die Einführung einer allgemein gültigen Service-Orientierten Architektur leichter als je zuvor, denn nun können Systeme und Komponenten miteinander kommunizieren, ohne sich zu kennen oder gar von der Existenz des anderen zu wissen. Dieser standardisierte Ansatz zur Service-Architektur hat das Potenzial, bestehende technische und geschäftliche Probleme zu lösen.

Letztendlich soll SOA die Führungsebene der Business- und IT-Abteilungen von eine unflexiblen, inkompatiblen und oft teuren, Ansammlung von IT-Systemen befreien, die viele Unternehmen im Laufe der Zeit angeschafft haben. Die Probleme und Kosten, solche Legacy-Systeme miteinander zu verbinden und dazu noch so zu verändern, daß sie mit aktuellen Veränderungen Schritt halten können, überfordert die meisten Budgets und verhindert Innovationen.

Das Ziel ist ein Abbau der Interoperabilitätsprobleme, indem monolithische und statische Systeme durch modulare und flexible Komponenten ersetzt werden, so daß sich die IT auf die Unterstützung des operativen Geschäfts konzentrieren kann, anstatt Geld und Zeit dafür afzubringen, die antiquierten System und Strukturen immer wieder nachzuziehen.

Im weiteren Verlauf des Artikels sind folgende Definitionen hilfreich:

Service (Dienst)

Ein eigenständiger, wiederholbarer Geschäftsablauf, wie beispielsweise die Berechnung von Steuern, Prüfung der Kreditwürdigkeit eine Kunden, oder die Eröffnung eines Kontos

Service-Orientierung

Integration eines Geschäftsprozesses in eine Kette wiederverwendbarer Dienste. Die Ausgabe, quasi das Ergebnis, dieser Kette ist Teil der Service-Orientierung

Service-orientierte Architektur

Eine IT-Architektur, die eine Service-Orientierung ermöglicht und z.T. implementiert.

Composite Applications

Integrierte Dienste zu Abwicklung von Geschäftsprozessen über unterschiedliche Anwendungen hinweg, die jeweils auf SOA-Prinzipien basieren.

Folgende Abbildung illustriert den Übergang von einer Säulenarchitektur hin zu einem Service-orientierten Modell:

In diesem Kontext werden Applikationen als Dienste betrachet und auch so verwaltet. Zusammen mit Web Services und anderen Anbindungen, ergibt diese Anwendungen Verbindungen, die den Bedürfnissen von Geschäftsprozessen entsprechen. Das Ziel ist die Eliminierung von Rundanzen, sowohl was die intern entwickelten Lösungen als auch die von Drittanbietern bezogenen betrifft, und die Bereitstellung von allgemeingültigen Geschäftsaufgaben (wie biespielsweise Steuerberechnungen). Das Ergebnis ist eine einfachere IT-Umgebung bestehend aus wiederverwendbaren Komponenten, die logisch miteinander verbunden werden können, um einen bestimmten Geschäftsprozess zu implementieren. Ein wichtiger Vorteil ist die Fähigkeit, schneller auf Markbewegungen reagieren und Probleme mit geringerem finanziellen Aufwand bewältigen zu können.

In einer Service-orientierten Struktur sind Applikationen und Geschäftsprozesse Teil einer Ansammlung von standardbasierten Komponenten (oder “Diensten”). Jeder von ihnen verrichtet eine diskrete Funktion. Die eigenständigen Prozesse sind locker gekoppelt (engl. loosely coupled) und so entworfen, daß sie beispielsweise ereignis- oder nachrichtenbezogen funktionieren und nicht mehr über festgeschriebene Funktionen betrieben werden. Die Dienste selbst sind können natürlich neu geschaffen werden oder durch Wrapper in existierende Geschäftsabläufe integriert werden, so daß ihre Funktionen mittels standardisierter Schnitttellen zugänglich gemacht werden.

SOA baut auf den Prinzipien modularer Entwicklung, wie wir es von modernen Fertigungen kennen. Denken sie dabei an die Autoindustrie. Hier wird ein Auto aus einem modularen Satz von Komponenten zusammengesetzt. Das gleiche gilt für die Computerindustrie. Wird ein Produkt (oder auch ein Geschäftsprozess modularisiert), sind Teile des Designkerns eigenständig und können beliebig neu integriert werden, solange eine formale Architektur oder ein formaler Plan berücksichtigt wird.

Aus Sicht eines Ingenieurs hat die Modularisierung eines Designs drei Ziele:

• Gewadmet für zukünftige Veränderungen zu sein
• Die Integration komplexer Systeme verwaltbar zu machen
• Parallele Evolution, Innovation und Verarbeitung zu ermöglichen

Modularisierung führt aber auch zu gewissen Unsicherheiten, denn Elemente der Architektur können sich ändern, um unvorhergesehenen Anforderungsänderungen gerecht zu werden. Dabei dürfen die Richtlinien der Architektur nicht außer Acht gelassen werden. So kann aber sichergestellt werden, daß eine alte Komponente gegen eine neue ohne großen Aufwand ausgetauscht werden kann.

Etablierung, Einführung und Verwaltung einer SOA

Wie wir aus den vorangegangenen Ausführungen erkennen können, bedarf die Einführung einer SOA mehr als zu Technologie. Sie bedarf einer systematischen Planung und ein starkes Management. Einfach nur Komponenten auf Web Services umzustellen ergibt noch lange keine SOA, obwohl sie ein wichtigen Teil der Implementierung darstellen. Ebenso ist SOA nur der Anfang, unterliegt ständigen Anpassungen und benötigt viel Zeit um erfolgreich eingeführt und in die existieren Unternehmensphilosophie zu werden. Desweiteren werden Tools und Prozesse und, sehr viel wichtiger, oranisatorische Umformungen der Geschäftsabteilungen und der IT benötigt. Für die meisten Unternehmen ist eine Stufenausbau die beste Lösung, da sie schnell Fortschritte messen können und gegebenenfalls früh auf Probleme bei der Implementierung reagieren können.

Einige Hersteller von SOA-Produkten verfolgen eine Strategie, die als “Rip and Replace” (dt. “rausreissen und ersetzen”) bezeichnet wird. Teil der Strategie ist die Identifizierung potentieller Vorteile einer SOA und die anschließende Implementierung einer Gesamtlösung. Damit würden Kunden durch eine schnelle Konsolidierung ihrer Dienste innerhalb des Unternehmens früh die Vorzüge einer SOA kennenlernen und davon profitieren.

Ein gewisser Grad and Konsolidierung spart sicherlich Kosten, jedoch sollte die Integration von Systemen, die Ausarbeitung neuer Dienste und die Errichtung von Composite-Applikationen nicht in einem Schritt vorgenommen werden. Eine so weitreichende Umstrukturieren des Unternehmens ist mit relativ hohem technischen und politischem Risiko verbunden.

Wenn es um die Einführung einer SOA geht, so sollte nicht alles auf einmal gemacht werden. Das wäre so, als würde man in seinem Haus saämtliche Rohre und Leitungen austauschen und während dessen weiter darin leben wollen. Das Leben würde sehr schnell ziemlich kompliziert werden und Küche, Bad und WC könnten nicht richtig verwendet werden solange nicht alles fertig ist. Keine wünschenswerte Situation.

Ein schrittweiser Ansatz ist viel leichter verwaltbar und führt zu kleinen aber unmittelbar spührbaren Ergebnissen. Ein Unternehmen SOA-fähig zu machen ist ein Langzeitvorhaben und wird von den Geschäftsanforderungen angetrieben, nicht von architektonischen Aspekten.

Eine mehrschichtige Herangehensweise vereinfacht den Wechsel, denn Unternehmen können inkrementelle Veränderungen beim Ausbau zu einer ganzheitlichen Lösung vornehmen. Geschäftsmetriken bestimmen letztendlich die Geschwindigkeit des Umstellungsprozesses. Dabei können die Metriken helfe, Bereiche zu identifizieren, die mehr Aufmerksamkeit benötigen und solche die vielleicht unverhältnismäßig stark berücksichigt werden. Gleichzeitig minimiert sich das Risiko und erhöht sich das ROI.

In der Regel basiert eine mehrstufige SOA-Einführung aus mehreren, aber nicht mehr als drei, Phasen.

Phase 1: Analyse

Es gilt zunächst jene Geschäftsbereiche zu identifizieren, die am nötigsten angepaßt werden müssen, aber gleichzeitig den größen Nutzen für das Unternehmen bergen. Dabei wird festgestellt, welche Anwendungen nicht richtig funktionieren und welche Geschäftsfelder es wert sind in sie zu investieren. Sobald die Erkenntnisse gewonnen und priorisiert wurden, können Modelle erstellt werden, ganz ähnlich wie bei der Renovierung eines Hauses. Ein wichtiger Punkt für das Design des Modells ist die Frage, wie viel eines bestimmten Bereichs umgebaut werden soll. Wir können ein Projekt umstellen, eine paar Abteilungen oder das gesamte Unternehmen.

Die auszuarbeitenden Pläne müssen berücksichtigen, daß der umzuformende Teil und andere periphäre Teile des Unternehmens während der Remodellierungsphase weiter arbeiten müssen. Für Führungskräfte bedeutet das, sie müssen Regeln, Auflagen, Managementpläne und andere Bestimmungen, so daß die beteiligten Personen, Abteilungen und Prozesse entsprechend geführt und koordiniert werden können. Desweiteren reduzieren sie das Risiko, die Kosten und den Aufwand kanz erheblich, denn selbst wenn ein Teilproblem auftritt, wird nicht der gesamte Prozess aufgehalten.

Phase 2: Rationalisierung

In der nächsten und längsten Phase werden die existierenden Strukturen überprüft und überarbeitet um sie auf die SOA-Umstellung vorzubereiten. Alle Änderungen, die an bestehenden Systemen gemacht werden müssen, sind in dieser Phase vorzunehmen. Dienste und Software werden entwickelt, implementiert und getestet. Anschließend wird ein Sicherheitskonzept auf die Komponenten übertragen. Gleichermaßen müssen die beteiligten Personen, Prozesse und Abteilungen in das Sicherheitskonzept einbezogen werden.

Phase 3: Transformation

Die letzte Phase besteht aus der Verwaltung und Wartung unseres neuen Gebäudes. Es wird nun kontinuierlich durch ein effektives System gestützt und verwaltet. Hochqualifizierte Mitarbeiter und detailliert ausgearbeitete Prozesse erlauben ständige Anpassungen der Geschäftsmodelle innerhalb der SOA. Der Erfolg einer SOA-Implementierung ist gekennzeichnet von der Fähigkeit, Geschäftsprozesse einfach zu implementieren, aber dennoch maximale Wirkung im Hinblick auf Agilität, Leistungsfähigkeit und Risikominimierung zu entfalten.

Ein solches Leitungs- und Entwicklungsmodell liefert die besten Ergebnisse mit den geringsten Beeinträchtigungen für das operative Geschäft.

Während des 3-Phasenprozesses ist es sehr hilfreich, Methoden zu entwickeln, die den Fortschritt über alle Abteilungen und Organisationsstrukturen des Unternehmens hinweg visualisieren. Ein Anwendungsbereich kann sich recht früh in der SOA-Landschaft positionieren, seine volle Wirkung kann er jedoch erst entfalten, wenn mehrere Domänen von diesem Gebrauch machen. Erinnern wir uns an das Beispiel mit der Berechnung von Steuern. Zuvor gab es eine Reihe von Modulen, die alle das gleiche getan haben, jetzt können alle das gleiche Modul (nach SOA-Manier als “Dienst” bezeichnet) nutzen, was eine deutliche Reduzierung des Verwaltungsaufwands bedeutet und gleiche Ergebnisse in allen Anwendungsdomänen liefert.

Eine SOA zu errichten, erfordert ein Verständnis der Verbindungen zwischen den Schlüsseldimensionen der Unternehmensstrategie, der Prozesse, der Anwendungen und der Infrastruktur. Um dieses Verständnis zu erlangen, müssen Organisationen innerhalb des Unternehmens weitreichende Einblicke in die Strukturen erhalten, was bedeutet, daß Unternehmen mit geringer Transparenz wenig Chancen haben, eine SOA erfolgreich zu etablieren. Nur so ist die Akzeptanz der eingeschlagenen Strategie zu vermitteln und die Kooperation der Belegschaft zu gewinnen.

Für SOA planen

Die Evolution in eine SOA müssen Unternehmen vorrausschauend planen. Das ist typisch für jede Revision einer größeren Architektur oder eines Projekts. Die folgenden Punkte sollen helfen, die richtigen Entscheidungen bei der Planung für eine SOA zu treffen. Anschließend betrachten wir eine Roadmap zur Ausrollung der Architektur.

Das wichtigste Element bei der Einführung einer SOA ist die Führung. Es liegt in der Verantwortung eines Teams oder einer Führungspersönlichkeit folgende Aufgaben zu bewältigen:

• Auswahl geeigneter Technologien für die Architektur
• Auswahl der Projekte und Prozesse, die unbedingt angegangen und welche nicht angerührt werden sollen
• Entwicklung einer geeigneten Ausbaustrategie
• Messung des Fortschrittes und der Vorteile gegenüber des herkömmlichen Modells

Für eine höchsteffiziente Transformation, empfehle ich folgende Schritte:

Setze Führungsstrukturen ein

Stelle ein Team von Experten zusammen, die abteilungsübergreifende Einführung und Akzeptanz der SOA sicherstellen. Analysiere die Herausforderungen, die eine Entwicklung SOA von der Konzeptionierung bis zu Einführung an Prozesse, Standards und Vorgaben stellen.

Erstelle eine Roadmap

Setze Dich mit den fundamentalen Grundlagen zur Ausarbeitung einer SOA-Strategie auseinander und beginne mit der Ist-Aufnahme der Geschäftsprozesse und erstelle ein Soll-Konzept. Stelle sicher, daß alle Prozesse in allen relevanten organisatorischen Einheiten sichtbar sind. Stichwort: Transparenz.

Versichere Dich der richtigen Ausrichtung der Prozesse, Applikationen und Infrastruktur

Das Ziel ist, die vorhandenen Mittel wie Systeme, Komponenten und Strukturen optimal auszunutzen und sie in neue Strukturen zu integrieren um Kosten zu sparen.

Erstelle einen Businessfall und implementiere ihn in mehreren Phasen

Übersetze die Roadmap die gewonnen Erkenntnisse einen echten ausführbaren Businessfall. Bestimme die Vorteile, welche Du durch Wiederverwendbarkeit von Code, Komponenten, Strukturen und Systemen erreichen kannst. Berücksichtige auch die Vorteile erhöhter Agilität und Transparenz des Unternehmens.

Erstelle eine Kompatibilitäts-Framework für die Integration

Entwickle Guidelines um echte Interoperabilität im gesamten Unternehmen zu gewährleisten.

Sichere die Umgebung

Unternimm praktische Maßnahmen zur Sicherung der Umgebung. Versuche den Zugriff auf Web Services über Identitäten zu regulieren.

Faktoren für die erfolgreiche Einführung einer SOA

Vergessen wir nicht: SOA ist keine Technologie oder ein Produkt. Man sie nicht kaufen oder als Service abonnieren. SOA ist ein architektonisches Konzept, welches sich unabhängig von der Technologie ausprägt. Um eine Unternehmensarchitektur in eine SOA umzuwandeln ist eine systematisch erarbeitete Roadmap unerläßlich.

Stelle das richtige Team zusammen. Wähle die richtigen Leute aus. Unter ihnen sollten Architekten aus allen organisatorischen Einheiten sein. Wähle einen von Ihnen als SOA-Architekt aus, der die richtigen SOA-Standards und -Technologien versteht. Stelle fest, was Du nicht weiß und gehen Kooperationen mit kompetenten Partnern ein, die zum Erfolg beitragen können. Schließlich, komnunizerien, komnunizerien, komnunizerien! Veröffentliche Deine Resultat in regelmäßigen Abständen beispielsweise einmal im Monat und spare nicht mit Grafiken. Sie sagen oft mehr als Worte, besonders in weniger technischen Abteilungen.

Organisiere Erfolg durch Etablierung eines Centers of Excellence in Form einer Expertengruppe. Zentralisiere das Projektmanagement, die Planung, Release-Management und Infrastrukturdienstleistungen. Erdenke Dir ein Auslieferungsmodell, standardisiere es und mach es zum Teil der Gesamtstrategie.

Nutze das vorhandene Wissen der Organisationen und Geschäftspartner. Versuche stets, breite Unterstützung durch die Führungsebene zu erhalten und etabliere Partnerschaften mit Herstellern, die bereits Erfahrung mit SOA und ihren Tools sammeln konnten. Finde ein ausgewogenes Gleichgewicht zwischen den Visionen der Führungsebene und Deinen Visionen, die auch den technischen Aspekt einbeziehen. Konzentriere dich auf kleine Erfolge, die das Management von dem Wert der Aufgabe für das Unternehmen überzeugen.

Bleib flexibel. Entwerfe Deine Strategie nicht zu abitioniert und nicht zu weit vorausschauend. Versuche, Deine Ziele überschaubar zu machen, um leichter auf Veränderungen reagieren zu können. Ein zu hochgegriffenes Ziel kann Dir den Blick für die Details nehmen. Halte die Infrastrukturdienstleistungen leicht und modular. Designkomponenten sollten abstrakt bleiben, um Wiederverwendbarkeit zu garantieren.

OK, wir wissen, das SOA noch immer das ist, was ein Unternehmen darin sieht: SOA steht und fällt mit der Bedeutung für ein Unternehmen. Und welche Rolle können hier nun die Hersteller von SOA-Produkten spielen? Ich habe keine Ahnung, aber ein paar Überlegungen angestellt, die ich im folgenden kurz darlegen möchte.

Reden, reden, reden!

Viele SOA-Hersteller sind so getrieben von den Marketing-Abteilungen und ihren großen Versprechen, daß sie ganz vergessen um was es bei der Einführung einer SOA bei einem Kunden geht. Es wäre wirklich toll, wenn alle Unternehmen gleiche Problembereiche identifizieren könnten, die auch noch in die gleiche SOA-Definition passen. Die Realität sieht aber nun einmal anders aus. Unternehmen sind nie gleich, keines ist mit einem anderen vergleichbar. Kaum vorstellbar, daß es eine Lösung für die Einführung einer SOA gibt.

Einer Lösung kämen wir aber näher, wenn die Hersteller den SOA-Protagonisten eines Unternehmens mehr zuhören würden. Das Resultat wäre ein verlässlicheres Werkzeug für die SOA-Einführung, wie maßgeschneidert. Allerdings stellt sich dann die Frage, wie so ein Produkt in Serie gehen kann. Ganz einfach: gar nicht! Eine SOA ist eine Angelegenheit, die jedes Unternehmen auf unterschiedliche Weise angeht. Es ist ein langfristiges Projekt mit unterschiedlichen Zielsetzungen, beispielsweise gibt es Unternehmen, die lediglich interne Prozesse betrachten, während andere besonderes Augenmerk auf die Interaktion mit externen Diensten und Dienstleistern legen.

Ich Tarzan, Du Jane!

Viele Hersteller verkaufen SOA-Produkte mit bestimmten Funktionen. Jedes Produkt macht eine bestimmte, meist genau definierte Sache. Von der Einzigartigkeit des Kunden aus betrachtet heißt das, existierende Strukturen und Architekturen an die Fähigkeiten des Produkts anzupassen, da es sonst keine Existenzberechtigung hätte.

Ein Beispiel: Anbieter A hat eine Lösung für die Datenintegration im Portfolio. Dieses Produkt betrachtet alle SOAs als Datenintegrationsprobleme, die es zu lösen gilt, kann aber, mangels Fähigkeiten, Faktoren wie Verhaltensweisen oder transaktionale Integration der Daten nicht berücksichtigen. Diese Konzepte passen einfach nicht in die Muster des Produkts.

Eins, zwei, drei, SOA!

Interessanterweise lassen sich auf dem “SOA-Markt” die gleichen Muster beobachten, wie sie bereits in anderen Bereichen stattfanden, und stets von einer Welle der Euphorie getragen wurden, die dann langsam abflachte um in etwas anderem wieder aufzugehen. Ich spreche von “magischer Technologie”. Sie kann existierende Geschäftsprozesse und -strukturen in SOA umwandeln. Auf Knopfdruck! Das ist natürlich Unsinn! Und in den meisten Fällen wird alles noch viel schlimmer, denn solche Programme machen die existierende Architektur noch viel komplexer als sie ohnehin schon ist.

Die Wahrheit ist, daß die Einführung einer Architektur (das “A” in SOA drückt das aus) in der IT einen systematischen Wandel in der Nutzung und Konfiguration von IT-Ressourcen bedeutet und in SOA die Abstraktion von atomaren Vorgängen (Prozessen) in Dienste meint, die anschließend in Solutions überführt werden können. Ein ESB oder ein Governance Tool macht das nicht, denn es kann vorsichtige, langfristige Planung und Ausführung nicht ersetzen. Hinzu kommt, daß die Auswahl der richtigen Technologie einen ganz wesentlichen Teil zum Erfolg eines SOA-Rollout beiträgt. Was diesen Prozess begleiten kann sind Best Practices und Tools für das Lifecycle Management. Eine Technolgie leistet das nicht allein.

Es gibt einen SOA-Markt…

…aber nicht für Massenprodukte. Ob SAP, Software AG, IBM, BEA, etc.. Sie alle verkaufen Produkte, die den meisten Unternehmen keinen Vorteil bringen, da sie naturgemäß nicht die Einzigartigkeit eines Unternehmens abbilden können. Demnach kann Software für die Unterstützung eines SOA-Rollout nur maßgeschneidert sein und muss in dem langen Prozess der Einführung immer wieder neuen Herausforderungen angepaßt werden.

Genau das leisten kleinere Start-Ups, die sich auf die Beratung bei der Einführung einer SOA spezialisiert haben. Sie passen Softwarelösungen an, stehen dem Unternehmen beratend über alle Phasen hinweg zur Seite und sind in der Lage schnell auf Veränderungen zu reagieren.

Einen Markt für SOA-Produkte im herkömmlichen Sinn gibt es noch nicht. Und wer jetzt an ESBs denkt, dem sei gesagt, daß es diese Produkte oft schon vor der Definition von SOA existierten und damals bereits einen Markt bedienten. SOA muß Ihre Niche noch finden.

Noch liegt .NET mit etwa 31% vorn, dicht gefolgt von Java mit 28%. Damit sind beide Technologien quasi gleichermaßen attraktiv für Unternehmen. Nicht zu vernachlässigen ist der Anteil jener Unternehmen, die beide Technologien unterstützen wollen. Dieser beläuft sich auf etwa 20% der Befragten.

John Andrews, CEO der Evans Data Corp, sieht für diese Entwicklung einen einfachen Grund:

Die Open Source-Welt ist in Bezug auf SOA momentan sehr aktiv, ganz besonders im Eclipse-Umfeld. Die meisten Unternehmen in diesem Bereich stellen neue SOA-Lösungen vor, die fast alle Java-basiert sind. Open Source SOA scheint dazu verdammt zu sein, eine wichtige Rolle auf dem SOA-Markt zu spielen und .NET echte Konkurrenz zu machen.

SOA hat inzwischen an Fahrt gewonnen und mittlerweile seien bereits drei viertel der Unternehmen, die selbst Web Services einsetzen oder implementieren, bereit, SOA-Ausrollungen zu planen oder in Kürze vorzunehmen. Mehr als ein Fünftel der befragten Unternehmen hätten sich bereits auf die Einführung von SOA unternehmensweit eingestellt.

Andere Fakten, die aus der Befragung von mehr als 400 Entwicklern hervorgegangen sind:

• Über 70 Prozent der Entwickler, die mit Web Services arbeiten, würden Kostensenkungen spühren. Die Wiederverwendung von Code und die Automatisierung von Prozessen seien die Hauptgründe für diese Entwicklung.
• Web Services zu testen und Validieren sei die größte Herausforderung für die Entwicklung einer SOA, doch sei die Bestimmung des ROI (Return of Investment) eine ebenso große Herausforderung.
• Business to Business (B2B) sei die häufigste Anwendungsform von Web Services, gefolgt von der Datenintegration.

Der halb-jährliche Report über die Entwicklung von Web Services wurde im Juni erstellt und am Montag veröffentlicht.

Brian F. Shimmin, Principal Analyst für Application Infrastructure bei Current Analyst LCC, versichert, daß der “Geek Factor” nicht verloren gehen wird, obwohl ein wenig mehr Weißhemd- und Krawattenträger anwesend sind als in den letzten 5 Jahren:

Noch immer ist der Geek Factor vorhanden. Doch gibt es diesmal nicht so viele abgehobene Themen, die nicht alle mit Enterprise Architektur zu tun haben, aber trotzdem interessant sind. Vielmehr geht es diesmal mehr um Enterprises, Sicherheit, Performance und Verfügbarkeit. Es gibt jede Menge wichtige Arbeit was die Entwicklungen im Java EE 5 und Spring-Umfeld angeht.

Neu in diesem Jahr ist der Java Technology Business Day, der heute stattfindet. Es ist ein Tagesprogramm für Geschäftsleute, die erfahren wollen, wie sie die Java Technologie richtig einsetzen und die Marke Java nutzen um Geld zu verdienen, sagt Jean Elliot, Senior Director für Java Software Product Marketing bei Sun Microsystems.

Gestern eröffnete die Show mit dem NetBeans Day mit einem technikorientierten Programm, an dem Sun und die NetBeans-Community eine Vorschau auf die neue Java IDE NetBeans 6.0 gegeben haben. Die neue IDE geht über eine Entwicklungsumgebung für die Java- und C/C++-Entwicklung hinaus und wird Ruby und JavaScript unterstützen. Die Unterstützung von Ruby bezieht sich auch auf den NetBeans GUI-Builder, der es Entwicklern nun auch erlaubt, Ruby on Rails mit vorhandenem Java-Code zu verknüpfen.

Gestern stellte auch ICEsoft Technologies seine Unterstützung für NetBeans zur Entwicklung von Rich Internet Applications (RIAs) mit AJAX vor. Nexaweb Technologies demonstrierte seine neuen Tools für die Entwicklung von Applikationen mit Java und Web 2.0 vor. Sie lassen sich einfach in die bestehende Java-Umgebung integrieren.

Heute jedoch, erfahren die Teilnehmer neues über Java EE 6, obwohl führende Hersteller wie IBM noch nicht einmal von J2EE auf Java EE 5 umgestiegen sind, welche das Highlight auf der letzten JavaOne war.

Ich denke, daß Sun die Bedeutung von Java EE 5 nocheinmal hervorheben wird und ausdrückt, wie wichtig die Plattform ist. Außerdem wird Sun versuchen, den großen Herstellern, die bereits an Board sind, Raum für ihre Erfolgsgeschichten einzuäumen. Natürlich werden sie mit hoher Wahrscheinlichkeit neue Funktionen von Java EE 6 zeigen, darunter auch die neuen Technologien für die mobile Entwicklung. Es sind nur Kleinigkeiten hier und da, nicht so als ob sie jetzt Java EE 6 ausrollen würden.

fügte Shimmin hinzu. Jean Elliot empfiehlt, allen Teilnehmern sich für das JavaOne Camp anzumelden, welches Entwicklern erlaubt, Ihre Wünsche für das neue Release zu äußern. Das wird eine Sitzung mit “offenem Mikrophon” sein, wo die Leute einfach in einer zwanglosen Atmosphäre drauflos reden und sich mit Entwicklern von Sun austauschen können.

Am Mittwoch, also morgen, wird dir Bühne um Java EE 5 Oracle gehören. Es wird damit gerechnet, daß Oracle bekannt gibt, in welchem Umfang der neue Oracle Application Server EE 5 unterstützen wird. Desweiteren stehen SOA-Standards, WS-Policy (das momentan in den Mühlen der W3C-Prozesse steckt) und Service Data Objects (SDO) auf dem Programm. SDO ist nun an die OASIS übergeben worden.

Ted Farrell, Oracles Chefarchitekt und Vizepräsident für Tools and Middleware, sagte, daß Oracle auch seine neue IDE JDeveloper vorstellen wird, die sich speziell an Entwickler für Web Services und SOA richtet. Außerdem wird das Application Developer Framework (ADF) vorgestellt, daß die Runtime für JDeveloper bereitstellt.

Wir haben besonders Rich Internet Applications im Auge gehabt. Wir sehen den Trend in der Entwicklung von Anwendungen für Web 2.0, die mit Hilfe von AJAX und Adobe Flash völlig neue interaktive Erfahrungen für Benutzer liefern.

sagte der Chefarchitekt. Shimmin fügt hinzu, daß auch die Bekanntgabe des Spring Frameworks für Oracle Application Server eine wichtige Angelegenheit sei. Spring passe viel besser in den Bereich Enterprise Business dieser Show.

Bei Spring geht es nicht um Web 2.0, Ajax und Mashups. Spring steht für Anwendungen, die auf einem Java EE Server laufen, die möglicherweise eine andere Applikation via Web Services bedient, die wiederum für das Bestellwesen oder ähnliches verantwortlich ist. Spring ist eben mehr auf Business ausgerichtet.

Teil der neuen Offensive des Computer- und Softwareherstellers aus dem sonnigen Santa Clara ist die heutige Konferenz unter dem Titel CommunityOne, nur einen Tag for der JavaOne Developer Conference. Auf beiden Konferenzen in San Francisco wird Sun seine weitreichenden Angebote aus der Open Source-Welt, die von engagierten Entwicklern aus aller Welt vorangetrieben werden, bewerben. Der Vorstoß ist nicht ganz uneigennützig, schließlich sind viele der neuen Unternehmen im Web 2.0-Ökosystem auch potentielle Kandidaten für zukunftsträchtige Open Source-Projekte.

Wir sind im letzten Jahr sehr aktiv gewesen und haben eine Menge Programme etabliert, die nicht nur auf Start-Ups sondern auch auf Open Source ausgerichtet sind. Wir nehmen unsere Führungsrolle sehr ernst.

sagte Richard Green, Executive Vice President der Softwaresparte bei Sun. Erst vor kurzem sei Sun von der Europäischen Union als führendes Unternehmen bei der Unterstützung von Open Source-Software bestätigt worden, fügte Green hinzu.

Zwar könnte Sun tatsächlich als führendes Unternehmen in der Open Source-Welt angesehen werden, insbesondere nach der Öffnung des Java- und Solaris-Codes, doch im Serversegment ist Sun nicht mehr die erste Wahl der Web 2.0-Unternehmen.

Ein Trend des zweiten Internet-Booms ist die Nutzung von günstigen sog. White Box Servern, die mit Standardprozessoren von Intel oder AMD arbeiten. Ebenfalls günstiger als je zuvor sind aktuelle Web Hosting- und On-Demand-Angebote wie beispielsweise Amazon’s Pay-As-You-Serve-Dienste EC2 und S3.

Während des letzten Dot-Com-Booms erteilte Sun vielen Start-Ups Rabatte, um ihnen den Erwerb hochwertiger und teurer Server aus der SPARC-Familie zu erleichtern. Viele dieser Unternehmen sind aber, wie wir leidvoll erfahren mußten, im letzten Abwärtstrend untergegangen.

Nun ist Sun wieder dabei, wenn es um die Unterstützung junger, innovativer Unternehmen geht, von denen sich das eine oder andere durchaus zum nächsten Google- oder Yahoo!-Wunder entwickeln könnte. Diesmal werden die Rabatte aber auf Server und Workstations mit Prozessoren von Intel und AMD erteilt. Darüber hinaus kann Sun umfangreiche freie Softwarelösungen beisteuern, zum einen, um sie auf die Solaris-Schiene weg von Linux zu bringen und zum anderen, um ihre Java-Technologien weiter zu verbreiten. Darüber hinaus unterstützt das Unternehmen Start-Ups mit Boot Camps.

Indem wir unsere Technologien der Open Source-Welt zur Verfügung stellen und die Open Soure-Welt selbst ein enormer Anziehungsfaktor ist, können wir Leute bereits im frühesten Stadium der Entwicklung unterstützen. Wir sind inzwischen ein deutlich vielseitigeres Unternehmen. Nun können die Organisationen, die versuchen, das neue große Ding zu landen, mit Sun sprechen, um technische Probleme zu lösen.

sagt Green. Mit dem Grid-Angebot, welches Firmen erlaubt, große Rechenkapazitäten zu mieten, wie es letztlich auch Hewlett-Packard tut, erweitert es sein Portfolio, steht allerdings einem ähnlichen Angebot von Amazon gegenüber, das mit niedrigsten Preisen lockt.

An der Softwarefront sieht sich Sun einer anderen Herausforderung gegenüber. Der populäre Software-Stack LAMP (Linux, Apache, MySQL, PHP/Perl) ist die bevorzugte Kombination von Web 2.0-Startups. Das P kann auf PHP, Perl oder Python gemünzt werden, letzteres ist besonders bei Google beliebt, das erst kürzlich Python-Erfinder Guido van Rossum einstellte.

“Eine enorme Anzahl von Leuten setzen auf LAMP”, versichert Stephen O’Grady, Analyst bei RedMonk, der auf Sun’s CommunityOne sprechen wird. Weiter fügt er hinzu, daß die Konferenz nicht dazu da ist, Entwickler von Solaris und Java zu überzeugen, damit sie sich gegen die LAMP-Kombination entscheiden. Stattdessen “schaffen wir es, Brücken zu bauen und Konversationen in Gang zu bringen”.

Dennoch, Sun’s Programmierplattform Java ist nun über 10 Jahre alt und sieht sich starkem Druck von der Python-Gemeinde und Ruby ausgesetzt. Beide sind fast ebenso lange existent, entwickeln jedoch erst mit dem Web 2.0-Boom ihre volle Wirksamkeit. Die Verbreitung von Ruby nahm sprunghaft zu, nachdem das Framework Ruby on Rails im Jahre 2004 das Licht der Welt erblickte. Besonders jüngere Entwickler schätzen die beiden Sprachen aufgrund der leichten Erlernbarkeit und kürzeren Entwicklungszeit von Anwendungen, was ein kritischer Faktor für neue Unternehmen ist.

Rob Russel, Executive Director von Planet Argon, Entwickler von Community und Social Networking Sites, beobachtete, daß “Ruby on Rails als ernste Bedrohung für Java eingeschäzt wurde”. Sun hat jetzt JRuby vorgestellt, das Ruby-Anwendungen auf der Java-Runtime ausführen kann. Passend dazu ist das Motto der JavaOne-Konferenz: Open Possibilities.

Sun ignoriert die Bedrohung durch neue Sprachen nicht, doch wichtiger ist, daß Sun seine Technologien auch weiterhin öffnet, um nicht zurückzufallen.

bemerkt Dan Kohn, CEO der Linux Foundation in San Francisco und trifft damit der Nerv der Zeit.

Das SOA Consortium, welches Anfang diesen Jahres ins Leben gerufen wurde, wird von Endbenutzern, Service Providern und Herstellern getragen, um eine größere Akzeptanz und Verbreitung einer Service-orientierten Architektur zu unterstützen. Zu den Hauptsponsoren gehören, BEA Systems, Cisco Systems, IBM und die SAP AG. Momentan sind etwa 17 sog. Practitioner Members aktiv, darunter American Red Cross, AT&T, General Services Administration und Hewlett-Packard, die eine frühe, experimentelle Ausrollung einer SOA in ihrem Unternehmen schultern können und dabei von dem Consortium unterstützt werden.

Das Consortium wird von der Object Management Group (OMG) verwaltet aber als eigenständige Einheit verstanden, versichert Jon Siegel, Vizepräsident von Technology Transfer der OMG. Siegel gab eine Präsentation auf der dritten Service Oriented Architecture for E-Government Conference am 1. und 2. Mai, die sowohl von der US-regierungsnahen CIO Council’s SOA Community of Practice und Mitre (McLean, Virginia), organisiert wurde.

Wie viele Sprecher auf der Veranstaltung richtig betonten, ist SOA keine Technologie, sondern ein Ansatz für Business Agility (der Fähigkeit, schnell auf Marktveränderungen reagieren zu können), der es Unternehmen ermöglicht, größere Interoperabilität und Interaktivität innerhalb und zwischen Organisationen zu erreichen. Das SOA-Consortium ist eine zeitlich begrenzte Unternehmung, die bis zum Jahr 2010 bestehen, ihre Arbeit danach aber einstellen wird.

Viele Führungskräfte nehmen SOA als eine Art Disziplin zur Integration ihrer Informationstechnologie war, dabei gehe es wirklich nur um Business Agility, betonte Siegel. Das Consortium ist davon überzeugt, daß die Mitglieder und seine Practitioner nur durch eine breite Community in der Lage sind, den Erfolg von SOA zu maximieren.

Das SOA Consortium spricht nicht die Entwickler in ihren Büro an, sondern jene in den höchsten Positionen im Unternehemen, die den Trend nach unten in das Unternehmen tragen

sagt Siegel. So will die Gruppe sich auch auf Business und IT-Analysten und Projektmanager konzentrieren. Sie erwartet, daß sich damit eine SOA-Philosophie bis in die Köpfe der Entwickler ausbreitet.

Dazu fokusiert das Consortium drei Themenbereiche:

• Business-driven SOA: Sensibilisierung der Führungskräfte für die Notwendigkeit, Kosten, Wertschöpfungen, Herausforderungen und Erfolgsfaktoren für eine SOA. Dazu sollen insbesondere CIO-Summits und Case Studies herangezogen werden.
• Verbesserung der Konkurrenzfähigkeit durch SOA: In diesem Bereich sollen besonders Geschäftsleute in den mittleren Ebenen mit Modellen, Methoden und Werkzeugen vertraut gemacht werden, um zum einen ihre SOA-Ziele zu erreichen und zum anderen die Konkurrenzfähigkeit des Unternehmens zu steigern. Das soll durch sog. Leadership Conferences erreicht werden.
• Etablierung einer Business-driven SOA: Das Ziel ist, Architekten und Entwicklungsmanagern die Entwicklung, den Übergang in und die Unterstützung einer praktischen SOA zu ermöglichen. Dazu sollen Practitioner Workshops un Open Practitioner Foren veranstaltet werden

Bis 2010 möchte das SOA Consortium erfolgreiche SOA-Implementierungen in 75% der weltweit größten 1.000 Unternehmen und Regierungsorganisationen sehen, während für mittlere und kleinere Unternehmen ca 50% avisiert werden.