Should the average enterprise pursuing mobility also push back against tighter privacy rules, or preemptively curtail their ability to collect data about app users? The answer: neither push back nor panic makes sense for most enterprises. Instead, the sound approach to Washington’s app privacy direction is to make sure you have enough agility with your mobility platform so that your apps can adapt to restrictions that might take shape, while still ensuring you are able to collect highly useful data.

But first, it’s important to understand a couple of key points about the FTC’s staff report:

• The report is non-binding and doesn’t establish new regulations. While new regulations might take shape, the report actually suggests industry groups take the lead by following some recommended best practices.
• Some of the recommendations are essentially about the communication of privacy policies, rather than the data collection restrictions. If stronger rules take shape, much of the challenge might be to quickly get privacy notices or new consent screens out to app users.

At this point, there appears to be no imminent move toward a FTC crack down. However, at minimum the FTC is calling for more transparency from mobile app developers. The report talks about “just-in time” disclosures and obtaining user consent. Enterprises that are able to quickly push out notices or consent screens because they have an enterprise mobility platform would be able to meet transparency practices easily.

The tougher requirement—whether government mandated or coming from industry best practices—would be to actually change the amount or type of private data that an app collects. Most home-grown apps would require significant rework to change the amount of data that is collected from users or to what extent that data is stored. The apps will likely be hardcoded to collect certain data points for the user, so changes will require re-coding, recompiling, and redistributing a new app to each user. 

On the other hand, with an enterprise mobility platform, changes in what an app collects can be implemented quickly and easily without the need to push out a new app to each user or resubmit the app to the app store. A platform is built to accommodate a variety of requirements and should be able to enforce new requirements through configuration changes, not major rewrites.

Of course, compliance with privacy rules is nothing new in sectors such as financial services, which have stricter privacy rules than most. They already are transparent in communication of privacy policies. But if the direction in Washington continues, more sectors, especially those who build business-to-consumer apps, are going to have be agile in generating disclosures or consent screens.

The big question—and one that no one knows yet—is whether future app privacy rules will curb the collection of private data, or how companies use that private data. In fact, a report from the World Economic Forum argues that privacy rules should focus on how personal data is used rather than the collection itself. That seems a sensible view, given that it’s the misuse of private data, such as reselling it to third parties without app user consent, which seems most onerous.

What regulators should appreciate is that knowing more about app users helps improve apps. For business-to-employee apps, privacy and consent are less of an issue, but vaguely worded regulations could hamper useful monitoring of B2E apps that are simply aimed at customer service, such as knowing the real-time geolocation of service people closest to a customer. Because of reasons like this, enterprises building mobile apps need integrated monitoring features to make their apps more effective.

Companies shouldn’t shy away from capabilities like app user monitoring out of regulatory fears. Whether future app privacy rules or best practices are mainly centered on transparency, or actually put limits on what’s collected, enterprises with an agile enterprise mobility platform will be in a better position to adapt their apps.

T.L. Neff is executive vice president of Global Client Services for Verivo Software.

Upon closer examination, however, we can see the differences between working from home or “telecommuting” and enterprise mobility. The two trends aren’t equivalent, though they share some similarities. Enterprise mobility has its roots in helping a person who must be remote—by the nature of his or her job function —be efficient and effective.

For example, sales reps and field service technicians need to access data and the ability to carry out transactions while on the road. Mobile apps have been built—both custom and off the shelf—to help these employees get their jobs done effectively. And these mobile apps have gotten better and better at bringing efficiency to these employees, thanks in part to a rapidly maturing ecosystem of mobile app tools, technologies and platforms.

With telecommuting, on the other hand, the primary driver for being remote shifts from “necessary by the nature of the job” to “preferred for the benefit of the employee.” Yes, to some degree telecommuting also can be seen as helping a company, such as with knowledge workers who at times would be more productive in a quiet home environment, but the primary driver of the trend is to accommodate employee needs.

