With the general release of SAP HANA, there is a lot of curiosity on how to break into this market and what skills to obtain by the individual or consulting companies. On the other hand you have customers who are interested in SAP HANA but are not sure yet what skills are required, training available for their staff or where to find skilled resources.
This blog will not go into the depth of SAP HANA and for everyone interested in additional information around SAP HANA I suggest checking out the in-memory and SAP HANA section on the SAP Community Network (SCN) and listening to the podcasts of Jon Reed.
Please note that currently SAP HANA can handle use cases around data mart functionality and thus the skills required are only targeting the capabilities of this version. As SAP HANA will likely evolve from pure analytical engine to transactional we will have to revisit this blog but as there is no clear roadmap on release and service pack strategy it is currently unknown when this will happen and the use cases that can be realized in the future.
When it comes to SAP HANA there are two different types of projects that I currently see in the market place:
- Implementing pre-packaged components delivered by SAP (and in the future partners) for known use cases
- Data Model
- Frontend reports
- Implementing a custom end-to-end solution using SAP HANA
- Use case unknown
- Individual customization
Since I have only participated in SAP HANA Proof of Concept initiatives (I am not aware of productive instances in the US) that focused on custom end-to-end solutions I will use that experience for this blog.
Just like with a real implementation project you need to assemble a team for a POC as well. With a SAP HANA POC in particular it is important to cover your bases right away and understand that there is no specific HANA role or skill set that can do it all.
Since a POC is quite limited in time it is advisable to have highly experienced resources on the team - even if most of them have not worked with SAP HANA before as it will be much easier for an experienced resource to grasp the concepts and inner ways of working of the HANA platform.
Let's have a quick look at a sample team lineup for a POC engagement as we can then derive the skills required of each role:
- Project Manager
- Solution Architect
- HANA Administrator
- Data Services Architect
- HANA Modeler
- HANA Scripter
- Frontend Developers
- SBOP Webi
- SBOP Explorer
- SBOP Dashboards
- Advanced Analysis for Excel
The project manager does not require HANA specific skills but since we know what we want to implement but don't (yet) know how to do it I had good experience using agile project management techniques to run those POC's.
The solution architect is a critical role and is normally a client resource that is familiar with the client's infrastructure, applications and especially the data as it relates to the use case(s) of the POC. If the POC is done with the mindset that the outcome should be re-used for a productive environment then good solution architecture is critical. This role does not have to be a HANA specialist and will help the team with his/her domain and technical knowledge.
The HANA administrator is responsible for the initial setup of the HANA system, updates and upgrades, configuration of system parameters and overall administration and monitoring of the system. You can compare this role with a NetWeaver administrator and in my POCs this role was supplied by SAP with help from client resources trained in BW/BWA administration. Ideally this should be an in-house resource but will currently be supplemented with skilled third party resources.
In this sample lineup we have a data services architect responsible for data provisioning of SAP HANA as this seems to be the most popular method. Depending on the use case this can also be R3Load, SLT or Sybase Replication Server. The resource will need to be familiar with the chosen toolset but does not have to have HANA specific skills. Using data services the resource extracts data from the data source (can be another database or from plain files), transforms the data if necessary and then loads it into the staging tables of HANA.
The HANA data modeler has a critical role in the project. The quality of the data model has a big impact on the overall performance, memory consumption (which is important depending on the data volume and size of appliance) as well as enhancement options and data provisioning integration. This person needs to have experience with advanced data modeling in general and even though it’s not mandatory it will help having SAP BW/BWA experience. Time savings can be huge with a sound foundation for the data model.
The HANA scripter will work closely with the data modeler or could even be the same person - in larger engagements this will be different roles however. This person needs to be proficient in SQL and especially HANA's SQLScript extension. The person will work on calculation views which can get pretty complex. Calculation views allow you to push data intensive processing into the database to improve performance. On my POC's this has been the most underestimated task as at this point you use trial and error to get it right without having reference objects or leading practice guides. This task requires extensive knowledge of the SAP HANA development language features and built in functions.
The frontend developers will develop analytical reports and dashboards with the tools most effectively suited for the identified use cases and even though they don't have to have special HANA skills it proved very useful to do basic knowledge transfer sessions at the beginning of the POC.
Now that we have learned about the roles and responsibilities of the SAP HANA POC team members we can take a look at options to get the necessary skills as they relate to SAP HANA.
SAP HANA documentation released by SAP can be found here but don't expect too much because it is just a first draft and requires a system to go with it - you can't really become proficient by just reading the documentation.
Training courses are an obvious choice with the two day public training course TZHANA offered currently around the world to provide an overview and first hands on experience. If you are considering the training course then please be aware that there is a high chance that the version you will work on is different then what you experience in the class room. This extends to the functionality of the IMC Studio (your main IDE for SAP HANA) as well as language specific features of SQLScript and built in functions.
The available training courses show basic functionality and will allow you to find your way around in IMC Studio and get yourself familiarized with the HANA components. This is to a certain extent expected as we are at the very beginning of the product lifecycle and new features (and bug fixes) will be made available via frequent service pack revisions – in the past revisions got released every 3 to 6 weeks.
A good option is to sign up for a hands-on workshop at the upcoming SAP TechEd as there are sessions offered to cover administration, data provisioning, data modeling and development as well as frontend integration with Business Objects toolset. The sessions are at most 4 hours and even though you are not an expert afterwards it can't be beat in getting your first exposure to a SAP HANA system. The first time you run your own query can be quite an emotional experience - bring your own tissues. It would surprise me if those sessions fill up quickly.
The preferred option however is to have access to a full blown SAP HANA environment for obvious reasons. This is not feasible for most people interested in SAP HANA and especially freelancers/contractors as it's quite a considerable investment.
Even if you have SAP HANA at your company it most likely is not available to everyone as system resources (e.g. main memory) are limited and controlled access is required to run development and testing efficiently.
SAP HANA in the cloud may be an option to increase adoption and allow more people to get exposure to it but in my mind there are certain issues that would have to be worked out first.
Those issues are in the area of scalability (servers and network versus amount of users and data), legality (IP related) and profitability (cost of subscriptions versus cost to run the cloud) and could easily fill another blog or two.
One other option for companies deciding to get SAP HANA and building an in-house team is to get an experienced data modeler that gets trained on SAP HANA and go the route of college grad recruiting for SAP HANA scripters. SQL skills are important for HANA scripters/modelers (mainly for debugging) but more important is to get a grasp of SQLScript which at this point will most likely happen by training on the job.
I hope that by now you realized the skills trap with SAP HANA as currently the options to break into the market are quite slim as well as getting experienced resources - sounds like a Catch-22 and reminds me of the early 90s with R/3.
I am sure that SAP is working on options for the ecosystem that will allow the increase of the adoption of HANA and quality implementations. They need to start with their own workforce to ensure that timely knowledge transfer happens between HANA development and field resources. Improving documentation has to be on the agenda as well together with role based training courses for SAP HANA.
