Agile BI Delivery with the SAP Information Design Tool – Introduction

Over the past few years there hasn’t been a Business Intelligence event I’ve attended that didn’t cover the topic of Agile BI in one sense or another.  It was always a fascinating source of discussion that quite often raised considerable passion.  To me, it seemed a common sense approach and one that, to varying degrees, the BI projects that I have been delivering over the years have pretty much been in line with.

At the start of last year, I was browsing various BI discussion boards and came across a recommendation for a new book title “Agile Analytics : A Value Driven Approach to Business Intelligence and Data Warehousing” written by Ken Collier.  There are many wonderful things about 21st Century living but one is surely the fact that, minutes after reading these recommendations, I’d downloaded the book onto my Kindle and was fully engrossed in what Collier had to say.  I’m happy to report that the recommendations were well made and I’ve been adding my own to clients and colleagues ever since finishing it the first time round.  What I thought I’d do here is tie in some of the concepts that Collier raises in his excellent book to some of the features in the now only relatively new SAP Information Design Tool.

I’m in no way trying to tie Collier to SAP.  One of the genius points about “Agile Analytics” is that – like me - it is technology independent.  Collier makes suggestions and clearly has some tools he’s familiar with more than others but stress is made, throughout the book, that Agile BI does not rely on a single tool set.  All I’m trying to do in the series of blogs for which this is the introduction, is highlight some of the areas where SAP’s Information Design Tool (IDT) can help support Agile BI.  There is, I intend to point out, plenty of room for improvement on SAP’s part but I do believe that the IDT is a good starting point, as far as technology ever can be, for any development team considering an Agile BI approach.

Let’s start though with some words about Agile BI.  I can do no better than recommend (again) Collier’s Agile Analytics book.  The introductory chapter makes clear that Agile BI  “is not a rigid or prescriptive methodology; rather it is a style of building a data warehouse, data marts, business intelligence applications and analytics applications that focuses on the early and continuous delivery of business value throughout the development lifecycle”.  There’s a brilliant analogy in the introduction setting the scene by comparing BI to mountaineering with traditional approaches seen as Siege Style Mountaineering (large teams of climbers expending much cost, effort, sherpas, etc…) whilst Agile BI delivers a more productive Alpine Style ascents (small teams reaching the summit faster with just the bare essentials). Throughout, Collier is at pains to observe that it is “simple but not easy” and does not shy away from the challenges of Agile BI (I especially appreciated the need to be ‘fearless’ when doing the most difficult thing first to fully identify ‘project peril’. 
Another key point Collier continually makes is that delivery resource needs to perfect ‘being’ Agile rather than just ‘doing’ Agile.  It’s a state of mind rather than a strictly replicable approach. This is where his adaptation of the original Agile Manifesto comes in.  It’s worth reproducing in full:


There’s a lot more detail about this manifesto in the book.  You might well question some points of the manifesto but Collier successfully rebuts most of the obvious concerns.  It’s all good stuff but it’s not my purpose to detail it all here – go on, buy it yourself!

My focus instead is how SAP’s IDT fits into this manifesto.  Clearly it’s a ‘tool’ which is not as valued  as ‘Individuals and Interactions’ but, the key point is, it is still valued.  Collier’s book is split into two sections covering both the Management and Technical aspects of Agile BI delivery.  What I’m attempting to do in these blogs is demonstrate how the IDT can support some of those technical aspects.

Before I can do that though it might be worth reviewing exactly what the SAP IDT is.  The Information Design Tool was introduced as a development environment with SAP BusinessObjects 4.0.   In short, it’s a new tool with which developers can create the longstanding SAP BI semantic layers – the Universes.  The old Universe Designer is still there, available for developers happy with the familiar but the IDT represents a significant leap forward in functionality and, I’d argue, is much more suited to Agile BI delivery than the legacy product.  This should allow for reduced development costs and a corresponding increase in all the highlighted elements to items on the left of the Agile Analytics Manifesto e.g. where solutions are less costly to change there is more scope for responding to change in user requirements and where systems can be self documenting there is less need for comprehensive documentation.

An easy way I’ve found to understand what the IDT does is to think of it as exploding the previous development environment for SAP Universes.  Rather than working on a single entity (the .unv file), the IDT works with three distinct layers – Connection, Data Foundation and Business Layer - to produce a new Universe (a .unx file).  The diagram below illustrates this explosion using the good old e-fashion Universe imported into the new format (a straightforward enough process).


So that’s a brief introduction to both Agile BI and the SAP Information Design Tool.  Over the next three blogs, I intend to review how the latter can support the former.

i) Collaborative Development – whilst it doesn’t offer the full version controlled environment commended by Collier’s eighth chapter, the SAP IDT does provide a good advance on what’s possible for a multi-developer team on the capacity available in the traditional Universe Designer.

ii) Continuous Testing – the IDT offers an interesting, not quite complete, solution to the need to perform continuous testing on the Agile-developed Universes and I’ll also cover how using triggered SAP WebIntelligence reports can help deliver on this approach.

iii) Evolving Excellent Design – the exploded Universe layers present a model against which this can be achieved.  Correct sources can be prototyped in multiple systems, reports developed and then repointed at an optimised single source solution if required i.e. no need to redevelop reports when a new source system is delivered.