Gartner: Think holistically (architecturally speaking) about mobile
Here, at Gartner Symposium/ITxpo in Lake Buena Vista, Florida, Gartner analysts for the first time are coming out and saying that it's time for enterprises to decide on a strategic architecture to support mobile handset computing, and to begin deployments.
Here, at Gartner Symposium/ITxpo in Lake Buena Vista, Florida, Gartner analysts for the first time are coming out and saying that it's time for enterprises to decide on a strategic architecture to support mobile handset computing, and to begin deployments. Until now, according to analysts William Clark and Nick Jones during a session called "Getting Mobility Right," it has been OK for enterprises to scrape by with piecemeal solutions that didn't require a commitment to an organization-wide strategic mobile architecture. But, right there on the opening slide of their session was the bold text: No Architecture is No Longer an Option. Said Clark of Gartner's previous position that, in absence of robust centralized architectures, mobile deployments should happen with eventual disposal in mind:
Whereas before we said throw stuff away, today, the diversity is becoming quite vast what we're seeing now is all kinds of convergence.
And what is the convergence point? Gartner is also beginning to spread the gospel about the technology that lives at the heart of such a mobile architecture -- something it calls the Multichannel Access Gateway or MAG for short. Multichannel Access Gateways, warned the analysts, are not solutions like Research in Motion's Blackberry Enterprise Server or Microsoft's Mobile Information server.
Rather, a MAG is a form of middleware that facilitates network agnostic (LAN, WAN, WWAN, etc.) connectivity between multiple, unintegrated and sometimes dissimilar back office systems and, on the client end of the pipe, a whole range of devices (notebooks, PDAs, phones, etc). The medium could be text, audio, images, or video -- whatever is context appropriate to the client-side device and the middleware conceals whatever back-end fusion is necessary to facilitate anytime, anywhere, any device access to corporate information. According to Gartner, "Mobile solutions not built on an extensible multi-channel architecture by 2007 will cost twice as much over their deployment life cycle compared to multichannel access gateway-based products." In other words, a piecemeal strategy involving unorchestrated mobile technologies is a really bad idea.
To help corporate technologists compartmentalize mobile architectures into categories with distinct characteristics, pros, and cons, Clark and Jones described six fundamental mobile architecture styles:
Thick client -- the implication being that the client-side devices (PDAs, smartphones, and PCs) have local compute resources, thick clients are well suited to scenarios where end-users must work with data when no network is available and where security is a primary concern (thickness lends itself to a broader range of options when it comes to security). On the downside however, their sophistication and cost is commensurate with the complexity. It is the most expensive of the MAG styles and involves the fewest number of devices.
Rich client -- Code may reside in the device, but not data -- at least not a lot of data. The best vertical examples I can think of are the tablets that the folks from FedEx and UPS carry around with them. Here at Symposium/ITxpo however, the analysts mentioned BREW and the mobile edition of Java (J2ME) as a horizontal platform that's characteristic of a rich client MAG. But given the diversity of J2ME implementations out there and the degree of sophistication it takes to work with all of them, the analysts also cautioned that "J2ME is a mess." Gartner recommends rich client deployments when "you need better usability than thin clients but better TCO than thick ones."
Thin client -- Though not as good on the usability front as rich or thick clients, the main selling point of a thin client approach is the broad range of devices supported, largely due to the reliance on standard client side technology such as HTML or XHTML browsers or the mobile version of Flash (Flash Light). Thin clients involve no persistent code or data on the device side, but fall completely apart once network connectivity is lost. There are also fewer security options (eg: VPN or HTTPS) but the good news is that total cost of ownership is commensurate with such dramatically diminished complexity (relative to rich or thick clients).
Streaming -- streaming is a bit like the thin client architecture in that it implies the existence of some sort of standard streaming software in the client-side device and the architecture is widely associated with media an entertainment. It's also primarily a one-way architecture making it suitable in corporate environments for specific needs like training. But Gartner's analysts see streaming getting stretched to do other things. For example, Jones mentioned that code may soon be in embedded in whatever gets streamed (which also could raise security concerns). On the downside, streaming requires a lot of bandwidth and low-latency networks (not exactly something that people in a wide-area scenario can rely on).
Messaging -- confined to the limitations of mobile email or SMS messaging which means that as the need for more sophistication goes up (eg: something transactional), the more the final solution begins to look like a rich client, or, the more the burden is placed on end-users to massage the message formats into something that a back-end infrastructure knows what to do with. Security may or may not be a concern here. When relying on proprietary e-mail mechanisms such as those offered by RIM or Microsoft, security is good. But SMS over wireless and public networks does not offer the sort of security that many applications require. On the point of total cost of ownership, reliance on off the shelf solutions makes this a low cost option
No client - applicable largely to dumb phone situations where tone-based dialing or interactive voice recognition (IVR) suffice as interface mechanisms. With no client side technology to worry about, the "no client" architecture is one of the least expensive approaches and the implication is that all information can be conveyed in an audio format. The implication is easy of deployment from and end-user point of view since everyone is comfortable with phones and audio.
At one point, the analysts pointed out that even though it was a late arrival, Microsoft's Mobile .NET architecture is a far better choice than is Sun's J2ME architecture. Technically speaking, given the degree of control that Microsoft has over .NET, that may be true. But from a target device availability point of view, J2ME is a far bigger target for developers hit when you consider all of the handsets that include the technology today. The problem, on the complexity front (which is why the analysts said J2ME is a mess) is that J2ME is so fragmented (when comparing device specific implementations) that its a difficult target to hit in a predictable fashion. The analysts did however note that the situation with J2ME is improving.
Jones and Clark ended by presenting a newly minted Gartner Magic Quadrant for the category of Multichannel Access Gateways. Magic Quadrants are graphical presentations of market niches that are designed to give users an idea of where vendors are relative to each other in terms of vision, execution, and leadership. Vendors usually boast of their positioning in the highly coveted top-right (or northeast-most) quadrant where vendors within are considered to be the leading visionaries with the ability to execute.
But unfortunately for end-users that rely on Gartner's quadrants for guidance, the leader's quadrant for MAGS is currently empty. Meanwhile, there's a huge cluster of solution providers in the lower right hand quadrant where most of the vendors are known for their nichiness and their ability to execute is questionable. At the bottom of the barrel were Fujitsu and Oracle. The closest to the leaders quadrant were IBM (more visionary than anything else) and Sybase (with a better ability to execute). Sybase, was discussed pretty much as the one to beat.