Business Analyse: Hoch kollaborative Umgebungen verstehen

In der Firma beschäftige ich mich momentan mit Business Analyse. Das Buch Business Analysis For Dummies [1] definiert Business Analyse wie folgt:

set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.

Es geht bei Business Analyse also darum, Unternehmensabläufe zu verstehen, um sie verbessern zu können. E.g. auch mit Hilfe von Software, welche bis dato noch fehlte oder veraltet ist. Im Zuge der Recherche habe ich mir einige Gedanken gemacht und auch Synergien zur Uni gesucht. Die Gedanken möchte ich hier zu Blatt bringen.

Mein Interessensgebiet gilt Behörden und Organisationen mit Sicherheitsaufgaben - im Speziellen aufgrund vergangener Tätigkeiten der Feuerwehr(-Leitstelle). Betrachten wir initial die reale Welt wie sie ist:

Wir haben einen Verkehrsunfall.

Wir haben Personen, welche den Unfall beobachten und per Handy verbal oder anderen Medien (e.g. Apps) die Leitstelle informieren.

Wir haben die Leitstelle, welche die Informationen verarbeitet und die Ressourcen-Disposition koordiniert.

Wir haben Ressourcen, welche schadensminderte Tätigkeiten am Unfall durchführen.

Um die reale Welt besser verstehen zu können, empfiehlt es sich, diese zu abstrahieren. Dabei wird nur das abstrahiert, was für eine zukünftige Analyse von Interesse sein könnte. Will ich e.g. Vorgänge in der Anrufverteilung in der Leitstelle verstehen, muss ich diese so abstrahieren, dass ich das richtige Abstraktionslevel wähle, um die gestellten Fragen beantworten zu können.

Essentially, all models are wrong, but some are useful. – George Box

Es lohnt sich wieder einmal ein Ausflug in die akademische Welt, um eventuell einige interessante Aspekte extrahieren zu können. Architecture Description Language sind bereits eine sehr gut untersuchte Technik. Die elementaren Bausteine sind:

• Components: “the loci of computation and data management”. Das heißt: Komponenten wissen etwas zu einem Zeitpunkt X (State) und tun etwas (Computation). Das ist eigentlich eine gute Abstraktion für Mensch und Maschine in der realen Welt - finde ich. Das was wir tun wird durch einen internen oder externen Stimulus angeregt. Und wir wissen durch beobachten etwas.
• Connectors: Komponenten kommunizieren irgendwie miteinander. Connectors können auch Eigenschaften haben. In der realen Welt würde das bedeuten: Personen (Komponenten) können über unterschiedliche Medien (Connectors) kommunizieren: verbal, Whatsapp, Email, Wikipedia, … Und all diese Medien haben hinsichtlich Latenz, Zuverlässigkeit usw. unterschiedliche Eigenschaften.
• Modeling Configurations: Irgendwie hängt das Ganze (wie in der realen Welt) auch zusammen. Welche Komponenten können mit welchen kommunizieren?

Das beudetet, dass wir mit ADLs ziemlich gut kollaborative Umgebungen beschreiben können bzw. - wenn es keine ADL sein soll - zumindestens die essentiellen Aspekte von Components, Connectors und Configurations im Hinterkopf behalten. Denn uns interessiert:

• Welche Entitäten (Personen, Systeme) sind involviert?
• Was wissen sie zum Zeitpunkt X?
• Wie reagieren zu auf Stimulus X?
• Wie können Sie miteinander kommunzieren? Wie schauen die Contracts (Interfaces) aus?
• Wie schauen “Laufzeit”-Instanzen aus? (e.g. bei Laständerung gehen oder kommen Komponenten)

Russell und Norvig [4] sehen das in der Artificial Intelligence ähnlich: Ein Agent (autonome Instanz) sieht etwas (Sensoren) und setzt Aktionen. In der Business Analyse interessiert uns speziell, was er wie (Art des Mediums) beobachten kann.

Secenarios

Bis jetzt haben wir also die Struktur (Architektur) unseres Business analysiert. Wichtig ist dabei, dass wir alle Entitäten betrachten, die involviert sind und bei der Fragestellung von Interesse sind. Szenarien sind konkrete Ereignisse, welche die Maschinerie in Gang setzen und bildlich gesprochen e.g. Messages zwischen Komponenten flitzen lassen und deren State ändern. Betrachten wir ein vereinfachtes Modell des obigen Szenarios.