While it’s worth noting these differences, let’s also face facts. For all the attention placed on the decision at Yahoo!, it’s hard to envision all of corporate America banning telecommuting. Meanwhile, mobile workers and use of enterprise mobile apps is now commonplace not only for the classic “road warriors,” but for many types of knowledge workers, managers, and executives. So for companies that allow telecommuting, the focus should be on making telecommuting more effective; something they can do by taking a page from enterprise mobility.

For many enterprises, the first thing that is done to support telecommuters is to establish a virtual private network connection to many of the same apps workers would find on their desktops or laptops at a corporate office. The problem is the information technology support for teleworkers often stops right there.

Yes, you have secure VPN connection to some apps, but the company might not have outfitted the user with video conferencing capability, or apps and utilities that tell the rest of the enterprise where the worker is, or that share that worker’s schedule, or that push alerts to the user. Back at the enterprise, the IT department might not have good analytics. As a result, many telecommuters fall into an IT black hole—their apps aren’t keeping them in synch with the enterprise, and IT can’t keep good track of what telecommuters need the most.

Companies could address these shortcomings by borrowing on some of the strengths of enterprise mobility. When enterprise mobility is done right, there is close attention given to the management of the apps, to keeping users in sync with the enterprise, and on detailed analytics. For example:

• Enterprise mobile app platforms make it easy to push alerts and crucial messages to users. For example, if a customer urgently needs service on a piece of equipment, but the normal service technician is unavailable, a service alert can be pushed to all technicians within driving distance.
• Enterprise mobility platforms with built-in analytics can tell you details about which apps are getting used the most, which screens get used the most, and which device type the user is accessing the app with.
• When an enterprise mobile app user goes out of carrier network range, an effective app allows that worker to keep using the app and entering data, with an automatic sync once the device comes back into range.

Not only should teleworkers have collaboration tools like video conferencing, their apps should be more capable when it comes to factors that are table stakes for enterprise mobility—features such as geolocation, alerting, workflow, and communicating user status to colleagues.

Telecommuting is a well-established trend that’s not likely to go away. In fact, according to Telework Research Network, while 2.5 percent of the U.S. employees (excluding self-employed), or about 3.1 million people, considers home their primary place of work today, there are between 20 to 30 million Americans who work from home at least one day a week, and of those, 15 to 20 million are mobile workers.

The focus needs to be on making all workers more productive, whether they are telecommuters, traditional mobile workers, or the many knowledge workers and executives who need to be mobile at times.

So what can we learn from this discussion growing out the Yahoo! decision? Well, sometimes companies adjust telecommuting policies for unique reasons—like improving morale or tightening up teamwork—but it’s a stretch to see a larger telecommuting trend based on Yahoo’s decision.

Telecommuting will continue, so we need to make it more effective, taking lessons learned from creating apps for those workers who must be mobile, and applying it the apps we provide for employees who simply prefer to work from home, or at least need to at times.

Steve Levy is the chief executive officer of Verivo Software.

A few years ago, the idea of building custom enterprise apps instead of buying packaged software for functions such as customer relationship management had become a thing of the past.

Why build your own CRM or enterprise resources planning system when you could simply buy one off the shelf?

The old “buy versus build” argument—excluding websites—was a foregone conclusion in favor of “buy.” Then came the smartphones and everything changed.

With the introduction of the iPhone, followed by Android devices, consumer-led interest in mobile apps rose significantly. While some enterprises began building their own mobile apps for these devices, employees accustomed to a bring-your-own device environment began to download personal productivity apps from major app stores. In fact, according to Nielson research,  the average smartphone had 41 apps on it in 2012, up 28 percent from the year before 

The CRM and ERP vendors are also using specific functions as standard mobile apps – making the old “build-versus buy” argument relevant in today’s environment.  The question now is — should enterprises take the trouble of building their own mobile apps while so many functions are available from enterprise software vendors or from app stores?

There undoubtedly is an attraction to the promise of having no development burden for mobility. And for niche productivity apps from app stores, the acquisition cost seems low, if not free.

