Over the past several months, I have spoken with a large, diverse group of individuals working for a wide variety of companies that have interest in SAP HANA. In these conversations, it has become apparent to me that there is a critical need for recommendations and guidance on evaluating the need for HANA in any enterprise.

I have put together a phased approach to help enterprises determine if they need HANA, and the key phases and activities within each phase. I’ll show you this roadmap that you can then customize to your needs. My recommended approach for putting together a HANA plan for an organization is shown in Figure 1. It is about a three- to four-month-long exercise that entails significant diligence. It takes you through four phases: discovery, analysis, business case, and implementation roadmap.

Figure 1

An approach to assessing the need for HANA in your enterprise

Phase 1: Discovery

In this first phase, which should take three to four weeks, you need to get as much information on HANA as possible. You can do this through numerous sources, whether online forums, conferences, or conversations with SAP. One of the key outcomes of this phase is to form a good overall picture of HANA. There are a few things that are particularly important to learn:

• The SAP HANA appliance is not the same as the SAP HANA database: the database is a core component of the appliance. The appliance itself is a combination of hardware and software. Any enterprise implementing HANA is neither buying a software package, nor a database, nor a server.
• Although it is only columnar storage that is most commonly associated with HANA, it is actually a trio of three existing techniques on which HANA’s horsepower hinges: columnar storage, (record) insert-only, and compression.
• HANA is a relational database (RDBMS) where records are still stored in a tabular manner. Columnar storage does not imply that there are no rows involved.
• Astonishing as this may sound, there is nothing truly radical about HANA. It is a neatly packaged collection of technologies that has been around and used for many years.
• There is a minimum hardware framework that HANA needs. This is the single-node scenario. Beyond that, it depends on how much your enterprise wants to invest into hardware. If you want scalability, you might want to consider the (more expensive) multi-node scenario. There is no hardware that SAP provides, although SAP has a set of certified HANA vendors from which you can choose.

Phase 2: Evaluation

Once you have collected all this information, move to phase 2. This is the phase that should take the longest amount of time, roughly five to six weeks. You need to assimilate this information with the objective of evaluating the feasibility of HANA for your organization. Over the past several months, I have assembled a list of criteria and questions that you need to analyze. The answers to these questions largely determine whether you want to proceed to the next phase. Here is the list:

Does Your Enterprise Operate in an Environment with Many Mergers, Acquisitions, Divestments, or Consolidations?

There is almost always an increase in an acquirer’s data volumes as new systems are integrated and new data is introduced. Your data warehouse may have just exploded from 100 GB to 4 TB, especially after a series of acquisitions. Meanwhile, information consumers may be expecting the same response time from your queries. If reporting and analytics are a pain point in terms of timely access to information pre-merger, HANA may be a key consideration for you.

What Does Your IT Infrastructure Look Like?

For this assessment, you need to work closely with a knowledgeable resource in your infrastructure department. Your current hardware inventory may have available some or all of what you may need for HANA. In the IT industry, it is very common to come across statements like, “we are an HP shop” or “we are an IBM shop.” Some large organizations use multiple hardware vendors. It is possible that your primary hardware vendor is also a certified HANA vendor. The price tag for your HANA hardware may vary depending on your current inventory and from which vendor you decide to procure.

How Pervasive Is SAP in Your Enterprise?

If you have done your due diligence, you know that in the short term, your organization benefits most if you not only have SAP systems running, but also SAP NetWeaver BW (version 7.3 or higher). Although SAP is increasing its offerings of pre-packaged (transactional) business scenarios for HANA, the area in which HANA makes its greatest impact for the foreseeable future is in analytics. If you are on BW 7.3 (and on at least SP5), you may have the platform to use BW with HANA. In fact, if you are on BW 7.3 but have not implemented the BW Accelerator (BWA), you can circumvent that step altogether by running your BW 7.3 system on HANA. This approach helps you leverage commonalities between the NetWeaver and HANA computing platforms and also helps you reduce some of the maintenance chores that you would normally do in BW.

If you use SAP as one of your transactional systems but do not use BW for data warehousing and analytics, this may not be the right time for you to propose HANA. You may be better off waiting for the time when the SAP Business Suite is enabled to run on a HANA database. Your non-SAP data can also be extracted and replicated onto this database. You could do all your reporting and analytics in real time directly off this consolidated platform powered by a HANA database and application without needing to implement SAP NetWeaver BW. Also, you should consider the key role that BusinessObjects plays in helping you reap tangible benefits from HANA. BusinessObjects BI is well integrated with HANA and will continue to be significantly enhanced and expanded. Also, it provides you with tools for analyzing the data and Data Services provides tools to do ETL of non-SAP data. My recommendation is that if you are currently using BW, you should continue to maintain and upgrade it because HANA will supplement it.

Would You Eventually Consider Switching from Your Current Database Vendor to HANA?

This question is important because SAP’s eventual goal is to position HANA as a database. In this first stage of evolution, your data warehouses can be moved to primary memory for high-speed analytics. A later stage entails moving all the operational and application data (sitting in various databases) to primary memory and in theory everything is then real-time processing. Consequently, at that time, you may have to decide whether to switch from a legacy database to HANA, not only for your SAP data, but for all data. It is too early in HANA’s evolution to plan that far ahead but it’s something to think about for the future.

What Are the IT Skill Sets in Your Organization?

If your enterprise has been running SAP systems for a while, you are likely to have a competent resource pool of functional and technical experts. In the latter category you are likely to have ABAP developers, technical architects, SAP NetWeaver administrators, security specialists, and report designers in your IT organization or servicing it. But the real question is, can any of these skill sets be leveraged or repurposed for HANA? Yes indeed, a good technical architect should be able to use his experience with data modeling, extraction, transformation, and loading (ETL), and so forth. However, HANA entails a lot of different skills. There are specific tools such as the HANA Design Studio that you become proficient with only after being trained or having used it. You need to consider the cost of hiring, contracting, and training resources in doing a feasibility study for HANA.

What Is the Medium-Term and Long-Term IT Roadmap for Your Enterprise?

This strategic consideration is sometimes overlooked in the initial excitement of a new product offering. My experience is the technical subject matter experts (SMEs) in IT departments often tend to be focused in exploring new tools and applications without looking at the big picture. If such a thing does not exist on paper, it must exist in the CIO’s mind or those within the senior leadership teams. Your HANA strategy must align with the goals, objectives, and roadmap of your IT organization. If your enterprise is planning on another major (multi-year) systems integration or business process transformation effort, undertaking a HANA initiative is neither feasible nor practicable. A common manifestation of a misalignment is enterprises that are reducing spend and where IT is almost purely a support service. Such enterprises are highly unlikely to take on capital-intensive IT projects regardless of the benefits that may accrue.

Phase 3: Business Case

At the end of phase 2, you are ready to either move to the next phase or conclude your HANA evaluation with the determination that it is not the right fit for your enterprise, at least not in the immediate future. Assuming you have decided on the former option, you have already done a lot of the groundwork necessary in phase 3. During this phase, you need to articulate in clear terms to senior management and potential sponsors why you think HANA benefits your company. The importance of a clear, succinct business case cannot be overstated. I have spoken with senior IT and SAP architects and middle managers that felt they had compelling cases for HANA implementations in their companies but were not able to present a cogent business case. Some have treated this as a treatise on the technical workings of HANA not realizing that potential sponsors do not really care about the technical matters as much as the benefits. A compelling business case cannot be a long one and should not be more than 15 pages.

If your organization subscribes to IT service management standard Information Technology Information Library (ITIL), you do not need to reinvent the wheel. A business case is an integral component of the service strategy component and a business case for HANA should therefore follow established standards in your organization. Even if you do not subscribe to this model, a business case should have the following framework and components.

Overview

Establish the context for this business case in a brief manner including pain points, research and analysis, and an overview of the approach you are proposing. Explaining the key concepts of HANA based on the work you did in phase 1 is also a good idea.

Assumptions and Constraints

Your analysis and assertions are likely to be heavily influenced by facts and situations (e.g., funding, resource availability, delays caused by partners) that you do not control and therefore could change over time. You need to state these in clear terms.

Details of the Business Case

This is where you need to go into the details of your proposal. At a minimum, you should include an estimated cost, advantages, key metrics, other alternatives, and potential ramifications of non-implementation:

• Estimated cost: You need to be diligent about including all cost components, including hardware, software, licenses, consulting, implementing, training, maintenance, and support. You also need to distinguish between one-time costs and recurring costs. My experience has been that overestimating results in a non-starter, but underestimating can haunt you as you are held to these numbers. Striking a balance and including the necessary caveats is the key. You are likely to encounter your biggest challenge in estimating your HANA license costs. You may have to approach your SAP account executive for a quote. If you do not want to go that route, you might want to check with other companies that share key characteristics with yours and that have implemented HANA.
• Implementation advantages: Focus on qualitative benefits, especially on how well it aligns with your company’s corporate strategy.
• Key metrics: You must provide a return on investment (ROI) projection or one or more of the other metrics such as the net present value (NPV) or internal rate of return (IRR).
• Other alternatives evaluated: Include a comparative analysis with any other alternative you’ve researched. If you don’t, your business case can be misperceived.
• Potential ramifications of non-implementation: Spell out what could the impacts of rejecting this business case be, if possible, in financial terms. You should include the metrics you would already have calculated in phase 2. You should also include the qualitative adverse effects. Some examples of generic ones are not enough real-time information, queries run for a long time, poor ROI if users don’t adopt new tools, and no improvements to the current level of decision-making support.

Risks

Document the risks associated with a HANA implementation, the type of risk, and a risk mitigation strategy. I recommend using a matrix such as the one in Table 1. In it, I have shown a few of the generic risks that your organization may encounter in implementing HANA. You may consider it a scaled-down version of a qualitative risk assessment matrix. In the least, such a repository makes your organization cognizant of the factors to consider in implementing HANA. The more boxes that are checked, the more comprehensive is the nature of the risk. You can formalize it by adding probability of risk occurring, the impact, and any weight or ranking for each risk. In reality, risk identification and mitigation are of greater importance when you are dealing with new products such as HANA. You should also perform a quantitative risk assessment. Your risk mitigation approach can also be expanded to include other elements such as strategies, actions, and ownership.

Table 1

Sample risk matrix for an SAP HANA implementation

Recommendations

Bring together all the information you have provided earlier in the document, summarize, and provide a recommendation. Although your recommendation is a foregone conclusion, you should still state it in unequivocal terms.

Phase 4: Roadmap

Your IT department should spend no more than three to four weeks in putting together a roadmap. Most companies tend to jump from the business case phase straight to an implementation. For small, uncomplicated, internal projects, such an approach might work. However, if you are dealing with HANA, you need to think of not only your short-term approach, but a long-term strategy. As such, you should put together a roadmap with the various high-level activities and timelines.

In Figure 2, I have provided a sample short-term HANA roadmap. Waves 1 and 2 are my representation of a phased rollout of HANA. Wave 1 could entail rolling out HANA to your corporate users, or it could be a proof-of-concept or prototype. Wave 2 could mean rolling out HANA to another division or subsidiary or taking it from a proof-of-concept to a production-ready system. It could also entail expanding its scope to include one or more in-memory applications. Although I have only shown a 1.5-year-long roadmap, you should try to create one that spans at least three years. Once the roadmap is reviewed and vetted by your IT decision makers, it should be presented to the stakeholders and potential sponsors. The goal here is to ensure that you have a clear strategy in mind.

Figure 2

Sample SAP HANA roadmap

Anurag Barua

Anurag Barua is an independent SAP advisor. He has 23 years of experience in conceiving, designing, managing, and implementing complex software solutions, including more than 17 years of experience with SAP applications. He has been associated with several SAP implementations in various capacities. His core SAP competencies include FI and Controlling FI/CO, logistics, SAP BW, SAP BusinessObjects, Enterprise Performance Management, SAP Solution Manager, Governance, Risk, and Compliance (GRC), and project management. He is a frequent speaker at SAPinsider conferences and contributes to several publications. He holds a BS in computer science and an MBA in finance. He is a PMI-certified PMP, a Certified Scrum Master (CSM), and is ITIL V3F certified.

You may contact the author at Anurag.barua@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.