Key Decisions to Make When You Decide to Go Mobile

At such time you decide you need a mobile presence for your corporate website or for an enterprise application, you'll face some key decision points, the outcome of which will define how you execute on a mobile strategy.

We will provide more detailed guidance about these in a future advisory paper, but in the meantime, here are the key points to consider:

  1. Which Devices to target: This obviously depends on your target audience and what constitutes a mobile device for you. While simple cell phones, PDAs, smartphones, and tablets are quite obvious, what may be less obvious are devices such as gaming consoles or even the good old television that can act as delivery channels in some contexts. In my previous organization, I worked on developing a strategy for a hospital that wanted to be able to stream patient data on a linux-based handheld device carried by docs. Even without going that deep into what constitutes a mobile device, at the very minimum, you will need to decide what kinds of phones and tablets you want to target. This includes both the form factor (or the size) and operating systems (iOS, Android, We've discussed this issue in these blogs before:
  2. Mobile Apps, Web Apps, or Hybrids: There are many ways to develop applications and sites for mobile devices. So you'll need to decide whether you'll stick to browser-based web apps, create downloadable applications, or use both for different use cases. We provide some guidance on which option is suitable for specific use cases in our advisory paper Mobile-Enabling Enterprise Applications: Browser or Downloadable Apps? as well as number of blog posts like:
  3. Existing tools or new ones: You probably already have numerous enterprise applications that  provide some sort of capabilities for building mobile applications or web sites. For example, many Document Management vendors provide device specific applications to access a subset of functionality provided by their tools. Similarly, for a mobile website, you could possibly use your existing Web Content Management (WCM) tool or a Portal tool. Alternatively, depending on your scenario, you could invest in a sophisticated mobile middleware framework:
  4. Managing content for mobile site and related architectural Issues: Publishing a mobile site will raise additional issues related to content duplication, publishing, workflows, and presentation. So you will need to have a handle on technical issues such as:
    • Do you employ a separate repository for mobile content (and this duplicate content) or do you use a common content repository?
    • How do you publish content from your regular web production environment to mobile environment?
    • Do you repurpose or recreate content?
    • How do features such as in-context editing and rich text editors work for mobile websites?
  5. What happens to existing websites and content:  You obviously would not want to throw away your existing site, especially if it was not developed a long ago. So it'll be important to understand how you'd reuse existing content or mobilize an existing website. There are many approaches and tools to do that but if you've followed some basic principals of content management -- such as separating your content from its presentation -- you should experience fewer problems here.

There are many more considerations -- such as information architecture and user experience in a mobile context, content migration, alternative development approaches, and so forth. Yet, addressing the key starter issues above will give you a good launch point in your mobile roadmap.

What has been your experience and what are the key issues you've faced? Please feel free to comment below, email or tweet me.

Other Enterprise Portals posts

How did our 2017 predictions fare?

Like every analyst firm RSG makes annual predictions, but uniquely in the industry, we go back each year to evaluate our own prescience.

There is no such thing as a DXP

I don't know any enterprise customer that wants — or believes it remotely possible — to obtain all those services from a single vendor. No, this is a vendor fantasy, getting peddled by analyst shills.