What’s not to like?

In reality, there is a long list of arguments for the “build” camp, including:

• An out-the-box app from an enterprise software vendor typically only mobilizes data and processes from one system. Yes, a CRM mobile app might work well if you are looking to mobilize a CRM function such as sending a quote for a custom order. But what if you want your quote app to integrate with a shop-floor system to check on manufacturing turnaround time, or with supplier data for further insight on the parts involved? A ‘build’ approach using an enterprise mobility platform, however, gives you the flexibility to integrate data from multiple back-end systems.
• With a pre-packaged app, you may be stuck with a less than optimal look and feel or field low app performance. For example, you may only be given access to a mobile web app, rather than a native app. This will lead to unhappy users and poor app adoption. Of course with a custom app, you control the user experience. If you want to change a function or the look and feel, you can do so and at your own pace.
• Buying and running a collection of off-the-shelf apps from different vendors can be challenging — especially since you will need different tools for app monitoring, device management or software consoles. An enterprise mobility platform, on the other hand, centralizes the management, monitoring, and analytics function so you can focus on developing the custom app.

Let’s step back from the functional concerns and think about how an organization should plan their strategy around enterprise mobility, deliver on its roadmap and monitor and manage secure apps. Does a company want to be 100 percent reliant on an outside vendor or multiple vendors to provide new apps, new features, or update apps to take advantage of new device capabilities?

For many companies, the answer to the above questions is a definite “no,” which is why many have turned to enterprise mobility platforms to provide efficiency for a build approach, along with a means for centralized management. This is not to say that for some organizations, a buy strategy won’t work for at least some apps, as long as they find a way to have enough flexibility and control for their overall direction 

Enterprises going down the purely “buy” path need to take care, whether relying on a mix of mobile apps from enterprise-level vendors, or allowing a “bring your own app” environment for personal productivity apps. On this last point, analyst firm Gartner recently warned that for enterprises, “Apps downloaded from public app stores for mobile devices disrupt IT security, application and procurement strategies,” and advised companies need to look at ways to create enterprise app stores that serve both end-users and IT.

It all comes back to control over enterprise mobility, including the power to give users exactly what they need. The best way of controlling your enterprise mobility strategy is with a custom approach. When you pair that approach with an enterprise mobility platform, you get cross-device development efficiency and centralized management. That’s a good foundation, even for companies that decide to enhance it with some off-the-shelf apps.

Do you agree?

Marc Rosenbaum is director of Product Marketing at Verivo Software.

Is it a customer relationship management system or a specific CRM function, an enterprise resource planning suite? Maybe it’s a Web portal, mobile apps that integrate with a more specialized data store, held in a relational database or apps that “call” into an information source via Web services?

Tell me!

Parna Sarkar-Basu is Vice President of Marketing Communications, Verivo Software.

Moving quickly with enterprise mobility is more important than ever. Where a year ago, many companies still exhibited a “stick a toe in the water” approach with a pilot project that might take a year, today, multiple app projects per year is becoming the norm, as recent research has noted.

That means speed is imperative. Previously on Mobility Watch, I’ve addressed some of the bigger picture challenges that tend to get many companies “stuck” on getting started with mobility, but there are some methods to speed deployments which are relatively simple. But we could be doing them on all app projects, not just when getting started.

Think of these as implementation accelerators for mobility — little tricks that can move the process along as companies look to churn out more apps:

Take a snapshot of what you have and what others are doing. One of the first steps for getting a quick start on mobility is to simply know the resources and mobility preferences within your enterprise. Which devices would your people want to use under the bring your own device policy? What are their favorite apps? The flip side of this is a quick analysis of what key competitors in your industry are doing with mobility? Which of their apps are winners, and might relate to an idea you have? These snapshots get the ideation process moving quickly.

