ACM-Thesenpapier

7 Thesen zu Adaptive Case Management

Kollektiv der Masons of SOA
©iStockfoto.com/JrgBSchubert

Nachdem sich die Autoren längere Zeit mit dem Thema der dynamischen und adaptiven Prozesse beschäftigt haben, führten wir einen Workshop durch, zu dem wir einige ausgewählte Vertreter aus großen Unternehmen einluden, um unsere Theorien einem weiteren Praxischeck zu unterziehen (Kasten: „ACM-Thesen“). Dieses Thesenpapier schreibt die Erkenntnisse dieses Workshops fest und soll zur Diskussion einladen.

ACM-Thesen
Diese Thesen entstanden in ihrer ersten Version in einem ACM-Workshop auf der ASI-Lodge im schönen Rofan-Gebirge. Wir bedanken uns besonders bei diesen Kontributoren für ihren wertvollen Input: Jürgen Broda (Continental), Michael Lenzen (Atradius), Ralf Ernst (Arbeitsagentur), Timo Frey (Sparkassenversicherung), Gregor Ineichen (Visana Krankenkasse), Steffen Burkardsmaier (Domcura) und Jochen Seemann (MID). Den Rahmen beschreibt der Artikel aus Ausgabe 1.2014 des Business Technologie Magazins.

These 1

ACM unterstützt den Entscheidungsfindungsprozess und stellt die Entscheidung durch den Mensch in den Mittelpunkt (Human-Centric): Bei ACM steht der Mensch (Wissensarbeiter => Knowledge Worker) ganz klar im Mittelpunkt. Ziel von ACM ist es, das Wissen des Wissensarbeiters nutzen zu können und ihm ein Werkzeug/Mittel zur Verfügung zu stellen, das ihn primär dabei unterstützt, (noch) bessere Entscheidungen zu fällen und sein Wissen auch Kollegen zur Verfügung zu stellen. ACM führt den Wissensarbeiter und unterstützt ihn jederzeit mit den passenden Hilfsmitteln. ACM agiert dabei primär im Hintergrund, ohne dem Menschen zu viele Zwänge und Schranken aufzulegen. ACM ist eine Aiding Engine im Sinne eines Navigationsgeräts beim Auto. Bei der Routenführung durch ein Navigationssystem kann der Fahrer jederzeit vom vorgeschlagenen Weg abweichen, wenn er mehr Kontext über aktuelle Ziele hat, z. B. der Tank ist leer oder ein Kaffee dringend nötig. Anschließend greift das Navigationssystem wieder ein, holt den Menschen dort ab, wo er gerade ist und beginnt erneut die Führung hin zum eigentlichen Ziel. Erfahrene Mitarbeiter finden den Weg weitestgehend selbstständig (profitieren aber von Hinweisen etwa zur dynamischen Stauumfahrung), während sich unerfahrene Mitarbeiter über weite Strecken komplett von dem Navigationssystem leiten lassen.

Im Gegensatz dazu steht der BPM-Ansatz, bei dem der Businessanalyst, der Prozessmodellierer bzw. der Entwickler im Zentrum steht. Er bestimmt starr die möglichen Wege, meist mit dem Ziel, einen möglichst hohen Automationsgrad zu erreichen. Der Mitarbeiter, der das fertige System nachher verwenden muss, ist hier nur noch Mittel zum Zweck, er soll die Lücken schließen, wo eine hundertprozentige Automatisierung nicht oder nur mit sehr hohem Aufwand möglich wäre. Die Freiheiten des Systemanwenders sind dabei explizit eingeschränkt und es besteht kein Interesse, zu viele unterschiedliche Prozessflussvarianten zu modellieren, da sonst die Übersichtlichkeit des Prozessmodells leidet. Im Mittelpunkt von ACM steht der Knowledge Worker (KW). Dieser muss anhand von gegebenen Informationen Entscheidungen treffen. Während seiner Arbeit erreicht eine Vielzahl von Ereignissen den KW. Anhand der gelieferten und der zusätzlich beschafften Informationen müssen Entscheidungen getroffen werden. ACM unterstützt den KW durch verschiedene Informationsinterfaces bei seiner Arbeit:

