56 HMD 290

Robert Krawatzeck, Michael Zimmer, Stefan Trahasch

Agile Business Intelligence
Definition, Manahmen und Herausforderungen
Agile Business Intelligence hat sich als einer der
Trends innerhalb der Business Intelligence (BI)
etabliert. Eine hohe BI-Agilitt lsst sich durch
die Kombination verschiedener Manahmen aus
den Bereichen Prinzipien, Vorgehensmodelle,
Entwicklungsmethoden und Technologie ver-
wirklichen. Diese sind je nach Unternehmensziel
unternehmensindividuell auszuwhlen und an-
zupassen. Offene Fragestellungen sind u. a., wie
der Grad an BI-Agilitt gemessen werden kann
und welche Auswirkungen ein hoher Grad an BI-
Agilitt auf die Geschftsprozesse und die IT-
Architektur eines Unternehmens hat.
Inhaltsbersicht
1 Motivation fr agile Lsungen
2 Business Intelligence und Agilitt
2.1 Einflussfaktoren und
Gestaltungsspielraum
2.2 Business-Intelligence-Agilitt
3 Manahmen zur Steigerung der Business-
Intelligence-Agilitt
3.1 Technische Manahmen
3.2 Organisatorische Manahmen
3.3 Wechselwirkungen zwischen
Manahmen und Unternehmen
4 Aktuelle Herausforderungen
5 Literatur
1 Motivation fr agile Lsungen
Die Dynamik in unterschiedlichsten Wirt-
schaftszweigen fordert von den Marktteilneh-
mern eine kontinuierliche Anpassung ihrer Ge-
schftsprozesse, um die Wettbewerbsfhigkeit
zu erhalten und auszubauen. Die hhere Dyna-
mik des Geschfts bedingt, dass Entscheidun-
gen hufiger und schneller zu treffen sind. Dies
erfordert eine hhere Flexibilitt und Adap-
tionsfhigkeit der dispositiven Systeme zur
Entscheidungsuntersttzung. Demgegenber
steigt durch die Dynamik die Komplexitt der
zu verarbeitenden Daten, was beispielsweise an
Form (strukturiert vs. unstrukturiert), Abhn-
gigkeit (Data Governance, Data Ownership, His-
torie) und Menge sichtbar ist. Sollen schnell an-
gemessene, integrierte, IT-basierte Gesamtl-
sungen zur betrieblichen Entscheidungsunter-
sttzung (Business-Intelligence-Lsungen [Kemper
et al. 2010]) geschaffen werden, stellen hohe
Anpassungsfhigkeit und steigende Komplexi-
tt eine Herausforderung dar.
Bei Anwendung etablierter Vorgehen zur
Softwareentwicklung, wie beispielsweise des
Wasserfallmodells oder inkrementeller Entwick-
lung, besteht die Gefahr, im dynamischen Um-
feld nicht zeitnah auf Anforderungen reagieren
zu knnen. Dies kann dazu fhren, dass die L-
sung bei der Auslieferung nicht mehr den vern-
derten Gegebenheiten entspricht und somit die
Erwartungshaltung der Anwender verfehlt. Um
eine permanente Vernderung in der Software-
entwicklung zu begegnen, haben sich im Soft-
ware Engineering agile Werte (Agiles Manifest
[Beck et al. 2001]) etabliert (vgl. hierzu auch den
Beitrag [von Brauk 2013] in diesem Heft):
! Individuen und Interaktionen mehr als Pro-
zesse und Werkzeuge
! Funktionierende Software mehr als umfas-
sende Dokumentation
! Zusammenarbeit mit dem Kunden mehr als
Vertragsverhandlung
! Reagieren auf Vernderung mehr als das Be-
folgen eines Plans
Aus diesen agilen Werten wurden agile Prozesse
(Vorgehensmodelle) wie Scrum und agile
Methoden wie Test Driven Development abge-
Agile Business Intelligence
HMD 290 57
leitet. Auerdem entstanden zwlf Prinzipien
fr agile Softwareentwicklung, wie beispiels-
weise: Unsere hchste Prioritt ist es, den Kun-
den durch frhe und kontinuierliche Ausliefe-
rung wertvoller Software zufrieden zu stellen
und Fachexperten und Entwickler mssen
whrend des Projektes tglich zusammenarbei-
ten [Beck et al. 2001].
Da sich Projekte zur Entwicklung von BI-
Anwendungen in wichtigen Punkten vom Soft-
ware Engineering im Rahmen klassischer
Anwendungsentwicklungsprojekte unterschei-
den, sind diese agilen Methoden und Vorgehens-
modelle nicht direkt auf die Welt der dispositiven
Systeme bertragbar. Unterschiede sind dabei
z.B. eine erschwerte Anforderungsanalyse, abtei-
lungsabhngige fachliche Begriffsdefinitionen
sowie eine hohe Vernetzung der abteilungsber-
greifenden beteiligten Systeme [Knig 2009].
Gleichzeitig werden BI-Anwendungen stark
durch die eingesetzten Werkzeuge reglemen-
tiert. Zustzlich werden BI-Lsungen einerseits
mithilfe von heterogenen BI-Werkzeugen (Da-
tenintegration, Datenhaltung, Analyse, Informa-
tionsbereitstellung) entwickelt, wobei diese Ent-
wicklung hauptschlich darin besteht, die einge-
setzte Standardsoftware zu parametrisieren und
zu konfigurieren. Andererseits erfordert bei-
spielsweise die Definition eines bereichsspezifi-
schen Datenraums (Data Mart, Cube) aufgrund
der hohen Fachlichkeit eine direkte Interaktion
mit dem Fachbereich und wird durch die Funktio-
nalitt des gewhlten BI-Werkzeugs einge-
schrnkt. Des Weiteren werden bei der BI-
Entwicklung oftmals langjhrig bestehende BI-
Lsungen erweitert und angepasst, um neue
analytische Fragestellungen beantworten zu
knnen. Herausforderungen sind dabei u. a. die
Beibehaltung der Historie von Daten und das er-
schwerte Refactoring aufgrund fehlender Funk-
tionskapselung mit standardisierten Program-
mierschnittstellen (APIs). Gibt es im Rahmen der
klassischen Softwareentwicklung ein fertiges
Endprodukt, handelt es sich bei der Entwicklung
von BI-Anwendungen um einen kontinuierlichen
Prozess zur Erfllung eines Informationsbedarfs
mit permanenten Anpassungen auch whrend
des Betriebs.
Agile Vorgehensmodelle und Methoden aus
dem Software Engineering sind daher nicht ohne
Weiteres auf Business Intelligence bertragbar,
jedoch scheinen die agilen Werte und Prinzipien,
wie z.B. Zusammenarbeit mit dem Kunden
mehr als Vertragsverhandlung und Reagieren
auf Vernderung mehr als das Befolgen eines
Plans, ein guter Ausgangspunkt zu sein, um
eine anpassungsfhige BI-Entwicklung unter Be-
rcksichtigung steigender Dynamik und Kom-
plexitt zu ermglichen [Zimmer et al. 2012].
2 Business Intelligence und Agilitt
Agile Entwicklungsanstze haben keinen Allein-
vertretungsanspruch. Nicht jeder Unterneh-
mensbereich mit den zugehrigen Geschftspro-
zessen unterliegt einer hohen Dynamik, sodass
hierfr agile Anstze mglicherweise nicht zwin-
gend notwendig sind und traditionelle Anstze
besser geeignet sein knnen. Die Notwendigkeit
und die Ausprgung der unternehmensspezifi-
schen Entwicklungsanstze mssen sich von der
Unternehmensstrategie, der Unternehmensphi-
losophie und -haltung ableiten lassen. Daher
wird im Folgenden erlutert, welcher Gestal-
tungsspielraum fr eine unternehmensindividu-
elle Ausprgung des BI-Betriebs unter Bercksich-
tigung verschiedener Einflussfaktoren existiert.
2.1 Einflussfaktoren und
Gestaltungsspielraum
Die Strategie eines Unternehmens legt fest, auf
welche Art und Weise die langfristigen Unter-
nehmensziele unter Bercksichtigung der unter-
nehmenseigenen Werte (Unternehmensphiloso-
phie) und Einstellungen (Unternehmenshal-
tung) erreicht werden knnen, wobei bei der
Zieldefinition externe Einflussfaktoren wie
Markt, Wettbewerber, Kunden, Partner und ge-
setzliche Rahmenbedingungen bercksichtigt
werden. Die Strategie wird in der Geschftsarchi-
Agile Business Intelligence
58 HMD 290
tektur konkretisiert, die die fachlichen Services,
die Geschftsprozesse sowie die Organisations-
struktur eines Unternehmens spezifiziert. Von
der Geschftsarchitektur wird wiederum die IT-
Architektur abgeleitet. Die BI-Architektur stellt
einen Teil dieser IT-Architektur dar. Zudem wird
Business Intelligence in einer BI-Aufbauorganisa-
tion und in BI-Prozessen operationalisiert.
Eine BI-Architektur als Bauplan eines Infor-
mationssystems zur Managementunterstt-
zung beschreibt das Zusammenspiel der Sys-
tembausteine Sie besteht beispielsweise aus
Komponenten wie Extraction, Transformation,
Load (ETL), einem Data Warehouse (DWH) oder
einem Data Mart. Die BI-Aufbauorganisation
umfasst hingegen Themengebiete wie die Un-
tersttzung des BI-Betriebs, beispielsweise
durch die Etablierung eines Business Intelli-
gence Competency Center (BICC) und zugehri-
ger Kontrollstrukturen. Bei einem BICC handelt
es sich um eine Organisationsform, die den Ein-
satz von BI im Unternehmen frdert und mit
entsprechenden Rollen und Prozessen unter-
sttzt. Die Ausgestaltung eines BICC ist unter-
nehmensindividuell und stark durch die Ar-
beitsteilung zwischen Fachbereich und IT ge-
prgt [Kemper et al. 2010]. Unter BI-Prozessen
werden die fr die Ablauforganisation relevan-
ten Prozesse verstanden. Hierbei handelt es sich
um einfache Change-Request-Prozesse, Prozesse
zur Erstellung von Reports durch Power User im
Fachbereich bis hin zu komplexen Prozessen zur
Weiterentwicklung eines DWH durch das BICC,
die IT und den Fachbereich.
Die unternehmensspezifischen Bereiche BI-
Architektur, BI-Aufbauorganisation und BI-Prozesse
definieren zusammen einen Gestaltungsspiel-
raum, innerhalb dessen der BI-Betrieb und die
BI-Evolution ausgestaltet werden knnen (vgl.
Abb. 1).
2.2 Business-Intelligence-Agilitt
Die Eigenschaft der Business Intelligence, vor-
hersehbare und unvorhersehbare Anforderun-
gen aufgrund einer wachsenden Dynamik und
Komplexitt in Bezug auf Funktionalitt oder
den Inhalt einer BI-Lsung in einem vorgegebe-
nen Zeitrahmen in angemessener Qualitt ab-
zubilden, wird als Business-Intelligence-(BI-)
Agilitt bezeichnet [Zimmer et al. 2012]. Dabei
sind sowohl die BI-Architektur, die BI-Aufbauor-
ganisation als auch die zugehrigen BI-Prozesse
zu betrachten. BI-Agilitt beinhaltet einerseits
eine Reaktion auf vorhersehbare Anforderun-
gen und andererseits das proaktive Unterstt-
zen von unvorhersehbaren Anforderungen.
Externe
Einflussfaktoren
U
n
t
e
r
n
e
h
m
e
n
s
t
r
a
te
gie, -ph
ilo
s
o
p
h
i
e
,
-
h
a
l
t
u
n
g
V
i
s
i
o
n
M
i
s
s
i
o
n
G
e
s
c
h

