"Anticipating Change: Secrets Behind the SAP Empire" Dr. Hasso Plattner
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
As an IT professional, you might be interested in the story of how SAP became a success. This text, translated to English in 2000 is chock full of revealing discussions with SAP's pragmatic CEO Hasso Plattner. These conversations afford an important insight into the thought processes of SAP's CEO. Hasso talks about the principles of management, the challenges of software development and how enterprises will conduct business in the future in this interesting text.
In this excerpt from "Anticipating Change: Secrets Behind the SAP Empire", Hasso discusses the parallels between ABAP and Java with August-Wilhelm Scheer. Dr. Sheer is Director of the Institute for Business Information Science at the University of Sarrland and founder of the supervisory board for IDS Sheer AG.-------------------------------------------
Sheer Concepts such as soft coupling, error-tolerant communications exchange, no standards--does this horrify the information technician, or is it exactly the direction in which software or applications architectures are imagined by the information technician? Where you actually deal more with concepts such as correctness verification by software, hard things, and where you do not call software engineering a science, but really just say it is something soft that we cannot explain through science.
Plattner I don't know if it fits, but we have brought in the image of radio? Now I have the front panels of electronic instruments in my mind's eye, how we arrange the individual elements of the front panel and to what degree the operation is mechanical or movement sensitive, whether you are turning a knob or perhaps changing it through a digital submodule. For the end user, it is entirely inconsequential if this knob architecture --let this be the example for a front-end architecture--is carried over into the core module of the system that lies behind it. Whether the transformation from the front-end module into the logic of the radio, whether this is a component part of the radio, or whether it is an element in between, or whether the component is mechanical in nature with a bit of electronics-- that actually does not matter. What I want to say in this illustration is-- let us now look at the radio module development technology that lies behind this--that we can rapidly tie in with various switching technologies; this is perhaps a development of the past year.
When we take a look at the development of ABAP and Java, there are a lot of parallels. ABAP anticipated things in 1991, when it started to run in the client/server environment, that today are among the core elements of Java: how, by itself, it distributes itself to computers on the Net; that it compiles on its own, on the fly, when it is changed; that it rests upon a central repository, and so on. There are many relationships and therefore Java and ABAP understand each other very well. This is an important point: Programming languages are not as egocentric as they were 20 years ago, such as PL1 and COBOL. You could get them to work together only through very formal, clumsy interfaces.
The connection of various development systems has become much better. We can build in the functionality of Java and front-end systems simply and cheaply; perhaps this is not the best and most elegant way in which to build, but it is very cost effective. We can rapidly convert this functionality in a world where we have a lot of experience and a lot of people with a command of this world. We have distribution logistics so that we can use the existing modules we have in the middle layer very easily to build variants.
We have thought about alternatives in which we can make this route more systematic, and we have done proper development projects that have all led to very complicated structures. I will not rule out that in the future things might develop in this direction--with formal description about which object is actually being dealt with, who is concerning themselves with it, and what kind of hierarchy there is for partial views of this object. When you try to get a grip on this in a formal manner, you can easily build a very large broker system, but possibly miss the target, namely to build 500 front-end variants for the existing transactions.
These variants, consisting of a front panel and modules behind it, are of a different sort that "I want to connect this piece of equipment with another piece of equipment." There is a different quality to making a connection from a radio to an amplifier, to a recording system, or to a television system than putting a new front panel on a piece of equipment-- only because we have always said that now we have new user groups. It is partly enough that we simply put various front-end operations panels on the same existing modules. Then when the programs communicate with each other, we must employ carefully built interfaces because programs are very sensitive when the interfaces change. So I have to construct these interfaces much more carefully.