Skip to Content

                                                                                 game changer.jpg

        Image Credit: http://www.verticalresponse.com/blog/wp-content/uploads/2012/11/iStock_000019901721XSmall1.jpg

As we all know, Jan 10, 2013 was a remarkable day for innovation enthusiasts. Several people were excited and pleased with the announcement. At the same time, there also appears to be a disconnect between SAP leadership & a majority of customers. This is not totally unexpected because of the drastic changes SAP-HANA is expected to bring.

Based on my experience & observations, I compiled a few questions on SAP’s commitment to support traditional databases.

Exadata/Exalogic

What is Exadata/Exalogic?

Exalogic and Exadata are very similar, with the major difference being that Exadata is optimized for running the Oracle Database whereas Exalogic is optimized for running Oracle middleware and applications. Much of the technology that comprises Exalogic came from Exadata. Exadata is the preferred platform for the database(s) behind Oracle Commerce because of its performance, reliability, advanced connection capabilities to Exalogic, and overall total cost of ownership. Oracle Commerce is fully certified to run with Exadata and requires no further optimizations to take advantage of Exadata.

                                                                                                  Source: http://www.oracle.com/us/products/database/exalogic-and-exadata-1893933.pdf

I can think of four types of SAP customers on Oracle DB:

  1. Currently using Exadata either in combination with Exalogic or standalone
  2. Currently implementing Exadata either in combination with Exalogic or standalone
  3. Currently considering Exadata or Exalogic in the next year or two
  4. and others who plan to stay on non-Exadata Oracle environment

What are the options for them?

Before I discuss my thought on options they have, let us discuss the characteristics of Exadata/Exalogic.

Both Exadata and Exalogic are engineered systems from Oracle – Exadata optimized for databases & Exalogic optimized for current SAP application. Exalogic As I understand it is nothing but a group of application servers(for our discussion, this simple definition is good enough!) integrated tightly with exadata to provide superior level of security, reliability and performance. Exadata on the other hand could be configured/purchased with lot of memory (4TB maximum when I checked last) so data can be processed at the DB server quickly.

Exalogic, as you can see, would be a good option as long as the business logic stays within the application. If business logic is moved to the DB server(Exadata) as SAP explained on Jan 10, then Exalogic would be underutilized – not little but almost none of capabilities of Exalogic would be utilized. That’s not the only issue;we would need to add more capacity to Exadata. And Exadata is not cheap.

Type 1 customers would incur more cost to add more Exadata capacity while not utilizing what they already have, Exalogic.

Type 2 customers would have to decide whether to continue with the implementation or terminate or put on hold.

Type 3 customers are probably in a better position than (1) & (2) but still need more information to make an educated decision

Type 4 customers should also be concerned with #SAPonHANA announcement as SAP’s direction is probably going to impact them. Read further.

Z programs  

As we all know, customers have either customized and/or developed programs in Z namespace. They normally pull data from the traditional databases and then process them in application servers using application server’s memory & CPU. Since SAP is planning to push logic to DB server, I presume they would need to be rewritten. SAP might provide one or two options:

  • Switch all programs to new mode immediately or
  • Switch Z program one by one.

Switching all programs to new mode immediately would allow customers to downsize their application server capabilities. In virtual environment, they could easily move resources from application server to DB server. In this scenario, they can accomplish two objectives in one step. The downside is disruption, cost & efforts to rewrite code. Some code I know was written several years ago with little or no documentation. Rewriting that code would take time, lot of efforts & money.

Switching Z program one by one would be a good idea but then customers should plan on retaining major portion of application server capabilities while upgrading DB server capabilities. This is not only going to be expensive but what would they do with obsolete application servers after all Z programs are migrated.

Scalability

As I explained here, SAP relies to a great extent on their own architecture to provide scalability.Would SAP be able to move scalability along with business logic to the DB layer?

Advances in Technology      

Dr Hasso Plattner mentioned the business logic could be moved to the database servers due to the advances in Technology. I wonder what they’re. True, we can add more memory to DB servers;however, we also know, adding more memory is not necessarily going to improve or help implement business logic on database server. I’m sure customers would be curious to know what technology advances he referred to.

SAP-HANA Environment for New Development

SAP-HANA as all know, is completely different from the traditional databases. SAP announced they would, going forward, use SAP-HANA for all their development requirements. If all SAP development team will have access to is SAP-HANA, I’m not sure how they would be able to write code to support traditional databases. In current scenario, the developers probably don’t have access to all databases. However they probably have access to a product whose fundamental architecture is not entirely different from other DB products. As I understand it, in order to make SAP compatible or take advantage of vendor-specific DB features, SAP & the vendor work closely in Waldorf,  Germany.

SAP mentioned since SQL is common to both traditional and SAP-HANA environments, they alluded they could continue to develop programs to support all databases. However the way data is processed is completely different between SAP-HANA & other traditional databases. Even when (if) SAP delivers Stored Procedures for traditional databases, all data is still going to reside in the storage disks. And read/write operations will continue to be a bottleneck. And then there’re architectural differences between SAP-HANA processing and tradiitonal database processing.

Innovation Without Disruption

Dr Sikka provides growth of a city (such as Shanghai, China) as an example to explain “Innovation Without Disruption”. That is a good explanation. When a city grows, there’s definitely a certain level – not a major one but still – of disruption. For example, when a city constructs road or adds additional lanes, they close a portion of road for a certain period of time. Sometimes the construction workers work in nights to minimize the disruption. This level of disruption is understandable & acceptable. Considering all issues I discussed in this blog, it appears SAP-HANA is going to disrupt a little more than “growing city”.

z/OS DB2

I worked on SAP on DB2 on z/OS several years ago. At that time, z/OS (CPU/Memory) used to be very expensive. I assume it still is expensive. In my opinion, SAP’s decision to move business logic to DB server would probably have a bigger impact on z/OS customers. I may be wrong but for some customers, the need to upsize their z/OS environment could warrant a change in their direction because the customers I know are trying to find a way to downsize their z/OS environment. And upsizing z/OS environment is not cheap.

DB Server Sizing

How much memory and CPU would new DB server require? Depending on this answer, some customers may need to retire existing servers and replace them with the latest servers so they could upgrade to whatever level new code dictates.

SAP-HANA Maturity

SAP began this year really well. They showed significant level of confidence in SAP-HANA. That’s promising. At the same time, we’re not sure how long it would take before customers start running their mission critical applications on SAP-HANA.

Training

In addition to all other issues discussed, customers also need to plan to not only train current employees but recruit qualified human resources to support SAP-HANA. This is going to be a challenge on many levels:

  1. SAP-HANA is still evolving specifically application development standpoint. In IT,we all know, technology continues to evolve. However SAP-HANA is evolving faster than other technologies. When should customers start spending money on training?
  2. Should customers wait for some more time before deciding whether to migrate to SAP-HANA, or train employees first?
  3. Not sure what other vendors are doing. Even if other vendors deliver SAP-HANA like technologies in near future, would SAP be as open as in the past to integrate with SAP? Here SAP definitely has a distinct advantage: They know application. So both SAP-HANA and the application could be developed to take advantage of each other.

SAP-HANA Versus Status Quo

I wish traditional DB vendors would start telling customers why Status Quo would be a great idea. So far, I’ve not read any blogs or articles or announcements from other DB vendors explaining why customers should stay with disk based RDBMS. I hope soon they would come out and offer their opinion so customers would be better educated on very important decision: Migrate to SAP-HANA or stick to disk-based RDBMS!

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply