Agile Business Intelligence Definition, Maßnahmen und Herausforderungen

Transkript

1 The final publication is available at link.springer.com: Robert Krawatzeck, Michael Zimmer, Stephan Trahasch Agile Business Intelligence Definition, Maßnahmen und Herausforderungen Stichwörter Agile Business Intelligence, Agile BI, BI-Agilität, Agilität Abstract Agile Business Intelligence hat sich als einer der Trends innerhalb der Business Intelligence (BI) etabliert. Eine hohe BI-Agilität lässt sich durch die Kombination verschiedener Maßnahmen aus den Bereichen Prinzipien, Vorgehensmodelle, Entwicklungsmethoden und Technologie verwirklichen. Diese sind je nach Unternehmensziel unternehmensindividuell auszuwählen und anzupassen. Offene Fragestellungen sind u.a., wie der Grad an BI-Agilität gemessen werden kann und welche Auswirkungen ein hoher Grad an BI-Agilität auf die Geschäftsprozesse und die IT-Architektur eines Unternehmens hat. Inhaltsübersicht 1. Motivation für agile Lösungen 2. Business Intelligence und Agilität 2.1 Einflussfaktoren und Gestaltungsspielraum 2.2 BI-Agilität 3. Maßnahmen zur Steigerung der BI-Agilität 3.1 Technische Maßnahmen 3.2 Organisatorische Maßnahmen 3.3 Wechselwirkungen zwischen Maßnahmen und Unternehmen 4. Aktuelle Herausforderungen 5. Literatur 1. Motivation für agile Lösungen Die Dynamik in unterschiedlichsten Wirtschaftszweigen fordert von den Marktteilnehmern eine kontinuierliche Anpassung ihrer Geschäftsprozesse, um die Wettbewerbsfähigkeit zu erhalten und auszubauen. Die höhere Dynamik des Geschäfts bedingt, dass Entscheidungen häufiger und schneller zu treffen sind. Dies erfordert eine höhere Flexibilität und Adaptionsfähigkeit der dispositiven Systeme zur Entscheidungsunterstützung. Demgegenüber steigt durch die Dynamik die Komplexität der zu verarbeitenden Daten, was bspw. an Form (strukturiert vs. 1

2 unstrukturiert), Abhängigkeit (Data Governance, Data Ownership, Historie) und Menge sichtbar ist. Sollen schnell angemessene, integrierte, IT-basierte Gesamtlösungen zur betrieblichen Entscheidungsunterstützung (Business Intelligence Lösungen (BI-Lösungen) [vgl. Kemper et al. 2010]) geschaffen werden, stellen hohe Anpassungsfähigkeit und steigende Komplexität eine Herausforderung dar. Bei Anwendung etablierter Vorgehen zur Softwareentwicklung, wie bspw. Wasserfall oder inkrementeller Entwicklung, besteht die Gefahr, im dynamischen Umfeld nicht zeitnah auf Anforderungen reagieren zu können. Dies kann dazu führen, dass die Lösung bei der Auslieferung nicht mehr den veränderten Gegebenheiten entspricht und somit die Erwartungshaltung der Anwender verfehlt. Um eine permanente Veränderung in der Softwareentwicklung zu begegnen, haben sich im Software Engineering agile Werte ( Agile Manifesto [Beck et al. 2001]) etabliert (vgl. hierzu auch den Beitrag Zurückeroberung der Zukunft Chancen agiler IT von Stefan von Brauk in diesem Heft): Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung [und] Reagieren auf Veränderung mehr als das Befolgen eines Plans. Aus diesen agilen Werten wurden agile Prozesse (Vorgehensmodelle) wie Scrum und agile Methoden wie Test-Driven Development abgeleitet. Außerdem entstanden zwölf Prinzipien für agile Softwareentwicklung, wie beispielsweise: [ ] die höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen und Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten [Beck et al. 2001]. Da sich Projekte zur Entwicklung von BI-Anwendungen in wichtigen Punkten vom Software Engineering im Rahmen klassischer Anwendungsentwicklungsprojekte unterscheiden, sind diese agilen Methoden und Vorgehensmodelle nicht direkt auf die Welt der dispositiven Systeme übertragbar. Unterschiede sind dabei beispielsweise eine erschwerte Anforderungsanalyse, abteilungsabhängige fachliche Begriffsdefinitionen sowie eine hohe Vernetzung der abteilungsübergreifenden beteiligten Systeme [König 2009]. Gleichzeitig werden BI-Anwendungen stark durch die eingesetzten Werkzeuge reglementiert. Zusätzlich werden BI-Lösungen einerseits mit Hilfe von heterogenen BI-Werkzeugen (Datenintegration, Datenhaltung, Analyse, Informationsbereitstellung) entwickelt, wobei diese Entwicklung hauptsächlich darin besteht, die eingesetzte Standardsoftware zu parametrisieren und zu konfigurieren. Andererseits erfordert bspw. die Definition eines bereichsspezifischen Datenraums (Data-Mart, Cube) aufgrund der hohen Fachlichkeit eine direkte Interaktion mit dem Fachbereich und wird durch die Funktionalität des gewählten BI-Werkzeugs eingeschränkt. Des Weiteren werden bei der BI-Entwicklung oftmals langjährig bestehende BI-Lösungen erweitert und angepasst, um neue analytische Fragestellungen beantworten zu können. Herausforderungen sind dabei u.a. die Beibehaltung der Historie von Daten und das erschwerte Refactoring aufgrund fehlender Funktionskapselung mit standardisierten Programmierschnittstellen (APIs). Gibt es im Rahmen der klassischen Softwareentwicklung ein 2

