Chapter 4. Mobile Application Development

It was only June 29th, 2007 when the first iPhone came out, but it feels like we have been living with these devices and their apps for much longer. Smartphones have created a new way of living. We are always connected, have instant access to information, instant directions to any location, and much more. The mobile experience is now expected, and enterprises have to adapt and provide these experiences to their customers, employees, and partners. In this chapter, we will discuss Mobile App Development in the enterprise. The enterprise challenge goes beyond the app that runs on the device. The challenges reside in the areas of data, security, analytics, engagement, and so forth. In this chapter, we will focus on the enterprise challenges in mobile. We will focus both on the challenges for both developing the client side app, as well as focusing the core capabilities enterprises need to provide in the cloud.

In the extreme cases, you can deliver web content through a mobile browser, often called mobile web, or you can build a full native app with the SDK of the device. In between, you have the notion of hybrid based development, where you bundle HTML code within an app. Some hybrid applications are built fully with HTML 5 based technology; others use a mix of Native and HTML 5. Some applications are primarily native with a small amount of web content. Some applications are mostly web and access some native capabilities.

Business Factors: There is a clear difference in how much mobile influences development in different industries. For example, enterprise customers will have very differing requirements than gaming companies. As such, business factors are often a telling gauge for the style of development. Financial industries for example, build out applications that people may constantly use. Requirements include quick access to the latest account information, different visualizations of spending habits, depositing a check with your camera securely, and so forth. As such, a native application with the best experience may be best. Other industries, such as insurance, may not require constant usage, but have key use cases that need to work when accessed, such as filing a claim.

B2C or B2E/B2B: One thing to keep in mind is that mobile plays not only in the B2C space but in the B2E/B2B space as well. The services you provide for your customer as compared to those provided for your employees and partners may have very different characteristics. In addition, while you may be able to control your employee’s devices (company owned devices, Device Management Services, etc.), you cannot control your customer’s devices. Mobile provides huge opportunities for field-based employees to have instant access to data. Industries like travel, utilities, and insurance provide great opportunities for new mobile patterns for employees.

Target Audience: Understanding your target audience is by far one of the most important factors in selecting a development style. How technical is your audience? Are you trying to reach an audience that is familiar with existing mobile applications, or one for which this may be their first mobile application?

Cost Revenue: Many companies have already realized the financial gain of mobile; however, there are applications you may write that only add to operational cost. For example, providing services to your existing client base may be a matter of survival, but produce no additional direct revenue. Certain internal applications oriented towards your employees may offer little financial benefit as well, but only have intangible benefits, for instance, in improving employee morale.

Frequency of Usage: Some people think about high-use social applications like Facebook when considering applications on a mobile device. People use these applications often and spend a great deal of time on them. However, not all mobile applications, especially in business, adhere to this principle. For example, how often will a person look at his or her insurance policy? How often does an insurance company want you to process a claim? Sometimes, an application may go months without being either used or updated, but you have to make sure that it works when the use is required.

Data Visualization: Mobile devices offer touch capabilities and unique ways to interact with apps. Many business monitoring and reporting capabilities can take advantage of such views. Viewing financial trends, customer trends, etc. are examples of such use cases. However, other data, such as a list of policies, your last five bank transactions, and other data of this sort may require much less visualization.

Multi-Channel Business Context: Sometimes a mobile device is used to do only part of a job. You may start a transaction on a mobile device, and the finish it on a laptop. For example, I might start on insurance claim at the point of an accident by taking a picture, but later provide much more detailed information when I get home. You have to consider how easy is it to move that business context across channels from an integration standpoint when designing your applications.

Good Enough Not to Notice: Usability is a very important factor, proven by Apple through its mobile innovation. The performance of the experience often time plays a role in user perception. However, with the advances in Web Standards and hybrid, sometimes the difference between a native experience and web experience is not noticeable. Technologies like Ionic offer smooth looking transitions between mobile parts of the application, and end users might not be able to tell the difference. However, sometimes you may have advanced graphics and animations where the difference is noticeable. You need to determine how good is good enough, especially if gaining customer reach is important to you.

