Vom IT-Engpass hin zu Business-Agilität – So beheben Sie das Nadelöhr

Was die obige Abbildung zeigt: Das Problem besteht bereits auf organisatorischer Ebene. Business und IT sind aneinander gekoppelt. Missverständnisse oder Unklarheiten ziehen sich durch die einzelnen Iterationen der Softwareentwicklung hindurch, bis letztlich das richtige Ergebnis erzielt wird.

Ein Blick auf die vielfältigen Schnittstellen zwischen den Fachanforderungen des Business-Analysten und der technischen Umsetzung zeigt: Softwareentwicklung ist häufig wie die “Stille Post”: Je mehr Schnittstellen beteiligt sind, desto mehr Informationen gehen verloren oder werden anders interpretiert.

Entkopplung als Architekturansatz für Business-Agilität

Die Lösung: Eine geeignete Architektur ermöglicht Entkopplung auf Organisationsebene und steigert dadurch die Business-Agilität. Was bedeutet das? Der Fachbereich (Business) wird in die Lage versetzt, (s)einen Teil der Softwareentwicklung eigenverantwortlich zu übernehmen – und zwar die Fachlogik.

Fachlogik ändert sich meist häufiger als die Prozesslogik oder die IT-Umsysteme und erfordert viel fachliches Wissen. Es macht daher Sinn, die Verantwortung für Fachlogik in die Fachbereiche zu übertragen. Doch Softwareentwicklung ist sehr komplex, geschäftskritisch erfordert viel Kontrolle. Wie also kann man Fachbereiche dazu befähigen, ihren Teil der Softwareentwicklung möglichst selbständig zu übernehmen? Die Antwort ist: Durch Abstraktion und ein geeignetes Toolset.

Fachbereichs-Enablement ist längst Gang und Gäbe

In der Tat ist dieses Vorgehen schon lange Realität: Microsoft Excel oder WYSIWYG-Web-Content-Management-Systeme sind Beispiele dafür, wie durch Abstraktion und ein einfaches Tooling Komplexität verborgen bzw. handhabbar gemacht wird – auch für Anwender ohne Programmierkenntnisse (aber mit einer gewissen technischen Affinität).

Abstraktion erlaubt Einbezug neuer Anwendergruppen

Weitere Beispiele sind das Business Rules Management bzw. das Decision Management. Die beiden Disziplinen setzen auf eine grafische Modellierung von Fachlogik. Visuelle Modelle, Ablaufdiagramme und Tabellen sind beispielsweise auch für IT-fremde Anwender leicht verständlich – und wesentlich übersichtlicher als etwa verschachtelte Bedingungen mittels “If-Then” im Programmcode. Gleichzeitig erlauben grafische Modelle die Abbildung von sehr komplexen Zusammenhängen, die etwa in Risikoprüfungen, Kreditentscheidungen, Compliance-Checks, etc bestehen.

Die folgenden Abbildungen zeigen Beispiele für grafische Modelle, die durch Fachbereiche erstellt werden können und die bereits den Teil im Softwareentwicklungsprozess darstellen. Beispiel 1 zeigt, wie fachliche Anforderungen einer Kreditentscheidung definiert werden (links), und wie die Fachlogik mit Hilfe einer Entscheidungstabelle implementiert wird (rechts).

Das folgende Beispiel 2 zeigt die Modellierung und Definition einer Preisberechnungslogik. Solche Geschäftsregeln können sehr umfangreich werden. Der visuelle Ansatz hilft Anwendern, den Überblick zu bewahren und sich schnell zurecht zu finden. Der Projektbaum auf der linken Seite unterstützt bei der Strukturierung und Organisation der verschiedenen Geschäftsregeln, die innerhalb eines Projekts genutzt werden.

Wir halten fest: Grafische Modelle erlauben es, komplexe technische Sachverhalte durch Abstraktion einer größeren Benutzergruppe (dem Fachbereich) zugänglich zu machen. Abstraktion geht zwar meist mit Einschränkungen im Funktionsumfang einher. Doch die fachlichen Aspekte eines Systems erfordern häufig nicht die ganze Mächtigkeit von Programmiersprachen.

Geeignete Toolsets unterstützen bei IT-Aufgaben

Fachbereichs-Enablement bedeutet keineswegs, dass Fachanwender zu IT-Experten ausgebildet werden. Mit der technischen Integration, mit komplexen Angelegenheiten wie Concurrency, Transaktionen, Ausfallsicherheit, etc. haben die Fachanwender weiterhin nichts zu tun. Dennoch geht das Fachbereichs-Enablement über die bloße Definition der Anforderungen und Fachlogik hinaus. Um echte Entkopplung und damit Business-Agilität zu erreichen, müssen Fachanwender durch entsprechende Toolsets auch über die Modellierung hinaus unterstützt werden: Und zwar beim Testen, Überwachen und Bereitstellen ihrer Fachlogik.

Wo der Schnitt zwischen Fachbereichs-Aufgaben und IT-Aufgaben genau liegt, unterscheidet sich in der Praxis von Projekt zu Projekt. So übernehmen Fachbereiche häufig die Modellierung und das Testen “ihrer” Fachlogik, während die IT die Qualitätssicherung, die Bereitstellung und das Monitoring übernimmt.

Fazit

Wenn die IT immer mehr zum Nadelöhr wird und die vielen Business-Anforderungen nicht  schnell genug umsetzen kann, sollten sich Unternehmen überlegen, welche IT-Aufgaben auch im Fachbereich stattfinden können. Folgende Fragen können dabei helfen, solche Aufgaben zu identifizieren und dadurch Business-Agilität auch in der Softwarearchitektur zu verankern:

• Welche Aspekte eines Systems sind geschäftskritisch oder -fördernd?
• Welche Aspekte werden häufig geändert (häufiger als die Release-Zyklen der Systeme)?
• Welche Aspekte erfordern besondere Transparenz (z. B. Compliance-Anforderungen)?
• Macht es Sinn, diese Aspekte direkt in der Fachabteilung zu pflegen?

Mittels Abstraktion, einem geeigneten Toolset, ein wenig Mut und Vertrauen können Unternehmen wesentlich agiler werden. Die raren IT-Fachkräfte können sich wirklich wichtigen Themen widmen, statt ständig neue Business-Spezifikationen umzusetzen. Fachbereiche gewinnen mehr Freiheit und sind in der Lage, ihr Business laufend zu verbessern, ohne auf die IT angewiesen zu sein. Dass dieser Ansatz für Business-Agilität Erfolg verspricht, konnten wir schon in Hunderten von Projekten feststellen.