HANA is fast, not least in reducing development cycles
HANA is fast. But there is an aspect where HANA is fast you may not have expected, and that is in speed of development.
Imagine this: on Friday morning an executive meeting is held where a new short-running corporate initiative is kicked off. This initiative needs analytic support to track progress and make sure that it has the desired effect. The CTO tasks one of his resources to put some dashboards together that in one view show how we’re tracking against a number of chosen metrics. This should be live by Monday. Luckily, the data needed for this is already in HANA. The IT resource identifies the relevant data elements, creates an analytic view, generates a universe and develops a couple of dashboards in the afternoon. By close of business Friday, a mail goes out to the executives with a link to the newly deployed dashboards…
This is not fantasy. As part of a performance test project in the Co-Innovation Lab in Palo Alto, I was presented with a HANA appliance that had data already loaded in it. I developed an Analytic view, generated a SAP Business Objects universe, and then used that in Web Intelligence to produce four test reports. The entire process took me…. no more than four hours.
Isn’t that incredibly powerful? It means it is now feasible to quickly stand up support for even short term business initiatives. We’re not talking about cutting development of a data warehouse from 3 years to 6 months. We’re literally talking about hours and days.
This is just one example. I was recently involved with a customer discussion around their BI strategy. They had been burnt on prior attempts developing an Enterprise data warehouse, and settled on a combination of physical and virtual databases brought together in a main staging area, with the idea to build dozens of data marts on top of this for specific business functions, as the need arises. This is of a much bigger scale, but the principles are essentially the same: with data already present in HANA – either physically or through virtualized tables through Smart Data Access – we can easily model new views for very rapid development of analytic content.
Of course, data warehousing purists will shudder at this approach. Operating like this in a relational database platform world would likely suffer from major performance problems. But with HANA this approach remains highly flexible throughout. In a relational world, putting physical data structures together which are then populated through Extract, Transform and Load (ETL) jobs requires careful planning and design, and is tough to change. Compare that to HANA: As we do the modeling, we’re also doing the equivalent of the ETL at the same time. Since developing the ETL processes often constitutes a major effort in data mart development, cutting that whole aspect out dramatically reduces development timelines.
Of course, it won’t perform quite as fast compared to a streamlined star schema, but a slight degradation in performance can be an acceptable trade-off. Therefore, in cases where speed of implementation to support changing business requirements is more important than blistering speed of performance, this approach can be highly effective.
Since modeling views in HANA Studio does not require complex ETL development, as long as data is already inside the system, developing new analytics for specific business purposes is very fast. This allows you to respond to new business requests for information within hours and days, rather than weeks, months or years.
For more blogs about SAP HANA Services, click here.
To learn how SAP Services can guide you on the road to SAP
HANA, click here.