Show, don’t tell. Once you’ve identified a needed app, you need to flesh out its look and function. But hey, it’s an app, and mobile apps are very visual, so don’t describe it to death with words. Use some screen mock ups in a slide presentation, or show a screen image from an existing app you like. Such visuals can more quickly refine ideas and consensus when it comes to what you want in your apps.

Have a resource plan for each project. When companies’ first get into mobility, one of the most important steps is to take inventory of your developers’ skill-set, existing mobile devices, security and log-on procedures for your internal systems. In short, anything that will come into play with your mobile strategy. But you also need to update what your resource needs are as well as likely constraints for each project. You might be getting into projects that involve more HTML5, for instance, or you might know that your next app is a tablet app. So, you should check the migration plans your enterprise or your users have for tablet devices so you can get the most of new features, i.e. much higher screen resolution. So keep your resource plans current and avoid some speed bumps down the road.

App ideation, deployment and management always will require plenty of creativity and resourcefulness from the mobility team you’ve established. However, by using little accelerators like pulling together concrete examples from your vertical space, getting visual about the micro-processes you want your apps to carry out, or knowing ahead of time what you need for each project, you can be one of those enterprises that has no problem cranking out multiple apps annually and deliver real value.

What’s your view on acceleration methods and do you have another “accelerator” that’s not listed here? 

Michael Shea is the founder and CEO of Mobility Effect.

Our charting app is very different than what iOS native is providing. When it comes to charting, there are different options in the mobile apps.  One of them is use native code and build your own charting options, the other one is to use a third party, and also [third] use HTML5. So there was different options the platform would enable us to do.

Between all of these [options] we decided not to use native-not to code it natively, because if you code it natively and implement it within the platform, we kind of get away from our, ‘develop once and deploy it multiple’ guidelines. So that one … we didn’t put it on the table. The other part of it-using the third party-that one was also not an option for us because that means we had to get out of our application for a chart and come back, and that was not an accepted user experience. So we ended up with an HTML5 approach and what is unique with HTML5 is that first of all,  we were able to reuse whatever we had done on the Web, which was huge for us. 

It was easy implementation-we just reused whatever we had done on the Web.  And, other than that, it also provided us a lot of interactivity with the chart itself. So you could kind of simulate in a native app but in an HTML5 container, so that would allow us the best user experience, as well as kind of, the ease of implementation.”

Babak Rastgoo, business technology specialist at Invesco Canada.

Being a financial asset management firm, security is of course one of our primary concerns whenever we are talking about digital, be it our website, or the mobile app.

For me, it’s one of the most important things. And it’s not a very glamorous feature, but it’s table stakes. It’s what our shareholders and our investors expect of us. We don’t want to be a company that is compromising personal information of our investors or our financial advisors.

So advisors who are already registered for our website can use the same credentials to log into our app. There was no cumbersome re-registration; they didn’t have to submit any personal information as they were registering.

The other key security element was that we don’t actually store any of the information from client accounts locally on the device. So iPads, mobile devices, are far more likely to be lost or stolen than a laptop or another form of computer. So it was really important to us to ensure that should a device be compromised, that no personal information for end investors would be found on that device.

We do have the ability for non-personal information to email it to clients. So advisors can email marketing materials and videos, but again when it comes to statements, we restricted that. So this information stays on Invesco servers and not locally on the devices.

That was our approach. We worked very closely our IT and IT security teams. Being the first external app within Invesco globally, there was a lot of attention paid to our development and we wanted to make sure that we were a success story, and that we didn’t have any issues.

Bruce Borgundvaag is assistant vice president, Digital Strategy at Invesco Canada.

Hari Pillai, manager, e-Development & Design

Our mobile initiative started with, like a combined approach actually. There was a lot of interest through our sales team that our advisors are getting more mobile savvy. And essentially, they wanted us to look into different mobile offerings that are in the market right now. And we also, at the same time, we were also doing a lot of research-within our team, within our e-services team, within our marketing team-we were doing a lot of research on what is out there, and what are the different mobile technologies. So it was like a combined effort, and our senior management was very supportive for us to explore this further.”

