3 Ways Red Hats Mobile Right Strategy Changes Enterprise Apps

3 Ways Red Hat's 'Mobile Right' Strategy Changes Enterprise Apps

6 minute read
Scott M. Fulton III avatar
Throughout the world, businesses have already moved to smaller, more mobile, more tactile screens as

Throughout the world, businesses have already moved to smaller, more mobile, more tactile screens as their means of interacting with critical business information. Cloud dynamics has made it easier for server-based applications to reach these people on their new devices.

So the Big Transition — worthy of capital letters — should already have happened. For many customer relationship management (CRM) users, it certainly has. Customer outreach platforms are reaching out to customers where they are. They are not on their PCs.

But for a great many users of ERP, BPM and — the big one — content management systems (CMS), their IT platforms do not yet employ mobile access models. There’s no app for everything you need to do to run a business. For too many web sites, the “mobile version” relies very heavily upon pinch-to-zoom.

Must all enterprise applications become mobile because their users are mobile? The answer to this question may not be what you expect, especially the one we received from Red Hat.

3 Things To Understand

1. Mobile Access Needs Mobile Developers

 “A lot of the old ‘mobile first’ deployments that we’ve run across are ones where customers purchased a platform that was all-in-one,” explained Steve O’Keefe, Red Hat’s mobile product line manager. “The customer had to build the app, build the integrations and run it all in one system. And they found that to be very difficult to maintain, and very difficult to repeat the success to get the second or third app out.”

In the days of web sites, businesses relied upon publishing platforms with default setups and automated deployment. From their perspective, they rented their lot in cyberspace and would add fixtures and decoration as they progressed.

In the era of apps, however, customer outreach requires developers (the software kind, not the real estate kind).

Last week, Red Hat made an announcement regarding its approach to serving customers who deploy enterprise-scale applications for mobile employees. The company listed four pillars, and told the world it would be focusing on those four in the interest of maintaining customer mobility and business agility.

Never mind what those pillars are for a moment. You’ve probably heard them already. Somewhere in-between the moment of inspiration and the point of delivery, Red Hat’s message became deluged by all the major buzzwords: “DevOps processes,” “developer-centric,” “continuous development,” “integration,” “middleware.”

Red Hat covered all the bases, but lost sight of the play. O’Keefe made several critical clarifications, bringing Red Hat’s message back to where it should have been at the beginning.

When an organization begins moving to customer outreach on mobile platforms, O’Keefe said, they hire mobile developers. They bring in with them a wealth of talent, techniques and practices that others in the organization have never seen before. “We found a lot of enterprises struggling with that,” he said.

O’Keefe told us that Red Hat came to the conclusion there should never be just one version of a mobile app. “The mobile app development landscape is a rich, vibrant ecosystem of tools, tool chains, and frameworks, and we want to embrace that.”

Red Hat wants enterprises to hire those developers with the unique, mobile-only skills, and let them build whatever apps may be necessary to reach customers where they are. The company could profess one way to build an app, or offer one development environment to rule all the device platforms, or install one class of middleware to keep customers inside their own branded channels.

Instead, it would rather offer rich and replete system development kits (SDK) from which these developers can pick and choose what they need.

2. Stop Subdividing Platforms by Device Class

You’ve heard of the “Mobile First/Cloud First” approach. It’s Microsoft’s term, often repeated by new CEO Satya Nadella, for its new strategy for software deployment. Microsoft is finally taking into account the new reality that customers are no longer chained to Windows.

But “Mobile First/Cloud First” may not apply to the rest of the world as much as to Microsoft. Outside of the Redmond, Wash. campus, mobile devices and cloud servers are two opposite ends of a huge scale of information technology. It may be an effective product strategy for Microsoft, but it’s not a cohesive implementation strategy for businesses seeking to bring their IT portfolios into the 21st century.

Learning Opportunities

“We think of mobile as an extension,” said Red Hat’s O’Keefe, before making an astonishing concession to reason.

“We’ve always talked about extending enterprise applications out to mobile devices ... which is a very nice sentence to say from a strategic standpoint. But when you get down to the nuts and bolts of doing that, you have to acknowledge that these mobile devices — while powerful computing devices in and of themselves — are constrained in certain ways.”

Bandwidth is still limited, he said, and much of that bandwidth is still provided by public networks. While tablets are becoming more pervasive, most touchscreens are only the size of smartphones. So touch is typically small.

Typically, but not always. So O’Keefe suggests that, from here on out, enterprise applications take into account the devices they’re running on, as they are running. When the constraints are heavier, they should adjust themselves, offering a subset of the application’s full functionality. Where bandwidth is greater, screen size is larger and interactions are faster, they should scale themselves out.

Mobile functionality, in other words, but never a single “mobile version.”

3. Build the Enterprise Workflow First

For them to get to this point, O’Keefe suggests that businesses — not just software developers or DevOps technicians or administrators, but entire businesses — completely map out their optimum work processes or workflows. They should decide how work should work, and let developers build functions that follow that map.

“Take a traditional CRM or ERP system. Those are massive systems that do lots of different things,” he said. “The single mobile app really can’t replicate all that functionality. What the organization needs to do in that mobile instance is realize that the experience of the user needs to be focused on a certain task or workflow within that application.”

Make it possible for the user to know and understand what the application platform enables her to do. The user is probably smart enough to recognize when a device lacks the capacity to perform a given function. That said, the user should be enabled to move to a different device, and perform the function there.

Same platform, same functionality, different locations. It’s the user who has the mobility, and who is moving between devices. As far as the platform is concerned, everywhere she goes, there it is.

“If you think solely about ‘mobile first,'” said O’Keefe, “you’ll build very small, incremental apps with small, incremental back ends. It’s really more ‘mobile right,’ in that an enterprise stores data and manages complex processes in a different way than an independent, consumer-focused developer would. Getting ‘mobile right’ is about acknowledging those differences, applying the techniques of mobile ... but then supporting them on a back-end system that may aggregate several of those bespoke apps for an enterprise application.”

Creative Commons Creative Commons Attribution 2.0 Generic License Title image by familymwr.