How will the enterprise mobility space play out?
TAKE NOTE(Insights into SAP solutions and EmergingTechnology)
I recently had the opportunity to meet with about 40 executives from a large international construction company. They operate in many different countries and you won’t be surprised to hear that they have a complex application environment. I’d ask someone a question like “How do you keep track of tools and supply inventories at various sites?” and invariably, the “answer” was a question – “in which country?” or “for commercial or residential?” or “for corporate to track it or the site managers?”
They made it clear that while they had a myriad of needs for mobility, there were process differences, regulations, and legacy investments across their operations that made it hard to roll out a single technology solution to any particular business problem.
They did mention that they used Business Objects as their standardized reporting and analytics environment, and all said that a key requirement was that the tool that could work across everything. Fundamentally, it’s too complicated to implement specialized reporting tools across every different system – and it is too tricky for users and expensive for IT.
That got me thinking – are there lessons that enterprise mobility experts can learn from the Business Intelligence (BI) market and the differentiators that customers truly value?
Back to the future
I spent many years of my career in the Business Intelligence market at companies like Hyperion, Pentaho, and the aforementioned Business Objects. The more I learn about Enterprise Mobility, the more I see parallels to Business Intelligence.
From my view, there were three key elements that allowed BI to flourish, and the same dynamics apply to mobility.
Value-add – Extending the value of existing investments
Openness – “Playing nice with others” in a heterogeneous IT environment
Focus – Product advantages in functionality and ease of use
Where we go from here
If you accept the parallels, it’s reasonable to expect that mobility will go through the same evolution, and ultimately succeed because of value-add, openness, and focus.
The 3 major phases will be:
Disappointment – Companies who evaluated systems based on desktop functionality and think of mobile as a “checkbox” will be disappointed in the same way companies that treated reporting and BI as a checkbox. “It sounded cool and demoed well, but doesn’t work for our users,” will be the refrain.
A Search for Standards – Companies will realize that while different solutions are needed, a plethora of disjointed solutions will create its own problems for users as well as IT budgets, and they will look for a single solution for every use case under the sun.
Mass awakening – Companies will realize that mobility is also like BI in that different solutions are better suited to certain use cases. They will end up picking one solution that’s a good fit for most of their needs and will use specialized solutions when needed.
UNDER DEVELOPMENT(Information for ABAP Developers)
The ABAP Developer Road Map to SAP HANA
Chances are that if you work with SAP ABAP, you have heard of SAP HANA by now. You’ve probably heard that it’s “the future” and a “game changer.” You’ve also probably heard that it’s much faster, and it can take tasks that require hours and finish them in minutes. This all sounds wonderful, but technical folks understand that nothing works by magic. What we would like to know is not the what, but the how. What exactly is SAP HANA? How is it able to bring such dramatic improvements to our programs? And finally, how will switching over to SAP HANA impact me as an ABAP developer?
SAP HANA Overview on a Technical Level
SAP HANA is a platform that serves to replace the classical hard disk baseddata storage system with an in-memory alternative. The SAP HANA Acronym stands for (High-performance ANalyticAppliance). While HANA serves as a replacement for classical hard disk basedstorage systems, it should be understood that it is more than just a replacement. While HANA can perform any and all features of a traditional DBMS, it also provides many benefits that a classical database server does not. Let’s begin our overview of SAP HANA by contrasting it to the traditional DBMS.
As a refresher, let’s recall how a classical database works. A DMBS manages an array of HDDs that store data in a row based format. Using INSERTS, READS, UPDATESand QUERIES, the database allows users to persist, retrieve, and manage data on demand. The principle drawback of a classical database is the fact that it uses HDDs. Reading, writing, and searching using HDD are an inherent bottleneck to any classical database. Hard disk drives are mechanical devices, requiring a rotating magnetized platter that stores binary data, and a read/write head that accesses and reads that data.(see below)
Although many advances have been made over the years to improve HDD technology speed and storage capability, the HDD can never match the speed of computer memory. Enter SAP HANA and its in-memory data storage. By storing the vast majority of data in memory, HANA sidesteps the costly action of reading data from HDDs to provide data to users. Since retrieving data from computer memory is 100,000 times faster than retrieving data from HDDs on average, the speed increases are exponential and instantaneous. Simply changing the architecture from HDD based to memory based storage is enough to provide drastic speed increases on its own, but SAP HANA takes it a step further by providing features on top of this in-memory platform. This allows for even greater speed of access, data retrieval, and data processing.
SAP HANA Architecture
SAP HANA and Column Stores
A major difference between SAP HANA and traditional databases is that HANA uses column-store for most database tables, while classical DBs use row-store. The row-store approach works well when you often need to retrieve an entire record from the database at the time, but as ABAP developers know, it is much more common to retrieve a subset of fields during processing. In addition, row-storage often provides only two options when searching a non-primary field. You can either create secondary indexes to speed up data retrieval or risk performing full table scans when retrieving data outside of the primary index.
Read Full Post at itpfed.com
Q&A(Post your questions to Facebook or Twitter and get the answers you need)
Q.We are migrating our DB to HANA and I had a few questions. I have been working in the BW/BI area of SAP using something called BWA (Business Warehouse Accelerator). I believe this is also an in-memory solution. How does BWA differ from HANA? And secondly, can non-SAP solutions use HANA?
A.Really good questions! let’s take each one in turn…
How does BWA differ from HANA?
SAP BW Accelerator (SAP BWA) is an in-memory accelerator for BW. HANA is a full featured in-memory platform. BWA was specifically designed to accelerate BW queries by reducing the data acquisition time by persisting copies of the Info Cube data in-memory. SAP BWA is focused on improving the query performance of SAP Net Weaver BW. SAP BWA can be used today with any SAP BW 7.0 release and above.
SAP HANA is an in-memory appliance and platform for delivering high-performance analytics and applications. As such, it includes a full-featured in-memory database. Data can be loaded into SAP HANA from SAP & non-SAP data sources and viewed using SAP Business Objects front end tools. In the near future, SAP HANA will also act as an In-memory database that will power SAP Net Weaver BW 7.3 and above. In this way, it will be able to dramatically improve the overall performance of SAP Net Weaver BW by combining the value proposition of both the database & BWA into a single platform.
Can Non-SAP solutions use HANA?
Absolutely! The beauty of SAP HANA is that it caters to both the SAP applications & Non-SAP applications world. Even during the ramp-up and pilot phases, Non-SAP applications customers can use SAP Business Objects Data services to load data from Non-SAP systems into SAP HANA and used SAP Business Objects BI tools to gain better insight into their data at very high speeds.
A “classic” example of this could be a Utility company loading smart metering data in near-real time into SAP HANA and running complex calculations to determine whether they should buy or sell power from/to the grid. This has a huge impact on their profitability and could be solved easily with SAP HANA.