Bruce Borgundvaag, Assistant Vice President, Digital Strategy

So our mobility initiatives really enhanced our existing reputation as a technology leader. We were very pleased that we able to, in a relatively short time period, all told about six months from start to finish, launch a mobile app which is the first external-facing app for Invesco globally. So among our firm certainly we are leading in this area and we’ve been working very closely with other areas within Invesco-in the U.S., in Europe-to share what we’ve learned from this experience and help them in their initiatives. And several people have followed suit since with their own apps.

Like a mobile enterprise application platform (MEAP), BaaS uses middleware technology to allow developers to link to backend systems like enterprise resources planning (ERP) without extensive coding. But with a BaaS solution, the middleware runs on the cloud as a service, rather than as a platform you can deploy in-house.

The other key difference between MEAP and BaaS is one of scope. With BaaS, developers can use various mobile front-end environments to create apps, whereas a MEAP typically includes some front-end tools. Though some MEAP vendors have moved to embrace other development avenues such as HTML5, today the difference is most MEAPs include a front-end environment.

Perhaps more significantly, a MEAP typically has a greater range of utilities to secure and manage apps, such as data encryption, remote wiping of enterprise data on lost devices, app analytics, and other reporting and monitoring functions. In a blog post in April 2012, Forrester Analyst Michael Facemire summarized some of the key BaaS functionality, and notes the availability of some analytics. However, it’s generally true that BaaS is not meant to be as broad platform as a MEAP.

So while the BaaS market is rapidly evolving, and some research predicts strong growth for the space, its more narrow focus means that by definition, it’s less of a complete solution than a mature MEAP. Yes, Baas may take the heavy lifting out of many integration challenges, but as far as having an overall mobility platform at your disposal, some assembly is still required with BaaS.

Of course, vendors within a market will vary in their capabilities. For some mobile apps, especially those that focus on collaboration with existing social media resources, a BaaS might be a highly effective solution. It’s also worth noting that we are seeing a divide in the BaaS market, with analysts such as Forrester classifying some offering as “enterprise-class” BaaS.

So while BaaS has potential and may be a sound choice in certain cases, potential users have to dig through the hype to see what really fits into their mobility strategy.

Are there other tools for functions such as security that they are going to have to assemble while using BaaS for the integration piece? Does the BaaS provider offer pre-built middleware “plug-ins” to all the major systems like ERP or customer relationship management? Will the cloud-based integration allow for offline synchronization of massive amounts of data that enterprise users need when they are working outside of wireless coverage?

Finally, because BaaS lives in the cloud, will ongoing communication with on-premise, backend systems require workarounds such as use of a site-to-site virtual private network?

These are the types of questions that companies considering BaaS should dig deep into. Meanwhile, the core drivers for BaaS—simplified integration and more freedom on the front-end—reflect true market needs that frankly, deserve all the attention they can receive.

Chris Garber is the director of Product Management at Verivo Software.

Jeffrey Hammond of Forrester Research and Christopher Willis, chief marketing officer for Verivo Software, discuss the seven steps to managing BYOD. From the types of devices, workloads and security classes you need to support to the information, features and activities that users expect to use, learn more about the best approach to planning and executing successful enterprise mobility initiatives.

Chris Willis, CMO, Verivo: Bring-your-own device or BYOD has become a very hot topic, and recently you released seven steps to managing that process [see the Forrester report, “Charter a Mobility Council with Seven Tasks”]. Can you talk a little bit about that?

Jeffrey S. Hammond, Principal Analyst, Forrester Research, on first step: Workforce Segmentation: “Sure, absolutely. The first thing that you need to do is think about the people that you are mobilizing. It’s very important. I think one of the easiest things to do is to survey your employees, and ask them, what kind of devices are they using? It’s not rocket science here. And it’s pretty easy to look at Web traffic, if you’ve got people trying to browse your site, and see what kinds of devices people are using. Or, you can even do customer surveys.  And you may end of seeing that gee, you know, 80 percent of the devices that our employees are using are either iPhones or Androids, or they are iPhones and RIM devices. Well that gives you some really good insight into the types of devices that you need to support. But you should go beyond that and ask them a very simple question, ‘what do you need to do when you are out of your office?’ Now that doesn’t necessarily mean out of the building; it means physically out of their office or cubicle…”

