Vendors Survival: Software AG's IDS Scheer acquisition - revisited

In a previous post I asked the question: Will Software AG survive until 2019. 

The intended acquisition of IDS Scheer was the trigger for writing the post.

On October, 23 the intention was translated to Software AG's acquisition of 90% of IDS Scheer.

Future applications: SaaS or traditional?

After hearing a podcast of Dana Gardner's interesting interviewing Aneel Bhusri Workday CEO,

I tried to figure out what went wrong in the transition from traditional applications suites composed of large components to Service Oriented based application suites.

In 2003 I had to present Giga Information Group's view in a local ERP conference in Haifa.

A presentation by Giga's Analyst (and afterwards Forrester Research Analyst) Byron Miller titled: "ERP Technology Is Going Mainstream" was used for that purpose.

The presentation depicts three possible future ERP states:

Suite State – proprietary vendors suits.

Industry or Vendor Ecosystems – more evolved standard based suits.

New B-O-B World – standards based Best of Breed state. Use of ERP components from different suits is possible because of the standardization.

New B-O-B World is the most desired state; however according to Giga's prediction the most probable future state is Suite State.

I am not sure if SAP's and Oracle's initiatives to transform their ERP suites to Service Oriented suites are attempts to move to Industry or Vendor Ecosystems state or to New B-O-B World (I suspect that their goal is to build a Service Oriented Ecosystems and not a New B-O-B World), but so far the initiatives are far from being successful.

One of the best ways to save money during the recession period is to delay ERP upgrades. Delaying ERP upgrades could save millions of dollars. In a Case Study presented in Gartner Group's Architecture Webinar, an organization saved 2M$, by delaying an ERP upgrade for 3 years.

The reasons to postpone an ERP upgrade during Recession are obvious: It is not strategic and it is expansive.

Compare these upgrades with Web 2.0 or SaaS applications upgrade with no user responsibility, resources and efforts. Aneel Bhusri talked about a version upgrade of Workday Hr application about once in 3 or 4 months. Google as well as other Web 2.0 vendors do not even have versions for their SaaS applications at all (see my post Web 2.o for Dummies: Part 4: What is Web 2.0?).

I do think that ERP and other Core Applications vendors have no choice: In order to be Agile, Future applications should be Service based applications, but how would these applications be transformed to services.? The hard way is by decomposing current Component based ERP systems to services by Fusion project, partially Java rewrite of ABAP applications and similar initiatives. The easy way is to start fresh Service based single ERP or CRM application such as SalesForce.com, Workday or Netsuite and extends it gradually.

The other side of the coin is the functional gap between current ERP and the SaaS based solutions, but this gap could be closed in the long run.

Oracle's Exadata 2: Analytic and Operational Database in a single machine

More than a week ago I wrote a post on Oracle-Sun hardware in the light of Exadata 2 announcement. This announcement did not change my view before the acquisition and right after the Sun acquisition: Oracle is not a hardware vendor.

This post is more technical than the previous posts mentioned above.

Storage Hierarchy

The schematic illustration above depicts schematically Storage Hierarchy. It includes internal memory, as well as external storage.

The top of the hierarchy includes small, fast and expensive storage types, so the amount of storage of that types is limited. Sometimes the amount is also limited by technological constraints. As we proceed down the hierarchy the storage is cheaper and the amount of storage of that kind is larger, but the time required for accessing it is longer.

The illustration does not show size ratios it shows only size order from smaller to bigger. It also does not differentiate between slow and slower storage included in the bottom box. Size and speed of the storage types included in that box may vary significantly.

Software systems such as Paging systems for internal memory and archiving systems for external storage aim at optimizing the use of the storage hierarchy on a principle of Least Recently Used (LRU): the least recently used content is moved to a lower and cheaper storage, based on the assumption that an element that was not used for a long time probably will not be used again.

For optimizing the movement of elements between different storage level hierarchies another principle is used: Locality of Reference. There is Locality of Reference if after using data the system will use again the same data or a data located close to original data in memory. For example, if a banking system moves customer data from disk to memory for executing an online query, it is reasonable that a related transaction by the same customer will follow the query and probably use at list part of the data used for the query. Finding the data in a higher level memory and not in a disk will accelerate the transaction.

On the other hand, usage of a relatively small storage level such as a Cache with no Locality of Reference could result in large amounts of elements movements from a faster level to a slower level of the storage hierarchy. Those movements, called Thrashing will diminish the benefits of a Cache or other high level fast storage.

Analytical Data Warehouse/ BI systems vs. Operational Systems

There are significant differences between Data Warehouse (DWH)/ Business Intelligence (BI) systems and Operational Transactional systems. Analyzing these differences is beyond the scope of this post. For analysis including technical as well as cultural differences between DWH/BI systems and Transactional Systems, read one of Ralph Kimball's books. However, the following bullets describe briefly major differences related to Storage Hierarchy:

• Read/Write Ratio – DWH/BI systems are almost read only and Transactional systems Read, Write and Update. Based on my experience I would expect a 20% or 30% of the IO operations to be Write/Update operations. The processing of DWH/BI is composed mainly from Read operations for Reporting and Analysis. Write operations for DWH databases are executed separately in an ETL process.

• Unlike Transactional systems, Locality of Reference is not a pattern of DWH/BI systems because these systems process large and separated amounts of data.

The DWH/BI DBMS market is different from the overall DBMS market, which mostly reflects the more frequently, used Transactional systems.

Actually there are only four major players in the DWH/BI DBMS market: The three leading DBMS vendors: Oracle, IBM and Microsoft and also Teradata.

Microsoft's product is not a good fit for very large DWH, so in the high-end three vendors with three different approaches compete.

IBM's recommends to many customers, especially for Mainframe based Data Warehouses, to use a single large database for both Transactional systems and Data Warehouse. The advantage of this approach is avoiding of complex ETL processes. The approach is based upon the massive processing and especially IO capacity of Mainframes.

In the Oracle world usually the classic approach of different databases for the DWH/BI and the Transactional system is common, even if Oracle database is used for the Transactional systems. The DWH/BI database processing was executed on standard Servers under UNIX, Linux or Windows Operating Systems.

Teradata, without any presence in the Transactional DBMS market has no choice. The classic separation between Operational and Analytic databases model is the only possible model.

Teradata solution is unique solution. It is a combined hardware and software database machine. The hardware is based on standard Intel processors, capable of parallel processing, so its Scalability is relatively high especially for very large databases BI processing.

Exadata 1 and Exadata 2

The introduction of Exadata 1 special purpose Database machine by HP & Oracle less than a year ago was a model change. Oracle adopted a similar model to Teradata's model, in order to compete in the High-End market.

The machine was based on standard Intel processors and was designed for Data Warehouse applications.

Exadata 2 is based on Sun's hardware, as mentioned in previous post, instead of HP's hardware. Its, performance is significantly better than Exadata 1. According to Oracle it addresses both the Transactional market, as well as the DWH/BI market.

Probably, it is the first special purpose database hardware which addresses the Online Transaction Processing (OLTP) market.

Exadata 2 is also based on standard Intel processors. A significant enhancement is the addition of another storage level as part of the machine: Flash Disk. The Flash Disk could enhance significantly OLTP performance. But due to lack of Locality of Reference it may propose no improvements of DWH/BI applications performance or may even affect it negatively.

Exadata 1 could be a Teradata like model for DWH/BI. Is Exadata 2 a similar model to the model of one shared database for OLTP and DWH/BI as proposed in some cases by IBM? I am not sure it is, but in any case it is a machine aiming at addressing the High-End market and could be too expensive overkill for less scalable applications.