3 fertiges Endprodukt, handelt es sich bei der Entwicklung von BI-Anwendungen um einen kontinuierlichen Prozess zur Erfüllung eines Informationsbedarfs mit permanenten Anpassungen auch während 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 zum Beispiel Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung und Reagieren auf Veränderung mehr als das Befolgen eines Plans, ein guter Ausgangspunkt zu sein, um eine anpassungsfähige BI-Entwicklung unter Berücksichtigung steigender Dynamik und Komplexität zu ermöglichen [Zimmer et al. 2012]. 2. Business Intelligence und Agilität Agile Entwicklungsansätze haben keinen Alleinvertretungsanspruch. Nicht jeder Unternehmensbereich mit den zugehörigen Geschäftsprozessen unterliegt einer hohen Dynamik, sodass hierfür agile Ansätze möglicherweise nicht zwingend notwendig sind und traditionelle Ansätze besser geeignet sein können. Die Notwendigkeit und die Ausprägung der unternehmensspezifischen Entwicklungsansätze müssen sich von der Unternehmensstrategie, der Unternehmensphilosophie und -haltung ableiten lassen. Daher wird im Folgenden erläutert, welcher Gestaltungsspielraum für eine unternehmensindividuelle Ausprägung des BI-Betriebs unter Berücksichtigung verschiedener Einflussfaktoren existiert Einflussfaktoren und Gestaltungsspielraum Die Strategie eines Unternehmens legt fest, auf welche Art und Weise die langfristigen Unternehmensziele unter Berücksichtigung der unternehmenseigenen Werte (Unternehmensphilosophie) und Einstellungen (Unternehmenshaltung) erreicht werden können, wobei bei der Zieldefinition externe Einflussfaktoren wie Markt, Wettbewerber, Kunden, Partner und gesetzliche Rahmenbedingungen berücksichtigt werden. Die Strategie wird in der Geschäftsarchitektur konkretisiert, welche die fachlichen Services, die Geschäftsprozesse sowie die Organisationsstruktur eines Unternehmens spezifiziert. Von der Geschäftsarchitektur wird wiederum die IT-Architektur abgeleitet. Die BI-Architektur stellt einen Teil dieser IT- Architektur dar. Zudem wird Business Intelligence in einer BI-Aufbauorganisation und in BI- Prozessen operationalisiert. Eine BI-Architektur als Bauplan eines Informationssystems zur Managementunterstützung beschreibt das Zusammenspiel der Systembausteine Sie umfasst beispielswese Komponenten wie Extraction, Transformation, Load (ETL), ein Data Warehouse (DWH) oder einen Data-Mart. Die BI-Aufbauorganisation umfasst hingegen Themengebiete wie die Unterstützung des BI- Betriebes, beispielsweise durch die Etablierung eines Business Intelligence Competency Centers (BICCs) und zugehöriger Kontrollstrukturen. Bei einem BICC handelt es sich um eine Organisationsform, die den Einsatz von BI im Unternehmen fördert und mit entsprechenden Rollen und Prozessen unterstützt. Die Ausgestaltung eines BICCs ist unternehmensindividuell und stark durch die Arbeitsteilung zwischen Fachbereich und IT geprägt [Kemper et al. 2010]. Unter BI-Prozessen werden die für die Ablauforganisation relevanten Prozesse verstanden. 3

