Wandering Data

My colleague Eric Giguere knows a whole lot about BlackBerry programming and today he launched a blog on the topic called, straightforwardly enough, BlackBerry Programming. Worth subscribing to.

Meanwhile Microsoft’s Rabi Satter, who does a lot of mobile programming on Windows Mobile, is moving on to work on the full .NET Framework. I’ll keep subscribed to Satter Ramblings anyway. Best of luck in the new job Rabi.

And anyone involved in mobile computing could do worse than subscribe to Random Acts of Reality. It’s a blog by an Emergency Medical Technician in London and any time you are thinking your job is stressful and unrewarding, read what this bloke has to go through. Today it’s just going around a patient’s flat with a damp cloth “cleaning the blood while my crewmate pointed out the bits that I missed”.

My work centres around UltraLite, which runs on Windows, Windows Mobile, Palm OS, and now Linux and BlackBerry OS. All these platforms matter. But right now I’m getting run ragged just trying to keep up with questions about UltraLiteJ, which is the UltraLite for BlackBerry implementation that we announced a couple of weeks ago. In the last week I have talked to people from:

• a medium-sized company who wants to put HR applications on the BlackBerry,
• a company that does spatial or mapping applications that is interested in potential integration and use.
• a company that builds a combined hardware/software product line for data collection.
• a bank that has several applications they are looking to take mobile on the BlackBerry
• a software consulting company that does BlackBerry work
• a major software company that has tools they want to put on the BlackBerry

Plus there have been questions coming in by email and our system consultants have been answering their own.

It’s early days of course - SQL Anywhere 11 only comes out in Q3 - but the expression of interest is  gratifying if a bit hectic for a lazy person like me. So if I write nothing but BlackBerry for a while here, it’s not that other platforms aren’t important - they are - it’s just that this new thing is generating a lot of questions.

Exclusive eWeek research finds mobile application development stuck in second gear, awaiting the inflection point of an industry-standard development platform.

That’s the abstract from a May 12 eWeek article called Standard Issue by Stan Gibson. It doesn’t seem to be online anywhere just yet so No Link for You. Later on Gibson writes that

many organizations [are doing] what they can with a browser for now while waiting for a standard application development platform to emerge.

Such a platform may be Android, which is sponsored by Google and the Open Handset Alliance; Symbian OS, which is used by Nokia on its smart phones, or an Apple iPhone SDK.

Organizations waiting for the One True Platform won’t get it from any of the candidates he lists, or from anywhere else in the next few years. The mobile device space is not like the desktop - there is no single ubiquitous OS. But that doesn’t mean that organizations have no options.

What’s a platform anyway? Stan Gibson uses the phrase to mean an operating system, and whatever the success or failure of the various candidates there is no way that Android, Symbian OS or iPhone will dislodge Windows Mobile and BlackBerry any time soon. In fact, as new entrants, iPhone and Android make a standard mobile application development platform less likely rather than more.

So is the browser the solution? It will be for some applications of course, but there are reasons why it’s not going to be the right choice for many applications, such as lack of local data (hence performance issues) and also device integration. The restricted interface of a smartphone means that many applications have to integrate into the basic features of the phone to be useful. Times link to the calendar, people to the address book, places to the GPS system and so on. This linking to the basic features of the phone is device dependent - the BlackBerry APIs, Windows Mobile APIs, and iPhone APIs - even if they are available to the browser, are not going to be the same. Any application that wants to provide a good user experience on a particular phone is going to be device dependent, browser-based or not.

Going the native route introduces new issues. Programming language is one - BlackBerry is Java, Windows Mobile is .NET, iPhone is Objective C. Then there are the different process models (one process at a time on the iPhone, as many as you want on Windows Mobile and BlackBerry), the different UI and user interaction principles, and on and on. No one-size-fits all in that direction.

We do get asked from time to time if you can use SQL Anywhere to write portable applications, and the answer is no. The reason is straightforward - native apps for the BlackBerry need to be in Java, native apps for Windows Mobile will be .NET and so on. And even if you use Java with a VM for Windows Mobile, which you can, you still have to tackle all those issues I just mentioned. Sure it may work for some people, but for a mainstream approach it’s not going to work.

Our answer, right now anyway, is that you share what you can across devices and cut down on the device-dependent work you have to do. And what you can share is data. Using SQL Anywhere lets you use a single back-end architecture to share data across all your mobile devices and exploit a common database schema on the devices. And if you think about it, my guess is that if you have a single platform complete then the design of the database schema was an integral part of the application design. The UI needs to be different to match device specifications and the business logic has to be implemented twice, but once you have done the difficult design work you can carry that over to the next device you need.

It’s not ideal, but for serious applications that make the most of the devices on which they run, a mobile data platform (that is, a database system and a data movement/enterprise integration system) is as close as you get right now to a common platform. Plus, as we continue to look at new platforms, we help to insure you against the appearance of new and unpredictable devices and operating systems. It’s a pragmatic approach to the problem, and for my money it’s a better bet than waiting for an industry-standard mobile device platform to appear.

Nothing to do with mobile computing, but the entire Wandering Data family got to see this man in concert last night. Brilliant.

Nokia seems to have a dual personality. In most parts of the world it seems innovative, in-touch, and ubiquitous, selling about 40% of all cell phones across the world. But in North America it has experienced stumble after stumble and now Michael Mace at MobileOpportunity picks up on a report from April that I missed, which states that “Nokia’s North American market share has plunged from 20% to 7% in two years.”

Ouch.

I guess that’s iPhone and BlackBerry putting the proverbial boots in.  It is natural that a mobile data platform like SQL Anywhere carries most value when there is a wide range of mobile devices out there, so here’s hoping that Nokia picks itself up and finds a bit of the style it seems to have elsewhere.

I know even less about hardware than I do about other aspects of computing, so it’s good that people like Jon Stokes of ars technica post things to help me understand what’s going on.

Recently Moore’s Law seems to have taken a breather in mobile devices. Buy a heavy-duty handheld two years ago and you would get a 624MHz ARM RISC chip. Buy a BlackBerry Bold later this summer and you will get … a 624MHz ARM RISC chip.

But that may be about to change. There is a battle brewing between the next generation of existing RISC processors and Intel with its “Silverthorne” - now named Atom - line of low-power x86 chips. The technical advantage is with RISC, but then it was in the desktop/server CPU wars of a few years ago as well. And as Jon Stokes says (link via Mike Hall):

To ARM and its vast army of licensees, Intel’s mockup-heavy bluster about x86-powered UMPCs, MIDs, and smartphones might look just as laughably silly as the Pentium Pro and its successors looked to the likes of SGI and DEC, if it weren’t for the fact that x86 is now wearing the scalps of both now-defunct RISC powerhouses as trophies. No, in today’s world, when Intel aims both barrels of its formidable fab capacity directly at a new market segment, it’s not a joke to anyone who ends up in the crosshairs.

The question is whether Intel’s superior manufacturing abilities, coupled with some workarounds, can overcome the architectural advantage that RISC chips have over CISC. Stokes’s conclusions are cautious:

In the near to medium term, Atom and its predecessors [successors? ed] will pay a relatively hefty price for their CISC legacy. More benchmarks will give a clearer picture of whether tricks like SMT, when combined with Intel’s ongoing process engineering leadership, will lower that price enough to enable x86 to squeeze ARM out of some future version of an iPhone-like device. In addition to SMT, the other microarchitectural trick that I see on the long-term horizon for Atom is the return of an instruction window; this will provide a real boost in performance/watt, and Intel may be able to introduce it at 32nm or later.

The question of how well Intel will fare in the renewed RISC vs. CISC battle that’s taking shape in the mobile space hinges largely on the answer to two questions:

1. How much is the legacy x86 code base really worth for mobile and ultramobile devices? The consensus seems to be “not much,” and I vacillate on this question quite a bit. This question merits an entire article of its own, though.
2. Will Intel retain its process leadership vs. foundries like TSMC, which are rapidly catching up to it in their timetables for process transitions? ARM, MIPS, and other players mobile device space that I haven’t mentioned like NVIDIA, AMD/ATI, VIA, and PowerVR, all depend on these foundries to get their chips to market, so being one process node behind hurts them. But if these RISC and mobile graphics products can compete with Intel’s offerings on feature size, then that will neutralize Intel’s considerable process advantage.

As for timing, we will see Atom chips in “gadgets that are smaller than a laptop but bigger than a smartphone. Apparently, the devices will start appearing in late May and early June on store shelves in China, Japan and South Korea. N.America and Europe distribution will come at a later date.” Then it’s smaller and less power from there and see how far they can go I guess.

So it looks like nothing in the next 12 months or so that will affect smartphones and the other handheld devices but give it a couple of years and we may see an end to the ARM monopoly in North America and inroads into the MIPS strongholds elsewhere. Or not. What do I know, I’m a product manager not a hardware engineer.

Everyone knows the BlackBerry as an email/messaging/voice device, but what about applications? So far, the number, adoption, and sophistication of BlackBerry applications has been low compared to those on Windows Mobile, especially when it comes to business applications. I’d say the evidence from WES 2008 is that this tide is turning but it’s still a long way out (or in? how does that metaphor work?).

What I mean is that last year (when there were 3500 attendees, as opposed to 5400 this year), RIM was making a big push on applications at the show but the awareness and interest level among participants was generally low, and the options available in the solutions showcase were not broad. This year the offerings on the showcase floor are far more varied. Plus, we’ve been getting far more inquiries about applications than last year, and more questions from application developers. But I’d have to say that while I’ve had some great conversations with some very knowledgeable people, a lot of the inquiries still come from people and organizations in the early days of investigating applications on the BlackBerry, looking at what’s out there and learning what it takes to get something useful working.

Some common expectations are not realistic in the current state of app development. In particular, some people are looking for out-of-the-box applications that immediately provide what they need for their specific organization on the handheld, and which integrate with little or no work into their highly customized enterprise backend systems. The truth is that implementing a customer-specific application that extends customer-specific systems to enable customer-specific tasks is going to take some customization work.

Still, those expectations will get changed, partly because on the supply side we or our partners will move towards making things easier (more deployments bring more expertise and bring fewer surprises on each new customization), and partly because on the demand side they will learn more about what’s involved.

A colleague (Hi Kate) asked what kind of applications I’m seeing people look for in addition to customer relationship management (CRM) and other sales force automation applications. For organizations, I’ve seen expense reporting/forms-based applications, key performance indicators (dashboard applications), approval applications (which can be simple, or can be like the “equity on the spot” app that got an award today), as well as lots of field service and job scheduling/task management applications. Plus there are lots of document-handling solutions and location-driven applications that don’t involve so much structured data.

In a way that list is deceptively narrow because each category is so broad: a CRM application for a laundry operator is very different to that for a financial services company. The application needs of Morgan Stanley are different from those of Unite (the British trade union) which are different to those of the West Yorkshire Police, each of which I had conversations with today, even if it’s the same class of application.

My impression, then, is that there is an appetite for applications on the BlackBerry that didn’t exist a year ago, and given the growing number of devices and deployments, the appetite is only going to get bigger, but that the market is still immature and there’s some way to go before the growing pains are sorted out. Still, I’d say this conference has made me optimistic about SQL Anywhere for the BlackBerry, and it’s not that easy to make me optimistic.

Chris Kleisath points to an interview that, among other things, shows how shockingly old I am.But it also talks in 3 minutes about the usual journalistic questions: WHO we are, WHAT it means to have SQL Anywhere for the BlackBerry, WHY we are doing it now, and WHEN it is out. (WHERE? iAnywhere of course).

It can be difficult to communicate what’s special about the software we do. For example, Berry Review  speculates that “This might be similar to the Cognos client that came out recently”. Close, but no cigar. The Cognos client is an application that runs on the BlackBerry; UltraLiteJ is a database that Cognos could (had we had this ready) have chosen to build their client on. The benefits we provide are efficient storage, quick access (because we have indexes, SQL and a query optimizer) and efficient data synchronization.

“Efficient data synchronization” is also one of those things that is difficult to describe, but a conversation I had here yesterday sums it up. I was talking to someone from a small company that develops a Customer Relationship Management (CRM) application for the BlackBerry and he asked me if we support blob data (yes) and how long it takes to download data to the device. I said that the biggest sync I’ve done myself was about 10,000 rows of 100 bytes a piece, for a total of about 1MB of raw data. “How many hours did that take” asked the developer, rolling his eyes because he knows how long it can take. “Twenty minutes” I was able to reply, because I’ve done the test - and that’s done in such a way that you can contiue to use your device during that time. It takes about half the time downloading (over an EDGE network) and half the time applying the data. The surprised look I got in return was priceless.

There’s no doubt that among the slew of BlackBerry announcements from RIM and from RIM partners here at WES 2008 the big deal is the forthcoming BlackBerry Bold. But here at Sybase iAnywhere we had our own announcement about bringing SQL Anywhere to the BlackBerry. And there is a link beyond the bare facts of BlackBerry and timing.

I took a look at the Bold in the demo area they have set up here. It’s a very very cool device. Standing at a demo booth there is no doubt that the most striking thing is the display - a sample video of The Golden Compass preview on the device is absolutely eye-popping in its clarity and in the speed of its resolution (even if the movie itself doesn’t capture the depth of the books - I do hope they make a sequel).

But the video is mainly for pro-sumer types. What about the nitty gritty numbers? Well. there’s a lot there. The basics, are a 624 MHz StrongArm CPU, 128 MB of RAM, 128MB additional internal flash, and 1GB on-board media storage, as well as a slot for a micro SD card that will permit an extra 16GB by the end of 2008. My guess is that the “128MB additional flash” runs the RIM objectstore while the 1GB on-board media storage is formatted as a micro SD card with serial I/O.

What this means is that, while BlackBerry was very limited until two years ago, and while the current models work on a 312MHz processor which is kept turning over slowly to keep battery life up, the specs for the new BlackBerry are up there with top-of-the-line enterprise handhelds from Motorola and Intermec. So the BlackBerry Bold is a serious handheld device, capable of running serious applications. Nice.

And that’s where UltraLiteJ, which is SQL Anywhere’s BlackBerry component comes in. We’ve been working on it for a while now and it’s going to be part of our upcoming SQL Anywhere 11 release. It provides the foundation for data-rich apps on the BlackBerry. While there are a lot of BlackBerrys out there 14 million last year, there is some industry speculation about how big the market for BlackBerry applications is and how big it is going to be. I think the Bold makes it clear that the market is going to be big, it’s just a matter of when. So UltraLiteJ has a big role to play.

It clocks in at 400KB, which is under 2% of the 256MB combined space on the device. It provides efficient relational database storage (indexes for quick lookup and so on) and all the stuff needed for data synchronization.

The capabilities of UltraLiteJ match well with the direction that the BlackBerry is taking, as exemplified by the Bold. So I have high hopes that BlackBerry application developers will see it as the right way to develop data-rich applications.I guess the next two or three years will tell if I am right. The thing about blogging is, my prediction is now out there. Email me in 2010 and tell me whether I was right.

Starting tomorrow I’m at the BlackBerry Wireless Enterprise Symposium (WES) 2008 and the BlackBerry Alliance Summit that precedes it. There’s an announcement from us at Sybase, plus I’m sure there will be lots of news from the folks at RIM. I’m looking forward to it and will try to post here daily on what I see and hear. Watch this space.