Design Studio Innovation Series - Topic 2: Takeaways from DSLayer Podcast "Into 2015 - Is Design Studio the Dashboard Slayer?"

[MustafaBensan]

Introduction

In this second edition of the Design Studio Innovation Series, I would like to share my takeaways from a recent podcast episode, Into 2015 – Is Design Studio the Dashboard Slayer? of the Diversified Semantic Layer (DSLayer) series, with participants eric.vallo,  jamie.oswald, ahmed.sherif and mike.howles4.

I found it to be a very informative and timely discussion with a balanced mix of opinions, which makes for a good follow-up and contrast to prior discussions on the topic such as What is the future for Dashboards created by the mythical "Business User?" by andrew.fox3 and BI 2014 Design Studio and Dashboards - Looking to the Future by tammy.powlas3.

It is not my intention to produce an exact transcript of the podcast but rather summarise/paraphrase my understanding of the main points and compliment this with related commentary and relevant references for the purposes of further discussion.

Overall, the conversation revolved around where we are today with Design Studio and the transition from Dashboards (formerly known as Xcelsius, which is the more familiar name I'll continue to use in the rest of this blog).

The podcast discussion points centred around four main areas: technology, adoption, use cases and the product roadmap,  so I'll present my summary in that context too.  Although many of the discussion points could easily span several of these topics, I'll try to slot them into a main area.

Technology

Product Features

One question that came up: is the product just palatable or feature rich enough to make it compelling to use?  The view was that there is still a lot of work to be done for Design Studio to achieve a baseline comparable to Xcelsius.  However, the gaps are being filled with SDK components from vendors and community participation.  I think that while there may still be improvements required, the gaps are narrowing with each new major release of Design Studio where features continue to be enhanced and new ones introduced, such as personalisation, bookmarking and fragments.  We have certainly come a long way from Design Studio 1.0.

Architecture

Design Studio and Xcelsius are architecturally very different, with Design Studio being much closer to BEx Web Application Designer (WAD) and Xcelsius being based on a local Excel calculation engine, which represents a completely different development paradigm.

Data Set Size

One important limitation of Xcelsius is the very low data set size supported and performance issues that occur as the data volume increases.  Design Studio handles this much better, although it was pointed out that the Universe data source result set size limit of 50,000 cells (or 5,000 rows) is inadequate, whereas BW data sources have a much larger hardcoded limit of 500,000 cells.  I also think that the Design Studio SDK result set limit of 10,000 cells is too low (the subject of the first blog post in this series). 

Adoption

There were several factors influencing adoption discussed.  I have grouped them below to highlight my understanding of the important drivers.

Target Audience

One of the main issues raised from an adoption perspective was that Design Studio relies heavily on coding and is therefore more of an IT developer tool whereas Xcelsius is an analyst / architect tool, thereby appealing to a broader audience.  My impression was that from the perspective of the typical Xcelsius user, there is a perception of a fear of coding in the transition from Xcelsius to Design Studio.  This perception is what needs to be overcome to encourage significantly higher adoption of Design Studio sooner. 

Indeed SAP has previously promoted Design Studio as an IT Developer or Power User tool for "professionally authored" dashboards and BI apps, although I noticed during the d-code Las Vegas World Premiere of SAP BusinessObjects Design Studio 1.4 presentation last year the new positioning as a "Professional Environment for Designers & Developers to Create Purpose-Built Apps & Templates", which seems to be moving away from the "you need to be a coder" message. 

BI Team Resources

Another perspective on adoption discussed was the typical BI team skill set.  Although it is possible to build basic Design Studio dashboards with minimal or almost no coding, once the requirement includes multiple charts and data sources, user interaction and data refreshes, then a significant amount of coding can be required.  The scripting language of Design Studio is effectively a subset of JavaScript, making it a more difficult transition for the traditional Xcelsius developer.  In particular, the skill mix of the "typical" BI team consists of people with very good proficiency in SQL, Excel and BI tools rather than programmers.  The perception is that this represents too much of a leap, which makes it difficult to upskill team members and convert them from very good tool users to programmers. 

The discussion gave the example of it being easier to convert a Crystal Reports expert to an Xcelsius or Lumira developer than a Design Studio developer.  For instance, a one-hour webinar can be sufficient to get upto speed with Lumira but the perception is that it is not as straight forward with Design Studio.  It was suggested that a 3-day Design Studio for Developers course is required.  The only such official course that I am aware of is BOD310 SAP BusinessObjects Design Studio 1.4 but I'm not sure of the level of detail covered.  

I think the above scenario is especially applicable to the more traditional, non-BW BusinessObjects shops.  Another perspective discussed was that the transition for BW shops was easier since BEx Web Application Designer skills were more readily transferable to Design Studio.  Having a web developer background also complements this, a skill which in my opinion is more likely to be found with WAD developers.

It comes down to which development paradigm is preferred by the audience, more coding-based like Design Studio or more visual like Xcelsius.  In this regard it was pointed out that as much as the robustness and scalability of having an Excel model as the data staging layer for Xcelsius was questioned, this is the very feature that has made dashboard development possible for a much broader range of BI developers compared to Design Studio.  In this context, Design Studio is seen to appeal more to the person with some application developer background but this is not the typical BI developer.  It was suggested that Xcelsius on the other hand was originally built for analysts rather than IT authors, therefore making it easier to use than Design Studio.  

Rapid Prototyping Capability

A key influencer of adoption is the lack of rapid prototyping capability within Design Studio in that it is not possible to connect to mock data.  Instead, a live data source connection is generally required to build an interactive prototype.  In contrast, a major benefit of Xcelsius is the capability to embed sample data in the spreadsheet model for quick and easy prototyping without the need for a live data connection.

Indeed, the gap described above is the very reason why SDK components such as the Bring Your Own Datasource have been developed.

Out-of-the-box Functionality vs. SDK Components

A major factor in the success and adoption of Xcelsius has been that it simply works out of the box because it includes a comprehensive set of standard components that meet typical dashboard development requirements.  In contrast, since Design Studio is still playing catch-up there can be a need to use SDK components to achieve functionality that is on par with Xcelsius.  There is a reluctance to use SDK components because the expectation is that the functionality to put Design Studio on par with Xcelsius should already be there and available out of the box.  Even if SDK components are free, it is seen as extra effort to install and maintain.  There can also be a reluctance to attempt to code SDK components internally because of the effort involved, particularly when the expectation is that the functionality should be there in the first place.

I agree that ultimately the gap between standard components across Xcelsius and Design Studio needs to be closed or at least significantly narrowed and expect this will happen in due course.  Nevertheless, personally I am a big fan of the Design Studio SDK and see it as an enabler for significant innovation to complement standard functionality, whether such components are developed internally, by the community or commercially.  To this end, the Design Studio SDK Development Community has contributed a significant selection of components to help narrow the feature gaps.  A summary of Commercial and Community components is provided in the List of Design Studio SDK Components.   

And for those of you who would like some interesting reading about the benefits of add-ons and the 3rd-party component dilemma, I can suggest the following blog posts which I came across some time ago but remain relevant today:

Irrational Dislike of Product Extensions

Enabling professional web and mobile analytics with Design Studio 1.2 and Add-Ons

Use Cases

New Development

For new development, consider Design Studio first.  If you're thinking about Xcelsius then think carefully about your requirements, especially if the underlying reason is for that animated chart or "shiny object" (or "bling" as some may call it).  Is that really a good use case? 

A question that was raised for new development was whether it was possible to take an Xcelsius dashboard and convert it with one hundred percent matching functionality to Design Studio?  I think this is certainly feasible for simple dashboards.  For more sophisticated ones though it was pointed out that the use of the SDK may be required to achieve comparable functionality and simplify usability for end users.

From a BW shop perspective, moving to Design Studio was seen to be very beneficial in terms of future state maintainability and simplification of the data layer which otherwise in Xcelsius required WebI blocks to be exposed as BI Web Services connected through Query as a Web Service and then scheduled to create WebI instances, which was a laborious process when making changes.  On the other hand, for pure BusinessObjects shops the benefits didn't seem to be as clear cut, with difficulty in generating interest and use cases for Design Studio.

Self-Service

Another observation was the increasing demand for more self-service discovery tools like Lumira over Xcelsius or Design Studio, where users simply require access to the content of a traditional dashboard but with more data discovery capability.  However, the term self-service can also be misleading in that it can have different meanings to different users: ad-hoc analysis for some, scheduled reports for others and guided analysis for yet others.

The potential for compelling use cases for the interoperability between Lumira and Design Studio, whereby an analysis could start in Lumira then be handed over to Design Studio to present the data as a dashboard and then provide links to launch Lumira again for more detailed analysis and drill down, was seen as a benefit.

Analytic Apps

A further discussion point was the desire in the past for Xcelsius to become more of a tool for analytic app development with features such as writebacks and better interaction between dashboard components.  Design Studio seems to be heading in that direction.  One frustration expressed though was that with Design Studio it is still difficult to develop analytic apps that have the same level of sophistication, interactivity, performant switching between screens and responsiveness on different devices and form factors compared to purpose-built apps developed with other platforms such as UI5, Java or .NET combined with the D3 library.

Design Process

From a design perspective the following suggestions were made:

1) Increasing the Level of BI Maturity

There are benefits to an increasing level of BI maturity in an organisation whereby rather than simply trying to rebuild the same complex Xcelsius dashboards in Design Studio, it can be an opportunity to simplify requirements gathering and dashboard development by reducing the number data sources and density of information.  I think here, you could even take the approach of breaking a complex Xcelsius dashboard into several simpler Design Studio dashboards that each focus on a particular area with a more specific purpose.  So it can be a case of becoming better at managing the demand and simplifying the design.

2) Careful Design

Both a well thought out database design for aggregating summary data and a well thought out dashboard design for usability are required.

Roadmap

The Design Studio Roadmap was recently updated and I think we have a lot to look forward to.  In particular, I was happy to see the following new additions:

• Data-bound Component Properties
• SDK Enhancements: attribute values and exception levels exposed
• Offline Dashboards
  
• Local Calculations and Projections
• Formatted Table / Scorecard
• Improve Mobile Experience
• Improve Designer Experience

I think the local calculations and projections, combined with the improved designer experience (reduced need for scripting in common interaction patterns) should alleviate the issue of reliance on coding discussed above as a barrier to adoption and encourage a larger transition of the traditional Xcelsius developer base to Design Studio.

Two main points related to the roadmap were discussed during the podcast:

1) Migration Tool

The Xcelsius to Design Studio migration tool which appeared on the roadmap for a long time has disappeared from more recent roadmaps.  This is not entirely surprising given the difference in architecture between the tools and the complexity of attempting to convert the Excel-based development model of Xcelsius to the script-based one of Design Studio.  I imagine in the end building a usable migration tool has proved to be unviable. 

2) Legacy Content

While it is possible to deprecate and converge tools, it is not possible or desirable to deprecate content. (This is also consistent with SAP's communication about the Convergence of the SAP BusinessObjects BI Product Portfolio).

So given the above, there is no need to recreate all Xcelsius content in Design Studio and there is less of a reason to start new development with Xcelsius.  Some of the important Xclesius legacy dashboards could be redeveloped in Design Studio as a proof-of-concept with a view to continuing new development with the latter.

Conclusion

In the end, maybe this blog has turned out to be a little more than just a summary but hopefully it conveys the intended essence of the podcast, with the addition of some food for thought.  To wrap up, I think the important conclusions drawn from the discussion were:

• For BW shops it makes considerable sense to develop with Design Studio where possible

• For pure BusinessObjects shops (i.e. BW agnostic) the argument for Design Studio is not as strong and a very specific use case combined with the right internal resources is required to choose Design Studio over Xcelsius.  The perception is that converting all Xclesius developers into Design Studio developers is unrealistic for most customers (although I think the code-minimising featuresin the roadmap discussed above should help)

• There needs to be a non-application developer experience in Design Studio if there is to be a successful phasing out of Xcelsius and transition to Design Studio with the same kind of uptake (again I think the Improved Designer Experience added to the roadmap will assist with the transition and accelerate adoption)

• To increase adoption, Design Studio must have the ability to build a reasonably comprehensive dashboard without any coding, with coding still available for when there is a requirement to go above and beyond this.
  

Comments and feedback are welcome.

Blog Series Index:  Design Studio Innovation Series - Welcome