• Dem KW werden pro Fall kontextbezogene Dokumente und Informationen bereitgestellt (Zugriffsmöglichkeit).
• Der KW erhält statistische und analytische Informationen, die die Entscheidungsfindung erleichtern sollen.
• Jede Aktivität verändert die Informationsbasis, die wiederum zur Weiterarbeit und Analyse verwendet wird.
• Fallbezogene Informationsinhalte beeinflussen die Auswahl der möglichen Folgeaktivitäten.
• Informationen werden durch eine Ontologie formuliert und dadurch einer großen Masse zugänglich gemacht.

These 2

ACM stellt „Living Knowledge“, also sich permanent ändernde, lebendige Informationen und Beziehungsgeflechte in den Vordergrund, während bei traditionellen Geschäftsprozessen eine im Vorfeld zu definierende Ablaufreihenfolge dominiert: Die Grundidee der klassischen BPM-Vorgehensweise, hier als normative Prozesse bezeichnet, besteht darin, dass ein Prozess eine a priori definierte, sequenzielle Folge von Aktivitäten ist. Alle Transitionen zwischen den Aktivitäten sind a priori definiert. Die Weichen des Prozesses basieren auf automatisch ausführbaren Geschäftsregeln. Alle denkbaren Varianten des Prozesses sind durch die Weichen (BPMN „Gateways“) vorgegeben. Es ist unmöglich, einen anderen Weg zu gehen, als im Gesamtprozessmodell vorgegeben.

Bei ACM werden Aktivitäten vorgegeben, mit der Option, adaptiv weitere Arbeitsschritte einbauen zu können. Die Transitionen zwischen den Aktivitäten werden nicht ausmodelliert, sondern erfolgen zur Laufzeit als Entscheidung durch den Menschen, der am Prozess teilnimmt. Er wird durch Regeln unterstützt, die als Vorbedingungen deklariert sein können. Diese Regeln schlagen dem Benutzer eine Liste der im gegenwärtigen Kontext denkbaren Aktivitäten und Werkzeuge vor. ACM ist informations- und nicht transitions- oder prozessgetrieben.

Während beim klassischen BPM der Prozess (Aktivitäten und Transitionen) als solcher im Vordergrund steht, liegt bei ACM der Fokus auf dem Informationsmodell und den Regeln, die auf diese Wissensbasis (Knowledge-Base/Informationsmodell und Instanzen) zugreifen. SOA und BPM arbeiten auf strukturierten, stabilen Sets an Informationen, die a priori über Hierarchien (vgl. XSD-Typdefinitionen) definiert werden und meist hart an den Prozesslebenszyklus gebunden sind. Ein Case kann jedoch viele verschiedene, zur Deployment-Zeit unbekannte Datenstrukturen enthalten, teils strukturiert, teils unstrukturiert und bringt diese über den Case-Lebenszyklus in eine gemeinsame Beziehung, wobei Relationen auch zu anderen Cases enthalten sein können. Beispiel: Zwei Patientenakten, die ähnliche Symptome listen. Um den beiden größten Problemen von BPM(N) Herr zu werden, nämlich:

• Notwendigkeit der Definition der Strukturen und Relationen vor dem Deployment, also nicht zur Laufzeit,
• Zu starre Prozess- und Instanzkontexte, die dynamisch kein spontanes Durchsuchen beliebiger Informationen erlauben,

setzt ACM auf einer lebenden Wissensbasis auf, die es erlaubt, Objekte aus mehreren Cases in Relation zueinander zu bringen, Strukturen dynamisch festzulegen und zu ändern und vor allem diese für Vorschläge durchsuchbar zu machen. ACM benötigt eine Knowledge-Base, um alle Vorteile ausspielen zu können.

These 3

ACM kann zu (selbst-)optimierten, normierten Prozessen führen: Adaptive Prozesse befinden sich in einem permanenten Zustand des Lernens und Weiterentwickelns. Dies unterscheidet sie von dynamischen Prozessen, die dem Benutzer in Form einer willkürlichen Ausführung ohne eine genau vorgegebene Reihenfolge zwar große Freiheiten lassen, aber kein Mittel der Optimierung über Prozesserfahrung eingebaut haben. Adaptive Prozesse geben dem Wissensarbeiter die Möglichkeit, situationsgetrieben weitere Prozessschritte zu definieren. Dies hilft ihm, die Wissensbasis zu erweitern und damit nachhaltig Mehrwert zu generieren. So wird eine permanente Adaption an die Realität erreicht. Trotz aller Freiheiten wird der Weg, den Prozessbeteiligte gegangen sind, protokolliert – als Basis für eine permanente Prozessoptimierung durch Fachseiten und IT. Insbesondere Verbesserungsvorschläge der Prozessbeteiligten werden protokolliert und regelmäßig ausgewertet.

