5 steps to setting up an agency app store
Connecting state and local government leaders
Building an app store can be the best way to make sure employees are using the right mobile apps. Here's a checklist to help you get there.
Applications are the heart of what make mobile devices so very useful to public and private organizations.
But developing, acquiring and managing applications within a federal agency’s IT architecture presents administrators with a number of challenges. How do you make sure the apps your employees use are secure and compatible with your systems? One way to handle these issues is through a Web- and mobile-accessible site or storefront.
Enterprise applications stores provide federal agencies with a single place for personnel to access approved applications. Mobile device software, either commercial or developed in-house, can be approved and made available through the storefront.
Related coverage:
DISA to roll out defense-wide mobility plan
NASA: Moving to mobile is win-win
Besides providing a single source for applications, large agencies with many constituent organizations can create federated stores that have an enterprisewide main page with links leading to agency-specific applications.
But what steps do agencies need to take to establish their own enterprise applications stores? Here’s a checklist of five steps federal agencies are taking to establish their own sites for mobile applications.
1. Preparation
The Defense Department is the government organization most involved in developing mobile applications and aggressively adopting mobility policies on a wide scale. Coordinating and managing this process is the job of the Defense Information Systems Agency (DISA), which is working to set up classified and unclassified enterprise mobility services across the DOD. A central part of this effort is establishing an enterprise applications store, which is scheduled to be running by the end of this summer, said Rear Admiral David Simpson, DISA’s vice director.
One of the agency’s goals is to create an “ecosystem” of services, ranging from mobile device management capabilities supporting a variety of mobile devices across the DOD to the applications store that will also serve as a gateway to other stores run by the individual service branches.
While DISA is working on its enterprise applications store to serve the entire DOD, the individual services have been working on their own efforts. One example is the Army Apps program, which was an effort to determine if the service could set up and run its own applications store.
“The Army wanted to know: Do we have soldiers and government civilians who can write apps, and if so, should we be teaching them to write apps?” said Lt. Col. Gregory Motes, chief of the Army Mobile Applications Branch at Fort Gordon, Ga.
One result of the Army Apps program was the establishment of the Army Mobile Applications Branch, which is responsible for identifying and training personnel—mostly officers—to write mobile applications.
Since 2010, Motes's group has written some 90 applications, nearly two thirds of which have been made available on the iTunes or Android markets. One reason for focusing on these commercial stores is that they offer a distribution mechanism that can reach a wide group of users and provide useful feedback from the field. The group’s applications have been downloaded nearly 1.4 million times, he said.
2. Accreditation
Once an organization sets up its app store, it must put processes in place to ensure both the security and network interoperability of those applications. That’s where accreditation comes into play.
A key part of DISA’s mobility program is to establish applications stores in agency data centers, Simpson said. DISA also is creating a hierarchical process with service-run app stores to create a unified store front. “That’s the easy part, in my mind,” he said.
A more pressing challenge is getting applications into the store without overly burdensome layers of accreditation, or official documentation. What has made mobility so useful in the commercial world is the ability to rapidly create applications from a very diverse part of the workforce. “We need to be able to do that in a repeatable and secure way,” Simpson said.
DISA is using its experiences with Forge.mil, an open-source software development site, and provisioning-on-demand to embed just the right amount of certification into the process in an automated fashion, where possible, Simpson said. This will ensure that properly vetted apps are posted in the store and that guidelines are in place to detect anomalous activity.
Although DISA has not yet achieved built-in application vetting, Simpson expects that the agency will soon determine what the right balance is for the process. For example, the agency may be able to support a device-aware and application-aware security capability for DOD communities requiring high-level access. But this capability also would turn off certain applications that do not have the same level of security required for some specific environments. Simpson expects this approach to be used to tailor security for a diverse set of users with a wide range of mission sets.
3. Security
Securing applications so they behave on an enterprise network is both a challenge and a headache facing many federal agencies considering mobile device programs.
One way to provide application security is to avoid the classic IT model of firewalls and protected end-user devices by moving the security directly onto the applications, said Sasi Kumar Pillay, NASA’s chief technology officer for IT. Embedding security features into applications offers a number of advantages over traditional models because security can be fine tuned on an application-by-application basis.
Built-in security allows organizations to perform “risk-based decision-making,” which permits applications with varying levels of security to coexist on the same mobile device, Pillay said. This process also allows organizations to launch highly focused, or “granular,” security policies that offer better, more flexible defensive options than traditional perimeter methods.
For example, security policies can be written that would restrict access to a particular application to a list of approved individuals with certain roles in an organization. Use of the application can be further restricted to the time of day and location of the individual, such as on the organization’s campus, Pillay said.
What mobility offers public and commercial enterprises is the ability to take advantage of a growing confluence of technologies and opportunities, such as granular security. “Mobility is going to be the thing of the future,” he said. “It already is the thing of the present, and what we are trying to do is adopt to that type of environment.”
The Army’s app program initially avoided many of the security issues by focusing most of its development efforts on applications that will run on unclassified networks. This was partially a decision to expedite the accessibility of mobile applications for military personnel and to collect feedback, said Motes.
Other Army efforts are working with the National Security Agency, academia and commercial companies such as Google to develop more secure versions of the Android operating system. Like much of the federal government, the military is also continuing to use BlackBerry devices and servers because of their inherent security features. DOD is also working with Apple and Good Technology on improved security technologies for mobile devices, Motes said.
4. Look before you leap
When agencies set up their own apps stores, they need to avoid trying to reinvent the wheel, said Chris Schroeder, chief executive officer of App 47. He recommends that organizations consider two things when thinking about setting up an enterprise applications store.
First, agencies should see if this is really what they need to do. They should not try to build their own applications store or write own applications if there are commercially available alternatives, Schroeder said. Although there are technical challenges associated with setting up a virtual storefront and deploying applications, agencies need to view them from a cost-effectiveness perspective.
Regardless of an organization’s security requirements, Schroeder said that commercial applications and models can meet almost all of their needs. He noted that in the commercial sector, financial and health care institutions have high security requirements and support a robust vendor ecosystem to supply them. Government organizations can easily tap into this pool of vendors, he said.
The second piece of advice is to begin with the end in mind. Agencies need to think beyond establishing their apps stores and plan through the following steps: upgrades, customers and managing the applications on their storefront. Schroeder said that CIOs need to think back to the early days of the Web. When organizations first began building their Web sites, there was an explosion of applications to support them. This was a great time for agencies because it let small offices and units on the military side to develop applications that allowed them to do their jobs more efficiently and in scale.
But the proliferation of Web sites and applications created deployment and performance issues, which created the need for lifecycle management solutions for Web applications. “My point is that we’ve been through this problem before. The problem is that new disruptive technology gets introduced to the IT organization, the organization has to react to it,” he said.
5. The applications
But once federal agencies have set up their applications stores and the underlying infrastructure to support them, what choices do they have? Federal agency applications can be written in-house or they can be bought, accredited and made available through the apps store.
Both Schroeder and Pillay advise organizations to look to the commercial sector for readily available applications. Agencies can work with vendors to modify existing applications for their use or in some cases where security or operational requirements call for their use, they can develop their own in-house tools.
Several examples of in-house applications include one developed by the Army Mobile Applications Branch that is designed to allow mobile devices to scan code bars on pieces of equipment in communications trailers. Each piece of equipment has a specific data code that identifies it, its function and replacement/reorder options when called up on a soldier’s mobile device. The application was developed to help logistics and communications specialists with tracking and identifying gear when performing maintenance.
The Federal Aviation Administration recently launched a pilot effort to equip flight and maintenance personnel with Apple iPads. As a part of this program, personnel in various branches of the organization wrote applications to support their jobs. FAA lawyers wrote an application that allows them to store and play radar tracks of flight violations. FAA officials noted that, with the app, most cases are settled before trial when defendants are presented with the evidence. The officials noted that this saves the administration $100,000 per court case.
An example of a widely used application developed with a commercial vendor is the Defense Connect Online mobile application, which was developed by DISA and Carahsoft. A mobile version of a widely used desktop web tool, DCO is built around Adobe Connect and the Cisco Jabber chat function. The application allows users to remotely set up and manage meetings and share information over unclassified networks.