The Apple iPhone and iPad immediately come to mind when mobile devices are mentioned. These beautifully designed consumer products have captured the market and sent Apple stock soaring. More important, these devices have been described as the death knell of the desktop and laptop computer. There are some dissenting voices, but it is clear that the combination of mobile devices and cloud services is irrevocably changing the way computers are used.

The mobile devices are not just the latest gadget to catch the consumer’s eye. They are a force in transforming the IT environment and they are changing more than consumer buying habits. The devices are small and portable, but these characteristics alone do not explain their effect on enterprise IT.

Cloud services and mobile devices intertwine. Many of the most important mobile applications rely upon cloud implementations. This is especially true of enterprise mobile apps, which interact with enterprise data and processes. Music services such as iTunes rely on a catalog of music stored in a cloud. Social networking applications such as Facebook rely on an enormous cloud implementation. Search engines such as Google also rely on cloud. These and many more cloud applications turn tiny mobile devices into expansive portals.

What Is a Mobile Device?

A mobile device is a computer designed to be portable and small enough to be held in the hand instead of sitting on a desk or a lap. Mobile devices are certainly mobile, but they have other distinguishing characteristics, as noted in the following sidebar.

Mobile devices are designed to be used with a network connection, and they can be crippled if they do not have access to external resources—network connectivity and storage being the most important. Mobile applications compensate for connectivity lapses by storing data locally and syncing up later, but everyone who travels in areas where cellular access is sporadic or nonexistent knows how frustrating a smartphone or tablet can be when it is separated from the network.

Mobile devices that move about freely and yet connect with voice and data networks are the product of evolution that influences the way many people think about mobile computing. When DOS and Windows were designed, network connections were not common; operating systems for personal computers were built without assuming that the computer would be plugged into a network. Until recently, most Windows applications were designed to perform their work without calling on resources other than those on the computer. Conversely, these desktop devices were built with the assumption that external access to the machine would be limited—an environment where desktop security was easier to maintain. This thinking still lurks in the background and can be the source of dangerously poor decisions in mobile and cloud architecture.

As computing progressed, network connections became more common and personal computers became more connected, but until wireless networks became widely available, connection to the network was an exceptional condition, not the norm, especially for laptops. In conference rooms all over the world, laptop users scrambled to plug into network ports that were never plentiful enough to go around. The quest for network ports also applies to desktop personal computers. Although setting up fixed physical desks with network drops is less of a problem than it is for laptops, decisions on locating wired desktops are often determined by proximity to drops.

Consequently, until recently, desktops and laptops had to be designed to function offline nearly as well as they did online. A typical word processor was designed to work offline. It read a document stored on the computer, edited it, and stored it back to the computer. This offline operation required program code that was physically present on the local computer.

To support that mode of operation, the word processing program had to be installed locally and the PC had to have substantial local storage. The code had to be installed and updated from physical media such as floppy disks, CD-ROMs and DVDs, or downloaded when the computer was online. In addition, the local processor and memory had to be adequate to perform all the computing necessary to process the text.

Today, traditional word processors such as Microsoft Word and LibreOffice depend on the network to provide help text, but all normal operation, except installation and update, takes place locally. In 1995, reading a document from a remote server into a word processor, editing it, and storing it back to the remote server was an extravagant and impractical idea. This has changed. Today, with document servers such as SharePoint, the practice is commonplace.

Online office suites, such as Google Docs and Microsoft Office 365, go somewhat further. Rather than a downloading a copy of the document to be edited to the local machine, the document stays on the server in its store. The local client gets a representation of the document and generates operations, such as “Insert a string of characters at this point” in the document, which it transmits to the server. The server performs the operation and returns a representation of the result to the local machine. This system makes it possible for many users to edit the same document at the same time. Most processing occurs on the server. The client displays the server’s representation and generates commands from the user’s input; the server processes the commands and publishes a modified representation. When more than one client is modifying the document, the server coordinates the activity by accepting and executing commands serially.

Online office suites have greatly increased the appeal of mobile computing, especially tablets, by offering an office environment that greatly exceeds the capacity of the mobile device. A user has access to many more documents than the device holds. Consequently, working from mobile tablets and even mobile phones has become practical. Online office suites also enable laptops to be lighter, cheaper, and more easily portable.

Despite innovation in online computing, the concept of the stand-alone personal computer remains strong. Personal computers are designed to store every document, photo, and chart the user is likely to want access to at one time. Processors are designed to handle the computing loads generated for any task a user might reasonably undertake. With the progress that has been made in CPUs, memory, and hard disk storage in the past decade, independent personal computers are more powerful than ever before. To users who have been accustomed to stand-alone computing for decades, the current computing and storage capacity available on the desktop is what they have been looking for. They finally have the power and capacity to do what they want.

But today’s desktop capacity is not enough. Now that computers connect to the network almost anywhere, at least in urban and suburban areas, the stand-alone assumption is seldom valid and users are seldom willing to accept it. They have become accustomed to the instant information and communication offered in the online world. In addition to information and communication, services are now online. An example of a service is the weather web service offered by the National Oceanic and Atmospheric Administration (NOAA). This service provides current weather information from a national database and NOAA weather stations. This service is the source for current temperature and weather conditions found in many web sites, applications, and operating systems.

The transition from the stand-alone desktop to a portal into a world of remote resources is profoundly significant—certainly as significant as the rise of distributed computing and perhaps as significant as the invention of the programmable electronic computer itself.

But the concept of the personal device as a portal has critics. Those who insist upon having a self-contained personal computer have legitimate arguments. A private machine is private, easily secured, and its reliability is under the control of the owner. The stand-alone model affords better privacy, security, and reliability than a system that is implemented largely using remote resources. This disparity presents a challenge to mobile and cloud-based services to become as private, secure, and reliable as their local counterparts.

With the advantages to stand-alone computing, why are users rushing headlong into a massively connected environment? The answer is that the perceived advantages outweigh the perceived disadvantages. As computing has expanded, the demands we place on computing have also expanded.

Keeping all your resources on your own machine may be safer, but it is bothersome. The connected paradigm places resources in a central location that all the players can access. Under this paradigm, resources are “in the cloud”—not any place in particular. If you want to work somewhere besides your own desk, the cloud and your documents are as accessible from a hotel room a thousand miles away as they are from your office. If you want to listen to your music on the beach as well as in your living room, if you have several devices, your music in the cloud is accessible everywhere. If you want to collaborate with others, you can share resources by placing them in the cloud. If you want to take on a computing-intensive task like analyzing big data, a stand-alone computer lacks the capacity, but through the cloud you can tap into capacity that is limited only by your willingness to pay for it. And when you are finished using the capacity, you can release it and quit paying for it. Under the connected cloud paradigm, the capacity of the device on the desk or in the hand is not the limiting factor on what can be accomplished.

Our notions of security, privacy, and reliability are changing as the transition to using remote resources progresses. Traditionally, security, privacy, and reliability were tied to the idea that you can only trust is what is locked behind your own physical door. This has been a valid assumption for a long time, but there are other ways to establish trust. You can establish your physical security and privacy by triple locking your doors and putting bars on all your windows, but that strategy fails when driving an automobile. It seldom matters if the doors are locked during an accident on the highway because drivers are exposed to other drivers whom they cannot lock out of their personal driving environment, but instead of refusing to venture onto the streets, drivers manage the risk by purchasing insurance and supporting good roads, effective traffic laws, and law enforcement.

Computing security, privacy, and reliability in a connected, cloud service-supported environment is like driving on a highway, not a castle reinforced for a siege. The growing pains of entering the service-supported environment appear every day: security breaches, disregard of privacy, and resource failures. These are serious problems that will not go away without effort. Some of the problems have already been partially addressed. Others have not yet been discovered, let alone addressed, but the challenge is not insurmountable. On entering a new paradigm, old issues are transformed, and often their solutions are unexpected in the new environment. Most important, there are powerful incentives for resolving these issues because the benefits, both to the problem solver and the problem sufferer, promise to be enormous.

A mobile device is much more than a small form factor. It is a device designed to be so portable that it can easily be taken anywhere and architected to be a gateway to vast resources that are not physically on the device.

A mobile device places the whole world of computing into the user’s hand. Work, play, explore, experiment. Contact, collaborate, just hang out with anyone anywhere from anywhere. Audio, photo, and video data were all once considered too bulky to transmit easily, but mobile devices exchange audio files, photos, and videos without difficulty. All of this becomes possible when resources are universally accessible through the network. Unfortunately, some of these resources are dangerous.

Mobile devices and the connected, cloud service-supported environment are all related, and, like most things that change in computing, can be related to Moore’s law. Mobile devices are an example of an innovation made possible by packing more computing power into less space, but they would also be impossible without the increasing reach and capacity of the network. It is somewhat paradoxical that shrinking handheld computing hardware has caused even more computing power to become centralized in clouds and available over the network.

Programming Mobile Devices

At this time, there are three kinds of applications being built for mobile devices: mobile apps, web apps, and hybrids. They are comparable to the fat and thin clients of the last decade. A mobile app is an application that is coded to interact with the operating system of the handheld. A web app is an application that is coded to run on a server and interact with the user through a browser. The server is most likely in a cloud. A hybrid combines some characteristics of both a mobile and a web app. The advantages and disadvantages of mobile apps and web apps parallel the differences between on-premises local processing-based clients and browser-based clients.

Web Apps

Mobile device web apps have the same architecture as familiar browser-based applications, sometimes called thin client architectures. In thin client architectures, a browser displays and manages interaction between the end user and the application. The data and logic for the application all reside on the server, not the client (Figure 4-1).

This architecture has proven to be very effective for many kinds of enterprise and consumer applications. Readily available standard browsers, such as Internet Explorer, Chrome, Safari, and Firefox, hide the architecture of the underlying client. A web application designed to run on Firefox can be used by any desktop, laptop, or mobile device that supports Firefox and provides nearly the same user experience on any client platform. Performance is largely dependent on the server, the network, and the efficiency of the browser code, so neither the user hardware nor the user operating system greatly affects the experience. Further, developers can expect to deliver similar experiences on most browsers.¹ Consequently, the developers can write one set of server code that will reach all clients, including handhelds, with the same functionality.

Also, since the application code is on the server, maintaining the application is simplified. Application code, particularly JavaScript, is often cached and executed on the client, but the canonical code for the application is on the server. Unlike older fat client architectures, updates and patches are made to the code on the server, which then triggers refreshes of cached code on the client. In the fat client model, updates must be installed on the client, a more arduous process than web app cache refreshes. It is not necessary to keep track of which machines have the web app installed and request, or force, downloads and installations of upgrades or patches on each installed client.

For application developers and IT departments, these advantages are significant. Instead of developing several different versions of a fat client that had to be ported to each platform require, developers can write server code that will be accessible everywhere. Although they still may have to port to different server platforms, that is more manageable than the nightmare of combinations and permutations of mixed server-and-client platforms that boils up when an application becomes widely distributed. The effort required to write patches and upgrades is also reduced when all the clients act identically.

Web applications reduce the effort required from IT departments. They no longer have to stage major campaigns to manage distribution and installation of fat client code for each user of the application. When a defect is found, a single patch applied to a server solves the problem. There is no need to push down or manually install patches to each client.

Clients based on local code are much different. Patches must be sent to and installed on each client. Clients on different local platforms require different patches. You cannot patch a Linux client with a Windows patch. In the worst case, the IT department has to segment their user base by platform and send out the proper patch to each user. Not only does the IT department have to keep track of who their application users are and how to contact them, they also have to keep track of which platform they are on and hope they have not changed platforms. These activities not only absorb the time of IT professionals, but their users often see patch installation as efficiency sapping and close to harassment. Under this level of duress, IT departments often prefer to defer improved new releases and even run known defective code to avoid upgrading or patching a fat client architecture.

It is no surprise that web applications have become very popular among application providers and IT departments. Web application architecture is the foundation for software as a service (SaaS). In a non-SaaS deployment of a web application, the consumers run their servers on their own equipment in their own datacenters. In a SaaS deployment, a service provider replaces the consumer’s on-premises server with a server running on the provider’s premises. This is possible because the server holds the entire application and the provider can offer the application service to the users as a pure service over the network. This relieves the consumer, who may be an individual or an enterprise, of the chores of keeping the physical server running and administering the application.²

Native Apps

With all the advantages to web apps in enterprise applications, why is there so much interest in native apps? There are several characteristics of mobile devices that make native apps attractive.

Like fat clients, the application logic of native apps is usually implemented directly on the handheld and executed locally, not on a server, interacting directly with the mobile device operating system. Rather than passing HTML screens, they send and receive brief messages to and from web services on the server (Figure 4-2).

Mobile (native) apps have attractions similar to those of fat clients. The user experience with native apps is generally superior because app developers have direct access to the mobile device operating system. Browsers have trouble with accessing the native features of mobile devices that users love: the cellular interface to telephony and messaging, GPSs, accelerometers, cameras, and so on. Native apps easily access local data storage, which makes caching and local databases easier to implement. This is important on devices where connectivity may be sporadic. Mobile device processors have steadily become more powerful. Devices based on these processors can perform well without depending as much on network speed. This is important because mobile device network connectivity has become ubiquitous in urban areas but is often not as fast as that of typical desktops, and laptops. Rural areas sometimes have issues with basic connectivity.

Even native apps that do not interact with mobile device native features have a distinct advantage over web apps. A web app server is aware of some of the characteristics of the device and browser it interacts with and can tailor the interface accordingly, but a native app has more information. This affects appearance and behavior. Web apps frequently force users to pan over the display and fiddle with the magnification to use the app. A well-constructed native app does not require panning and avoids the peephole appearance of many web apps on a mobile device. Even though gesturing on a mobile touch screen is more natural and quicker than manipulating a desktop or laptop screen with mouse and keyboard, native apps require less user effort.

Native apps also can implement business logic on the local device rather than relying on a server in the cloud for all logic. This can be an advantage for apps that perform intensive interactive processing of data. By processing locally, the app avoids the network latency in passing data back and forth with the cloud server and can make better use of local device features.

At present, native apps are usually preferred to web apps. Perhaps the main reason for this is that browsers running on mobile devices cannot yet provide a user experience of the quality and functionality of a client that interacts directly with the device operating system.

The mobile device operating system vendors, Google Android, Apple iOS, and Microsoft Windows Phone/Windows 8, have stepped up to helping with the maintenance and support problems by following Apple’s lead in setting up markets—“app stores” from which applications are purchased and downloaded—making the whole installation process uniform and relatively pain-free. These markets also manage upgrades and patches, automatically upgrading client when necessary, taking some of the sting out of those chores. However, users still experience pauses when the updates are downloading.

One of the drawbacks to fat clients was the necessity of providing different client code for different platforms. In many cases, a single client for Windows was enough because Windows dominated the desktop user market. However, large enterprises and institutions sometimes did not use Windows in some departments. For example, engineering departments often have tools that require UNIX or Linux desktops. Application providers were forced in that situation to provide one client a version for Windows and others for the variant platforms like the flavors of UNIX.

This fat client problem may also be an issue for mobile native apps. There are two contending mobile device operating systems, Android and iOS, that split the market. Although Microsoft has lagged in the mobile device market and Windows 8 and 10 hold only a small slice of the mobile device market today, Microsoft has engineering and product design resources that are hard to discount and they may be making headway in the tablet market. A three-way split among mobile device operating systems is conceivable in the next few years. Developers who want their applications to reach all mobile devices will have to plan for at least two and possibly three versions of each mobile application. Like the fat clients of old, extra rounds of quality assurance testing will be required. Different versions of patches will have to be developed and managed.

Changes to a native app go through the app store. This is both an advantage and disadvantage to the developer. The app store takes care of distribution and installation of the new versions an app, which removes a major drawback to fat clients. However, there is still the need to go through more than one app store to support more than one mobile platform and each store has its own requirements which may be difficult to work with for an app with unique features.

Hybrid Apps

There are also hybrid apps, which are designed to run on more than one mobile device platform with little modification. A hybrid app uses components of the browser engine, but not the browser itself like a web app. A hybrid app is installed on the mobile device like a native app and has access to local resources, but it uses components of the browser engine to run JavaScript code and render HTML and Cascading Style Sheets (CSS) screens. Although the user has to install the hybrid app, by using the browser as the platform, the hybrid has some of the portability of a web app.

Mobile or Web App?

Developers have a difficult decision. Native apps provide pleasing interfaces that can use all the features of the mobile device hardware. There are features that handheld device users expect and they may react negatively to their absence. In addition, in some circumstances, a native app can lessen the effects of network latency and interruptions by performing more processing on the local device instead of a cloud server.

Unfortunately, in the current mobile device market, supporting a single platform is seldom viable. At a minimum, both Apple iOS and open-source Android³ are usually required. Future conditions may introduce more platform variety. Some enterprises may be committed to less common platforms, adding more complications. Multiple platforms multiply the development effort.

Web apps, on the other hand, provide a usable interface that has greater reach and is easier to maintain. Existing browser-based applications will often run on mobile device devices without changes, but they usually need to be modified for usability, sometimes greatly modified. Web apps designed for both traditional desktops and laptops and mobile devices usually detect which device the browser is running on and modify the appearance and controls to match the display. However, these seldom match the elegance and functionality of a native app that takes full advantage of the mobile device environment. Native app development environments and plentiful prebuilt widgets make native app development easier, but web apps use techniques that have been used longer and experienced web app builders are plentiful. Development staffs may already have the training and resources to build web apps or modify existing browser-based applications to run on mobile devices.

Hybrid apps can be seen as having the advantages of both web apps and native apps, but they also share some of the disadvantages of each. Hybrid apps have access to local resources, and the core code is the same for all platforms. However, there still must be a distinct version for each platform the app is installed on. Patches may be similar, but developers have to create separate patches and updates for each platform. Integrated development environments (IDEs) help, but they are not the entire answer.⁴ In addition, since hybrid apps use the same browser components as web apps, hybrids are subject to the vagaries of the browser implementation and still have some of the limitations of a browser display.

There is no easy answer, although, like the thin vs. fat client wars of a decade ago, time will sort things out. For the time being, developers have to balance the benefits of the reach of web apps, the compromise provided by hybrid apps, and the rich user experience provided by native apps.

Enterprise applications are probably more suited to web app implementation than consumer applications. To minimize user training, enterprises often try to duplicate the experience of desktop web apps on the handheld. They may be able to make a few modifications to their existing thin client application to become both a desktop application and a mobile device web app that meets all their requirements. Also, enterprise applications tend not to use features like cameras that are dependent on handheld resources. Therefore, enterprise developers may gain more from the reach of web apps to more platforms with minimal increase in support and maintenance.

Consumer application builders are usually eager to use mobile device resources and they probably do not have to duplicate the functionality of an existing thin client application. As they see it, they are probably competing against other native apps and they have to top the experience provided by their competitors. If providing an interface to the desktop and laptop world is not important to them, consumer application builders are probably better off with a native app and contending with the multiple code bases for the platforms they want to address. If only one platform serves their needs, all the better.

The field may be shifting. HTML5 includes support for many of the native mobile-device features and enhances web app developers’ control over appearance. HTML5 was released in October 2014 by the World Wide Web Consortium (W3C). The major browsers all have added support for HTML5 elements and application programming interfaces (APIs) as they have appeared. The Windows 10 Edge browser, which replaces Internet Explorer, includes HTML5 support.⁵ However, HTML5 coverage is not complete or consistent. Nevertheless, as HTML5 evolves and browsers extend support, building web apps that satisfy mobile device users will become easier.

If HTML5 is successful, mobile and web apps may follow the pattern of fat and thin clients. As the functionality of web apps improves, the maintenance and support issues of native apps may become an overwhelming disadvantage just as they did for fat clients.

Mobile Devices and the Cloud

The cloud and mobile devices are a good match. Their appearance at roughly the same time shows the effect of two sides of the increasing density of logic on computer chips. Mobile devices are made possible by highly compact yet powerful processors and dense memory chips. Clouds are made possible by using the same power and density to build datacenters of tremendous capacity. The same low-level advances have made possible faster, higher-capacity, and further-reaching networks that support clouds and mobility.

The combination of mobile devices and the cloud makes it possible for computing power to penetrate much more deeply into everyday life. This penetration ranges from family groups that communicate over social media like Facebook on their smartphones, exchanging photographs of new babies and cute animals in near real time. Authors can collect whole libraries of research in cloud repositories and check a fact on their smartphone during a casual conversation; they can conduct research from a public computer in a library with the same resources they have at the desktop in their office. A scientist in a research institute can check on data for a critical experiment in real time from a tablet. If we are careful about the way we store data, losing a device through a crash or a mishap is no longer a crisis—we just access our pictures, music, and documents from another device.

All these advantages are wonderful—but not without their headaches for the enterprise cloud architect. The connections between mobile devices and the cloud open a whole new realm of performance, integration, security, privacy, and regulatory issues that all have to be resolved.

Bring Your Own Device

Bring your own device (BYOD) is a practice that exhibits the benefits and challenges of the wide popularity of the combination of clouds and mobile devices. Many employees now prefer to work from handhelds or laptops they own and carry with them rather than enterprise-supplied devices. This gives them the freedom to work from anywhere in an environment of their choice, using devices they have chosen for themselves (Figure 4-4).

Employers welcome this because they may believe workers who are available round the clock are more productive than workers who are only available during regular working hours on the office premises. Many also believe that allowing employees to work in an environment of their choice enhances productivity and job satisfaction. Employee-owned equipment is equipment the enterprise does not have to purchase, carry on their books, or maintain. The total cost of ownership (TCO) of an employee’s device like an iPad is the employee’s problem, not the employer’s.

Pre-BYOD-and-Cloud IT Management

Before BYOD and clouds, enterprise IT security built a physical and network wall around the enterprise to keep out intruders and control data moving both in and out of the enterprise. The wall existed both as locked doors and restricted access and private networks protected with firewalls and proxies.

Locked doors and tight control of network access blocked intrusions from outside the enterprise. Within a secure perimeter, the IT department could focus on preventing unauthorized employees from accessing and changing information and stopping unauthorized interference with critical processes. When the enterprise owned all equipment within the perimeter and employees were only allowed to work within the perimeter, the enterprise exercised total control of access to its network and everything connected to it.

Tight perimeters are still maintained in high-security settings. However, the typical perimeter is becoming more penetrable and security has been forced to change. The portable laptop that can be connected to public and home networks has been common for some time. Access to outside networks, particularly the Internet, has become embedded in many business practices. All but the most security-conscious enterprises grant some form of Internet access. Although protected by firewalls and proxies, this access can become a portal for malware. Social engineering exploits can trick employees into granting access and privileges to unauthorized outsiders. Operating systems, applications, and services built under the outmoded assumption of a friendly environment have inadvertent or naïve security flaws, which are readily exploited by malefactors. With this in mind, development practices have been tightened up with security awareness training and security checklists, and security reviews and patching processes have become more reliable and prompt. However, as individuals, business, and government use interconnected computers more, the stakes and opportunities for abuse and crime have also grown. Laws and regulations like Sarbanes-Oxley, Gramm-Leach-Bliley, and the Health Insurance Portability and Accountability Act (HIPAA) have raised the standards for computing security.

These are challenges that have pushed enterprise computer security far beyond the state of a few years ago. BYOD heightens these challenges and adds to them.

BYOD and Cloud Security

Both clouds and BYOD weaken the enterprise perimeter. Aside from the issues of third party governance involved with cloud, cloud implementations make data and processes accessible outside the perimeter. When combined with mobile devices, enterprise data is exposed on a moving target that may be using insecure connections like the public wireless in a coffee shop or on the beach. Even when an employee works from home, the enterprise may have no assurance that the employee’s network is secure.

The combination of cloud, mobile devices, and BYOD is potent; both utility and vulnerability are enhanced by the combination. A cloud makes processes and data much more available than when they are locked up within the enterprise perimeter. Mobile devices add another dimension to availability by freeing users from desktop machines. BYOD completes the troika by giving employees control of their detached devices.

When the employee owns the equipment, the perimeter becomes more porous and in some areas effectively disappears. Many issues arise. IT department control of an employee-owned device is often unclear. An employee may object when the IT department requests to scan an employee’s smartphone for apps that are dangerous to the enterprise. An employee may protest when the IT department requests removal an unsafe app used for sharing baby pictures when the app could also be used to share critical enterprise data.

If the IT department detects an imminent threat, such as a missing critical patch, the department may need to remove the threat immediately without permission from the employee. If, in the course of removing a threat, the IT department damages or exposes personal data, the employee may look for legal recourse.

Many departments have policies and tools to erase and obliterate all the contents of a company laptop or mobile device that IT identifies as lost or stolen. A personal laptop is somewhat different. Instead of stolen, the laptop might have been innocently borrowed. The employees may react harshly when their personal data is deleted.

In addition, BYOD brings consumer services, such as cloud data-storage services into the enterprise. An employee might install a cloud file synchronization service on his personal laptop. These services often do not meet rigorous security standards that businesses rely on for safe storage of data. The consumer services are meant to be convenient, but convenience is often antithetical to security. Therefore, some consumer services are far from secure by business standards. The consumer cloud service has all the vulnerabilities of any cloud implementation, but the enterprise does not have a service agreement with the consumer service provider nor is the consumer service likely to have audit certification.

Although BYOD is a reality in many enterprises, in some cases enterprise management and governance has lagged behind the reality. Explicit, written BYOD policies are relatively rare, which is unfortunate because without clear guidelines that employees explicitly acknowledge and agree to, BYOD security is problematic. Employees have to give up some rights to their devices if enterprise security and governance are to be upheld. Explicit agreements between employer and employee on BYOD are desirable to lay down the limits and expectations on both sides.

There are technological solutions, such as encryption, that can help BYOD security. For example, a public key-encrypted document can be set up to be inaccessible without a private key on a limited set of devices. In theory, such a document would remain secure no matter where it is stored. This arrangement depends on the security of the public key encryption, which has been something of a cat and mouse game between the encryption developers and the encryption breakers. Mobile device operating systems can be designed to separate company activities from private activities, perhaps similar to a multiuser operating system. Other possibilities include running virtual machines on the mobile device to separate company from private activities, also similar to some multiuser implementations. There will no doubt be considerable improvements as BYOD becomes more prevalent and the enterprise perimeter continues to fade away.

Mobile Devices and the Enterprise Architect

Enterprise architects designing cloud applications should never forget that mobile devices from outside the enterprise may access the cloud system. Even applications written for an enterprise that bans BYOD should probably anticipate that BYOD will be allowed at some time.