Dies wird als „model afterwards“ oder auch „design by doing“ bezeichnet. Der eigentliche „Prozesslauf“, obwohl im Vorfeld möglicherweise gar nicht modelliert, ergibt sich nachträglich aus der Vielzahl konkret abgelaufener Instanzen (z. B. Aufzeichnung der konkreten Laufwege von vielen Wissensarbeitern über Monate). Dadurch wird eine Art „Process Mining“ möglich, aus dem sich aus der Vielzahl von denkbaren Wegen durch die einzelnen (dynamischen) Prozessbausteine und Aktivitäten mehr oder weniger tiefe Trampelpfade herauskristallisieren. Damit gewinnt man Prozessflussbilder aus echten Laufzeitdaten, ohne im Vorfeld eine genaue Modellierung aller Varianten durchführen zu müssen. Auf Basis dieser Erkenntnisse lassen sich die Prozesse, bzw. das Vorschlagssystem für sinnvolle nächste Aktivitäten effizient optimieren. Beispiel aus der Bautechnik: Beim Neubau eines Campus wurden im Gelände keine Wege angelegt. Man hat sich eine Zeitlang angesehen, wo sich Trampelpfade bilden und dann dort die Wege angelegt. Denn Menschen neigen automatisch zum Abkürzen und wählen intuitiv die beste Abkürzung (The Oregon Experiment). Übertragen auf die Prozesswelt lässt sich mit dieser Denkweise ein System aufbauen, in dem der Wissensarbeiter optimal unterstützt wird und dabei im Hintergrund zur Optimierung beiträgt. Somit kann die „KI“ Hinweise geben wie: „Sie haben Aktivität X gewählt. An dieser Stelle wählen 85 Prozent der erfolgreichsten Sachbearbeiter die Aktivität Y. Sie können X wählen, sind sie sicher?“.

These 4

ACM bedeutet dynamisches Assembly von a) a priori definierten und b) von zum Designzeitpunkt noch unbekannten Aktivitäten: BPMN basiert auf der Idee, Services und Tasks zur Design-Time zu definieren. ACM beschränkt sich nicht auf ein a priori definiertes starres System aus Aktivitäten, sondern diese können zur Laufzeit definiert werden. Dazu müssen sie folgende Anforderungen erfüllen:

• Jede Aktivität ist für genau einen Aufgabenbereich zuständig, atomar und transaktional in sich abgeschlossen.
• Aktivitäten können in einem Repository registriert und die angebotenen Fähigkeiten publiziert sein.
• Aktivitäten werden durch eine Ontologie beschrieben und können durch ein Reasoning dynamisch ausfindig gemacht werden.
• Alle Aktivitäten beschreiben In-/Out-Events, die Syntax und Semantik der In-Out-Parameter, die ausführbaren Rollen (Personen/Verantwortliche/Org).
• Aktivitäten müssen in mehreren Versionen verfügbar und gleichzeitig ausführbar sein.
• Bei der Registrierung wird das Mapping der Rollen, Daten, Aktivitäten und Events durch eine Ontologiebeschreibung vorgenommen.

Das dynamische Zusammenschalten der Aktivitäten und des Mappings kann durch eine ACM Engine erfolgen. ACM stellt nicht den Anspruch alle Eventualitäten, die denkbar sind, abzubilden. Aber der Mensch muss Freiheitsgrade ausnutzen können, um ggf. aus dem definierten Systemverhalten ausbrechen zu dürfen.

[ header = Seite 2: These 5-7 ]

These 5

ACM und rigide (normative) Prozessmodellierung sind zwei komplementäre Disziplinen im BPM-Umfeld, sie konkurrieren nicht, sondern sie ergänzen sich gegenseitig: Innerhalb einer BPM-Initiative ist es unabdingbar, eine Festlegung zu treffen, ob eher der „Production Worker“ oder eher der „Knowledge Worker“ optimal unterstützt werden soll. Rigide oder normativ definierte Prozesse, die im Vorfeld der Ausführung genau festlegen, wie ein Prozess durchlaufen wird, sind geeignet, wenn das Ziel tatsächlich im Sinne des Taylorismus in der Vereinheitlichung der Arbeit liegt. Wenn etwa Angebotsprozesse, Urlaubsanträge, rechtlich bedingte Freigabeprozesse, geführte Arbeit in IT-Systemen, Integrationsprozesse etc. auf immer identische Weise ablaufen sollen, um eine einheitliche Qualität zu erreichen, bietet sich die klassische Prozessautomatisierung an.