4 Hierbei handelt es sich von einfachen Change-Request-Prozessen über Prozesse zur Erstellung von Reports durch Power User im Fachbereich bis hin zu komplexen Prozessen zur Weiterentwicklung eines DWHs durch das BICC, die IT und den Fachbereich. Die unternehmensspezifischen Bereiche BI-Architektur, BI-Aufbauorganisation und BI-Prozesse definieren zusammen einen Gestaltungsspielraum, innerhalb dessen der BI-Betrieb und die BI- Evolution ausgestaltet werden können (vgl. Abb. 1). Abbildung 1: Einflussfaktoren auf Business Intelligence Lösungen sowie der unternehmensindividuelle Gestaltungsspielraum für den BI-Betrieb BI-Agilität Die Eigenschaft der Business Intelligence, vorhersehbare und unvorhersehbare Anforderungen aufgrund einer wachsenden Dynamik und Komplexität in Bezug auf Funktionalität oder den Inhalt einer BI-Lösung in einem vorgegebenen Zeitrahmen in angemessener Qualität abzubilden, wird als BI-Agilität bezeichnet [Zimmer et al. 2012]. Dabei sind sowohl die BI- Architektur, die BI-Aufbauorganisation als auch die zugehörigen BI-Prozesse zu betrachten. BI- Agilität beinhaltet einerseits eine Reaktion auf vorhersehbare Anforderungen und andererseits das proaktive Unterstützen von unvorhersehbaren Anforderungen. IT-Agilität lässt sich im Allgemeinen anhand einer unternehmensspezifischen Kombination aus Kopplung, Redundanz, Parametrisierbarkeit und Komplexität messen [Nissen et al. 2012]. Im Rahmen der BI müssen die bestehenden IT-Indikatoren validiert und ggf. angepasst sowie ergänzt werden, da aufgrund der BI-Spezifika ein direktes Übertragen nicht möglich ist. 4