An app on a mobile device served by a cloud implementation is not much different from a fat or thin client interacting with a server in an on-premises system. Web services work in the same way with mobile devices on the Internet as they work with on-premises clients connected to the enterprise network. Within the enterprise perimeter, where every user is part of the organization, applications can reduce security a bit if it buys greater convenience. This is not the case for an application interacting with a mobile device over the Internet.

Within the enterprise perimeter, a simple username-password challenge, corresponding to HTTP basic authentication, is often adequate to authenticate a user already known to the organization. In the Internet world, basic authentication is usually inadequate. HTTP basic authentication transmits passwords in clear text, open and available to the person sitting next to you at the coffee shop with the packet sniffing software. The same packet sniffer can also read all the data sent to and received from the server because the packets are unencrypted. There are other problems. Web sites can be hi-jacked and spoofed, so clients need proof that the site they have connected with is the site they intended to connect with before they start sending out valuable data.

These issues are largely resolved with Secure Sockets Layer (SSL) or more accurately, Transport Layer Security (TLS.)⁶ When HTTP uses TLS, the protocol is called Secure HTTP (HTTPS). HTTPS encrypts data both going to and coming from the server and requires third-party certified authentication of the identity of the server. The encryption scheme is negotiated between the client and the server. The security of the connection can be reduced by negotiating a less secure scheme. HTTPS is well established and supported, and it is used by many sites on the web. An enterprise mobile app that handles critical information should always use HTTPS and require the latest encryption scheme.

Nevertheless, HTTPS is often not enough. A protocol that relies solely on a password is not as secure as it could be. Passwords are easily spied upon; users tend to use passwords that are predictable, and social engineering exploits can sometimes obtain passwords. Users frequently forget their passwords, necessitating password resets, which are themselves vulnerable. Alternatives that use personal artifacts like fingerprint and retinal scans can be compromised by clever reproductions of the artifact. When this happens, the artifact cannot be replaced like changing a password. A solution that has seen some success is two-phase authentication where the user enters a conventional password, and then receives a short-lived password that is sent to a pre-arranged place, like a cellphone or email address. A malefactor must know both the conventional password and obtain access to the temporary password.

Moving data and processes from inside a corporate perimeter to a cloud that can be accessed externally and offering that access from mobile devices offers new freedom to enterprise systems, but security has become more challenging for enterprise architects who must meet equally pressing demands for security and convenient access.

Conclusion

Computing has been tied to the display-keyboard-mouse form factor for three decades. It is now breaking free of this paradigm with small, light, powerful, and, above all, portable devices that work with data and processes that run on a public or private cloud. One result is further decay of the enterprise security perimeter, which is springing leaks as more and more highly portable devices are used from outside the perimeter. The cloud makes these problems worse because the core of enterprise computing and data storage is also slipping outside the perimeter. Enterprise architects must meet these challenges.

¹This statement has to be qualified. Although the browsers all support the standards, their support varies. Interpretations of the standard can differ. No browser supports every feature defined in every applicable standard. To keep the user experience acceptable on all browsers, developers have to restrict themselves to the features shared by their target browsers and use conditional code that executes differently to suit each browser. This annoyance is unfortunate but a fact. Developers have become adept at working around it.

²SaaS has its own challenges. Applications were traditionally designed for a single installation supporting a single enterprise. SaaS can be architected that way, but that architecture is hard to scale and maintain. From the consumer’s viewpoint, on-premises architectures are under the governance of the consumer. They can be secured and customized easily. The consumer decides when and how to patch, not the provider. The challenges can and are being addressed.

³Android code is released under the Apache license.

⁴IBM’s Worklight is an example of a hybrid IDE that plugs into Eclipse. See an overview here: www.sitepoint.com/build-a-mobile-hybrid-app-using-ibm-worklight-part-1/.

⁵For a comparison of browser HTML5 support, see https://html5test.com/results/tablet.html. Accessed August 2015.

⁶TLS replaced SSL fifteen years ago. SSL is no longer considered secure. There have been several revisions of TLS, each closing security holes in the previous version. SSL is still the more common term, but it nearly always refers to TLS.