Existing Skills: Many enterprise customers have invested in developer skills in the area of web development. If customers have a large investment, it may not be advantageous to hire expensive and in-demand native developers, especially if you need to target multiple platforms.

Integrating Across Organizational Boundaries: Many enterprises build applications that interact with other business applications from different groups or different partners. Within Web sites, sometimes this integration is via service calls, sometimes using techniques like embedding web content in an iFrame from somewhere else. Apps introduce some challenges into this style of integration. For example, integrating across two native apps written by partners may be difficult if they did not anticipate integration up front.

Often, different departments within a business host different web applications and only provide links to each other. Thus, from an end user standpoint it might still look like a single site, even though the technological underpinnings are not integrated. However, an enterprise may not be able to provide six or seven unique apps to their customers. For instance, who would want to look for different insurance applications (separately covering auto, health, and life insurance) from the same company?

¹ Brown, Kyle, et al. 2014. Modern Web Development with IBM WebSphere: Developing, Deploying, and Managing Mobile and Multi-Platform Apps. IBP Press.

Having architecture like this is critical for hybrid. In general though although hybrid apps will save you time coding, you may find the cost of tuning your application across a diverse set of Android devices to negate the value in some cases.

Because the iOS and Android are dominating the market, many enterprises are choosing to build native apps. You can have a successful strategy doing native development. Once you learn the frameworks, tools, and languages, you will find that the closed box MVC model can greatly reduce amount of tuning on the client and such. In addition, as vendors release new native patterns, it takes longer for web frameworks to adapt.

1. Developing/deploying a mobile app

2. Running/hosting a mobile solution

3. Mobile app end user

At a high-level, cloud capabilities for mobile support the lifecycle of enterprise mobile applications that are deployed to employee or customer devices and provide managed access to backend business applications and enterprise data sources which support the mobile apps on the devices. These solutions allow companies to leverage emerging mobile technologies to reinvent customer relationships by engaging them anywhere and anytime the context is relevant.

Cloud computing and cloud services are a good match for supporting mobile devices. Mobile apps tend to have time variable usage patterns that are well handled by the scalability and elasticity of cloud computing—increasing and decreasing the backend resources to match the level of requests from the mobile devices. It is also characteristic of mobile apps to make use of serverside data that is unique to the apps. Some of this data is not enterprise data, such as social data (e.g., Twitter or Facebook data), and there are good cloud services available to incorporate such data.

Some data associated with mobile apps is accessed with a frequency and in a volume and format that can be difficult to accommodate with traditional enterprise transaction-based systems. It is common to support mobile apps with one or more databases containing the data for the app. Such databases typically hold copies of the necessary enterprise data in a form suited to serving the mobile apps, such as JSON data held in a NoSQL database. The elastic provision and support of these app specific databases is one of the notable capabilities of cloud computing. Using app specific databases also reduces the need to access enterprise systems and systems of record, along with a reduction in resource requirements.

Another factor influencing mobile app design is the often global nature of app use. Users accessing the apps from many locations put pressure on the infrastructure, with a need to provide “local” endpoints around the globe to avoid latency issues. Cloud computing is well suited to running the same backend services in multiple datacenters around the world.

When developing and deploying a mobile app, it is important to remember that mobile apps typically have a short lifecycle—they change fast to adapt to new devices and business markets. Therefore, planning for agility is another requirement of mobile apps—allowing for frequent, regular updates to the apps and the functionality that supports them. There is a need to support “2 speed IT”—where enterprises manage the systems of record, on premise, enterprise systems at traditional change cycles while allowing applications at the edge or in the cloud to iterate faster—this includes being able to deploy quickly on devices and the mobile backend. Cloud services are good at supporting DevOps, agile development and operations; with the ability to introduce new versions of apps and backend services rapidly through use of automated test and deployment capabilities paired with automated deployments plus monitoring to validate operational quality.

As with earlier major transformative shifts in enterprise technology, a proliferation of implementation options and deployment topologies can make the adoption of mobile capabilities a challenge.

For example, different mobile device platforms, including Apple iOS, Google Android, Microsoft Windows® Phone, and BlackBerry, each come with their own application SDKs. They all support building apps using portable technology; however, native implementations involving a custom app implementation for each device type usually offer the best user experience. This means that organizations need skills and tools to support developing and deploying across all these devices and implementation types.

This proliferation also contributes to challenges with bring-your-own-device (BYOD) in the enterprise. Enterprises need ways to apply corporate policies to devices, which are allowed access to the enterprise network. This includes a means to distribute and update a portfolio of secure custom enterprise mobile applications for employees to use.

Let us focus on the service provider and service consumer in the mobile app lifecycle using cloud computing. The mobile cloud architecture guidance provided by this chapter can help enterprises understand common architectures that have been proven in numerous successful enterprise deployments.

Figure 4.3 shows the overall high-level logical architectural components for hosting a mobile app. It shows how a mobile device, managed by mobile device management, connects to the core cloud components like mobile gateway, mobile backend, mobile business applications, and data services, while transformation and connectivity get relevant data from enterprise systems to show on the device. It shows how a born on the cloud application would use the data services and return the data to the app.

Figure 4.4 illustrates the high-level architecture of a mobile cloud solution. The architecture has four tiers, each containing a subset of the components:

• Mobile device

• Public Network, which connects the device to the mobile cloud services

• Provider cloud service environment, where the various cloud services exist

• Enterprise systems, containing existing enterprise applications, services, and data

• Vendor Frameworks—Provide access to device capabilities and features from the device manufacturer and/or mobile network provider, like Apple Pay, Google Wallet, and Core Data.

• Enterprise Software Development Kits (SDKs)—Provide the ability to support communication with mobile backend services through SDK’s that are consumable for mobile developers and encapsulates client flows needed to access the backends.

• Management Agent—Management agents apply the policies of the enterprise, typically for devices used by employees of the enterprise where the apps deal with sensitive enterprise data. The agent is a part of the SDK that stores, enforces, and manages policies, including security policies, on the device.

• Offline Capabilities—Since mobile networks are not always available to the device, it may be the case that a mobile app may use offline capabilities such as an encrypted database to access and store secure data. This component provides the ability to store data securely on devices and sync to the backend when the network is available.

• DNS Server: Resolves the URL for a particular web resource to the TCP-IP address of the system or service which can deliver that resource.

• Firewall: Controls communication access to or from a system—aiming to permit only traffic meeting a set of policies to proceed and blocking any traffic which does not meet the policies. Firewalls can be implemented as separate dedicated hardware, or as a component in other networking hardware such as a load-balancer or router or as integral software to an operating system.

• Load Balancers: Provide distribution of network or application traffic across many resources (such as computers, processors, storage, or network links) to maximize throughput, minimize response time, increase capacity, and increase reliability of applications. Load balancers can balance loads locally and globally. Load balancers should be highly available and without a single point of failure. Load balancers could support any of the components, but support is especially important for the mobile gateway and mobile backend.

• Content Delivery Networks (CDN): Provide geographically distributed systems of servers deployed to minimize the response time for serving resources to geographically distributed users, ensuring that content is highly available and provided to users with minimum latency. Which servers are engaged will depend on server proximity to the user, and where the content is stored or cached.

• Mobile Provider Network: Provider of wireless communications that owns or controls all of the elements necessary to sell and deliver services to an end user, including radio spectrum allocation, wireless network infrastructure, back haul infrastructure, billing, customer care, provisioning computer systems and marketing, and repair organizations.

• Authentication/Authorization: Provides the ability to identify, authenticate, and authorize the user, using a variety of methods and token types. Mobile authentication services provide the ability to handle different token types, like OAuth or OpenID as well as biometric technologies like Voice ID or voice authentication.

• Policy Enforcement: Provides the ability to enforce corporate policies during invocations from mobile devices.

• API/Invocation Analytics: Provides the ability to capture analytical data of API invocation by a variety of clients (e.g., how often an API is invoked and who is invoking the API).

• API/Reverse Proxy: Provides the entry point of an API, usually in a DMZ. API proxy routes an API call to an implementation instance such as an application in the mobile backend.

