Ob IBM auch so smart wie die Roten war, denn diese hatten bei der IBM Impact Konferenz im May in Las Vegas eine hervorragende Idee – die Begrüßung und Verabschiedung aller Gäste während der Impact auf dem Vegas Airport mit riesigen Bannern: http://img.ly/UU

btw: Nachlese zur Impact siehe: http://x-integrate.com/x-in-cms.nsf/id/DE_Impact_2009_Nachlese?open&l=DE&ccm=500100

Sie sprechen mir aus der Seele

Grüße aus Karlsruhe,
Alexander

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?

Quelle: Amazon
……

Resoa.org ist ein Open Source Architektur Ansatz, der die entscheidende Rahmenbedingungen schaffen kann, dass SOA und Cloud Computing zukünftig zusammenwachsen. Resoa erfindet nicht das Rad neu, sondern ergänzt und kombiniert vorhandene frameworks, primär aus dem Bereich Rest/JSON.
Wir benutzen ihn erfolgreich für unsere Applikationen und stellen ihn nun public mit der Überzeugung, dass sich eine größere community finden wird, die diese Idee weiterentwickeln will.

Auf welchem Mond leben denn die SOA/BPM Befürworter???

Denkt diese Sache eigentlich niemand durch? Alle wolle nur endlose Bürokratie aufziehen und den Mitarbeiter bescheurt idalisierte aber rigide Prozesse aufzwingen.

Zusätzich braucht man auch noch Flexibilität. Es gibt nämich kaum fixe Prozesse. Also was soll der ganze BPM(N-S-L) Müll.

Die Zukunft kann nur so sein, dass der Prozesseigner seine Prozesse selbst einstellen kann und mit seinem Team ausführen. Das wird sicher nicht auf Basis der BPMN definiert werden weil das keiner kann und keinen interessiert. Ein kollaborativer Ansatz der alle Daten und Dokumente kontrolliert und übersichtlich macht wird der einzig machbare Weg sein.

Aus meiner Sicht ist BPMN Flowcharting eine reine Technonolgie Illusion. Man braucht sich nur anzusehen was beo BPMN 2.0 noch alles am Dampfen ist und damit ist klar, dass es verrückt wäre sich darauf einzulassen.

Wie kann man nur so kurzsichtig sein …

Bedauerlicherweise muss ich generell feststellen, dass häufig Projekte initiiert und gestartet werden ohne das diese mit den Unternehmenszielen und / oder der Unternehmensstrategie abgestimmt wurden.

Dann erfolgt irgendwann der Abbruch des Projektes und eigentlich weiß niemand genau warum eigentlich das Projekt nicht erfolgreich werden konnte. Es lief doch eigentlich alles ganz gut. Mitunter wird versucht solche Fehler durch gaaaaanz viel Geld noch nachträglich irgendwie wieder zu korrigieren.

Das das nicht funktionieren kann, dürfte jedem klar sein.

Übrigens: Die US Immobilienkrise hat nicht die weltweite Finanzkrise ausgelöst sondern die Willigkeit der Finanzkonzerne und der Börsen unbesicherte Kreditzertifikte und darauf beruhende Derivate anzukaufen weil sie hohe Renditen abwerfen. Dabei wurde auf die Besicherung vergessen weil viele Zertifikate das Kreditrating der emitierenden Bank bekamen aber dabei nicht beachtet wurde was dahintersteht. Welche Anleger verstanden dies? Warren Buffet sagte: ‘Investieren sie nicht in etwas das sie nicht verstehen.’ Ich habe mich daran gehalten weiss aber mittlerweile nicht einmal mehr auf welcher Bank ich das Geld meines Unternehmens liegen haben sollte da dieses vom Staat nicht besichert wird. Auch in der Informatik ist Ursache und Wirkung nicht so einfach sondern auch eine Wechselwirkung aus der von den Börsen verursachten Quartals-Kurzsichtigkeit aus der ja auch der idiotische IT Outsourcing Trend entstammt. Weiters sind weltweite Konzerne weder aus einer Zentrale verwaltbar noch mit IT versorgbar. Die Inkompetenz herrscht auf höchster Ebene in einem kommunistisch, zentralistischen Planungswahn.
Das ironische daran ist das man jetzt die Kapitalisten dafür verantwortlich macht.
Tja, Informatik ist direkt mit Wirtschaft und Politik verknüpft auch wenn sie das überraschen mag.

