Agile BI Building Blocks 2.0

Quite a while ago, I published a blog post about my Agile BI Maturity Model. In this post I’d like to show you the current state of the model.

First of all I renamed the model to “Agile BI Building Blocks”. I don’t like the “maturity” term anymore as it somehow values the way you are doing things. Building blocks are more neutral. I simply want to show what aspects you need to take into consideration to introduce Agile BI in a sustainable way. The following picture shows the current model:

What changed compared to version 1? Let me go through the individual building blocks:

  1. Agile Basics & Mindset. No change – still very important: You need to start with agile basics and the agile mindset. A good starting point is still the Agile Manifesto or the newer Modern Agile.
  2. Envision Cycle & Inception Phase. No change – this about the importance of the Inception Phase especially for BI project. Simply don’t jump straight into development but do some minimal upfront work like setup the infrastructure or create a highlevel release scope and secure funding.
  3. BI specific User Stories. Changed the term from simply User Stories to “BI specific User Stories”. Unfortunately I didn’t manage to write a blog post about this yet, but in my recent workshop materials you’ll find some ideas around it.
  4. No / Relative Estimating. Changed from Relative Estimating (which is mainly about Story Points) to include also No Estimating which is basically about the #NoEstimates movement. I held a recent presentation at TDWI Schweiz 2017 about this topic (in German only for now)
  5. (Self Organizing) Teams. Changed and put the term “Self Organizing” in brackets as this building block is about teams and team roles in general.
  6. Workspace & Co-Location. Added “Workspace” as this building block is not only about co-location (though this is an important aspect of the agile workspace in general)
  7. Agile Contracting. No change, in my recent presentation at TDWI Schweiz 2017 I talked about Agile Contracting including giving an overview of the idea of the “Agiler Festpreis”, more details you can find in the (German) book here.
  8. New: Data Modeling & Metadata Mgt. Not only for AgileBI data modeling tool support and the question around how to deal with metadata is crucial. In combination with Data Warehouse Automation these elements become even more important in the context of AgileBI.
  9. New: Data Warehouse Automation. The more I work with Data Warehouse Automation tools like WhereScape, the more I wonder how we could work previously without it. These kind of tools are an important building block on your journey of becoming a more agile BI environment. You can get a glimpse at these tools in my recent TDWI / BI-Spektrum article (again, in German only unfortunately)
  10. Version Control. No change here – still a pity that version control and integration into common tools like Git are not standard in the BI world.
  11. Test Automation. No change here, a very important aspect. Glad to see finally some DWH specific tools emerging like BiGeval.
  12. Lean & Fast processes. No change here – this block refers to introducing an iterative-incremental process. There are various kinds of process frameworks available. I personally favor Disciplined Agile providing you with a goal-centric approach and a choice of different delivery lifecycles.
  13. Identify & Apply Design Patterns. No change except that I removed “Development Standards” as a separate building block as these are often tool or technology specific formings of a given design pattern. Common design patterns in the BI world range from requirements modeling patterns (e.g. the BEAM method by Lawrence Corr as well as the IBIREF framework) to data modeling patterns like Data Vault or Dimensional Modeling and design patterns for data visualization like the IBCS standards.
  14. New: Basic Refactoring. Refactoring is a crucial skill to become more agile and continously improve already existing artefacts. Basic refactoring means that you are able to do a refactoring within the same technology or tool type, e.g. within the database using database refactoring patterns.
  15. New: Additive Iterative Data Modeling. At a certain step in your journey to AgileBI you can’t draw the full data model upfront but want to design the model more iteratively. A first step into that direction is the additive way, that means you typically enhance your data model iteration by iteration, but you model in a way that the existing model isn’t changed much. A good resource around agile / iterative modeling can be found here.
  16. Test Driven Development / Design (TDD). No change here. On the data warehouse layer tools like BiGeval simplify the application of this approach tremendously. There are also materials availble online to learn more about TDD in the database context.
  17. Sandbox Development Infrastructure. No change, but also not much progress since version 1.0. Most BI systems I know still work with a three or four system landscape. No way that every developer has its own full stack.
  18. Datalab Sandboxes. No change. The idea here is that (power) business users can get their own, temporary data warehouse copy to run their own analysis and add and integrate their own data. I see this currently only in the data science context, where a data scientist uses such a playground to experiment with data of various kinds.
  19. Scriptable BI/DWH toolset. No change. Still a very important aspect. If your journey to AgileBI takes you to this third stage of “Agile Infrastructure & Patterns” which includes topics like individual developer environments and subsequently Continuous Integration, a scriptable BI/DWH toolset is an important precondition. Otherwise automation will become pretty difficult.
  20. Continuous Integration. No change. Still a vision for me – will definitely need some more time to invest into this in the BI context.
  21. Push Button Deployments. No change. Data Warehouse Automation tools (cf. building block 9) can help with this a lot already. Still need a lot of manual automation coding to have link with test automation or a coordinated deployment for multiple technology and tool layers.
  22. New: Multilayer Refactoring. In contrast to Basic Refactoring (cf. building block 14) this is the vision that you can refactor your artefacts across multiple technologies and tools. Clearly a vison (and not yet reality) for me…
  23. New:  Heavy Iterative Data Modeling. In contrast to Additive Iterative Data Modeling (cf. building block 15) this is about the vision that you can constantly evolve your data model incl. existing aspects of it. Having the multilayer refactoring capabilities is an important precondition to achieve this.

Looking at my own journey towards more agility in BI and data warehouse environments, I’m in the midst of the second phase about basic infrastructure and basic patterns & standards. Looking forward to an exciting year 2018. Maybe the jump over the chasm will work 😉

What about your journey? Where are you now? Do you have experience with the building blocks in the third phase about agile infrastructure & patterns? Let me know in the comments section!

Advertisements

Optimizing my dashboard: Creating a visual draft

Remember my last post about the Webi dashboard? As mentioned at the end of that post aimed to show a technical trick to put an interactive kind of a button onto a Webi report. Now this post is the first in a series of posts how to optimize the layout of the initial dashboard. Let’s start with creating a draft of our optimized dashboard layout. The advantage of such a draft is that it is not yet implemented with the actual BI tool but using either pen and pencil or a wireframing tool. I did the later and chose the cloud edition of Balsamiq. To get a quick start you can use a 30 days trial account.

Let me explain briefly how the tool works. After that I’ll explain some of my thoughts behind the chosen layout.
Within the editor you can drag and drop sketched objects like a window container, rectangles, text, buttons etc.

Balsamiq_Editor

My dashboard in the Balsamiq editor

Looking at the available chart objects, I’m not really satisfied:

Balsamiq_Charts

Default chart elements in Balsamiq

Therefore I added my own images representing typical IBCS chart types (IBCS stands for International Business Communication Standards. I wrote a short blog post about IBCS here.). The images are based on the graphomate add-on for SAP DesignStudio and BusinessObjects Dashboards.

IBCS_charts

Typical IBCS chart types (created with graphomate)

After all, my inital dashboard draft looks like this:

Page01.jpeg

My dashboard draft (chart view 1)

At the top you can see some reserved space for an appropriate title. Providing this is a major requirement stated by IBCS as one of the top ten proposals:

I adapted this to a BI specific title concept where I distinguish between general title elements (like the organization or global query filters) and object specific titles, e.g. for the table or a chart. For the table I used the default element of Balsamiq, maybe I will update this later on with an IBCS optimized one. For now it is just a placeholder.

The charts in this first view will show current year values and previous year values (where as the current year will be indicated within the global filters area) for revenue and margin. To make the analysis of available data more straight forward, I decided to add two variance charts, one for absolute values and one with percentage values. Again, this is one of the top 10 elements in IBCS:

You might have discovered the symbolic button to switch the chart view. The second view looks like this:

Page02.jpeg

My dashboard draft (chart view 2)

The header and table areas stay the same. In the lower area with charts I now show historical values for revenue with actual and plan values. Instead of putting everything into one big chart I decided to use small multiples for the top 5 product lines (based on total revenue over time) as well as one chart for all other product lines. Depending on how it will look like in Webi we might decide to show more product lines or add another topic to the dashboard (as we still have space left on the bottom right corner).

In this blog I showed how to create a simple dashboard draft using a wireframeing tool like Balsamiq. In addition I pointed out how to apply two of the top ten IBCS proposals in this conceptual phase.

Update May 5, 2015: Internally at IT-Logix we continued the implementation of the above shown mockup; we used both Design Studio and Web Intelligence. Unfortunately the time for writing a blog post was missing so far. Still, if you are interested in the Web Intelligence part, have a look at the following sapInsider BI2015 session held by my teammate Kristof Gramm: http://bit.ly/1EGKFtA He will show how you can do pretty amazing things with Webi (by the way, using this link you’ll be granted a 300€ discount on the conference registration 😉

IBCS – an emerging standard for business #dataviz

In my previous post I introduced the SUCCESS model of Rolf Hichert. In this post I’d like to introduce you to the subject of IBCS – the International Business Communication Standards. IBCS’ aim is to “foster the level of understanding in reports and presentations” (Source: IBCS). Currently, IBCS consists of two main parts:

Notation of meaning
The part “Notation of meaning” describes basically the semantics of a standardized business communication language. It covers all aspects of meaning in the context of business communication and suggests an appropriate notation.