Die wichtigsten Aspekte sind:

• Zwischen den Disponenten muss eine Koordination statt finden, da es sonst e.g. zu einer Doppelposition kommen könnten (zwei Notrufer melden das gleiche Unfallereignis an zwei unterschiedliche Disponenten). Ressource Allocation bedarf meist einer besonderen Aufmerksamkeit [3].
• Betrachten wir das ganze Szenario, so sprechen für von einer Kollaboration zwischen Notrufer, Disponenten und Ressourcen – mit dem Ziel, der verunfallten Person zu helfen.

Wir sprechen hier bewusst von einem Szenario - Feuerwehrleitstellen müssen mit unterschiedliche Einsatztypen umgehen können (die Architektur bleibt gleich – die Kommunikation bzw. Interaktion ändert sich). Zu beachten: die Architektur kann (wenn man sie z.B. simulieren möchte) zur Laufzeit instanziert werden – somit gibt es auch eine Runtime Configuration welche die Anzahl der Komponenten usw. ändert.

D.h. wir können momentan folgendes Zwischenfazit machen:

• Wir haben eine Architecture welche uns die reale Welt abstrahiert. Welche Entitäten (e.g. Systeme, Personen) können wie (Connectors) miteinander kommunizieren (Contracts)?
• Wir haben Scenarios (e.g. Verkehrsunfall klein / groß, Brand, Chemieunfall, …) welche auch eine Abstraktion von Geschehnissen der realen Welt darstellen und auf die Architektur abbilden.

Von Interesse ist noch, wie man e.g. Prozesse modellieren kann, welche Abläufe in Komponenten beschreiben. Von Finte State Machines (FSM) bis Business Process Model and Notation (BPMN) ist alles möglich. Alternative noch aus dem akademischen Umfeld eine hierarchische Beschreibungssprache für Prozesse: LittleJIL [6]. Wie auch immer. Komponenten folgen (hoffentlich) rational und deterministischen Prozessen die man analysieren und abbilden muss.

Wikipedia sagt zu BPMN:

ist eine grafische Spezifikationssprache in der Wirtschaftsinformatik und im Prozessmanagement. Sie stellt Symbole zur Verfügung, mit denen Fach-, Methoden- und Informatikspezialisten Geschäftsprozesse und Arbeitsabläufe modellieren und dokumentieren können.

Allerdings muss festgehalten werden, dass kollaborative Arbeit nicht Kernziel von BPMN und BPEL sind.

Die Kommunikation zwischen Entitäten folgt im allgemeinen gewissen Schemen (Patterns). Z.B.: Messages. Diese sind nicht veränderbar, kann zwischen Personen und System geschickt werden. Für die Business Analyse interessant: Wie schauen diese Nachrichten aus? Welche Informationen beinhalten sie?

Aber auch bei der Kollaboration gibt es Patterns – ein paar häufig anzutreffende Kandidaten:

• Shared Artifact: Gemeinsamer “Platz” zum Informationsaustausch
• Master/Worker: Arbeitszuteilung
• Publish/Subscriber: Interessiert an gewissen Events

In der Business Analyse gilt es also diese Muster zu identifizieren und zu dokumentieren (e.g. Modelle).

Was mit dem Modell tun?

Ich will an dieser Stelle auch Dinge beachten, die auch schon jenseits der Business Analyse sind. Die Möglichkeiten sind facettenreich:

• Man könnte das Modell des Business Environment für Simulationszwecke verwenden. Simulationen erlauben es, Eigenschaften des Systems zu messen, ohne dieses bauen zu müssen. Natürlich stellt sich an dieser Stelle die Frage, ob sich der Aufwand lohnt. Sind meine Fragen, die ich durch Messung erhoffe zu beantworten, so kritisch, dass der Erfolg des Projekts davon abhängt? Auch kann e.g. Simulation in manchen Bereichen kostgünstig sein: z.B. Logistik Transaktionen, welche ich real schwer nachstellen kann (oder mit anderen Parametern gerne mehrfach durchführen will oder verlangsamt betrachten will). Zu beachten ist, dass wir Simulation hier einsetzen können um das Business zu verstehen und/oder zu optimieren. Ich persönlich glaube, dass Simulation durchaus eine gute Sache ist – aber: Es gibt noch keine guten Tools, welche das unterstützen … (zumindest habe ich keines gefunden) Und damit sind wir schon beim Problem …
• Man könnte aus den Modellen, welche man in der Business Analyse gewonnen hat, weitere Modelle generieren. Eventuell sogar Modelle für die Umsetzung. Rentiert sich der Aufwand? Will man eine hohe Traceability zwischen Business Modellen und Umsetzung? Welchen Vorteil hat es? Auch hier sind die Möglichkeiten wieder facettenreich …

Zum zweiten Punkt noch eine Anmerkung:

Im Zuge der Business Analyse befindet man sich vermutlich auf dem Level eines Domain-Models. Wie aus der Abbildung [5] zu entnehmen ist, besteht zwischen Domain-Model und Design-Model eine Verbindung mit der Anmerkung Designation. Das bedeutet, dass gleiche Dinge in unterschiedlichen Modellen das Gleiche ausdrücken.

Diese Eigenschaft kann man sich (theoretisch) zu nutzen machen und daher im Design-Model Aspekte des Business-Models übernehmen. Das Domain-Model ist zweifelsohne einer der wichtigsten Outcomes der Business Analyse. Es erlaubt die Definition einer gemeinsamen Sprache (http://martinfowler.com/bliki/UbiquitousLanguage.html). Des Weiteren erlaubt es ein gemeinsames Verständnis der realen Domäne.

Ein Beispiel von mir seht ihr in der folgenden Abbildung.

Auch mit Objektdiagrammen kann man sich gut weiter helfen

Theoretisch könnte man aus UML auch “Sachen” generieren – ich sehe hier aber den großen Benefit nicht – allerdings habe ich noch keine Erfahrung mit Business Analyse – aber ich glaube trotzdem: Mich würde das als Konsument von Business Analyse eher hindern. Modelle können aber auch als Dokumentation verwendet werden – man muss hier nicht so strikt arbeiten und erreicht vermutlich trotzdem gute Ergebnisse.

Fazit

Egal welche Tools oder Techniken man verwendet – ich glaube das Wichtigste ist:

• Betrachten der gesamten Wertschöpfungskette (siehe Beispiel: Auch Notrufer und Ressourcen sind Teil davon)
• Modellierung essentiell (=gemeinsame Sprache)
  • Kunst: richtigen Grad erwischen. Frage: Was wollen wir mit Modellen machen? Synthetisieren bzw. Exekution / Simulation erforderlich? Oder nur dokumentieren (tendenziell einfacher)?
  • Unterschiedliche Möglichkeiten:
    • Modellierung der “Business”-Architektur (Software-Komponenten und Personen)
    • Modellierung von Geschäftsprozessen
    • Beides gemeinsam?
• Domain Model ist ein must-have um ein Business zu verstehen
  • Sprache der Domäne verstehen
• Outcome der Business Analyse sollte für Software-Architekten brauchbar sein
  • siehe Grafik “Fairbanks”
• Persönliches Anliegen: Requirements aus Sicht aller involvierten Personen
• Komponenten / Architektur Denkweise: Feststellen, welche Komponenten (Personen, Systeme) was zu welchem Zeitpunkt wissen und wie drauf reagieren. Über welche Medien (e.g. verbal, Funk, Computersystem) können Komponenten miteinander kommunizieren? Was sind die Eigenschaft dieser Medien?

[1] Business Analysis For Dummies
[2] Medvidovic, Nenad, and Richard N. Taylor. “A classification and comparison framework for software architecture description languages.” Software Engineering, IEEE Transactions on 26.1 (2000): 70-93.
[3] Malone, Thomas W., and Kevin Crowston. “The interdisciplinary study of coordination.” ACM Computing Surveys (CSUR) 26.1 (1994): 87-119.
[4] Russell, Stuart, Peter Norvig, and Artificial Intelligence. “A modern approach.“Artificial Intelligence. Prentice-Hall, Egnlewood Cliffs 25 (1995): 27.
[5] Fairbanks, George. Just enough software architecture: a risk-driven approach. Marshall & Brainerd, 2010.
[6] Zhu, Liming, et al. “Desiderata for Languages to be Used in the Defnition of Reference Business Processes.” Int. J. Software and Informatics 1.1 (2007): 37-65.