The trip to Sun had some highlights, but was pehaps overally disappointing. The initial introduction had no new information that could not have been conveyed in 5 minutes. Sun should differentiate between marketing, technical groups, and very technically aware groups (e.g. DSTC) and be more flexible with more advanced groups.
The Jini demo was new to some, and helped. Suspicion was still held that even the Axis camera was a ``fake'' done by a proxy. I was surprised by the speed at which services disappeared when the plug was pulled - there must have been some active polling going on, which isn't part of Jini, and probably isn't really recommended. Leases that expire (after e.g. 5 minutes), or failure mechanisms are what I understand should occur.
Doug was good value, even though he was off-topic (``Java and Jini Roadmap''). He gave some good contacts as well.
One emphasis I noted: Sun concentrated on ``device/service/client to Internet'', with a fat server sitting at the bottom. (SAP also had this same structure). It ignored direct device-to-device, service-to-client, etc, models. Maybe this was just the way the diagrams were done, but it seemed to me to be missing markets. In Sun's case, it seemed to miss the home network: Sun have no activities in home devices, and there is no role for the Enterprise Server there. However, there is a role for Jini there, which marketing was missing!
The first day was spent explaining SAP to novices, and how the PVC project fitted in. Ok, so SAP is huge, but it also consists of 16,000 applications in R/3. This caused problems: Max claimed SAP to be an elephant, Lutz told him he didn't understand the granularity of SAP; when we asked the role of SAP in certain situations, we typically got the answer ``no, it doesn't do this, but despite that, it is more encompassing and more flexible than you think''.
I found problems in the area of ``spontaneous networks''. They happened all the time during this workshop: the main group, breakouts in the formal sessions, casual groups at lunchtime. Being obsessed with Jini (I'll get over it) this is a good area for Jini. But I couldn't get a good answer to where SAP can fit in this area, so I couldn't get a good match between Jini and SAP on this. One answer I got was: ``SAP can supply to-do lists''. Big deal! My question was: how can R/3 help in a spontaneous network, such as breakout groups, and hospital systems where monitors have to come together around a patient.
I don't want to have to become an SAP expert to see scope of SAP. But something needs to be done to correct the impression of SAP as an elephant, and to give a realistic idea of what SAP can accomplish.
I think all the DSTC people agreed that the ITS was a horrible way to go, and probably won't succeed. My description was ``screen scraping''. Andy told us how Lotus Notes went down the same path - for a short while. To do screen scraping from SAP-GUI to HTML is passable (maybe). To do it to WML looks silly. Even converting to HTML sometimes involves introduction of extra ``presentation flows'' i.e. extra steps to accomplish a task. This will have to be done on an even more serious scale in moving to WML: in order to do this, perform 40 operations instead of 4. Not at $1 per minute connection costs! Using a WML interface will involve a change in workflow, and this change in workflow must take place within R/3 applications rather than patched on at a later stage.
DSTC is constrained by requirements to meet some deliverable deadlines. For the first deadline, maybe you (not me!) will have to follow this route. But I suggest that DSTC consider building a ``proper'' architecture to handle these different output devices. Andry is concerned about getting too involved with R/3 itself. I agree: build a prototype with proper usability tests for a typical SAP scenario, targeted to multiple I/O devices, but concentrate on principles rather than specifics of R/3. A clean conceptual structure presented to SAP after a couple of years will be more valuable than another hack on top of existing applications.
I came in as ``Jini expert'' to this workshop. I have already said that at the user end a good scenario for Jini (the spontaneous network) doesn't seem so good for SAP. The ``backend'' scenario is that of devices feeding information into SAP systems. The Coke machine as source of inventory data seems to be the prototypical example. This is actually pretty simple, and I have a separate proposal for this. Assuming that feeding data into SAP can be done using a ``batch''mechanism, a prototype could be done for the July SAPPHIRE conference.
There are parts of SAP that I have no desire to be involved with. However, there are scenarios involving SAP and of value to SAP that I can contribute to.
In addition, a number of problems were cast up by the workhop that may not fall within the purview of SAP, but are nevertheless interesting to M3. To me, these involve issues of spontaneous networking.