Design of components
The part “Design of components” covers rather the syntactical aspects of a standardized business communication language. It describes the basic report elements and specific rules to use them for the design of objects such as tables and charts. Several objects and additional elements make up complete pages. Although this part should not consider aspects of meaning, but only define the “grammar” of a unified communication language, some overlap to the “Notation of meaning” (semantics) is inevitable. (Source: IBCS)

IBCS and SUCCESS are closely related, therefore I will start with some explenations about how the two topics are positioned against each other. First of all SUCCESS and IBCS can be looked at from a time perspective. Clearly, SUCCESS was developed first:

Folie1

From this point of view IBCS  is a refinement of certain aspects of SUCCESS (namely the Unify part in SUCCESS). This refinement can be seen in the following perspective too:

Folie2

SUCCESS provides only generic guidelines without concrete implementation details, e.g. the following one:

UnifyStandardDimensions

Souce & Copyright: HICHERT + PARTNER

This guideline just tells you: If you visualize this year’s revenue with blue in chart number 1, you should also use blue in chart number 2. But the guideline doesn’t tell you to always use blue. If you wish to take brown for current revenue, it’s OK. Just use brown whenever you visualize current revenue. This and many of the other guidelines (some of them are mentioned in my previous blog post) in SUCCESS I therefore attribute to what I call “common sense” or data visualization basic recommendations. Now IBCS comes into play. Whereas SUCCESS is rather generic IBCS defines the details and writes them down. As indicated above IBCS does this in mainly two parts:

– the notation of meaning clearly defines which elements have which meaning:

UnifyStandardDimensionsIBCS

Source: IBCS

This way business communication should be simplified through standardization the same way as you are used to it with geographical maps for example. Blue always means water, north is always at the top of the map etc. This “semantic layer” is something which differentiates IBCS from other data visualization and information design concepts. Most if not all of them focus on generic recommendations only. In contrast, IBCS wants to harmonize the visualizations in a business context and make them therefore easier to understand.

– the second aspect of IBCS is the design of components

Let’s have a look at the SUCCESS guidline first, e.g. for chart design:

Source & Copyright: HICHERT + PARTNER

Source & Copyright: HICHERT + PARTNER

IBCS gives you much more information, e.g. regarding legends:

LegendsIBCS

Source: IBCS

You can look at IBCS and SUCCESS from a third perspective too:

Folie3

In this perspective IBCS is the solid base with all the detailed rules to consider for efficient data visualizations in business communications. Yet the IBCS rules are hard to digest (as every other industry standard…) SUCCESS can be seen as an implementation methodology of them (as IBCS and SUCCESS are mostly congurent to each other). SUCCESS is an acronym of seven verbs – if you act on them, you’ll see that implementing IBCS is pretty straight forward.

IBCS is work in progress and it is open-source (based on the Creative Commons BY-SA license). Its further development is orchestrated by the IBCS Association which again is run by HICHERT + PARTNER. Simply create a login on ibcs-a.org and start to add your own ideas to further refine and extend the standard.

If you want to learn more about IBCS, SUCCESS and how it can be implemented, join me during the BOAK conference this autumn. It takes place on Tuesday, September 16th in Zurich / Switzerland. In the data visualization track (sessions E1 to E4) you’ll find several sessions dedicated to IBCS. Jürgen Faisst, CEO of HICHERT + PARTNER will elaborate on the goals of IBCS. My friend Lars Schubert will demonstrate how you can apply IBCS using the IBCS certified software “graphomate” as part of SAP Design Studio or SAP BusinessObjects Dashboards. I myself will present together with a customer showing how we implemented an IBCS oriented design in Web Intelligence. The day after I will teach these best practices during a one day workshop. A sneak peek on the Webi reports you can find on my Hichert Certified Consultant page. Looking forward to seeing you during the BOAK conference!

What do you think about IBCS and the semantic layer? Do you think it is worth the effort to harmonize data visualizations in a business context? Just add a comment now!

Simple guidelines for more efficient report & dashboard design

It is already for more than three years that I’m engaged with the topic of business information design. It was during a regular Crystal Reports project. We were about to finalize the IT concept phase and the project was on track. Crystal Reports was already selected as the tool to go forward with. When suddenly something happened: The sponsor of the project, the company’s CFO, asked us if we can implement what he called a “Hichert chart”. I found that Hichert is a German business information design specialist and at first sight he had some weird ideas regarding chart design. So weird we couldn’t really implment them with Crystal Reports and – long story short – we couldn’t finish the project as the CFO’s requirement regarding Hichert charts was too strong. Not even other tools within the BusinessObjects portfolio were able to fullfil it. So the customer finally chose an Excel based solution…

Of course I was annoyed but at as well curious. How powerful this Hichert stuff must be in order to turn a project upside down? This was the start of my journey into business information design. According to Wikipedia this field is about the following:

