• United States



Mary K. Pratt
Contributing writer

How to cope when mobile app development goes rogue

Mar 14, 20178 mins
Mobile SecuritySoftware Development

Business units often develop mobile apps on their own, turning to IT only when things go wrong. Better governance around business units and their mobile app demands can help alleviate the worst pain points.

confusion decisions future misleading direction arrows
Credit: Thinkstock

When Independence Blue Cross released its first mobile app in 2012, it simultaneously embraced the tech trend of the moment and perpetuated the legacy of shadow IT.

That’s because the app came from the company’s marketing department — without any involvement from IT.

And like most shadow IT projects, that came back to haunt both marketing and IT.

The app, which offered patients mobile access to Independence’s member website, fulfilled marketing’s goal of getting a presence in the mobile space, but it was problematic nearly from the start, says Ken Russo, who was director of enterprise architecture at the Philadelphia-based nonprofit health insurance company when the app made its debut.

Developed by an outside agency hired by marketing, the app relied upon screen scraping to interface with the website. So the app broke every time the company’s portal changed, which was often. That sent marketing first back to the vendor for fixes and then to IT for help.

“The solution was very fragile. It required excessive maintenance from the vendor, and the cost became prohibitive. Also, a defect fixed on one platform wasn’t always fixed on the others. We needed a better way,” says Russo.

That experience demonstrated to company leadership the need for a better approach. Russo was given a new role and title — director of consumer and mobile solution delivery — and charged with establishing a technology strategy for mobile applications. He settled on a process that includes using the Kony mobile app development platform to get apps completed as quickly as business units needed.

As organizations rush to establish a coveted mobile presence, business units are developing and deploying apps on their own, and that means IT departments are facing a whole new era of shadow IT. In fact, research firm Gartner predicts that, by 2020, 70% of mobile apps used within the enterprise will be created or adopted without IT’s involvement.

The fact that so many mobile apps are developed outside of IT might seem like a blessing to overworked tech departments already facing lengthy lists of mission-critical tasks. But the situation rarely translates into fewer headaches for the tech team. In fact, outside development can cause a host of problems to land on IT’s doorstep — as Russo’s experience shows.

The potential problems with rogue mobile apps can go well beyond simply taxing IT’s time. Analysts say such apps could introduce infrastructure security risks if not configured and integrated properly. Similarly, such apps could put data at risk by not sufficiently protecting it from loss or theft. They also could add costs and inefficiencies to the organization if (a) different departments contract for the same services, (b) business sponsors fail to consider maintenance needs as well as integration requirements when launching pet apps, (c) they develop and deploy poor-quality apps that then fall back to IT to fix, or (d) all of the above.

“Business units wanting to build applications can be a positive thing, because it shows that organizations are forward-thinking and using mobile to innovate and transform their business. But IT has to be involved,” says Gartner analyst Jason Wong.

That makes sense to Isaac Sacolick, the global CIO and managing director at Greenwich Associates, a provider of market intelligence and advisory services to the financial industry.

Sacolick says that although hiring a vendor to develop a mobile app is easy, business units aren’t usually equipped to handle the complexities of building an app properly. Business divisions likely won’t give enough thought to user experience, security requirements, data needs, network connections to corporate back-end systems, and ongoing maintenance, he says. What’s more, they likely don’t have the skills or experience to evaluate vendors and set contract terms appropriate for development projects.

Embracing rogue app dev

Still, Sacolick and others don’t believe CIOs should — or even can — shut down mobile app development coming out of business units. Rather, IT should support such efforts, and potentially wind up with better, more secure apps.

“CIOs need to embrace this because it’s potentially a competitive advantage. CIOs need to stop seeing it as a threat and shift control. It’s OK to empower the business,” says Gartner analyst Katherine Lord.

Sacolick says CIOs should consider deploying a low-code mobile app development platform, creating standard APIs into backend systems for would-be programmers to use, and identifying and establishing agreements with external development partners as needed.

Forrester Research defines a platform as one that enables rapid application development and delivery with a minimum of hand-coding necessary. In a 2014 report, Forrester says such platforms allow IT to support business workers in building sustainable, easy-to-maintain apps.

Matt Willmore, program manager of the University of Notre Dame’s ND Mobile app, sees the API approach as a good one. Willmore says the university has seen students build mobile apps for various tasks, using publicly available data. They’re scraping or parsing to accomplish the task, but Willmore says he’d like to create publicly available APIs to support students’ mobile endeavors.

Needed: Clear standards, good governance

Whether CIOs choose to empower business users or keep development within IT, analysts say IT leadership needs to set clear standards and communicate best practices around mobile apps.

Establishing what tools, processes and standards should be used when developing mobile apps will give IT some assurance that apps will be sustainable from a technology standpoint as well as a fit with the organization’s strategic and security requirements, says Gartner’s Wong.

“IT is going to need to put in place an architecture and set of standards and policies and governance that help facilitate decentralization and democratic mobile app development without being a bottleneck,” Wong says.

Notre Dame’s Willmore is moving in that direction. “One of the things we’re trying to do is give students more and more resources to do development. We don’t want to squash it, so we’re organizing hackathons and weekend events and engaging with students and developing a development framework for students,” he says.

“Before, [an app] would be dropped on our doorstep with a message for us to support it; now we’re building frameworks for them to be built at the university level. If it gets to a point where we want to support it, then we already have it in our framework,” Willmore explains.

Communication is a key part in getting such plans to succeed, Lord says. IT leaders must build relationships with professionals throughout the business, letting executives, managers and staff workers know the mobile app development policies and procedures as well as the fact that IT is available to help. That means allocating appropriate staff time to make that happen, she adds.

“It needs to be collaborative. It can’t be just about IT controlling [development], or the business unit controlling it,” Lord says.

That’s the approach Independence Blue Cross’s Russo took. He worked to unify the company’s mobile effort. He deployed Kony’s application development platform, introduced agile development methods within IT to be more responsive to business-side requests, and created a team with IT and business-side workers to look at mobile strategy.

These steps, he says, enabled the company to create guidelines on key concerns such as user experience and data protection along with the first IT-sanctioned company mobile app, its flagship IBX, launched in late 2012.

Russo says the business units now come to IT when they want to go mobile, and IT helps them determine whether they just need to add a function to IBX or to create new app altogether, and what technologies will be best to accomplish what they want.

In some ways, Russo admits, it’s an old-fashioned management approach that’s solving the very modern pain points that come with rogue mobile apps.

“You build relationships and the organization builds confidence in you,” he says. “After four years of doing this, we’ve got a really good reputation, so when there’s a need in the mobile space, they know to come to us.”