X
Business

SAP's Peter Zencke: Inside Business ByDesign

Peter Zencke, a member of SAP’s Executive Board and head of R&D, spent the last fours years developing Business ByDesign, a new foundation for SAP's ERP software. I caught up with him during SAP TechEd ‘07 and asked about the origins of the product and what will differentiate it in the marketplace.
Written by Dan Farber, Inactive

Peter Zencke, a member of SAP’s Executive Board and head of R&D, spent the last fours years developing Business ByDesign, a new foundation for SAP's ERP software. I caught up with him during SAP TechEd ‘07 and asked about the origins of the product and what will differentiate it in the marketplace. (See earlier coverage of Zencke's TechEd '07 keynote and more SAP coverage here.)

DF: What was the genesis behind Business ByDesign?

PZ: "Four years ago, in 2003--exactly 10 years after R3 was introduced--we decided to go for new architecture, which we called "Ether" and then later "Enterprise SOA." The first year we were figuring out how to do enterprise SOA. We built a prototype but decided not to productize it. We were just working on some principles during the first year. Early on we made a decision for a more rigid approach figure, one that we could not let flow to our ERP product [SAP Business Suite].

DF: What is unique about the architecture of Business ByDesign from other SAP products besides that it is on demand and aimed at companies with 25 to 100 users of the software.

PZ: There are two elements, process integration for services and the process definition level, with small subcomponents. It is not at the database level, which is different from the past in mySAP [now called SAP Business Suite]. The key question is can we have the same reliability of traditional database integration. What happens if messages get lost. This is different than traditional database integration. If we go the non-database route, we can't do it with mySAP and change the transaction model. It won't work for the installed base. With Business ByDesign we define services for composition on top, and there isn't tight integration between front and back end. As a result, the risk of migration is too high. On the other hand, if we only go forward by evolution, we miss a lot and we cannot fully exploit enterprise SOA. [SAP will evolve its existing platforms to gain some of the features in Business ByDesign by enhancement packages that sit on top of NetWeaver.]

DF: How does Business ByDesign stack up in terms of performance and reliability?

PZ: Performance is a factor of four less than what we are used. When we started it was ten times. If we go for new hardware infrastructure, with multi-core processors as we do in our hosting, we get pricing gains. In the last 15 years, we have been optimizing R/3 on an ongoing basis for the highest volume. Business ByDesign is slower because it is multi-layered, which can eat up potential performance. First we went for what is clean and then we looked for shortcuts to speed performance.

DF: Was Shai Agassi [former head of products and technology who left SAP in March 2007] involved in developing Business ByDesign?

PZ: From day one it was always in my hands. Shai had second tier involvement.

DF: How important is the self-service aspect of Business ByDesign for gaining customers and is it operational?

PZ: The self service of buyer cycle is fully operational. All customers in first 20 went through the cycle. We did pre-qualify for customers, as the business center is not open for anybody. We wanted to find business in the mid-market, ranging from 25 up to 100 employees.

DF: Do you plan to open up the Business ByDesign platform to developers or to allow them to run their code on your servers as salesforce.com is doing with Force.com?

PZ: Salesforce.com's model is different. They are not mission critical. We have to be more risk averse about running code on our server infrastructure not developed by SAP. With NetWeaver as the composition environment, which is model driven and works with our code generator, so much more is in our hands. We have also implemented built-in services for support. If an incident happens, such as code not working or messages stuck or a database commit issue, we automatically track it and the system writes them into the SAP service back end. This remote control is launched with each installation, whether from us, hosting partners or on premises, which we don't yet have. In most cases, the customer doesn't know about incidents and it doesn't affect any application environment. The same automation happens with the composition environment in NetWeaver. If outside tools such as .NET or WebSphere are used, we would be more restrictive. But customers can run code on their own site that works with our hosted environment. The "hybrid" model is useful for fast moving composition.

DF: There is a lot of discussion around multi-tenant versus single-tenant approaches to delivering applications. What is the delivery architecture behind Business ByDesign?

PZ: Where we came from there was always one database, then client/server and multiple servers and front ends. mySAP's front end has become quite complex. We asked can we run an end-to-end stack, application, network, database, messaging and backend integration on one blade. It was a pretty aggressive goal. We found we could run 25 to 50 concurrent users, and the economics of a blade per tenant are very good. We never said we would go for 100 tenants on a huge server--that doesn't work for us. If salesforce.com has customers with 5 users, then it makes more sense to have more customers per blade. We start at 25, and those customers could be 50 users tomorrow, so we have room for growth and adding more sophisticated business processes. There isn't much treasure in going beyond one customer per blade for us.

We also have perfect tenant isolation through database techniques. In normal multitenancy you are using the same database scheme. We have done that for 30 years on the applications side. Instead, we are using database technology for tenant isolation. We run our own MaxDB [an open source, SAP-certified database for OLTP and OLAP usage] and run virtualization on the database with multiple instances that do full tenant separation. If a customer decides to migrate from "A" to "B," we can do that "in flight." If customers are sharing table schemes it is more difficult to move from machine to machine. With MaxDB in our own hands we are in a better starting position than others.

DF: What is the plan for introducing more AJAX into the Business ByDesign user experience?

PZ: AJAX comes step-by-step. The NetWeaver collaborative portal is AJAX based and open for us to use, but it's not in the design corridor of mySAP. We have an [AJAX-based] smart client coming soon.

DF: You have talked about a model-driven approach for Business ByDesign. What have you done that is unique?

PZ: There is a debate whether a pure model driven approach is working. What we have doe is drawn a very clean line on what is happening below and above services. On top is everything that a user sees--the UI, portal, work center. The Java code is generated or preassembled based on certain building blocks. This is a breakthrough, understanding user needs, what should be the user interaction and the user interface is something that developer community hadn't achieved. The world below is still traditional coding, done end-to-end on ABAP objects and reuse of intrinsic services with strict governance. For each function there is one implementation.

We introduced the concept of process components that aren't based on database integration. But that's not to say every object stands on its own. We aggregate about 10 to 15 objects into one process component so we end up with roughly 25 of these process components and then strict governance between independent components. There is only message-based integration--no database integration. An overall point is that if you are too granular, you could have performance problems. If you had only five components, then you end up with the old world of CRM, ERP, SCM.

There is one-to-one correspondence between every object on the model layer and what exists in the implementation. Objects and process components are active and you can go from model to code. Not everything is generated from the model, but it is controllable and has more flat, modular structure.

DF: Giving some of the rigidity of the system, how customizable is it?

PZ: You would be astonished to see how flexible it is from a configuration point of view. The number of customization parameters, which we have in ERP, have been reduced by at least factor 10, in fact closer to 100. The parameteization of the system is limited for the sake of complexity. Let's not inflate the variations, but be powerful in the combinations of elements so overall it is very powerful.

DF: You have said that Business ByDesign is a different kind of sales proposition. What are you doing to train system integrators and other channel partners?

PZ: The business process models, as important as they are, aren't the entry point for system integrators. On top of Business ByDesign is a new configurator with a question and answer and constraint engine. It doesn't touch the process model but influences it. The process model reacts against the settings. In the beginning we though we could work with process models, but it was too complex. We are hiding complexity for the sake of faster adoption.

DF: It seems that SAP is a very patient or stubborn company in the way you have slowly introduced on demand services.

PZ: We have a prudent way forward, with a brand new product and architecture. Some people are skeptical--some say we are too early and others are pushing us to move faster. We want to be responsive to early customers--it's not as easy as click, click, click get your configuration. We are talking about mission critical systems, not a salesforce.com or Workday.

DF: Given the benefits ascribed to Business ByDesign, are customers outside of the mid-market and standardized on other SAP suites hungry to get those benefits?

PZ: If we were to overload the solution with all functionality of All-in-One it will kill the beauty of that solution. For SAP this is white space and the solutions are either outdated or hard to afford. The key question is can we change the economics of the solutions.

Editorial standards