“Information design is the practice of presenting information in a way that fosters efficient and effective understanding of it. The term has come to be used specifically for graphic design for displaying information effectively, rather than just attractively or for artistic expression.” (Source)

In this and future blog posts I’d like to illustrate how you can achieve this more efficient understanding of data and information in the context of Business Intelligence.

There is already a lot of helpful content available, let me name just a few sources I use in my daily work:

For this article I’d like to introduce the SUCCESS model of Hichert. SUCCESS is an acronym for the following verbs:

Say – Unify – Condense – Check – Enable – Simplify – Structure

Every verb corresponds to a collection or category of design guidelines. Most of these guidelines are commonly accepted best-practices – and you find them as recommendations not only with Hichert but with many of the above people. The only difference with SUCCESS is, that the recommendations are put into about 120 concrete, numbered and illustrated  guidelines of “Dos & Don’ts” regarding information design. This very structured approach makes it very easy to get started with the topic. You can find everything summarized on the SUCCESS poster:

SUCCESS Poster

SUCCESS Poster (Source & Copyright: HICHERT+PARTNER)

You can download your own copy here.

Let me briefly explain what each category is about:

Say: This is about having a message to tell or in general about meaningful content in your reports and dashboards. A good example is the following guideline:

Replace Traffic Lights

Replace Traffic Lights (Source & Copyright: HICHERT+PARTNER)

Another important, yet pretty easy to implment guideline tackles the matter of having a clear title concept which enables the reader to quicker grasp what he or she is looking at:

Title Concept (Source & Copyright: HICHERT+PARTNER)

Title Concept (Source & Copyright: HICHERT+PARTNER)

Unify: This category of guidelines is about the statement “what looks the same should mean the same” and the other way round. The following guideline shows suggestions how you might unify the look of tables and charts – for now the important part is not yet what the chart or table looks like but that charts and tables always follow the same design pattern.

Unify Tables & Charts (Source & Copyright: HICHERT+PARTNER)

Unify Tables & Charts (Source & Copyright: HICHERT+PARTNER)

Condense: Condense is about increasing the information density on a given report or dashboard page / screen. A few simple but powerful guidelines:

Use empty space (Source & Copyright: HICHERT+PARTNER)

Use empty space (Source & Copyright: HICHERT+PARTNER)

Use Small Multiples (Source & Copyright: HICHERT+PARTNER)

Use Small Multiples (Source & Copyright: HICHERT+PARTNER)

Check: This category is about ensuring quality. One topic for example is to choose an appropriate chart type and the usage of propre scales:

Choose appropriate chart type (Source & Copyright: HICHERT+PARTNER)

Choose appropriate chart type (Source & Copyright: HICHERT+PARTNER)

Don't cut axes (Source & Copyright: HICHERT+PARTNER)

Don’t cut axes (Source & Copyright: HICHERT+PARTNER)

Enable: The guidelines in the Enable category are not about information design itself but how to best introduce the guidelines of the other categories into an organization:

Present alternatives (Source & Copyright: HICHERT+PARTNER)

Present alternatives (Source & Copyright: HICHERT+PARTNER)

Create a Rollout Plan (Source & Copyright: HICHERT+PARTNER)

Create a Rollout Plan (Source & Copyright: HICHERT+PARTNER)

Simplify: This category brings together a lot of guidelines which are all about avoiding noise and other distracting elements in the report and dashboard design:

Avoid meaningless elements (Source & Copyright: HICHERT+PARTNER)

Avoid meaningless elements (Source & Copyright: HICHERT+PARTNER)

Avoid 3D charts (Source & Copyright: HICHERT+PARTNER)

Avoid 3D charts (Source & Copyright: HICHERT+PARTNER)

Omit Long Numbers (Source & Copyright: HICHERT+PARTNER)

Omit Long Numbers (Source & Copyright: HICHERT+PARTNER)

Structure: Similar to the Say category, Structure is more about the content itself than its visual representation. The guidelines here describe how to group data:

Exhaustive Structures (Source & Copyright: HICHERT+PARTNER)

Exhaustive Structures (Source & Copyright: HICHERT+PARTNER)

Mutually Exclusive Structures (Source & Copyright: HICHERT+PARTNER)

Mutually Exclusive Structures (Source & Copyright: HICHERT+PARTNER)

 

Show Structures (Source & Copyright: HICHERT+PARTNER)

Show Structures (Source & Copyright: HICHERT+PARTNER)

Most of the above shown guidelines can be implemented straight away with most BI tools including SAP’s Web Intelligence and Crystal Reports. During my upcoming blog posts I’d like to look more closesly at several further aspects both from technical as well as conceptual perspective. This will also answer the question why we had troubles implementing “Hichert charts” in the customer project mentioned at the beginning.
In the meanwhile I’m happy to get your feedback what you think about SUCCESS and to learn about your experience regarding information design in the context of Business Intelligence.