The early days of mobile applications was pretty straightforward: Define the applications that needed to run on the handheld, then buy the handheld that the app vendor told you to buy. The choice of mobile OS platforms was limited, and the company was paying for the device anyway, so end-users "got what they got" and IT managed the whole process.
Today, the mobile world is a very different place. Computing trends like Software as a Service (SaaS) and cloud computing are changing how organizations deliver applications to their workforce. As has been mentioned here before, the mobile landscape has changed as well. With users buying their own devices, there is literally no telling which of a half-dozen operating systems the user may be running.
So how do you deal with an endless combination of end points? Either maintain the old way of thinking and limit application access to a small subset of devices, or change the rules for application requisition and deployment. If mobile clients are ever to achieve parity with the enterprise desktops and laptops, consideration for handheld devices has to be included in the requirements for the applications within your organization. For example, if your company is looking at customer relationship products, the number of mobile clients the product supports should be a factor in purchasing decisions. Whether support comes from a native application or through a properly formatted version of a web interface, weight needs to be given to the applications and services that will interact with the greatest number of mobile devices.
Ideally, the applications you choose will enable your IT department to take as device-agnostic stance as possible. Without specific OS requirements, your enterprise can not only support the greatest number of users, no matter what device they are bringing in, but they won't have to scramble if one of the smartphone vendors falls off the face of the earth. While Palm's future is not yet written, a new approach to mobile apps will prevent administrators from losing sleep over it.