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

AgileBI: How Corporate culture influences the development approach

In this blog post I discussed various building blocks which can help to establish and manifest an agile approach to Business Intelligence within an organisation. In this article I will focus on the aspect “Agile Mindset & Organisation”. The probing question is, which approach is best suited to develop a data warehouse (= DWH; not just the BI Frontend) incorporating the agile principles. Closely linked to this matter is the question of cutting user stories. Is it sensible to size a user story “end to end”, i.e. from the connection of the source, staging area and core DWH all the way to the output (e.g. a dashboard)? As you can imagine, the initial answer is “it depends”.

When looking at the question more closely, we can identify multiple factors that will have an impact on our decision.

Organizational structure

First of all, I would like to point out the distinction of the following two cases of the development organisation:

  • Organizational Structure A) DWH and BI Frontend are considered one application and are developed by the same team.
  • Organizational Structure B) DWH und BI Frontend are considered as separate applications (while being loosely coupled systems) and developed by different teams.

Characteristics of the Organizational Culture

In a next step we need to differentiate between two possible characteristics of organizational culture, which are extracted from Michael Bischoff’s book “IT Manager, gefangen in Mediokristan”, (engl.: IT Manager, trapped in Mediokristan). A nice review of the book can be found in this blog entry (in German).

  • „Mediokristan“: The „country“ Mediokristan is described as a sluggish environment where hierarchies and framework are predetermined, and risk- and management concepts are dominating factors. It stands symbolically for the experiences I have made in large corporate IT organizations. Everything moves at a slow pace, cycle times tend to be high; mediocrity is the highest standard.
  • “Extremistan”: The “country” Extremistan is best described as the opposite of Mediokristan. New, innovative solutions are developed and implemented quickly, fostered by individual responsibility, self-organization and a start-up atmosphere. Its citizens strive for the extreme: extremely good, extremely flexible, regardless of the consequences. What works will be pursued further, what does not will be discontinued. Any form of regulation or framework is rejected extremely too in case they are seen to hinder innovation.

Needless to say, the two cultures described are extremes, there are various other characteristics between the two ends of the spectrum.

Alternatives to agile development approaches

The third distinction I would like to point out are the following two alternative approaches to agile development:

  • Development Approach A) Single Iteration Approach (SIA): A number of user stories is selected in the beginning of an iteration (called a Sprint in the Scrum jargon), with the goal to have a potentially deployable result at the end of one iteration. With Organizational Structure A in place (see above), the user story will be cut “end to end” and has to encompass all aspects: Connecting the required source system (if not available already), data modeling, loading of the data into the staging layer, EDWH and data mart layer and last but not least creating a usable information product (e.g. a report or a dashboard). The processing of the user story also includes developing and carrying out tests, writing the appropriate documentation, etc. It is a very challenging approach and will generally require a Team of T-Skilled People, where each member of the team possesses the skills to manage and fulfil any and all of the upcoming tasks over the time.
    Folie4_SIA
  • Development approach B) Pipelined Delivery Approach (PDA): The PDA exists because of the assumption that the SIA is illusive in many cases. One reason is the lack of T-Skilled people in our specialist driven industry, or the involvement of multiple teams (e.g. separate teams of Business Analysts, Testing) in the development process in extreme cases. Another reason is the mere complexity we often see in DWH solutions. An iteration cycle of two to four weeks is already quite ambitious when – in the figurative sense – doing business in Mediokristan.
    As an alternative, PDA describes the creation of a DWH/BI solution based on a production line (also see the book written by Ralph Hughes: “Agile Data Warehousing Project Management: Business Intelligence Systems Using Scrum, Morgan Kaufmann, 2012). The production line (=pipeline) consists of at least three work stations: 1. Analysis & Design, 2. Development, 3. Testing. In the shown illustrations below (taken from a concrete customer project) I added a fourth station dedicated for the BI Frontend development. A user story runs through each work station in one iteration at the most. Ideally, the entire production line is run by the same team, which we will assume in the following example:

    • The user stories that are to be tackled in the early stages are defined and prioritized during a regular story conference at the outset of a production cycle. They will thereafter be worked on in the first work station “Analysis & Design”. Evidently, in this initial phase, the pipeline as well as some members of the team are not used to full capacity. In accordance with the Inception Phase in the Disciplined Agile approach, these gaps in capacity can be used optimally for other tasks necessary at the beginning of a project.
    • After the first iteration, the next set of user stories that will be worked on will be defined at the story conference and passed on to the first work station. Simultaneously, the user stories that were worked on in the first work station in the previous iteration will be passed on to the next one, the development station.
    • After the second iteration, more user stories will be chosen out of the backlog and passed on to the first work station, while the previous sets will move further along the pipeline. Thus, the user stories of the first iteration will now be worked on in the testing work station. (One word re testing: Of course we test throughtout the development too! But why would we need a separate testing iteration then? The reason lies within the nature of a DWH, namley data: During the development iteration a developer will work and test with a limited set of (test) data. During the dedicated testing iteration full and in an ideal case production data will be processed over multiple days; something you can hardly do during development itself).
    • Consequently, the pipeline will have produced “production ready” solutions for the first time after three iterations have passed. Once the pipeline has been filled, it will deliver working increments of the DWH solution after each iteration – similar to the SIA.
      Folie5_PDA1

      Pipelined Delivery Approach with four work stations

      Folie7_PDA3

      Testing inside one pipe cycle

The two approaches differ in the overall lead time of a user story between story conference and the ready-made solution, which tends to be shorter using the SIA in comparison to the PDA. What they have in common is the best practice of cutting user stories: They should always be vertical to the architecture layers, i.e. “end-to-end” from the integration of a source system up to the finished report (cf. organizational structure A) or at least the reporting layer within the DWH (cf. organizational structure B). While the PDA does incorporate all values and basic principles (this topic might be taken up in another article) of agile development, in case of doubt, the SIA is more flexible. However, put in practice, the SIA implementation is much more challenging and the temptation of cutting user stories per architectural layer (e.g. “Analysis Story”, “Staging Story”, “Datamart Story”, “Test Story”) rather than end-to-end is ever present.

When is which approach best suited?

Finally I would like to show where and how the above mentioned aspects are in correlation with each other.

Let’s have a look at “Organizational Structure A) DWH and BI Frontend are considered one application”. If the project team is working out of Extremistan and consists of mostly T-skilled team members, chances are that they will be able to implement a complete DWH/BI solution end-to-end working with the SIA. The success of the project with this approach is less likely, if large parts of the team are located in Mediokristan. Internal clarifications and dependencies will require additional time in matters of Analysis and Design. Furthermore, internal and legal governance regulations will have to be considered. Due to these factors, in my experience, the PDA has a better chance at success than the SIA when developing a DWH/Frontend in Mediokristan. Or, to put it more positively: Yes, Agile Development is possible even in Mediokristan.

The situation I have come across more often is „Organizational structure B) DWH and BI Frontend are considered two separate applications“. As a matter of principle, agile development with the SIA is simpler in the BI Frontend than the DWH backend development. That being said, the environment (Mediokristan vs. Extremistan) also has a great impact. It is possible to combine the two approaches (PDA for the DWH Backend, SIA for the BI Frontend), especially if the BI Frontend is already connected to an existing DWH and there is no need to adapt it according to every user story in the BI Frontend. Another interesting question in Organizational structure B) is how to cut the user stories in the DWH Backend. Does it make sense to formulate a user story when there is no concrete user at hand and the DWH is, in the practical sense, developed to establish a “basic information supply”? And if yes, how do we best go about it? An interesting approach in this case is the Feature Driven Development (FDD) approach, described in this Blog article of Agile-Visionary Mike Cohn. The adaption of the FDD approach when developing a DWH might be interesting material for a future article…

As you can see, the answer “It depends” mentioned at the beginning of this blog post is quite valid. What do you think? What is your experience with Agile BI in either Mediokristan or Extremistan? Please feel free to get in touch with me personally or respond with a comment to this blog post. I look forward to your responses and feedback.

(A preliminary version of this blog has been posted in German here. Many thanks to my teammate Nadine Wick for the translation of the text!)

BI specific requirements engineering – part 1

(Thanks to my co-author Alexander van’t Wout for supporting me writing this blog post!)

Collecting requirements for BI front end tools is often frustrating.

Imagine a sales conversation at your local car dealer. After some small talk you are going to tell the salesperson about your interest in buying a brand new car. Nothing easier than this you might think. But suddenly you are confused. The friendly salesperson asks you if you would please write down exactly what you want and draw a sketch of what you have in mind. As if this was not funny enough he hands a sketch board over to you with a blank sheet of paper on it.

This is how many Business Intelligence (BI) experts deal with their customers today. End users are often left alone to «design» their requirements. A car is a «commercial off-the-shelf product» and therefore very similar to a BI toolset, which is «off-the-shelf software». A common characteristic of both product types is the standardization of features, and therefore a limited set of features. On one hand, this might limit your flexibility; on the other hand, it simplifies the process of requirements’ definition drastically because you do not need to consider each and every detail to build a system.