Summary on rest of step one: Outside of cubicle or office, people reach for tablets or mobile phones first. By finding out what people need when they are out of their office, or what customers need when they are out of the home, you can start to prioritize which functions or information you need to mobilize.

Summary of Hammond on step two: Tiered Device Management/Security: One of the things that you want to think about are the classes of devices you are going to support. There are three basic classes. First, there are unsecured devices such as those that customers would use and the enterprise has no control over. At the other end of the spectrum are company liable devices that are highly secured. In the middle are “lightly managed devices” for which the enterprise might provide app-level security or a secure log on to a corporate portal, but wouldn’t manage the device hardware itself or have the ability to completely “wipe” the device. Supply chain or channel partners often fall into the middle tier of lightly managed devices.

Summary of Hammond on step three, App Prioritization: By considering what you’ve learned from what users need and other segmentation work, you can start to prioritize what you need in your app portfolio. Enterprises should identify the Tier 1 projects that will have the biggest impact on the company or with clients, followed by Tier 2, and Tier 3 projects. For example, apps that benefit a wide swath of users such as mobile email, mobile portal access, or mobile contact management might be in the first wave of apps, followed by high value apps for a subset of employees, such as mobile business intelligence for executives.

Summary of Hammond on step four, Multi-Platform Development: If your company is like most, the need to support multiple device platforms is the norm. As a result, you need to master multiplatform development. Enterprises that try to build native apps typically find their development and maintenance costs go sky high. Few enterprises are willing to spend 200 percent to 300 percent of their current app development budget on a native approach to the client side of mobile apps.

Summary of Hammond on step five, New Funding for Infrastructure: There is a need to “refund your network,” which means to have in place an architecture that supports multi-channel, mobile apps. Enterprises will need to consider mechanisms such as application programming interface (API) gateways, and cross-device notifications. The goal of this revamped infrastructure is “turn the app into a connected experience.”

Summary of Hammond on step six, New Reimbursement Policies: With BYOD, there isn’t the usual capital cost associated with buying devices, but there is the need to have clear employee reimbursement policies regarding carrier charges. This might involve establishing a cap on how much of a bill can be reimbursed, or identify a roaming plan that suits a subset of employees.

Summary of Hammond on step seven, Enterprise App Stores: Organizations are shifting from an IT push model to an employee pull model for app distribution, which means organizations need to consider the “app store” model. But because most companies don’t want private information within enterprise mobile apps distributed through a public app store, that means companies need to create an enterprise app store. These enterprise stores essentially are “private” versions of the public app stores for controlled distribution of apps to employees, or to partners.

Hammond’s closing remarks on the seven steps: “You follow those seven things—you’ll need where you need to be. You’re probably not going to get them all done in 2012 or 2013, but you can plan out a two- to three-year strategy to get all of those pieces in place.”

Remaining video overview: Hammond goes on to explain the different types of mobile work loads: device-centric wordloads, content-centric workloads, and connected workloads. A device centric workload is one that would be ideal to perform on an airplane or other setting where there is no wireless connectivity, and the form and function of the device takes precedence. A content-centric workload is one that involves presentation of text information, and graphics or video, such as a newspaper mobile app. A banking app would tend to have a connected workload, because bank balances change frequently, so connectivity to backend data is critical. As a result, it’s important to support a mobile framework or tool that supports the type of workloads you will have. Hammond goes on to explain the importance of considering the existing skill sets of your developers with mobile infrastructure choices, as well as how explaining how different platform pricing models might suit an enterprise depending on the typical use patterns the enterprise can expect for its mobile apps.