Mobile Backend—The mobile backend provides runtime services to mobile applications which implement serverside logic, maintain data, and use mobile services. Mobile backend provides an environment to run application logic and the implementation of APIs. Application logic hosted here can communicate with the enterprise network as well as other services and applications outside the service provider. It provides:

• Application Logic/API Implementation: Provides the implementation of the business logic being requested by the mobile app via the APIs. The implementation may in turn call on other services to provide required function. A variety of runtimes such as Java or Node JS can be used to code the business logic.

• Mobile App Operational Analytics: Provides the ability to do analytics on runtime flows. The mobile backend collects and logs information from mobile apps, such as what client pages were visited, what backend functions were called, what device type called a particular backend, offline storage statistics, and so forth.

• Push Notifications: Provide the ability to support subscription and sending of push notifications. Mobile apps allow users to register and receive push notifications while a mobile backend provides APIs for backend logic to push notifications to devices using the mobile provider network.

• Location Services: Provide the ability to collect and use location data from mobile apps running on a device.

• Mobile Data Sync: Provides the ability to synchronize data on a device and stored in the backend.

• Mobile App Security: Provides the ability to do authorization of users to perform app specific tasks; sometimes enterprise security applications are used to provide profile information for this.

Mobile Device Management (MDM)—MDM focuses on managing devices, mostly in Business to Employee (B2E) scenarios. MDM provides services to keep track of enterprise owned devices and also manage devices that connect to corporate networks using management agents on the devices. MDM provides:

• Enterprise App Distribution: Provides the ability to host enterprise catalogs and to distribute enterprise applications to mobile devices. If enterprise apps are not deployed to public app stores then enterprise catalogs are needed.

• Mobile Device Security: Provides the ability to support enterprise security policies that need to be applied to devices. This includes policies on accessing enterprise networks, password standards, encrypted documents, device wiping, and so forth.

• Device Management: Provides the ability for an enterprise to view its organization-wide device usage as well as administrators to be able to add, remove, wipe, and perform actions across all of those devices.

• Device Analytics: Provides the ability to capture metrics on the actions performed by employees on devices that can help improve management of devices.

Mobile Business Applications—Mobile business applications represent the enterprise or industry specific capabilities that need to be available to devices that consume mobile services or drive communications with users of devices. These can provide the gateway to enterprise applications and data, and include their own analytics components to track usage. They can include:

• Proximity Services and Analytics: Provide analysis and insight into patterns of activity in a physical location to optimize operations or facilitate next best actions. It connects insights from digital activity and physical presence to enable unique engagement with populations and the individual. It also enables contextually relevant mobile communications delivered at the right place at the right time.

• Campaign Management: Delivers contextually relevant experiences to connect with customers using mobile apps. This includes using different styles of Push, (Apple/Android) Passbook, Wallet, and SMS solutions. It connects with the mobile backend services and helps to send personalized messages to mobile device users and dynamic sets of individuals based on expressed preferences. This component applies deep analytics to help marketers and app developers understand mobile user behavior, preferences, and usage, thus enabling them to quickly deploy mobile campaigns with relevant offers. It includes the ability to personalize mobile offers in real time, and execute cross-channel marketing campaigns.

• Business Analytics and Reporting: Provide complete mobile visibility by capturing user information for mobile websites including both network and client interactions and touch-screen gestures such as pinching, zooming, scrolling, and device rotation. This component can be used to build and manage an early warning system to detect mobile user problems and provide proactive awareness into mobile application failures, usability issues or other obstacles that lead to failed transactions, abandonment, poor app store ratings, and negative feedback. It can also help quantify revenue impact and segmentation by analyzing specific mobile user behaviors or device attributes.

• Workflow/Rules: Orchestrates the flow of information at various points in the mobile architecture. A mobile client is integrated and synchronized with mobile business applications, mobile backend, and enterprise systems that are potentially based on different workflow /rules engine.

API Management—API management capabilities advertise the available services endpoints to which the mobile gateway has access. It provides API discovery, catalogs, connection of offered APIs to service implementations and management capabilities, such as API versioning.

• API Discovery/Documentation: Provides the ability for mobile developers to find and use APIs securely.

• Management: Provides a management view into API usage by mobile apps using information from mobile gateway, backend, etc.

Data Services—Data services enable mobile app data to be stored and accessed. Mobile applications deal with data from many different sources. For example, a user’s information exists in enterprise systems, on social networks, and a variety of other sources. Data is often stored in a form suitable for rapid access by mobile apps and sometimes includes (potentially transformed) extracts of enterprise data. Data services can include:

• Mobile App Data/NoSQL: Provides the ability to store data in a form that is easily and rapidly consumed by mobile apps.

• File Repositories: Provide the ability to store static files, such as PDFs and content. Many mobile applications read files and having a File Store is necessary.

• Caches: Provide the ability to cache data for fast access by mobile apps.

Security Services—Security services enable management of access so that only authorized users can securely access mobile cloud services. This component also provides protection of data across mobile devices and cloud services, and enables visibility to have actionable security intelligence across cloud and enterprise environments.

• Identity and Access Management: Identifies and authorizes the user providing risk and context based access to mobile and cloud services, including user management, authentication, identity federation, single sign-on, and mobile access management capabilities. These capabilities are leveraged by other components in this architecture—for instance, mobile gateway enforces user authentication and mobile access management, while enterprise secure connectivity enables security services to connect to enterprise security systems like LDAP registries.

• Data and Application Protection: Enables protection of enterprise data using a multilevel defense approach across infrastructure, application, and data layers. Application security enables security as part of the development, delivery, and execution of mobile apps, including libraries/tools to secure and scan mobile apps as part of the application development lifecycle. This component helps eliminate security vulnerabilities from mobile apps that access critical data before they are placed into production and deployed. Protecting deployed applications against application threats can be achieved through deploying web application firewalls. Data security capabilities support securing and monitoring access to data in mobile devices, enterprise databases, file shares, document-sharing solutions, and big data environments that may be accessed through the mobile platform, including encrypting data at rest integrated with enterprise key management, secure data in motion through secure connectivity architectures, and data activity monitoring that provides both real time data monitoring as well as vulnerability assessment. Infrastructure security capabilities are enabled by the edge services and the mobile device management components in this architecture.

• Security Intelligence: Enables comprehensive visibility and actionable intelligence that can help detect and defend against threats through analysis of events and logs and correlation and detection of high-risk threats which in turn can be integrated with enterprise incident management processes. These same capabilities could also enable with automated regulatory compliance and audit with collection, correlation, and reporting capabilities.

Enterprise Transformation and Connectivity—The enterprise transformation and connectivity component enables secure connection to enterprise systems and the ability to filter, aggregate, or modify data or its format as it moves between mobile components and enterprise systems. Data transformation may be required when the native format of enterprise data is not appropriate for transfer to mobile devices.

• Enterprise Security Connectivity: Provides the ability to securely integrate with enterprise data security. Enterprise systems typically hold directories of user identities, such as an LDAP registry, and the ability to access it, authenticate and authorize access to enterprise systems.

• Transformation: Provides the ability to transform data between enterprise systems and mobile components.

• Enterprise Data Connectivity: Provides the ability for mobile components to connect securely to enterprise data. Examples include VPN and gateway tunnels.

• Enterprise Data—One or more systems of record, for example, transactional data or data warehouses that represent the existing data in the enterprise.

• Enterprise Applications—Applications that run enterprise business processes and logic within existing enterprise systems.

1. Mobile app installation flow number 1 in blue.

2. Check deposit flow numbers 2–8 in yellow.

3. Push notification flow numbers 9–10 in green.

• The banking customer installs the mobile app onto their device after browsing a public application marketplace such as Google Play or the Apple App Store. In an enterprise usage scenario, the company—using their own enterprise app store and corporate mobile device manager—may instead push the application to the device over the public network. As part of the installation process, the user can opt-in for location aware services and sign up for push notifications on account balance changes or fraud alerts, for example.

• The customer then uses the mobile app to deposit a check by taking a picture with the camera built into the mobile device. The user logs into the app (which will communicate with mobile gateway for authentication) and then sends the “deposit check” request to the bank with the check image. The user interaction is logged for understanding customer behavior and for understanding operational efficiency.

• This service can be located using DNS, load balancers, and other public network boundary components collectively known as edge services. For all transitions from the mobile app on a device to the mobile gateway through the public networks, which can be wireless or mobile networks, the mobile app sends requests using a URL resolved by a DNS to an IP address. The IP address may be the IP address of a CDN server, load-balancer, firewall, or proxy service in front of the mobile gateway. The CDN server determines if the requested content is in the CDN storage network. If the CDN server cannot satisfy the request the request is sent to the firewall. The firewall evaluates the request and allows the request to continue forward to the mobile gateway if it meets the firewall rules.

• The mobile gateway receives the deposit request and checks security rules for access to the “deposit check” service and uses an API service lookup to direct the request to the right service implementation in the mobile backend. The security check validates credentials and authorization of actions and passes a successfully validated user request on to the mobile backend. It then logs the activity for analytical purposes.

• The mobile backend executes the “deposit check” business logic to store the check image and send the check information to backend processes and systems to deposit the check in the customer’s account. The service retrieves information through the transformation and connectivity components that enforce enterprise application security and ensure the account is valid. The mobile backend provides location services and manages subscription services for push notifications. It logs the activity for analytics usage. The mobile backend uses the workflow/rules service to start the deposit check process flow.

• Data services may be used to speed up response time—for example, the account balance could be stored in a NoSQL database and check images may be cached in the file repository. The “deposit check” business logic now stores the account, image of the check, and the deposit amount using the data services APIs. The information is logged for analytics.

• The mobile business application workflow sends the deposit check transaction through the transformation and connectivity components that enforce enterprise application security rules and grant access. The process flow uses different services to check the validity of the check, store the image of the check in the enterprise document repository, and deposit the check using the core banking application. The process execution step is logged for analytics.

• The enterprise account application stores the image of the check in the enterprise database for tracking purposes and applies the deposited amount to the customer’s account in the core banking application. Control returns to the mobile backend. When the mobile backend “deposit check” service application completes its tasks, the resulting content is delivered through the mobile gateway (which logs information for analytics again) and the public network to the mobile app.

• Sometime later, once the amount is added in the enterprise application, a request is sent through the transformation and connectivity components which use the data services API to update the account with amount deposited and the balance. This information is now cached in data services for expedited access and to save resources by reducing accesses to enterprise systems.

• Depositing of the check information in data services invokes the push notification service in the mobile backend to send an alert to the customer that the check was successfully deposited. The mobile backend manages subscription services to determine and send the alert via a push notification on the public network to the device. The push notification service takes care of connecting to and using the right mobile provider network.

The customer receives the notification that their deposit has been accepted and continues to interact with the banking application. The context of app usage is recorded for analysis by the bank to ensure ongoing excellent customer service.

Independently, the analytics being collected can be used for a variety of business purposes, including campaign management, fraud detection, and business presence needs. For example, as the analytics determines that this was a large deposit that can change the customer status to an elite customer, it sends information about elite customer service to the customer through push notification. Alternatively, locations service showing lots of activity from a certain geography may cause the bank to add an ATM locally or to engage them in local investment opportunities.

Using IaaS cloud services means that the cloud service supplies basic resources such as compute nodes and data storage capabilities—it is the customer’s responsibility to install the required software for each of the necessary service components and to configure them to work as a cohesive whole. Some of the components can be bought as off-the-shelf software, while others (such as the mobile backend applications) must be purchased or developed by the customer.

PaaS cloud services typically provide many if not all of the mobile service components as a set of cloud services. The customer selects and configures the services they need—and develops code for custom components such as the mobile backend applications. The deployment of the underlying resources is largely automated by the cloud service provider, with minimal effort from the customer.

For public cloud deployment, the components are instantiated in a shared datacenter of the cloud service provider. For private cloud deployment, the components are instantiated either on-premises within the enterprise or within an isolated environment in the datacenter of a cloud service provider. For hybrid cloud deployment, there is an element of choice of where to locate each component, either in a public cloud environment or on-premises. It is typically the case that public cloud deployment is likely to be lower cost than private cloud deployment, but may have security risks that cannot be accepted by the customer.

In each case, the actual deployment topology used is driven by business factors with the choice typically governed by security and performance considerations. Security and data protection considerations will depend on the nature of the data associated with the mobile apps and the business impact of risks such as unavailability of data or of data breaches. Generally, the greater the sensitivity of the data, the more likely it is that on-premises private cloud deployment is used. However, even if some components are deployed on-premises, it is not necessary that all components are deployed in this way.

For example, an enterprise can choose to deploy the mobile backend components in a globally distributed shared public cloud while keeping the mobile business application services and data within private data centers to meet performance objectives while at the same time ensuring proper security and protection for sensitive data.

The DNS and CDN usually live in the public Internet—these are typically purchased as services from a suitable provider.

For IaaS cloud services:

• The firewall and load balancer are deployed in the cloud service. Many cloud service providers have firewall services available. The load balancer can be run on one or more servers within the cloud service.

• The mobile backend components and the mobile business application services and data components are deployed onto virtual machines, containers, or bare metal nodes provisioned in the IaaS environment. Networks are configured to allow traffic through the mobile gateway, to the mobile business application and API networks, and to the mobile provider networks. Components can be collocated or installed onto separate virtual servers as desired.

• Significant consideration is required concerning the number of instances deployed for each component. For resilience and redundancy, it is advisable to have at least two instances of each component, preferably in geographically separated data centers. To take advantage of the scalability and elasticity of the cloud services, it is also necessary to increase and decrease the number of instances of a component dynamically according to the work load placed on it. This requires monitoring and management components and also requires appropriate load balancing in place for the component.

• The transformation and connectivity component spans between the cloud computing environment and enterprise system and consideration must be given to how it is structured—is it largely within the enterprise network, or does it mostly exist in the cloud computing environment? Performance and security are key factors influencing the design.

• For any components that involve data storage, such as the data services, considerable thought needs to be given to the number and the location of copies of the data. Replication and backup are necessary design points, as is consideration of the number of compute instances allocated to the components reading and writing the data, and also to the consistency model applied to the data.

For PaaS cloud services:

• The firewall and load balancer are typically part of the cloud service.

• The mobile backend components and the mobile business application services and data components are typically provided by the PaaS itself, only requiring allocation and configuration by the customer. Custom code must be developed for the application components, but this is typically deployed into runtime environments provisioned by the PaaS.

• Data storage components are part of the PaaS and it is typical for these to be provided with options for replication and backup—in the best case with customer control over the locations used to store the data.

• The transformation and connectivity component may be supplied by the PaaS, but it typically requires at least the installation of some connectivity code within the enterprise network.

• For a PaaS, scalability and elasticity are usually built in, although often requiring configuration—for example, establishing a set of policies for when to increase and when to decrease the allocation of resources. Similarly, it is common for a PaaS to support load balancing of replicated components, often done transparently when multiple instances are allocated.

Regardless of where components are deployed—public, private or hybrid—lifecycle, operations, and governance requirements need to be considered and addressed. Where components are deployed will strongly affect how management and governance are done. Private deployments may be able to use existing enterprise management and governance tools if they have access to the cloud infrastructure. Lifecycle operations (instantiate, initiate, and terminate) for components instantiated outside the enterprise need to be agreed on and supported by the cloud service provider for public, hybrid, and externally hosted private deployments. In all cases, the key is automation—as much as possible should be completely automated and manual interventions should be reduced to a minimum.

Similarly, operational monitoring and management interfaces for gathering metrics, checking SLAs, status, notifications, and negotiating changes in capacity for these public components will need to be obtained and support for them should be added appropriately to existing management tools. This may include integrating data, information, tools, and processes from multiple sources into common interfaces, reports, automation, etc. for efficient and scalable operations.

Governance and compliance processes will need to accommodate the change in control and risk over externally hosted components. Optimally, lifecycle management solutions should integrate across deployment models and provide a common, integrated context that enables management of release, change, security, SLAs, problem diagnosis, etc. in a complex, dynamic, and potentially unreliable environment.