What are the big changes on the IT horizon?
The integration of the real world and the IT world is going to happen, and it's going to accelerate. It's going to be driven by the increase in RFID in sensor networks and the rise of embedded microprocessors. We are doing things here that couldn't have been done three to five years ago. For example, we are looking at how to outfit fire engines with a variety of wireless communications gear so we can track the trucks back to SAP's back-end systems. One thing the fire department was interested in, for example, was ... understanding why a fire truck would take what appeared to be a nonoptimal route to a fire.
What's another example of this kind of pervasive wireless network?
The automobile has a tremendous number of microprocessors but has been slow to adopt networking. We are exploring back-end Web services [for] network-enabled cars. For example, my car told me I needed an oil change. But in the mail, I got a notice saying my car needed a software change. If the whole thing were network-enabled, I could have gotten an e-mail saying, "Your car needs to be serviced. Make an appointment by clicking here, and when you come in, we'll upgrade the software in your car." [There is] a potentially very large number of back-end services that can be delivered to the car or driver.
What's an example of a future corporate application of RFID and wireless networks?
We are also looking at RFID-enabled assembly lines. One issue is that the back-end inventory management system is often not as consistent with the actual inventory on the assembly line or the parts depot. By tracking parts usage on the assembly line, you potentially have fewer line shutdowns and more accurate forecasting and usage information. Also, if there are component product recalls, you have highly accurate information about where the faulty products were used.
What advice would you offer IT managers in light of this merging of the physical and digital worlds?
One thing they should do is adopt existing standards as quickly as possible, like OSGI [Open Service Gateway Initiative]. Adopting a service oriented architecture could be a huge win for the following reason: if they already have some sort of RFID application or sensor network application, they probably have a large amount of data already in their back-end systems. Replicating this information would raise [costs] and result in lowered accuracy. In one example application we did, we were able to combine existing repository information about properties of chemicals contained in drums to determine whether proximity of different drums of chemicals represented a hazard. In this way, we effectively made the drums "intelligent". To do something like this in a non-integrated fashion would be potentially inaccurate and more expensive.
What is SAP doing to service-enable its software?
We have spent a great deal of time implementing our Enterprise SOA in SAP NetWeaver. We are opening our software up to an ecosystem of partners. But I'd like to open it up even further and try to integrate and utilize some of the open-source enterprise applications packages that are coming out. There are ERP systems and CRM systems out there that are not SAP, and to the extent we can allow them to integrate [with SAP], it would be a win for customers. The open source packages out there, things like SugarCRM, aren't going to get tied in by accident. It will be a cooperative effort.
These sensors and RFID devices will generate huge amounts of data. How will companies handle that? One topic in our research group is event-enabling some of these things. As the data comes in, you want to only be notified of exceptional conditions, not the normal stuff. You only want to know the stuff that humans have to deal with.
How will you adapt to new hardware architectures?
Hardware vendors are not just throwing new designs over the wall and expecting software vendors to swallow them. The situation is changing, where they are coming to us and saying, "What do you think we should put into our architectures for 2010?" They are asking, "What are the opportunities for parallel processing [and] virtualization?"
Will you adapt SAP software to take advantage of the kind of parallelism possible in multicore processor chips?
There are levels of parallelism granularity that we are exploring: distributed parallelism; coarse-grained virtual machine; coarse-grained process parallelism; and medium-grained, thread-based parallelism. As far as I know, we're not looking at fine-grained, instruction-level parallelism, but I wouldn't be surprised if someone within SAP were looking at that as well.
What's needed in programming languages?
The DNA at SAP is a deep knowledge of business process. But if you try to see where that knowledge is embedded in our software -- there are hundreds of millions of lines of code -- there is no one place that you can point to that embodies this deep knowledge. So I see a future world where the business process is embodied in a well-designed piece of software, where the modelling is made explicit and is understandable by a wider audience than the hard-core C++ software engineer. Think of something like a scripting language that is designed just to support the business process.
What would be the benefits of such a language?
It's to more easily automate business processes and modify them. And it's so the CIO can measure compliance. That's increasingly important. You want to know what the software is doing, to make that fairly transparent so you can guarantee compliance. We are exploring the possibility of doing a new kind of language -- a graphical language or a scripting language or something that is sharply tailored to the needs of the business analyst.
I think embedding process models into a network fabric is another expression of the same idea. I have in mind something like Cisco's AON (Application-Oriented Networking) intelligent enterprise network message-routing system. It's possible to integrate business-oriented metadata to help optimize and manage network messaging traffic.