In vielen anderen Fällen sind normative Prozesse zu starr. Es ist nicht immer klar, wie viele Schritte nötig sind und welche Wege man genau gehen muss, um ans Ziel zu gelangen. Dies gilt zum einen für die wissensintensiveren Prozesse, zum anderen aber gerade auch für die Kernprozesse in den Unternehmen, für die spezielle Experten eingestellt werden. Typische Beispiele dafür sind Beratungs- oder Verkaufsgespräche, Unfallaufnahmen, Gutachten oder Untersuchungen. Hier stehen die Expertise und die individuelle Auswahl der Teilaufgaben durch den Benutzer im Vordergrund, um einen Geschäftsvorfall optimal abschließen zu können. Der Versuch, diese Art von Wissensarbeit dennoch mit normativen Prozessen zu unterstützen, führt in der realen Praxis zu Prozessbürokratie (alles ist gut, wenn der Prozess eingehalten ist, auch wenn das Unternehmen Schaden nimmt) und zu letztlich unproduktiveren Prozessinstanzen, da kein Nachsteuern über Erfahrung möglich ist. Hier brauchen wir den Taylorismus nicht. Hier ist eine zielunterstützende BPM, etwas Adaptives, deutlich zielführender.

Daher ist BPM allgemein eine übergreifende Managementdisziplin, die das Ziel der Prozessautomatisierung und letztlich -optimierung hat. „Normatives BPM“ (nBPM) und „adaptives BPM“ (aBPM) stellen zwei gleichwertige Teildisziplinen von BPM dar und sind damit jeweils nützliche Werkzeuge in der Toolbox der Business- und IT-Architekten, deren Einsatz vom Umfeld abhängt (Abb. 1). In der heutigen IT-Welt sind die normativen Prozesse im Sinne einer Prozessautomatisierung mit BPEL oder BPMN gut verstanden. Es obliegt somit jedem im BPM-Umfeld tätigen Architekten, sich mit den Konzepten der adaptiven Prozesse auseinanderzusetzen, um optimale Lösungen für die Anforderungen in wissensintensiven Kontexten gestalten zu können.

Abb. 1: Es gibt kein „besser“ oder „schlechter“ – BPM benötigt rBPM oder aBPM abhängig vom zu unterstützenden Mitarbeitertyp

Theoretisch könnte man alle ACM-„Prozesse“ prinzipiell auch in BPMN modellieren. Für alle Prozesse, deren Transitionen zur Analysephase bekannt sind, gilt, dass sie sich grundsätzlich als Flowchart ausdrücken lassen. Ein in der Case Management Modelling Notation (CMMN) modellierter Case könnte auch immer in BPMN modelliert werden. Hier muss man zunächst unterscheiden, was „kann in BPMN modelliert werden“ bedeutet. Um hierfür ein gutes Verständnis zu erlangen, schlagen wir die folgenden zwei Schwellenpunkte vor:

Komplexität nicht in Flowchart abbildbar: Dies sind Prozesse, deren Ablauf in einem Maße nicht deterministisch bestimmbar sind, sodass es nicht möglich ist, an jedem Prozesspunkt im Vorfeld zu sagen, welchen möglichen Pfad der Prozess als Nächstes im Gesamtbild gehen kann. Diese Art der Ausprägung existiert natürlich nur dann, wenn zur Laufzeit der Prozessinstanz Lösungswege/Aktivitäten ad hoc gefunden werden, die im Augenblick der Prozessanalyse nicht antizipierbar waren. Dann ist keine Abbildung in BPMN möglich.

Komplexität in Flowchart technisch möglich, fachlich nicht zielführend: Dies ist ein Prozess, der zwar technisch in BPMN modelliert werden kann, das Ergebnis ist jedoch für den Menschen nicht mehr verständlich. Die Voraussetzung für diese Art von Prozessmodellierung ist, dass alle Aktivitäten, die in einem Prozess auftreten können, zum Modellierungszeitpunkt bekannt sind. Ist dies der Fall, dann kann man diese Aktivitäten auf einem Prozessbild verteilen und jede bedenkliche Verbindung zwischen Aktivitäten auch ausmodellieren. Ab einer gewissen Anzahl von Transitionen (Querverweisen) wird das Prozessmodell jedoch unübersichtlich und nicht mehr für das Kernziel von BPM, nämlich Transparenz und eine Diskussionsgrundlage zu schaffen, zielführend.

Ansatz 1: Die Komplexität könnte z. B. auf mehrere Hierarchieebenen verteilt werden. Ein Prozessmodell auf der höheren Ebene enthält nach jedem Prozessschritt eine Weiche (ein BPMN-Gateway), deren Ergebnis benutzt wird, um einen Subprozess aufzurufen. Die Probleme mit diesem Ansatz sind, dass die Subprozesse häufig auf sehr unterschiedliche Wiedereinsprungspunkte im übergeordneten Prozess aufsetzen, was den Prozess insgesamt sehr schwer verständlich macht. Im übergeordneten Prozess werden so viele Weichen existieren, dass es schwer wird, sich mental ein Bild vom Normalablauf zu machen.

Ansatz 2: Die Komplexität wird auf einer Modellierungsebene in einem Prozessmodell untergebracht. Dies führt zu einer unübersehbaren Zahl von Transitionen im Prozessmodell zwischen den verschiedenen Prozessaktivitäten. Das Problem mit diesen Ansätzen ist jeweils die Verständlichkeit des Prozessablaufs. Für BPM ist es entscheidend, dass Menschen in der Lage sind, ein Prozessmodell zu verstehen und es als Grundlage für die Kommunikation über den Prozess verwenden zu können. Dazu ist der Mensch darauf angewiesen, einen roten Faden durch den Prozess zu finden. Sehr oft wird dabei mental das Bild eines Sonnenscheinpfads benutzt. Alle Varianzen sind dann Abweichungen von diesem Sonnenscheinpfad.

Vielleicht kann man entlang dieser Metapher den Unterschied zwischen Flow-Charting-basierten Prozessen und adaptiven Prozessen deutlich machen. Bei adaptiven Prozessen fehlt die Idee eines Sonnenscheinpfads. Wir glauben im Augenblick, dass die Mehrzahl der Prozesse, die in ACM abgebildet werden, in diese Kategorie fallen. Das heißt sie wären technisch gesehen abbildbar, aus Gründen der Komplexitätsbewältigung ist jedoch eine ACM-Lösung zu bevorzugen. Erste Projekterfahrung zeigt, dass genau die mentale Bewältigung des Ablaufs des Prozesses, also eine imaginierte Prozesskarte eine der größten Hürden und Herausforderungen im Umfeld von ACM-Lösungen darstellt. Prinzipiell könnte man also schon mit beliebig viel Geld und Ressourcenaufwand bzw. entsprechend hoher Denktiefe auch in BPMN sämtliche denkbaren Varianzen (Branches) im Vorfeld modellieren. Aus Aufwandsgründen lässt man dies jedoch weg und fügt im ACM-Kontext bei Bedarf noch fehlende Aktivitäten hinzu: Model the Unexpected. Auf diese Weise geht man ohne Vorabaufwand auf das Thema von Unexpected Events.

These 6

ACM kann eine Insel im BPMN-Prozess oder BPMN kann eine Insel im ACM-Ozean sein: Eine vieldiskutierte Frage ist die, welche Rolle ACM in Bezug auf rigide BPMN-Modelle spielt. Hier sind zwei Szenarien zu unterscheiden:

ACM kann eine Insel im BPMN-Prozess sein: Die ACM-Modellierung ordnet sich in ein übergeordnetes BPMN-Prozessmodell ein. Häufig tritt der Fall auf, dass die von ACM gelieferten Freiheitsgrade nicht für ein komplettes Szenario gewünscht sind, weil man etwa bestimmte Prozessanteile für alle Nutzer rigide führen möchte, aber an bestimmten Stellen im ACM-Sinne Freiheitsgrade bei der Wahl der nötigen Aktivitäten dem Menschen überlassen möchte. In diesem Fall kann man das ACM-Modell innerhalb eines BPMN-Prozesses abbilden. Hierzu kann das BPMN-Sprachmittel des Ad-hoc-Subprozesses verwendet werden. Ein Subprozess in BPMN ist eine abtrennbare Aktivität. Subprozesse werden genutzt, um Prozesse in Grenzen einzufassen, um Abstraktionen zu definieren und um die Komplexität eines Modells zu verstecken. Ein zusammengeklappter Subprozess versteckt seine interne Implementierung. Erweitert man den zusammengeklappten Subprozess, zeigt er seinen tatsächlichen Inhalt, nämlich ein weiteres BPMN-Modell. Im Unterschied dazu beinhalten Ad-hoc-Subprozesse keine weiteren BPMN-Modelle, sondern eine Menge von Aktivitäten. Diese Aktivitäten können in beliebiger Reihenfolge ausgeführt werden, bis eine Endebedingung erfüllt ist.

Im ACM-Sinne würde man also alle für einen Case relevanten und im Vorfeld bekannten Aktivitäten in einem Ad-hoc-Subprozess modellieren und diesen in den rigiden BPMN-Fluss einhängen. Damit ergibt sich das Bild einer „ACM-Insel“ innerhalb der rigiden BPMN-Welt. Vorteil ist, dass keine neue ACM-Modellierungskonvention verwendet werden muss und auch zur Laufzeit nicht zwangsweise eine ACM Engine zum Einsatz kommen muss, falls die genutzte BPMN Engine das Ad-hoc-Subprozess-Sprachkonstrukt ausführen kann. So steht es dem Anwender frei, welche Aktivitäten er in welcher Reihenfolge aus Basis seines Expertenwissens ausführt. Nachteil ist, dass sich so natürlich keine echte Adaptivität erreichen lässt, da alle Aktivitäten zur Designzeit bereits bekannt sein müssen – nur die Transitionen sind frei. Echte Adaptivität würde das Einfügen weiterer Ad-hoc-Aktivitäten durch den Anwender zur Laufzeit erlauben, was mit der „ACM-Insel“-Sichtweise aber nicht abbildbar ist.

BPMN kann eine Insel im ACM-Ozean sein: Die ACM-Modellierung steht für sich alleine und wird etwa mithilfe der CMMN und/oder Ontologien zu Papier gebracht. Hier ist keine Einbettung des Falls in übergeordnete (BPMN-)Prozessmodelle nötig. BPMN-Prozesse werden höchstens als Implementierung für diverse Aktivitäten des Falls verwendet.

These 7

ACM-Lösungen müssen sich nahtlos in bestehende Enterprise-Plattformlösungen integrieren lassen: ACM hat mit klassischen BPM-Werkzeugen gemeinsam, dass eine Lösung auf Unternehmensebene aus der Kernkomponente (ACM Engine bzw. BPM Engine) besteht, die in ein komplexes Ökosystem aus Lösungsbausteinen eingebettet sein sollte. Zu diesem Ökosystem bzw. den Bausteinen einer Plattform gehören

• Ein Portal
• Eine zentrale Aufgabenverwaltung
• Reporting und Dashboards
• Dokumentenmanagement
• Eine SOA-Infrastruktur
• Eine Event-Streaming-Infrastruktur
• Real-Time Analytics

Eine Standalone-ACM-Lösung, die sich nicht in eine bestehende entsprechende Unternehmensarchitektur einkoppeln lässt, hat damit, insbesondere in Bezug auf eine evolutionäre Weiterentwicklung über höhere Maturitätsstufen hinweg, einen wesentlichen Nachteil.

Geschrieben von
Kollektiv der Masons of SOA
Kollektiv der Masons of SOA
Das Autorenkollektiv der "Masons of SOA" besteht aus: - Jürgen Kress (Fusion Middleware Partner Adoption, Oracle EMEA) - Berthold Maier (Enterprise Architect, T-Systems International GmbH) - Hajo Normann (SOA & BPM Lead ASG, Accenture) - Danilo Schmiedel (Solution Architect, OPITZ Consulting Deutschland GmbH) - Guido Schmutz (Technology Manager, Trivadis) - Bernd Trops (Principal Solution Architect, Talend GmbH) - Clemens Utschig-Utschig (Chief Architect Global Business Solutions, Boehringer Ingelheim Pharma GmbH & Co. KG) - Torsten Winterberg (Business Development & Innovation, OPITZ Consulting Deutschland GmbH). Mehr Informationen zu den Autoren: http://soacommunity.com/index.php/institutional/masons-of-soa.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: