It wasn’t a long time ago at an SAP conference in 2013 that an impromptu discussion with fellow attendees resulted in a lengthy and interesting debate on the impact of HANA will have on SAP’s Business Warehouse (BW). The discussion was initially centered around whether BW has any future in the Business Intelligence (BI) landscape that will be driven by HANA. We drilled into the pros and cons of a packaged EDW solution (like BW) vs. classic custom-built data warehouse solution on HANA. We also discussed about how BI organizations should be ready to face the changes that will follow. These were relatively early days of BW on HANA and the discussion was based on a few predictions and a lot of assumptions.

Fast forward to present day, things have become clearer in the meantime:

• Embedded Analytics allowing the possibility to perform analytics right in the OLTP environment (S/4 HANA) in real time.
• The transition from classic BW to BW on HANA to BW/4 HANA (and/or SAP HANA SQL DW) resulting in a much-simplified and flexible BI architecture.
• Flexibility to integrate data across systems with HANA Enterprise Information Management (EIM) that includes techniques to connect non-SAP data sources like Hadoop and others virtually.
• Lesser dependency (or no dependency in case of BW/4HANA) on BICS for information delivery, resulting in better integration with third-party analysis tools (e.g. Tableau, Power BI)

Business Intelligence development standards, processes, controls and security: The possibilities for data acquisition (and virtualization), modeling and information delivery has set the BI solutions free to be designed beyond the boundaries of dimensional and content based modeling (as offered by conventional BW). Keeping this in mind, I think it is time to revisit the following:

• Defining development and architecture standards for the new generation of BI solutions and data warehousing. This also includes the definition of integration standards at various levels (data level, meta data level, UI level)
• Modify/redefine the change control process that supports the approach to BI delivery (I will expand on this topic later in the blog.)
• Explore information security and access control. Multiple access points to the data and models imply expansion of the security and access control framework to comply with the future state of BI architecture. Native analysis authorization from BW should be complemented with securing the data access (persistent or virtual), securing HANA models/tables, and access control for reporting from third party reporting tools. In case of an integrated reporting setup (with multiple frontend tools), the need for single sign on (SSO) should also be evaluated.

Business Intelligence Delivery Model: BI literate user groups and the rise of self-service exploration tools (such as Lumira, Tableau) are helping build elevated expectations from BI. From my recent experiences, I have seen customer IT teams playing catchup with these expectations. The succeeding question that comes up is whether the BI delivery methodology from the past is fit to meet future requirements and expectations. Agile BI is the a frequently discussed term in this context. While being agile is a relative term, I think there is a consensus that slower delivery of BI solutions and on demand access to enterprise information has been a consistent challenge in BI adoption. Faster turnaround time and self-service framework are the next logical areas of improvement in this case.

• In the realistic scenario, the BI requirements do evolve based on the knowledge of previously delivered report/analysis and constantly changing business needs. The conventional release based delivery has always struggled to adopt to this. Development approach should become more iterative and change control process more adaptive of these needs. It certainly doesn’t advocate giving up all the controls, but the point is to see the delivery in different perspectives (architected solutions vs. self-service).
• While the concept of BI delivery factory seems logical here, it is tough to achieve until customers evolve from conventional project based funding and execution model to a model that allows a continuous proactive engagement with the business rather than reacting to the needs.

Priorities of support framework: The leaner architecture, real-time replication, and reduced need for persistency is resulting in shrinking batch window. Plus, further automation of the monitoring processes (e.g. alert driven monitoring, SLA triggers) will continue to reduce the risks around system and data availability. The conventional BW support team bandwidth typically reserved for data load monitoring and housekeeping activities will go down and thus there is a need to repurpose that bandwidth towards the new service levels (SLAs) and KPIs for application support which are BI service driven. This includes self-service support for users as well. For departments with BI embedded in their day to day decision making, the information needs consistently vary in terms of how the information is looked upon and in terms of the context of analysis. This will fuel the urge to have control on the data by creating an offline storage. The need for self-service and exploratory BI evolved from this situation. The constraints from the classic BW era are dissolving fast with HANA based innovations. Thus, enabling a true self-service BI environment has become a possibility without adding much overhead on the governance. What it essentially means in the operations model must renovate to strike a right balance between standardization and flexibility.

Virtualization, Integration of BI systems and importance of data quality: I am not highlighting anything new here by mentioning data quality. This has been one of the primary success criteria (a major pain area as well) for BI. However, this challenge is overcome in classical EDW scenario by means of deploying the data cleansing and harmonization layer. The BI architecture is more inclined in retaining the data as close as possible to the source version and runtime data/metadata integration for analysis. It means having a persistent data cleansing and harmonization step is not always on option. The data that is more likely to remain distributed would need high level focus on maintaining the consistency of information and uniform interpretation of data across systems. The role of data stewards is more crucial than ever that can be accompanied with coaching BI users interpreting the data in a right way for the purposes of self-service and data exploration. Central BI team taking the ownership of maintaining the repository of KPIs, measure and dimensions will also help the cause.

Skills and People: Finally, the impact on the BI team and skill requirements expectations cannot be ignored. As I mentioned earlier, the role of BI support team would be more than monitoring and incident management. An ideal skill composition for BI support would include core BW, HANA modeling, SQL and frontend skills. Additionally, I also support the idea of having a team, with understanding for business processes, continuously engaging with business groups on identifying and defining BI solutions. This team is not likely to be pulled into day to day operations, but should be focused on business solutions.

Truly, the innovations in past few years have provided us the tools to transform the future data warehousing and BI. The impact is not limited to just the technology and architectural transformations, but this will also impact on the BI solution delivery process, usage, adaption, and operations. Customers who adapt sooner will be able to reap most of the benefits in years to come.
If you need a trusted advisor to sort out how to get to the next generation data warehousing, contact us.