At the Microsoft Partner Conference this week, most of the talk about software vendor (ISV) scenarios for Windows Mobile has centered on non-browser-based applications. In other words, “thick” client applications running on the phone.

This irks me, because today’s businesses are rarely able to standardize on a single mobile platform for their users. There are going to be iPhones, Windows Mobiles, G-phones, Blackberrys, Palms, and Symbians, not to mention “feature phones” that may or may not even have a browser. So if a custom client application will meet the business need, great, but is the plan to port to each different platform? That’s an expensive approach, difficult to maintain, and not scalable.

To be sure, there are still good reasons for the custom client app approach. First and foremost, there are customer scenarios in which access to data may be required at times when the network isn’t available. For example, if I want to view crop yield information on my phone, but I’m in the middle of a field with no wireless and no 3G, I’m stuck if that data isn’t already present on the device.

Another example: I’m a salesman and I input a new order into our CRM system. However, it’s a large deal and requires the approval of my boss. Unfortunately, she’s travelling. Via a custom CRM client running on her phone, she can approve the deal, but I have to wait until she’s connected, checks for pending approvals, or gets notified via some mechanism that there’s an order pending.

None of this behavior is impossible to achieve with some combination of a browser, mobile email, and SMS, and that’s my point. For example, the sales order approval could be handled in an automated way by the CRM system: send an email to my boss with some relevant metrics to drive the decision. For example, what’s this customer’s credit limit, and would this deal cause it to be exceeded? Then, my boss can reply to the email with the text “Approve” or “Deny” and the CRM system will receive it and take the appropriate action.

Similarly for the first scenario: why not push the crop yield information periodically via email?

This way, there are no custom apps required: such a transaction-oriented solution works on any phone with email support. That’s a low bar, much more affordable, maintainable, and scalable.

No Comments »