bynkii (bynkii) wrote,

A *good* iPhone article

Lest ye think that I only look for crap when it comes to iPhone punditry, please, allow me to present a well-written iPhone article from Computerworld, by Jon Espenschied.

Of course, my favorite blurb, (because it's biting, well-written, and correct, a hat trick that not enough pundits pull off) is this one:
What's bothersome is the nonsense put out by analysts declaring -- sans experiential data -- that the iPhone is unsuitable for business use, essentially because it does not look like what came before it. That kind of talk is good for getting your name in the newspapers, but there are two problems. The first is that IT analysis and pundits seem to have forgotten that suitability is closely related to the notion of technical standards, and that standards are not products. The second is that some technical aspects of any device are unknown without practical use; they can't be judged by the specifications alone.

Jon does an excellent job of pointing out that popularity != standards. IMAP is a standard. MAPI is simply popular. People can call MAPI a standard all they like, but that won't make it true, anymore than the insistence of well-intentioned parents will make strained beets taste like candy. Jon makes the outstanding point that we need to be concerned with standards and protocols more than implementation, and he's so right, he'd have to turn three times to be left. Another great quote:
We choose standards because products and platforms change -- and if nothing else, for purely monetary reasons, it's handy to be able to switch technology vendors. An oft-ignored but common situation in many organizations is a change in business and functional requirements without a concomitant upheaval in the security level requirements. For example, a medical products company may choose to become a service company, radically changing its communication-use cases without any decrease in the sensitivity of data handled by the technology. If such an organization's communications infrastructure were tied directly to business function, the company would likely face a major reconfiguration or rip-and-replace event. An organization communicating with open standards such as IMAP and iCal, on the other hand, might only need to reconfigure clients or obtain new endpoint software.

If you settle on data and protocol standards that are truly standards, then your vendor going out of business, or, (as is more likely), going in a direction that is incompatible with your needs is not a company-wide upheaval. If you're using standards, changing vendor products is relatively painless, because you aren't changing your infrastructure, you're just changing the implementation of existing standards. Going from IMAP server A to IMAP server B is far less problematic than going from say Groupwise to Domino, because you can change IMAP servers with an extremely high probability that your users will never need to know, and may never really know in the first place. If you have to change client applications, that can be more annoying, but you can mitigate that with the wider range of choices, so that you have a great chance of finding a new application that won't make your users hate you. Or just stay with the old one if you like, and can live with reduced or non-existent support.

If more iPhone pundits followed Jon's lead, the Intarweb would be a far less annoying place.

  • New Physics!

    Arachnivistic Velocity The speed at which an arachnophobe retreats from a spider. Can be expressed as: A v=1/D a Where A v is the speed of the…

  • Fuck Jaws

    He was a pussy...i give you true seaborne terror.... HOVERSHARK WITH FRICKIN' EYE LASERS!!!!! RUN AWAAAAAAY!

  • Wait, wait, wait

    I thought those darned illegals were taking away jobs that "Good Americans need and want", that they were denying us paying jobs in hard times. It…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.