vielen Dank für den sehr interessanten Artikel, den ich leider erst heute gefunden habe.
Ich bin z. Zt. bei Mittelständlern unterschiedlicher Größe und Branchen in Sachen BPM unterwegs und kann Ihnen größtenteils zustimmen. Es gibt für diesen Mangel in meinen Augen drei wesentliche Gründe: die Möglichkeiten eines druchgängigen BPMs wurden einfach noch nicht erkannt (auf den ersten Blick zutreffend). Bei genauerer Betrachtung kämpft man vielerorts noch an anderen Baustellen (z.B. der Kongruenz zwischen IT und Geschäftsprozessen – also dem IT-technischen Level). Ich kenne einige Mittelständler, bei denen läuft das ERP-System eher schlecht als recht, da im Vorfeld auf die Geschäftsprozessoptimierung kein Wert gelegt wurde (nach dem Motto: wir brauchen ein ERP … sofort!!) und da ist an BPM und SOA noch gar nicht zu denken. Zum Dritten hat man schlichtweg seine Prioriäten anders gesetzt (volle Auftragsbücher, dünne Personaldecke, kein strategischer Fokus, etc.), man ist mit den “nicht definierten” (aber implizit bekannten) Abläufen zufrieden und betriebt “Business as usual”. So zumindest meine Erfahrungen mit BPM bis dato.

Bleibt mir abschließend noch anzumerken, dass man sehr viel Überzeugungsarbeit zu leisten hat, um Mittelständlern den Nutzen eines BPM zu verdeutlichen – und über die Kosten hat man dann noch gar nicht gesprochen.

Haben Sie ähnliche Eindrücke?

Grüße
Benjamin Hötzel

vielen Dank für Ihren Beitrag, der hoffentlich endlich mehr Realismus in die SOA-Diskussion bringt.

Vor allem Ihr Hinweis auf die organisatorischen Veränderungen, die durch SOA-Projekte ausgelöst werden, ist dabei für mich wesentlich. IT-Projekte mit diesem Ausmaß können nicht allein aus einer technischen Perspektive betrachtet werden.

Ich weise in diesem Zusammenhang gerne auf meinen Beitrag in diesem Blog zum Thema “Change Management in BPM- und SOA-Vorhaben” hin:

http://www.computerwoche.de/soa-expertenrat/2008/03/14/change-management-soa-und-bpm-initiativen-gezielt-begleiten/

Die Weiterbildung der IT-Projektleiter und -Führungskräfte muss ergänzt werden durch die Vermittlung von Kompetenzen für Organisationsentwicklung und Change Management, damit IT-Projekte zukünftig auch nachhaltig in den Organisationen umgesetzt werden.

Ich werde am 9.9. auf der “Zukunft Personal” in Köln einen Vortrag zu diesem Thema halten.

Mit freundlichen Grüßen

Uwe Feddern

Sind sowohl die fachliche Seite als auch die technische Seite nicht 100% beschrieben, so kommt es folglich zu einer loose-loose Situation. Das Ziel wird nicht erreicht und/oder Nacharbeiten des Lieferanten senken seine eigene Marge.

Die grundlegenderen Techniken sind vorhanden und weniger fehlerhaft als die beteiligten Personen. Zeitliche, finanzielle und zwischenmenschliche Gründe sorgen dafür, dass Projekte oft am Ziel vorbei laufen. Grenzen wie die ersten beiden sind natürlich wichtig. Wer aber immer noch nach der Geiz ist Geil Mentalität seine Projekte betreibt, erhält was er bezahlt. Jasager und Katastrophen.

Aus mehr als 20 Jahren Software Entwicklung haben sich einige Details herauskristallisiert:
„Früher war alles anders“.
„Technik lässt sich schneller/einfacher ändern als Menschen“.
„Alles was sich exakt beschreiben lässt, ist ohne Kostenbetrachtung technisch umsetzbar“.
„Kleine Schritte in die richtige Richtung sind besser als Nichts zu unternehmen oder auf das Ultimative Ergebnis zu warten“. (Siehe dazu auch den Text in einer anderen Computer Zeitung. „Thema ich kaufe mir seit 2 Jahren einen Computer“).
„Man lernt nur aus Fehlern“.

Aus meiner Sicht gibt es keinen Grund den Kopf in den Sand zu stecken und eine Rolle rückwärts zu machen (Schon probiert? Man bricht sich das Genick).
Wie bei allen Projekten sollte man die Erwartungen nicht zu hoch schrauben, sondern realistisch seine Lage beurteilen. Wo bin ich, wo will ich hin, was habe ich erreicht und sind wir bereits soweit?

SOA ist die IMHO die Verknüpfung von spezialisierten Diensten die ihre Aufgabe optimal erledigen können, anders als Giga Anwendungen die Alles, aber das nicht richtig beherrschen. Gerade SOA ermöglicht es mir einen Anfang zu machen und in kleinen Schritten an den Stellen wo es nicht klappt bessere Systeme zu integrieren.

Sie haben völlig Recht: Natürlich haben Fachmedien wie die COMPUTERWOCHE ausführlich über die Potenziale einer SOA berichtet, dabei aber auch immer die Versprechen der Hersteller kritisch hinterfragt. Die schlechten Anwendererfahrungen haben die Medien aber ebenso wenig erfunden wie die Beispiele erfolgreicher Projekte.