ftsarc
h
it
e
k
t
u
r
B
I
-
A
r
c
h
i
t
e
k
t
u
r
B
I
-
A
u
f
b
a
u
o
r
g
a
n
i
s
a
t
i
o
n
B
I - P
r o z e
s
s
e
m
o
d
e
l
l
e
M
e
t
h
o
d
e
n
P
r
in
z
i
p
i
e
n
T
e
c
h
n
o
l
o
g
i e
V
o
r
g
e
h
e
n
s
-
Abb. 1: Einflussfaktoren auf BI-Lsungen sowie der unternehmensindividuelle Gestaltungsspielraum fr
den BI-Betrieb
Agile Business Intelligence
HMD 290 59
IT-Agilitt lsst sich im Allgemeinen anhand ei-
ner unternehmensspezifischen Kombination
aus Kopplung, Redundanz, Parametrisierbarkeit
und Komplexitt messen [Nissen et al. 2012]. Im
Rahmen der BI mssen die bestehenden IT-Indi-
katoren validiert und ggf. angepasst sowie er-
gnzt werden, da aufgrund der BI-Spezifika ein
direktes bertragen nicht mglich ist.
Weiterhin bleibt zu klren, wie die Agilitt
bei bestehenden oder zu entwickelnden BI-
Lsungen bercksichtigt werden kann. Hierzu
werden alle Manahmen eines Unternehmens,
die durchgefhrt werden, um die BI-Agilitt zu
erhhen, unter dem Begriff Agile Business In-
telligence (Agile BI) zusammengefasst. Dabei
beschrnkt sich Agile BI nicht allein auf die
Auswahl und Anwendung eines agilen Vorge-
hensmodells zur Produktentwicklung, sondern
schliet zudem Manahmen aus den Bereichen
Prinzipien, Methoden und Technologie ein.
Die genannten Bereiche unterliegen eben-
falls, wie die Unternehmen selbst, externen Ein-
flussfaktoren und bedingen sich zustzlich unter-
einander. Diese Parameter sind daher fr Unter-
nehmen, die zur Erfllung ihrer Unternehmens-
ziele auf agile BI-Lsungen angewiesen sind,
unternehmensindividuell anzupassen.
Im Folgenden werden fr die einzelnen Be-
reiche exemplarisch mgliche Manahmen
dargestellt, mit deren Hilfe die Agilitt von BI-
Systemen gesteigert werden kann.
3 Manahmen zur Steigerung der
Business-Intelligence-Agilitt
Wie im vorherigen Abschnitt definiert, handelt
es sich bei BI-Agilitt um die Eigenschaften einer
BI-Architektur und einer BI-Aufbauorganisation
sowie der zugehrigen BI-Prozesse. Je nach Aus-
gestaltung bieten diese jeweils ein gewisses
Ma an Agilitt. Ein klassischer Core-DWH-
Ansatz mit festen Strukturen ohne Beteiligung des
Fachbereichs und einem Fokus auf reines Stan-
dardreporting bietet beispielsweise ein geringes
Ma an BI-Agilitt. Ein Ansatz mit Fachbereichs-
Sandboxes in Verbindung mit geregelten Prozes-
sen zur Weiterentwicklung des DWH oder der
Data Marts unter Einbindung der Fachbereiche
liefert hingegen ein hheres Ma an BI-Agilitt.
Neben architektonischen Manahmen kann
auch mit organisatorischen Manahmen inner-
halb eines streng reglementierten Ansatzes BI-
Agilitt geschaffen werden. So ist beispielsweise
die Anforderung nach schnellen Ad-hoc-Anfra-
gen entweder architektonisch durch Sandboxes
im Fachbereich oder organisatorisch durch ein
zentral organisiertes und spezialisiertes Analysten-
team erfllbar [Zimmer et al. 2012].
Innerhalb dieses grundlegenden architek-
tonischen und organisatorischen Rahmens kn-
nen geeignete Vorgehensmodelle zustzlich die
BI-Agilitt erhhen. Ein Vorgehensmodell zur
Produktentwicklung liefert Rahmenbedingun-
gen, indem es Rollen, Verantwortlichkeiten, Ab-
lufe und die zu erstellenden Artefakte defi-
niert. Ralph Hughes [Hughes 2008] und Ken
Collier [Collier 2011] zeigen mit ihren Verffentli-
chungen, dass eine Adaption von agilen Vorge-
hensmodellen fr die Domnen Data Warehou-
sing und Business Intelligence mglich ist, wo-
bei bei diesen Anstzen nicht bercksichtigt
wird, dass Unternehmen in der Regel langjhrig
bestehende BI-Lsungen und eine komplexe BI-
Architektur besitzen.
Im Sinne der Agile Business Intelligence ms-
sen nicht ausschlielich agile Vorgehensmodelle
wie Crystal, Extreme Programming oder Scrum
eingesetzt werden. Zur Steigerung der BI-Agilitt
knnen klassische Wasserfallmodelle zur Ent-
wicklung und Wartung von BI-Lsungen auch le-
diglich in einzelnen Entwicklungsphasen mit agi-
len Methoden umgesetzt werden.
3.1 Technische Manahmen
Agile Methoden lassen sich auf verschiedene
Weisen auf den Bereich BI und Unternehmen
unterschiedlicher Gre bertragen und kn-
nen, beispielsweise zur Anwendung in einzel-
nen Entwicklungsphasen des Wasserfallmo-
dells, kategorisiert werden in:
Agile Business Intelligence
60 HMD 290
A. Methoden, die flexible Architekturen ermg-
lichen (Designphase),
B. Methoden, die whrend der Produktent-
wicklung angewendet werden (Entwicklungs-
phase),
C. Methoden zur Qualittssicherung (Testphase)
und
D. Methoden zur kontinuierlichen Produkter-
stellung (Bereitstellungsphase).
In der Designphase lsst sich eine flexible BI-
Architektur beispielsweise durch den Einsatz
von Agile Modeling- und Agile Database-
Techniken, wie von Scott Ambler vorgeschlagen
[Ambler 2002], sowie durch die Anwendung des
Paradigmas der modellgetriebenen Software-
entwicklung auf den Bereich Data Warehouse
Engineering erreichen.
Um unter Bercksichtigung einer angemes-
senen Qualitt flexibel auf Anforderungen rea-
gieren zu knnen, lsst sich die Entwicklung von
DWH-Lsungen oder ETL-Prozessen als Unter-
punkt durch Anwendung der Methoden Pair
Programming, Test Driven Development (TDD)
und kontinuierliches Refactoring agil gestalten.
Des Weiteren kann der Produktbereitstel-
lungsprozess (Build and Deploy) zur Sicherstel-
lung eines stets einsatzfhigen Produkts trotz
stndiger Anpassungen durch Anstze wie
Continuous Integration (CI) oder des erweiter-
ten CI-Ansatzes Continuous Delivery vollkom-
men automatisiert und beschleunigt werden.
Alle diese Methoden fhren jedoch nur
dann in einem angemessenen Zeitrahmen zu
zuverlssigen Ergebnissen, wenn nach nde-
rungen die notwendige Qualittsprfung zur
Gewhrleistung der Korrektheit von vorab vor-
handenen und neuen Funktionalitten zum
Groteil mit automatisierten Tests durchge-
fhrt wird.
Eine weitere, noch zu prfende Mglichkeit,
die BI-Agilitt zu steigern, liegt in der geschick-
ten Auswahl von leistungsfhigen, flexiblen
Technologien, die die technische Basis der un-
ternehmenseigenen BI-Lsung bilden. Techno-
logien wie BI in the Cloud ermglichen bei-
spielsweise ein schnelles Bereitstellen von neu-
en Funktionalitten, Werkzeugen oder Sand-
boxes als Cloud-Services. Diese Steigerung der
Flexibilitt birgt allerdings auch das Risiko, In-
sellsungen weiter zu frdern, da sich diese so
noch einfacher und verborgener aufbauen las-
sen als bisher [Baars & Qie 2012].
3.2 Organisatorische Manahmen
Neben allen genannten technischen Manah-
men ist die BI-Agilitt ebenso durch eine ver-
besserte Unternehmensorganisation zu stei-
gern, wie beispielsweise durch eine engere Ver-
zahnung der Fach- und IT-Abteilung sowie eine
im Unternehmen verankerte und intensiv ge-
lebte Feedbackkultur. Hierfr ist die Einrichtung
eines BICC als Vermittler der verschiedenen In-
teressengruppen denkbar [Baars et al. 2009].
Obwohl Begriffe wie Continous Delivery,
automatisierte Tests oder Pair Program-
ming im Rahmen der BI bisher wenig verbrei-
tet sind, wurden diese Praktiken bereits in der
Vergangenheit in der BI-Entwicklung einge-
setzt. Beispielsweise hat im Jahr 2006 eine
deutschsprachige Bankengruppe eine von Gart-
ner prmierte und auf diesen Methoden beru-
hende Lsung im Active Portfolio Management
des Investmentbankings eingefhrt [Unterneh-
mergesprch 2008]. Ziel dieser Lsung war die
untertgige Anbindung von Daten bei gleich-
zeitiger untertgiger Bereitstellung der zuge-
hrigen Berichte. Dazu wurde ein Pair Program-
ming zwischen IT und Fachbereich etabliert.
Diese direkte Zusammenarbeit ohne rumliche
Trennung der BI-Entwickler mit den Analysten
im Fachbereich stellt eine organisatorische n-
derung dar. Neben dieser organisatorischen
Manahme wurden zudem die Architekturen
und Prozesse zur untertgigen Produktivset-
zung von ETL-Prozessen, Datenstrukturen und
Reports in Form eines vollstndig automatisier-
ten Deployments inklusive einer Umgebung fr
automatisierte Tests mithilfe geeigneter tech-
nischer Manahmen umgesetzt.
Agile Business Intelligence
HMD 290 61
3.3 Wechselwirkungen zwischen
Manahmen und Unternehmen
Alle vom Unternehmen getroffenen Entschei-
dungen bezglich Agile BI beeinflussen wie-
derum das Unternehmen selbst. So ist fr einen
ausgereiften Continuous Integration-Ansatz
neben einem Produktivsystem eine dedizierte
Testumgebung erforderlich. Die Anwendung
des Paradigmas der modellgetriebenen Soft-
wareentwicklung in Form von bereits existieren-
den DWH-Generatoren beispielsweise biGenius
(trivadis GmbH), metaBI (Cimacon GmbH) oder
timeXtender (timeXtender Holding) setzt spezi-
elle Repositories voraus, in denen die erstellten
Modelle gespeichert und weiterverarbeitet wer-
den. Dabei ist zu beachten, dass diese Abhngig-
keit bidirektional ist. Hat ein Unternehmen bei-
spielsweise nicht die Mglichkeit, bentigte
Infrastrukturkomponenten zur Verfgung zu
stellen, kommen fr dieses Unternehmen nicht
alle Manahmen zur Steigerung der BI-Agilitt
infrage. Eine Entscheidung fr eine bis dahin
noch nicht umsetzbare automatisierte Produkt-
bereitstellungsmethode zieht nderungen in
der BI-Architektur sowie in der BI-Aufbauorgani-
sation und deren Prozesse nach sich. Dabei han-
delt es sich beispielsweise um neue Releaseab-
lufe mit neuen Unternehmensrollen, die die
Verantwortung fr die neuen Testumgebungen
tragen. Dies wiederum bedingt, dass die Fach-
lichkeit des Unternehmens um das Wissen fr
die neuen Aufgaben steigt und ein Umdenken in
der Unternehmensphilosophie im Sinne der
agilen Werte [Beck et al. 2001] stattfindet. In Ab-
bildung 2 sind einzelne Methoden mit ihren Aus-
wirkungen auf die unterschiedlichen Ebenen exem-
plarisch dargestellt.
Eine kundenorientierte Ausrichtung und of-
fene Kommunikation sowie die mit BI-Agilitt
einhergehende Mglichkeit, flexibel und zeitnah
auf Anforderungen zu reagieren, ermglichen es
Unternehmen, die Softwarequalitt zu steigern,
Entscheidungen schneller treffen zu knnen, sich
besonders am Markt zu positionieren und einen
frheren Return on Investment zu erzielen.
4 Aktuelle Herausforderungen
Aufgrund der Unterschiede in der Entwicklung
von klassischen Softwareanwendungen zu BI-
Anwendungen gibt es eine Reihe von Herausfor-
derungen im BI-Kontext, die adressiert werden
mssen, sodass BI-Agilitt und Agile BI ein ak-
tuelles und eigenstndiges Forschungsfeld dar-
stellen. Im Folgenden werden einige dieser Her-
ausforderungen nher erlutert, wobei diese Lis-
te keinen Anspruch auf Vollstndigkeit erhebt.
Das von Kent Beck vorgeschlagene Test
Driven Development (TDD) ist eine etablierte
Methode in der Softwareentwicklung, die zur
Verbesserung der Qualitt von Anwendungen
beitrgt. Ein wesentlicher Bestandteil von TDD
stellt das Unit Testing dar, bei dem die Funktio-
nalitt einzelner Komponenten vom Gesamt-
system losgelst getestet wird. Es stellt sich die
Frage, wie diese grundlegende Methode auf die
Entwicklung von BI-Anwendungen transferiert
und adaptiert werden kann. Dabei ist von Inter-
esse, was in BI-Lsungen einer zu testenden
Unit entspricht und wie sich diese Units in den
unterschiedlichen Ebenen wie Datenintegration,
Datenhaltung, Analyse und Informations-
bereitstellung unterscheiden. Ein weiterer we-
sentlicher Bestandteil von TDD stellt das konti-
nuierliche Refactoring dar. Dabei wird ein
Refactoring dann durchgefhrt, wenn soge-
nannte Code-Smells [Martin 2009] im Quell-
code auftreten, die in der Regel auf einen
schlecht geschriebenen Programmcode hinwei-
sen. Es bleibt zu untersuchen, welche Code-
Smells typischerweise in BI-Anwendungen
auftreten und mit welchem Refactoring diese
zu beseitigen sind. Des Weiteren ist es zur
Sicherstellung der Qualitt von BI-Anwendungen
bei erhhter Agilitt zwingend notwendig, Test-
verfahren wie Unit Tests, Integrations- und Ak-
zeptanztests methodisch weiterzuentwickeln
und Werkzeuge zur Automatisierung dieser
Tests zu realisieren.
Die flexible Ausrichtung der BI-Architektur
fhrt ebenso zu neuen Herausforderungen. Der
agile Wert laufende Software ber umfangrei-
Agile Business Intelligence
62 HMD 290
che Dokumentation [Beck et al. 2001] stellt bei
sich stets wandelnden Architekturen einen Wi-
derspruch zu der Entscheidung dar, qualitativ
hochwertige Dokumentationen im Sinne eines
guten Qualittsmanagements zu erzeugen.
Solche scheinbaren Widersprche gilt es, durch
neue Lsungswege zu beseitigen, indem bei-
spielsweise BI-Systeme vollkommen automati-
siert dokumentiert werden [Krawatzeck et al.
2011]. Neben der Auflsung scheinbarer Wider-
sprche gilt es des Weiteren, die durch die Aus-
wahl bestimmter Manahmen gegebenenfalls
entstehenden Synergieeffekte zu identifizieren
und zu nutzen. So kann die Entscheidung fr
eine umfangreiche Qualittssicherung durch
automatisierte Tests und durch die Anwendung
des Paradigmas der modellgetriebenen Soft-
wareentwicklung zur Umsetzung einer flexib-
len BI-Architektur, beispielsweise in Form von
modellgetriebenen automatisierten Software-
tests, kombiniert werden.
Die unternehmensspezifische Gestaltung
von Business Intelligence wirkt prgend auf die
Geschftsarchitektur und somit indirekt auch
auf die Unternehmensstrategie. Ein hoher Grad
an BI-Agilitt ermglicht und frdert beispiels-
weise die schnelle Anpassung von Prozessen.
Daher ist zu untersuchen, welche Wechselwir-
kungen zwischen Gestaltungszielen, wie bei-
spielsweise Kosteneffizienz, Agilitt oder Inno-
vation, fr Business Intelligence bestehen und
welche Auswirkungen ein hoher Grad an BI-
Agilitt auf die Geschftsprozesse oder die IT-
Architektur eines Unternehmens hat. Dies setzt
wiederum voraus, dass sich der Grad der BI-
Agilitt einer BI-Lsung messen lsst. Hierfr ist
die Definition von geeigneten Indikatoren fr
die Messung der BI-Agilitt notwendig.
5 Literatur
[Ambler 2002] Ambler, S.: Agile Modeling: Effective
Practices for eXtreme Programming and the
Unified Process. Wiley & Sons, New York, 2002.
[Baars & Qie 2012] Baars, H.; Qie, L.: Studie BI in the
Cloud: Die Cloud als neuer Ansatz zur Erhhung
der BI-Agilitt?. BI-Spektrum 7 (2012), 2, S. 26-29.
Design
Modellgetriebene
Softwareentwicklung
automatische
Generierung von
Code-/Konfigura-
tionsdateien
Pair Programming
.
Entwicklung
ETL-Strecken von
zwei Entwicklern
Definition Daten-
raum von Entwickler
und Fachanwender
Automatisierte
Tests
Regressionstests
Continuous
Integration
automatisierter Build
(Vorkonfiguration)
automatisierte
Testausfhrung
Entwicklung Test Bereitstellung
- Modell-Repository
bereitstellen
- CI-Server
bereitstellen
- Testumgebung
bereitstellen
- Testsystem
bereitstellen
BI-Architektur
- Verantwortlichkeit
Modell-Repository
benennen
- engere Verzahnung
von Fach- und
IT-Abteilung
- Verantwortlichkeit
CI-Server benennen
- Verantwortlichkeit
Testumgebung
benennen
- Verantwortlichkeit
Testsystem
benennen
BI-Aufbau-
organisation
- Integration des
Modell-Repository
in BI-Designprozess
- Untersttzungs-
prozesse fr
fachbereichsnahe
Entwicklung
- neue Releaseablufe
- Erweiterung
Entwicklungsprozess
um Testprozesse
BI-Prozesse
Methoden:
Einfluss auf:
Wasserfall-
modellphasen:
Abb. 2: Manahmen zur Steigerung der BI-Agilitt im Bereich Methoden sowie deren Einfluss auf die
BI-Architektur, BI-Aufbauorganisation und BI-Prozesse
Agile Business Intelligence
HMD 290 63
[Baars et al. 2009] Baars, H.; Zimmer, M.; Kemper, H.-G.:
The Business Intelligence Competence Centre
as an Interface between IT and User Depart-
ment in Maintenance and Release Develop-
ment. Proceedings of the 17th European Confe-
rence on Information Systems (ECIS2009),
Verona, 2009.
[Beck et al. 2001] Beck, K.; Beedle, M.; van Bennekum, A.;
Cockburn, A.; Cunningham, W.; Fowler, M.;
Grenning, J.; Highsmith, J.; Hunt, A.; Jeffries, R.;
Kern, J.; Marick, B.; Martin, R. C.; Mellor, S.;
Schwaber, K.; Sutherland, J.; Thomas, D.: Mani-
fest fr Agile Softwareentwicklung, http://agile-
manifesto.org/ iso/de/; Zugriff am 30.09.2012.
[von Brauk 2013] von Brauk, S.: Zurckeroberung der
Zukunft Chancen agiler IT. HMD Praxis der
Wirtschaftsinformatik 50 (2013), 290, S. 6-16.
[Collier 2011] Collier, K. W.: Agile Analytics: A Value-
Driven Approach to Business Intelligence and
Data Warehousing. Addison-Wesley, Upper
Saddle River, 2011.
[Hughes 2008] Hughes, R.: Agile Data Warehou-
sing: Delivering World-Class Business Intelli-
gence Systems Using Scrum and XP. iUniverse,
New York, 2008.
[Kemper et al. 2010] Kemper, H.-G.; Mehanna, W.;
Unger, C.: Business Intelligence Grundlagen
und praktische Anwendungen: Eine Einfh-
rung in die IT-basierte Managementunterstt-
zung. 3. berarbeitete Aufl., Vieweg Verlag,
Wiesbaden, 2010.
[Knig 2009] Knig, S.: Ein Wiki-basiertes Vorgehens-
modell fr Business Intelligence Projekte. Tagungs-
band des Forschungskolloquiums Business Intelli-
gence (FKBI09), Dortmund, 2009, S. 33-51.
[Krawatzeck et al. 2011] Krawatzeck, R.; Jacobi, F.;
Mller, A.; Hofmann, M.: Konzeption eines
Frameworks zur automatisierten Erstellung
nutzerspezifischer IT-Systemdokumentationen.
Tagungsband zum Workshop Business Intelli-
gence 2011 (WSBI11), Stuttgart, 2011, S. 15-23.
[Martin 2009] Martin, R. C.: Clean Code: Refacto-
ring, Patterns, Testen und Techniken fr saube-
ren Code. mitp, Heidelberg, 2009.
[Nissen et al. 2012] Nissen, V.; von Rennkampff, A.;
Termer, F.: IT-Architektur als Ma fr die IT-
Agilitt. Tagungsband der Multikonferenz Wirt-
schaftsinformatik 2012 (MKWI'12), Braunschweig,
2012, S. 931-942.
[Unternehmergesprch 2008] Stuttgarter Unter-
nehmergesprch 2008 der Universitt Stutt-
gart: Organisation, Prozesse und Technologien
fr eine Agile Business Intelligence, www.bwi.
uni-stuttgart.de/index.php?id=3617; Zugriff am
01.10.2012.
[Zimmer et al. 2012] Zimmer, M.; Baars, H.; Kemper,
H.-G.: The Impact of Agility Requirements on
Business Intelligence Architectures. Procee-
dings of the 45th Hawaii International Confe-
rence on System Sciences (HICSS'12). Maui,
Hawaii, USA, 2012, pp. 4189-4198.
Dipl.-Inf. Robert Krawatzeck
Technische Universitt Chemnitz
Professur Wirtschaftsinformatik II
09107 Chemnitz
robert.krawatzeck@
wirtschaft.tu-chemnitz.de
www.tu-chemnitz.de/wirtschaft/
wi2/wp
Michael Zimmer M.Sc.
Universitt Stuttgart
BWI Abteilung VII
Lehrstuhl fr Wirtschaftsinformatik I
Keplerstr. 17
70174 Stuttgart
zimmer@wi.uni-stuttgart.de
www.bwi.uni-stuttgart.de
Prof. Dr. Stephan Trahasch
Hochschule Offenburg
Fakultt Elektrotechnik und
Informationstechnik
Badstr. 24
77652 Offenburg
stephan.trahasch@hs-offenburg.de
http://ei.hs-offenburg.de
Krawatzeck, R.; Zimmer, M.; Trahasch, S.: Agile Business Intelligence Definition, Manahmen und Herausforderungen.
HMD Praxis der Wirtschaftsinformatik 50 (2013), 290, S. 56-63.