- SAP Managed Tags:
In a previous blog, I outlined why I thought that the SAPPHIRE announcements about Simple Suite were the equivalent to the move from R/2 (mainframe) to R/3 (client server).
It means that new approaches are possible for all the layers of the architecture. So, companies will have to consider the following:
- Impact of UI changes - How users interact with SAP
- Impact of coding changes - How to develop applications
- Impact of integration changes - How to talk to non-SAP systems
- Impact of platform changes - How HANA impacts how to plan an SAP landscape (this blog)
- Impact of the cloud - How SAP Cloud impacts users
In a series of blog over the coming months, I will consider each of the layers in the architecture and the changes that will be necessary for SAP customers to gain maximum benefit from SAP HANA.
This blog will focus on the impact of HANA as a platform, while future blogs will cover changes to the application architecture, user experience architecture, and integration architecture.
One interesting point to note is that, in many cases, things that were “not allowed” in the old world are now “best practices” in the new one!
How to Adopt HANA
First Step: Understand Where You Will Use It
You must first create a roadmap that maps the benefits of HANA to the opportunities and/or pain points in your organisation. To do this you will need to answer two key questions:
- What are the capabilities of HANA?
- What are the opportunities and pain points in your organisation?
Depending upon your organisation your enterprise architecture team may already have the answers to the second question. If they don’t, then read the various success stories on SAPHANA.com to trigger ideas. For instance, one common starting point is SAP Business Warehouse performance, where HANA can enable near-real time reporting where a non-HANA system may only be able to deliver results daily / weekly or monthly.
As far as the first question is concerned, SAPHANA.com is definitely your destination of choice as it has many guides on the various capabilities of SAP HANA. At a very high level, you could adopt SAP HANA as follows:
- Upgrade existing SAP applications – e.g. SAP BW on HANA, Suite on HANA, Simple Finance, and more.
- Adopt new “HANA only” SAP applications – e.g. SAP Operational Process Intelligence, SAP Integrated Planning, and much of SAP Fiori.
- Use SAP HANA to develop bespoke applications – Utilise the capabilities of SAP HANA to create “custom” apps that deliver competitive advantage – e.g. Burberry Client Telling App or John Deere Predictive Maintenance App.
Second Step: Acquire Skills in SAP HANA
The next step in your journey to SAP HANA (and this can be done in parallel with the first step) is to decide how you are going to acquire the skills needed to architect, design, implement, and operate SAP HANA.
How you achieve this will depend upon the sourcing strategy you have adopted as an organization. If you have selected an outsourced model, you’ll have to work with your partner (or perhaps a new one) to ensure they have invested in SAP HANA knowledge. That way, your partner can give you the best advice.
For an insourced model, you’ll need focused training for your architects, designers, developers and support. Again, SAPHANA.com is a great source for free training, as is open.SAP.com. Also look for SAP HANA certification courses.
Architects and designers will need to learn that SAP HANA is more than a “fast database.” They’ll need to understand the various engines that come bundled in the product—and decide how they should or could be used in the organisation. From an SAP-centric perspective, they will need to stop viewing the database layer as a file store that is only accessed via the application server level. In the old world, direct DB access was seen as negative (and in some cases, it was outside the customer’s database licence). Using HANA, you will only get its full power if you DO access the database (and associated services) directly.
For developers, new languages/concepts need to be learned, such as SAP River RDL, SQL, SQLScript, JavaScript, R and OData.
Meanwhile, the operations team will need the skills to monitor, tune, backup, restore and make data highly available.
The degree to which you have to learn any of the above will depend upon the HANA roadmap created in the first step.
Third Step: Hardware and Software
Based on the HANA roadmap, you’ll understand your usage pattern over the next three to five years. This will help inform the amount of HANA technology you’ll need and how it could be licenced.
A number of options exist. The right one for you will depend upon your usage pattern and your approach to the cloud. At a high level, consider the following options:
- Your own data centre with on-premise perpetual licence.
- A third-party data centre with managed cloud as a service subscription licence.
- SAP HANA Enterprise Cloud with perpetual licence.
- SAP HANA Enterprise Cloud with a subscription licence.
- SAP HANA Cloud Platform with subscription licence.
- Public clouds such as AWS and Azure with perpetual licence.
You should evaluate each option, as your solution could be a hybrid between two models. Using the managed cloud options (HEC and MCaaS) will greatly reduce the need to develop in-house operational HANA skills.
Fourth Step: Create an Implementation Programme
The final part of adoption means creating an implementation plan that addresses your HANA requirements over the long term. This will depend on your current landscape and the versions of software you run. As a general rule, the adoption of HANA under existing SAP applications will require the application to be on relatively new versions of the software with up-to-date service packs.
The other major impact area will be on projects that are in flight, or planned within the HANA adoption window. Any plans for using HANA will need to be dovetailed into these existing plans to ensure you avoid conflicts and leverage new opportunities. (For instance, HANA allows you to use much more of Fiori.)
Conclusion
If you go through the above process, I predict two things:
- You’ll find a use-case and business case to adopt HANA.
- The final landscape at the end of your three-to-five year roadmap will have less boxes and complexity than you have today.
10 Comments