5 Weiterhin bleibt zu klären, wie die Agilität bei bestehenden oder zu entwickelnden BI-Lösungen berücksichtigt werden kann. Hierzu werden alle Maßnahmen eines Unternehmens, welche durchgeführt werden, um die BI-Agilität zu erhöhen, unter dem Begriff Agile Business Intelligence (Agile BI) zusammengefasst. Dabei beschränkt sich Agile BI nicht allein auf die Auswahl und Anwendung eines agilen Vorgehensmodells zur Produktentwicklung, sondern schließt zudem Maßnahmen aus den Bereichen Prinzipien, Methoden und Technologie ein. Die genannten Bereiche unterliegen ebenfalls, wie die Unternehmen selbst, externen Einflussfaktoren und bedingen sich zusätzlich untereinander. Diese Parameter sind daher für Unternehmen, die zur Erfüllung ihrer Unternehmensziele auf agile BI-Lösungen angewiesen sind, unternehmensindividuell anzupassen. Im Folgenden werden für die einzelnen Bereiche exemplarisch mögliche Maßnahmen dargestellt, mit deren Hilfe die Agilität von BI-Systemen gesteigert werden kann. 3. Maßnahmen zur Steigerung der BI-Agilität Wie im vorherigen Kapitel definiert, handelt es sich bei BI-Agilität um die Eigenschaften einer BI-Architektur und einer BI-Aufbauorganisation sowie der zugehörigen BI-Prozesse. Je nach Ausgestaltung bieten diese jeweils ein gewisses Maß an Agilität. Ein klassischer Core-DWH- Ansatz mit festen Strukturen ohne Beteiligung des Fachbereichs und einem Fokus auf reines Standardreporting bietet beispielsweise ein geringes Maß an BI-Agilität. Ein Ansatz mit Fachbereichssandboxes in Verbindung mit geregelten Prozessen zur Weiterentwicklung des DWHs oder der Data-Marts unter Einbindung der Fachbereiche liefert hingegen ein höheres Maß an BI-Agilität. Neben architektonischen Maßnahmen kann auch mit organisatorischen Maßnahmen innerhalb eines streng reglementierten Ansatzes BI-Agilität geschaffen werden. So ist beispielsweise die Anforderung nach schnellen Ad-hoc-Anfragen entweder architektonisch durch Sandboxes im Fachbereich oder organisatorisch durch ein zentral organisiertes und spezialisiertes Analystenteam erfüllbar [Zimmer et al. 2012]. Innerhalb dieses grundlegenden architektonischen und organisatorischen Rahmens können geeignete Vorgehensmodelle zusätzlich die BI-Agilität erhöhen. Ein Vorgehensmodell zur Produktentwicklung liefert Rahmenbedingungen, indem es Rollen, Verantwortlichkeiten, Abläufe und die zu erstellenden Artefakte definiert. Ralph Hughes (Agile Data Warehouseing; [Hughes 2008]) und Ken Collier (Agile Analytics; [Collier 2011]) zeigen mit ihren Veröffentlichungen dass eine Adaption von agilen Vorgehensmodellen für die Domänen Data Warehousing und Business Intelligence möglich ist, wobei bei diesen Ansätzen nicht berücksichtigt wird, dass Unternehmen in der Regel langjährig bestehende BI-Lösungen und eine komplexe BI- Architektur besitzen. Im Sinne der Agile Business Intelligence müssen nicht ausschließlich agile Vorgehensmodelle wie Crystal, Extreme Programming oder Scrum eingesetzt werden. Zur Steigerung der BI- Agilität können klassische Wasserfallmodelle zur Entwicklung und Wartung von BI-Lösungen auch lediglich in einzelnen Entwicklungsphasen mit agilen Methoden umgesetzt werden. 5

6 3.1. Technische Maßnahmen Agile Methoden lassen sich auf verschiedene Weisen auf den Bereich BI und Unternehmen unterschiedlicher Größe übertragen und können, beispielsweise zur Anwendung in einzelnen Entwicklungsphasen des Wasserfallmodells, kategorisiert werden in: a) Methoden, die flexible Architekturen ermöglichen (Design-Phase), b) Methoden, die während der Produktentwicklung angewendet werden (Entwicklungs- Phase), c) Methoden zur Qualitätssicherung (Test-Phase) und d) Methoden zur kontinuierlichen Produkterstellung (Bereitstellungs-Phase). In der Design-Phase lässt sich eine flexible BI-Architektur beispielsweise durch den Einsatz von Agile Modeling - und Agile Database -Techniken, wie von Scott Ambler vorgeschlagen [Ambler 2002], sowie der Anwendung des Paradigmas der modellgetriebenen Softwareentwicklung auf den Bereich Data Warehouse Engineering erreichen. Um unter Berücksichtigung einer angemessenen Qualität flexibel auf Anforderungen reagieren zu können, lässt sich die Entwicklung von DWH-Lösungen oder ETL-Prozessen als Unterpunkt durch Anwendung der Methoden Pair Programming, Test-Driven Development (TDD) und kontinuierliches Refactoring agil gestalten. Des Weiteren kann der Produktbereitstellungsprozess ( Build and Deploy ) zur Sicherstellung eines stets einsatzfähigen Produktes trotz ständiger Anpassungen durch Ansätze wie Continuous Integration (CI) oder des erweiterten CI-Ansatzes Continuous Delivery vollkommen automatisiert und beschleunigt werden. Alle diese Methoden führen jedoch nur dann in einem angemessenen Zeitrahmen zu zuverlässigen Ergebnissen, wenn nach Änderungen die notwendige Qualitätsprüfung zur Gewährleistung der Korrektheit von vorab vorhandenen und neuen Funktionalitäten zum Großteil mit automatisierten Tests durchgeführt wird. Eine weitere, noch zu prüfende Möglichkeit, die BI-Agilität zu steigern, liegt in der geschickten Auswahl von leistungsfähigen, flexiblen Technologien, die die technische Basis der unternehmenseigenen BI-Lösung bilden. Technologien wie BI in the Cloud ermöglichen bspw. ein schnelles Bereitstellen von neuer Funktionalitäten, Werkzeugen oder Sandboxes als Cloud- Service. Diese Steigerung der Flexibilität birgt allerdings auch das Risiko Insellösungen weiter zu fördern, da sich diese so noch einfacher und verborgener aufbauen lassen als bisher [Baars & Qie 2012] Organisatorische Maßnahmen Neben allen genannten technischen Maßnahmen ist die BI-Agilität ebenso durch eine verbesserte Unternehmensorganisation zu steigern, wie beispielsweise durch eine engere Verzahnung der Fach- und IT-Abteilung sowie eine im Unternehmen verankerte und intensiv gelebte Feedbackkultur. Hierfür ist die Einrichtung eines BICCs als Vermittler der verschiedenen Interessensgruppen denkbar [Baars et al. 2009]. 6

7 Obwohl Begriffe wie Continous Delivery, automatisierte Tests oder Pair Programming im Rahmen der BI bisher wenig verbreitet sind, wurden diese Praktiken bereits in der Vergangenheit in der BI-Entwicklung eingesetzt. Beispielsweise hat im Jahr 2006 eine deutschsprachige Bankengruppe eine von Gartner prämierte und auf diesen Methoden beruhende Lösung im Active Portfolio Management des Investmentbankings eingeführt [Unternehmergespräch 2008]. Ziel dieser Lösung war die untertägige Anbindung von Daten bei gleichzeitiger untertägiger Bereitstellung der zugehörigen Berichte. Dazu wurde ein Pair Programming zwischen IT und Fachbereich etabliert. Diese direkte Zusammenarbeit ohne räumliche Trennung der BI-Entwickler mit den Analysten im Fachbereich stellt eine organisatorische Änderung dar. Neben dieser organisatorischen Maßnahme wurden zudem die Architekturen und Prozesse zur untertägigen Produktivsetzung von ETL-Prozessen, Datenstrukturen und Reports in Form eines vollständig automatisierten Deployments inklusive einer Umgebung für automatisierte Tests mit Hilfe geeigneter technischer Maßnahmen umgesetzt Wechselwirkungen zwischen Maßnahmen und Unternehmen Alle vom Unternehmen getroffenen Entscheidungen bezüglich Agile BI beeinflussen wiederum das Unternehmen selbst. So ist für einen ausgereiften Continuous Integration -Ansatz neben einem Produktivsystem eine dedizierte Testumgebung erforderlich. Die Anwendung des Paradigmas der modellgetriebenen Softwareentwicklung in Form von bereits existierenden DWH-Generatoren beispielsweise bigenius (trivadis GmbH), metabi (Cimacon GmbH) oder timextender (timextender Holding) setzt spezielle Repositories voraus, in denen die erstellten Modelle gespeichert und weiterverarbeitet werden. Dabei ist zu beachten, dass diese Abhängigkeit bidirektional ist. Hat ein Unternehmen beispielsweise nicht die Möglichkeit, benötigte Infrastrukturkomponenten zur Verfügung zu stellen, kommen für dieses Unternehmen nicht alle Maßnahmen zur Steigerung der BI-Agilität infrage. Eine Entscheidung für eine bis dahin noch nicht umsetzbare automatisierte Produktbereitstellungsmethode zieht Änderungen in der BI-Architektur sowie in der BI-Aufbauorganisation und deren Prozesse nach sich. Dabei handelt es sich beispielsweise um neue Release-Abläufe mit neuen Unternehmensrollen, welche die Verantwortung für die neuen Testumgebungen tragen. Dies wiederum bedingt, dass die Fachlichkeit des Unternehmens um das Wissen für die neuen Aufgaben steigt und ein Umdenken in der Unternehmensphilosophie im Sinne der agilen Werte [Beck et al. 2001] stattfindet. In Abb. 2 sind einzelne Methoden mit ihren Auswirkungen auf die unterschiedlichen Ebenen exemplarisch dargestellt. Eine kundenorientierte Ausrichtung und offene Kommunikation sowie die mit BI-Agilität einhergehende Möglichkeit, flexibel und zeitnah auf Anforderungen zu reagieren, ermöglichen es Unternehmen, die Softwarequalität zu steigern, Entscheidungen schneller treffen zu können, sich besonders am Markt zu positionieren und einen früheren Return on Investment zu erzielen. 7