We can distinguish two major scenarios where a business user community needs to specify requirements for BI front end tools: scenario A) is an organizational environment where the business intelligence software suite is already predefined. This means that for a regular project the project team is not free to choose from all available tools on the market, but only within the limited frame of what is usually called strategic vendors. In most organizations this means no choice at all. Typically, most organizations limit themselves to one or two strategic BI vendors, whereas every vendor provides a suite of tools and therefore provides a choice to project teams.

Scenario B) takes place when a company is about to choose their strategic BI vendors, or when it is about to define a front-end tool strategy based on a given toolset available. The difference to scenario A) is that there are no concrete requirements or previous use cases to do this. Decisions involving, for example, choosing strategic BI vendors, or building a front end tool strategy usually have to be derived from corporate requirements, which may mean some high-level requirements that are influenced by end users only in an indirect way.

In Scenario A, the main task is to map requirements to concrete features and specify detailed requirements (which take into consideration the chosen features). In scenario B, the main task is to get to know multiple tools and multiple tool suites of different BI vendors and make them comparable in an easy and quick way. For both cases, the authors suggest the visual approach of BI Picture Books as an analogy to a car catalog. In subsequent paragraphs, “end user” is used as a synonym for the party who is in charge of defining requirements for the BI front end tools.

Figure 1 Negotiation based on off-the-shelf softwareAs outlined in the introduction, working with business intelligence software is working with off-the-shelf software nowadays. This means that not all imaginable requirements are allowed anymore. In particular in scenario A) end users cannot have all they want, but their requirements need to be aligned with the available features of a given tool set. Still, the first step is collecting business requirements to compare with the technical features of the standard software. This process can be very frustrating for the business user after s/he has noted his requirements on a blank sheet of paper and tried to picture himself using a solution that fits his needs. The necessary negotiations regarding the technical feasibility are more likely a surrender of the business user’s initial requirements.

Therefore, the question that arises is, how could we show the end user in advance which options are available and therefore feasible as a solution to his requirements? To answer this question, we take a look at the automotive sector again.

Today, modern car manufacturers provide web-based car configurators, where customers can “build” their own car. The customers have to walk through several steps, e.g. choosing the color, the wheels, the engine and accessories. We can learn two things from such car configurators: First, guide the end user defining the necessary (and feasible) requirements. Second, provide visual support to the end user showing what different available options look like.

Structure BI front end requirements

To «build» a BI front end solution we identified seven crucial categories which need to be addressed during the requirements’ engineering process. This corresponds to scenario A above. For scenario B one can still use the same categories, but instead of defining requirements along the lines of these categories you can structure the available features and thus make the comparison of the different tools much easier. The following sections will outline the seven categories in more detail:

  1. Content options: In this first step, end users have to roughly define what information products they want to receive in the end, and the approximate content of these products. (The term information product is an umbrella term for all the various BI front end types such as report, statistics, cockpit, dashboard, analysis etc.). For scenario A end users are relatively free to note down everything they want, except for data content, which is a priori not available in the project time frame. For scenario B, the BI expert might list and compare all the available data connectivity options for a certain toolset.
  2. Navigation and selection options: In this second step, the end users need to think about how to navigate to or between the defined information products (e.g. using a folder structure in a given BI portal). Whereas navigation takes place outside information products, the selecting interactively data usually takes place inside an information product. In either case, the available options are limited by the software.
  3. Layout options: This third step is about collecting requirements regarding page layout, chart and table options. A common pitfall for end users is to assume that BI front ends are either like Microsoft Excel or Word. Trivial looking items such as a table of contents or some specific chart options which are available in Office products might not be available in the BI front end tools. In addition, if the end users’ organization adheres to notation standard rules such as the International Business Communication Standards (IBCS; http://www.ibcs-a.org/) this might further restrict the allowed layout options, in particular for charts and tables.
  4. Functional options: Whereas the third step addressed more of the static elements in a report, this fourth step is about defining requirements for the functions of a BI front end solution (in addition to the functions already defined in the navigation and selection category). Typical examples of functions are the usage of (interactive) alerts, export to various formats, printing, search, multi-language options, commentary features and so on. This category depends even more on the available features of a given BI front end tool than the previous ones.
  5. Delivery options: Step number five addresses how an information product is delivered to end users. Besides defining the delivery channel (e.g. by web browser, mobile, email) one must define how and when the report is refreshed. One possible option is viewing an information product on demand (the refresh is triggered directly by an end user). Scheduling the information product to be run at night is another option. Scheduling can be further divided into single information product scheduling and information product bursting where, based on one main product, a personalized instance of the information product is created and usually distributed to the specific recipient. Requirements for this category’s “delivery options” usually depend not only  on the front end tool itself, but also on the underlying BI platform system or available third party extensions, e.g. for bursting.
  6. Security options: Finally, end users have to think about security. In the context of BI front end solutions, there are two main security aspects to consider: Access restrictions on information product level, on one hand, and data level security, on the other hand. For the first aspect, an end user has to define who and in which role is allowed to see the report, and which features should be available, e.g. one user might access and refresh the report, but must not export the report. Similar to the previous category of delivery options, the access restrictions are highly dependent on the underlying BI platform and the available security options.
    The the second aspect of data level security is either addressed on database level or some kind of semantic layer of the BI front end tool. Again, the available technology decides upon available options.
  7. Qualitative options: Last but not least, this final category of options summarizes requirements of a qualitative nature. This includes elements such performance or usability requirements. For this category, it is more difficult to define requirements allowed. Nevertheless, one can guide the end user in defining realistic requirements, e.g. instead of asking an end user to define the maximum report refresh duration, provide predefined performance classes such as “< 30 sec”, “30 – 60 sec” and so on. This way an end user won’t define an unrealistic value like “every report must be refreshable below 3 seconds”.

Using these seven categories to either structure your end user requirements (scenario A) or structure and therefore compare the available features of multiple tools in an evaluation process (scenario B), you will be able to catch at least 80% of typical BI front end requirements. Depending on the concrete project, you will most probably have to extend the list with your own items. Still, the basic principle of guiding end users whilst defining requirements remains the same.

Another way of structuring the requirements using the seven categories is to outline dependencies. Similar to web based car configurators, there are certain requirements in a given category which have a direct impact on the allowed (or needed) requirements in another category, e.g. defining a delivery channel using mobile devices will most probably have an impact on the desired (or available) layout options, as well as certain security options. In such a case, one needs to cycle back or forwards in the categories and adjust previously defined requirements. In sum, the typical procedure will be to run through the seven categories in an iterative way starting with a rough idea of requirements in the first round and refining requirements (also considering newly discovered dependencies) in subsequent rounds.

However, there is one question left: What does a non-technical user understand by these categories? A simple feature list is usually not enough, in particular for people whose daily business is not building a BI front end solution. The authors suggest building and using a visual catalog of available options, just like the car-configurator. We call this a BI Picture Book. (More about this in part 2)

A ray of hope for frustrated BOBJ folks

Recently Mico Yuk wrote some tweets to express her frustration about the SAP Analytics (or just BusinessObjects) portfolio and missing innovation:


Wishing someone wld drop a social BOMB on #SAP #analytics << it’s faceless, dry and dead #2012 #honest
No. 1 feedback at #SAPBI12 << #SAP why do we hv so many tools that do the same thing?? << My answer = #SAPHANA Montana .. Feed the monster

It’s also good to note that #SAP copies  tools in the industry & calls it innovation. SAP no longer creates the #BI Joneses. Just follow
(“@pburckhardt: MicoYuk REALLY?? Dom you hv an example??” << #sapvisi looks like Tableau (it’s fairly visible) + Mobile BI is RoamBI knockoff)
The world would be a better place if #SAP skipped this late #Xcelsius #html5 rubbish and just accelerated #SAPzen dev. Avoid all the rework
Probably gym time before I let out what I really think on twitter… About our beloved #SAP #analytics portfolio
I’ve heard many industry folks stare #SAPzen is NOT the silver bullet for #Xcelsius to which I say +1
Dear #SAP #analytics we want innovation like infographic & human intelligence. #BI 5 pillars jargon is a wrapper to hide lack of innovation
While we’re on #SAP #bi 5 pillar talk – what heck is extreme about #SAP #analytics << Stop marketing & start bng true to adjectives please
I think #SAP #analytics should look at acquiring. The wheels of innovation are not moving. We need to be the #BI Joneses again IMO
Dear #SAP #analytics do we even hv a presence or resources in SAP LABS? Coolest ideas used to pop our from there
Our idea of #sap #analytics mobile innovation is re purporsing existing content in #2012 << are you serious? #sadbuttrue
As I implied this week. I don’t doubt #SAP #analytics will get it right? Just wonder how many customers will be left ??
IT is dying at the hands of biz users who r introducing new #BI tools evrydy as #SAPBI lags in basic functionality against its competitors.
As IT is confused on the #SAP #BI toolset they fail to meet biz needs = emergence of other tools IT is forced to adopt bcuz they hv no sltn
Dear #SAP #Analytics pl stop creating tools to compete << instead create tools that lead & hv no competition. #BOBJ used to be this b4 #SAP
Oh yes and #SAP #analytics we’ve lost faith in ur EVER CHANGING not to b confused w/ EVOLVING roadmaps. They mean nthg to biz users = buyers

First of all I can fully understand the feelings behind these lines. I have such moments if I have the pleasure to work with tools from other vendors myself like DigDash. There you find plenty of innovative features (or just basic ones) which we are missing in BO. Like the schedulable PowerPoint export using your own corporate template.

On the other hand I’m currently preparing my session “What’s New in BO 4.0” during our next BOAK event and I’m astonished by many of these new functionalities now available. In this blog I would like so share some thoughts and although it doesn’t vanish the criticism formulated by Mico, it gives at least a ray of hope…

Let’s address this Mobile BI stuff and the comparison to RoamBI. On one hand I agree, regarding visualizations SAP’s Mobile BI app can’t compete yet with RoamBI. And if talking about innovation at SAP BO we are far away from things like RoamBI Flow. Nevertheless I have three things to mention here IMO:

  1. Although I like RoamBI as a gadget, every customer who decides for it must be aware that you “lock” yourself into the iPad and iPhone. Or do you know from any exporting capabilities? As far as I know the tool you can’t even look at RoamBI analytics or a RoamBI Flow documents from a regular web browser. But is it really realistic – at least in the long term of a corporate context – that you want to keep some elements your business people use to take (important) decisions to be accessible just on a iPad? What about legal audits etc.? Anyway, if you need something outside the iPad – then you have to rebuild your content somewhere else, be it BO or another tool. This means a lot of troubles for support and maintenance not to speak of the additional investions as you have to create content twice – for iPads as well as for the rest of the world.
    This is different with SAP’s approach: Although I advise to design your Webi and Crystal Reports documents specifically for the usage on mobile devices, they are still accessible using the regular BO infrastructure. You can schedule and export the documents etc.
  2. What about SAP Streamwork? I don’t know how other vendors deal with that topic or if this is(n’t) a real demand from customers? From a technical persepective I’ve just noticed that the SAP Streamwork integration e.g. into the SAP BI app continues. I really like the annotation feature as well as the possiblity to share it directly with Streamwork. By the way: Did you know that SAP Streamwork is a new scheduling destination in BO 4.0? I personally think a collaboration platfrom like Streamwork is first of all a very innovative thing. And in addition it delivers real added value to companies. I’m not sure how useful all this fancy visualizations are in  real life and beyond “just playing around”.    
  3. I really like the BO Explorer: In terms of analyzing your data I personally like it much better than for example RoamBI. Once again, you are not locked in: There is an equivalent desktop / web edition. And within this web edition you can directly jump to Web Intelligence to further format your results from BO Explorer.

To further insist on that topic: Although from a selling perspective customers are easy to satisfy if you show them some fancy charts, I think there must be more behind. And although I agree there are some lacks of functionality in the BO frontend tools, don’t forget the strong platform they are built on: BusinessObjects Enterprise. Just think about the possibility to turn a Webi table into a Web Service and reuse this either within BO but as well outside. Think about all the options you have to set up a very sophisticated security model and integrate security into highly complex corporate standards. Even if business users don’t care about this – IT has to.

If we talk about security, have you seen the new possibility to add custom attributes to BO accounts and reuse them on Universe level, e.g. for row-level security? Here just a few screenshots:

The same on the Data Integration side: Just look at what is possible e.g. in the Social Media Analytics area – if you can read German see the blog of my coworker Roger Mathis.

Not to forget about Information Steward to manage data quality and do data profiling. Finally a tool even business users (who actually are in charge of data quality) can use.

Finally this brings us back to the question what suits better for a company: A BI-suite or a Best-of-Breed approach. Don’t forget: Many of the above cited tools are niche products. They are strong in certain areas. But in the corporate context you need to think about how to satisfy more than just one user group perhaps. Of course a BI-suite provider is less flexible and perhaps less innovative than a niche provider. But I guess you can’t have everything in the end.

Therefore as consultants and pre-sales in the SAP BO area: let’s tell customers about the “good” stuff in BO too – and show them that real added values goes beyond fancy (and sometimes useless) visualisations.