Grüße

Wolfgang Herrmann

Bitte nicht die Fachpresse (ja, auch die CW) vergessen!

Gruß,

Sebastian

Um Wiederverwendbarkeit zu ermöglichen, benötigt man ein sehr gutes (neuartiges) Repository, in dem genau und für jeden verständlich beschrieben ist, was der Service leistet. Das Problem ist mir seit vielen Jahren Erfahrung mit modularer Software bekannt – eine Lösung kenne ich bisher nicht. Gibt es eine?

Great! It’s a good site to learn more and have discussion.

It’s not bad to know that England Foreign Exchange EFXCO has so many facilities for traders and customers such as Loan Facilities, Mutual Fund, Hedge, Credit facilities, Insurance and etc…

Good Luck

ich habe in unserem Arbeitsgebiet, der Geschäfts- und Betriebsprozessmodellierung im Hinblick auf den Einsatz von IT-Services ähnliche Schwierigkeiten wie Sie mit solchen Einteilungen wie “Top-Down” und “Bottom-Up”. Man weiss nämlich nie, was der Gesprächpartner als Top (hier: die Ablauf- und Aufbauorganisation des Unternehmens) und was als Bottom (hier: das Rechnersystem und die IT-Services) verstanden wissen möchte. Zudem klingt “Top-Down” nach “grob” und “Bottom-Up” nach “detailliert”. Dieser Sprachgebrauch ist jedoch in der Praxis vielfach anzutreffen.

Ich würde, um Mißverständnisse auszuräumen, unabhängig davon, ob wir uns auf der Ebene der Unternehmensorganisation oder auf der Ebene der IT befinden, lieber einen Modellierungsanfang “aus der Mitte” heraus suchen. Also: Auch bei der Aufgaben- und Arbeitsprozessmodellierung von Einheiten (Komponenten) mittlerer Größe ausgehen und dann einer Insight-The-Component/Outsight-The-Component-Dychotomie das Wort reden.

Je nachdem, wie genau wir die Modellierung hierbei jeweils durchführen können, kommen wir zu einer hohen “Runnability” (spezifizierte “Betriebsmittel” der Prozesse) sowie einer hohen “Applicability” (spezifizierte “Bezugsobjekte” der Prozesse) unserer Prozessmodelle. Ein Betriebsmittel eines Prozesses ist bspw. ein Arbeitsplan, der einzuhalten ist und ein Bezugsobjekt eines Prozesses könnte bspw. ein Störfall in einem Unternehmen sein, dessen Beseitigung das Prozessmodell (Runnability) garantiert.

Die Modellierungsrichtung wäre: From Applicability to Runnability! Denn warum soll ich Prozessen eine Runnability (Betriebsmittel) “aufmodellieren”, wenn ich noch nicht spezifiziert habe, was eigentlich ihre Applicability (Bezugsobjekte) sein wird?

Beste Grüsse
Erich Ortner

ich sehe die größte Herausforderung zur Erreicherung von lauffähigen, technischen Prozessen, welche auf der initialen fachlichen Modellierung (Kompetenz BPM) beruhen, in der Abkehr vom Bottom-Up-Prinzip (bspw. Anwendungsfallmodellierung in UML) als Folge der Top-Down-Modellierung (Geschäftsprozessmodelle). Vielmehr gilt es, in Form einer erweiterten Geschäftsprozessmodellierungsphase Hilfsmittel wie eine Prozesslandkarte, Domänenmodell, Anwendungslandschaft, Rollen, Geschäftsobjekte, etc. heranzuziehen und die fachlich modellierten Geschäftsprozesse mit Informationen aus den genannten Hilfsmitteln anzureichern. Dadurch entstehen (theoretisch) fachlich orientierte, technisch angereicherte, ausführbare Prozesse, welche als Grundlage (plus weitere Ergebnistypen wie eine Liste der fachlichen Schnittstellen und Geschäftsobjekte) für die eigentliche implementierungsnahe Modellierung (z.B. UML) dienen. Die sogenannte “Runnability” zeichnet sich ja nicht durch eine maximale Detailmodellierung auf technischer Ebene aus, sondern durch die Ausrichtung an der Fachlichkeit! Der Mitarbeiter handelt fachlich, nicht technisch. Daher ist die Übertragung der “Fachsemantik” aus den GP-Modellen in die durch Services unterstütze ausführbare Prozesse mit Hilfe sequenzieller, teils iterativer Modellierungsstufen ein Hauptanliegen zur Erreichung von “Runnability” – denn ohne Nutzer leben die Prozesse nicht (außer bei einer 100%igen Automatisierung).

Viele Grüße,
Falk Ostermann
SAPICON GmbH