8 Wasserfallmodellphasen: Design Entwicklung Test Bereitstellung Methoden: Einfluss auf: Modellgetriebene Softwareentwicklung automatische Generierung von Code-/Konfigurationsdateien Pair-Programming. Entwicklung ETL- Strecken von zwei Entwicklern Definition Datenraum von Entwickler und Fachanwender Automatisierte Tests Regressionstests Continuous Integration automatisierter Build (Vorkonfiguration) automatisierte Testausführung BI-Architektur Modell-Repository bereitstellen Testsystem bereitstellen CI-Server bereitstellen Testumgebung bereitstellen BI-Aufbauorganisation Verantwortlichkeit Modell-Repository benennen engere Verzahnung von Fach- und IT- Abteilung Verantwortlichkeit Testsystem benennen Verantwortlichkeit CI-Server benennen Verantwortlichkeit Testumgebung benennen BI-Prozesse Integration des Modell-Repository in BI-Designprozess Unterstützungsprozesse für fachbereichsnahe Entwicklung Erweiterung Entwicklungsprozess um Testprozesse neue Release- Abläufe Abb. 2: Maßnahmen zur Steigerung der BI-Agilität im Bereich Methoden sowie deren Einfluss auf die BI- Architektur, BI-Aufbauorganisation und BI-Prozesse 4. Aktuelle Herausforderungen Aufgrund der Unterschiede in der Entwicklung von klassischen Softwareanwendungen zu BI- Anwendungen gibt es eine Reihe von Herausforderungen im BI-Kontext, die adressiert werden müssen, sodass BI-Agilität und Agile BI ein aktuelles und eigenständiges Forschungsfeld darstellen. Im Folgenden werden einige dieser Herausforderungen näher erläutert, wobei diese Liste keinen Anspruch auf Vollständigkeit erhebt. Das von Kent Beck vorgeschlagene Test-Driven Development ist eine etablierte Methode in der Softwareentwicklung, die zur Verbesserung der Qualität von Anwendungen beiträgt. Ein wesentlicher Bestandteil von TDD stellt das Unit Testing dar, bei dem die Funktionalität einzelner Komponenten vom Gesamtsystem losgelöst 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 Interesse, was in BI-Lösungen einer zu testenden Unit entspricht und wie sich diese Units in den unterschiedlichen Ebenen wie Datenintegration, Datenhaltung, Analyse und Informationsbereitstellung unterscheiden. Ein weiterer wesentlicher Bestandteil von TDD stellt das kontinuierliche Refactoring dar. Dabei wird ein Refactoring dann durchgeführt, wenn sogenannte Code Smells [Martin 2009] im Quellcode auftreten, die in der Regel auf einen schlecht geschriebenen Programmcode hinweisen. 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 Qualität von BI- Anwendungen bei erhöhter Agilität zwingend notwendig, Testverfahren wie Unit, Integrations- 8

9 und Akzeptanztests methodisch weiterzuentwickeln und Werkzeuge zur Automatisierung dieser Tests zu realisieren. Die flexible Ausrichtung der BI-Architektur führt ebenso zu neuen Herausforderungen. Der agile Wert laufende Software über umfangreiche Dokumentation [Beck et al. 2001] stellt bei sich stets wandelnden Architekturen einen Widerspruch zu der Entscheidung dar, qualitativ hochwertige Dokumentationen im Sinne eines guten Qualitätsmanagements zu erzeugen. Solche scheinbaren Widersprüche gilt es durch neue Lösungswege zu beseitigen, indem beispielsweise BI-Systeme vollkommen automatisiert dokumentiert werden [Krawatzeck et al. 2011]. Neben der Auflösung scheinbarer Widersprüche gilt es des Weiteren, die durch die Auswahl bestimmter Maßnahmen gegebenenfalls entstehenden Synergieeffekte zu identifizieren und zu nutzen. So kann die Entscheidung für eine umfangreiche Qualitätssicherung durch automatisierte Tests und durch die Anwendung des Paradigmas der modellgetriebenen Softwareentwicklung zur Umsetzung einer flexiblen BI-Architektur, beispielsweise in Form von modellgetriebenen automatisierten Softwaretests, kombiniert werden. Die unternehmensspezifische Gestaltung von Business Intelligence wirkt prägend auf die Geschäftsarchitektur zurück und somit indirekt auch auf die Unternehmensstrategie. Ein hoher Grad an BI-Agilität ermöglicht und fördert beispielsweise die schnelle Anpassung von Prozessen. Daher ist zu untersuchen, welche Wechselwirkungen zwischen Gestaltungszielen, wie beispielsweise Kosteneffizienz, Agilität oder Innovation, für Business Intelligence bestehen und welche Auswirkungen ein hoher Grad an BI-Agilität auf die Geschäftsprozesse oder die IT- Architektur eines Unternehmens hat. Dies setzt wiederum voraus, dass sich der Grad der BI- Agilität einer BI-Lösung messen lässt. Hierfür ist die Definition von geeigneten Indikatoren für die Messung der BI-Agilität 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 Erhöhung der BI-Agilität?. BI-Spektrum (2012), 2, S [Baars et al. 2009] Baars, H.; Zimmer, M; Kemper, H.-G.: The Business Intelligence Competence Centre as an Interface between IT and User Department in Maintenance and Release Development. Proc. of the 17th European Conference on Information Systems (ECIS 2009), Verona, [Beck et al. 2001] Beck, K.; Beedle, M.; van Bennekum, A.; Cockburn, A.; Cunningham, W.; Fowler, M.; Grenning, J.; et al.: Manifesto for Agile Software Development, Zugriff am [Collier 2011] Collier, K. W.: Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Addison-Wesley, Upper Saddle River,

10 [Hughes 2008] Hughes, R.: Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XP. iuniverse, New York, [Kemper et al. 2010] Kemper, H.-G.; Mehanna, W.; Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen eine Einführung in die IT-basierte Managementunterstützung (3. überarbeitete Auflage).Vieweg, Wiesbaden, [König 2009] König, S.: Ein Wiki-basiertes Vorgehensmodell für Business Intelligence Projekte. Tagungsband des Forschungskolloquiums Business Intelligence (FKBI 09), Dortmund, Deutschland, 2009, S [Krawatzeck et al. 2011] Krawatzeck, R.; Jacobi, F.; Müller, A.; Hofmann, M.: Konzeption eines Frameworks zur automatisierten Erstellung nutzerspezifischer IT- Systemdokumentationen. Tagungsband zum Workshop Business Intelligence 2011 (WSBI 11), Stuttgart, Deutschland, 2011, S [Martin 2009] Martin, R. C.: Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code. mitp, Heidelberg, [Nissen et al. 2012] Nissen, V.; von Rennkampff, A.; Termer, F.: IT-Architektur als Maß für die IT-Agilität. Tagungsband der Multikonferenz Wirtschaftsinformatik 2012 (MKWI'12). Braunschweig, Deutschland, 2010, S [Unternehmensgespräch 2008] Unternehmergespräche 2008 der Universität Stuttgart: Organisation, Prozesse und Technologien für eine Agile Business Intelligence, Zugriff am [Zimmer et al. 2012] Zimmer, M.; Baars, H.; Kemper, H.-G.: The Impact of Agility Requirements on Business Intelligence Architectures. Proc. of the 45th Hawaii International Conference on System Sciences (HICSS'12). Maui, Hawaii, USA, 2012, S