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:
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!
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:
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:
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.
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:
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.
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.)
If you go through the above process, I predict two things:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
3 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |