Commentary: How to Build Apps Even Your Kids Would Be Proud Of

Significant thought and planning are required to create software applications that can compete effectively with the best that Hollywood, Silicon Valley and Madison Avenue have to offer. But as feds wrestle with the demands of the Obama administration’s 21^st Century Digital Government Strategy, which requires them to make two high-value, customer-facing services available via mobile devices over the next year, they can learn much from the success a number of federal agencies have already demonstrated.

Too often, users simply add a mobile compliant interface to an existing system. While this might suffice as a stop-gap solution or be acceptable for services that are used infrequently, it doesn’t fully leverage the platform or the opportunity. 

Instead, you should seek to redesign and improve the existing process to capitalize on the device’s unique capabilities while accommodating specific organizational constraints. As a simple example, individual screens often replace fields as the default workflow for data entry on a mobile device. 

More significantly, there are ample opportunities to integrate the device’s native capabilities, such as cameras and Global Positioning System tracking, to further enhance the process. At the same time, adding additional features -- for example, biometric readers, barcode readers and insulin glucose meters -- open up a world of new opportunities for providing services.

Just as you wouldn’t design a DVR just to mimic a VCR, you shouldn’t constrain yourself based on what’s available (or possible) on the laptop today. Users generally look for entirely new features that capitalize on the platform’s unique characteristics versus incremental improvements in existing functionality. As just one example, new approaches to field authentication are a big driver in the law enforcement community’s interest in mobile devices. 

Another key lesson learned is that the most effective mobile apps are often narrowly targeted. This allows them to better address user expectations. Notably, this is the approach that Apple uses for the apps it develops. At the same time, these more targeted apps can be brought together to create suites and solutions optimized for specific users and their requirements. In designing an app, focus initially on the 20 percent of the process that gets used 80 percent of the time. This allows you to more quickly deliver value while avoiding unnecessary complexity and bloat. 

Another important consideration is to know your operating environment. Specifically, whether devices will be able to -- or need to -- connect to the network anytime, anywhere. For many scenarios, you will need to ensure that the app can operate independently of the network and use automated synchronization to maintain operational continuity.

Security: Getting the Balance Right

Maintaining enterprise security is incredibly important. By the same token, deploying mobile devices that users want to use is also a critical element of advancing the mission. Harmonizing these competing demands is risk management, where a balanced and realistic view of your requirements is needed. The alternative is to create systems that are so secure that they can’t be employed effectively.   

It is important to consider the alternatives when setting these thresholds. For example, important questions are being asked about what happens when a smartphone is lost, but few are asking the same questions regarding lost notebooks, either computers or the old fashion kind. In the case of pen and paper, the best you can hope for in terms of security is a diary lock that Cindy Brady might have used. 

Specific requirements you’ll typically need to address include:

• Authentication. This is the process of verifying that the user is who he or she claims to be. Traditional passwords are the most common approach. However, you can also integrate third-party devices, such as CAC card and biometric readers, to provide a higher level of authentication and comply with specific security provisions.
• Access Control. Once you have positively identified the user, you will often want to limit their access to information depending on their authority or needs. Controls also could include GPS triggers to automatically disable cameras within sensitive facilities. 
• Data Encryption. Information can be stored or protected in a non-readable format so that it is unintelligible if the device is lost or stolen. Data should be encrypted in transit across public airways and at rest on the device with different technologies often used. For particularly sensitive requirements, we have even developed solutions that maintain no persistent data on the device itself. 
• Sandboxing. This is a native feature of most operating systems that limits the actions of each application to its own container. In terms of security, this prevents malware from taking over other applications within the device. 

One of the key takeaways here is that these approaches are fairly mature and well-understood. This means that they should not be roadblocks to leveraging mobile devices. 

Users recognize the need for security provisions, but they want them to be as seamless and non-intrusive as possible. Multi-factor authentication may be appropriate in some cases, but it also may just drive users to workarounds that are far less secure, such as exchanging sensitive information via public e-mail accounts. 

About Those Security Requirements

The requirements for data encryption are embodied in Federal Information Processing Standard 140-2. Agencies employing data encryption within any IT system, including mobile devices, must comply with the FIPS 140-2 specifications or demonstrate that they have sufficient security provisions in place to protect their data. This second point is often overlooked but it shouldn’t be. 

While all mobile devices provide data encryption, not every approach is FIPS 140-2 certified. Currently, Apple’s native capabilities are not, BlackBerrys are, some Android devices are, and earlier versions of Microsoft’s mobile operating systems comply. This is a dynamic issue as changes in the operating system may require that the encryption module be recertified -- a potentially lengthy process. Astonishingly, we have even seen cases where products were certified after they were discontinued by their manufacturer.

It is important to remember that FIPS 140-2 doesn’t guarantee security as it’s just one element of an overall strategy. Fail to implement some other provision and your organization will be compromised.  The fact that many devices currently lack FIPS 140-2 certification has actually been positive as it has forced agencies to actively evaluate their security posture versus rubber stamping their compliance. 

And here’s the kicker – third-party, FIPS 140-2 certified data encryption modules that can be implemented on any device are commonly available. In addition to addressing specific gaps, benefits of this approach include the ability to standardize on a single encryption specification across multiple devices. 

Tim Hoechst is the chief technology officer of Agilex, where he leads the company’s Technology Innovation Center, a research and product development organization. He previously wrote about five ways mobile technology can benefit your mission.