Developing an Enterprise Mobility Framework

Is your enterprise ready for mobility and BYOD? It is a growing imperative, but not many are. Enterprise Mobility – the use of mobile computing within the enterprise – has gained significant momentum in recent times. This report establishes the requirements for an Enterprise Mobility Framework and outlines some of the key elements.

By Lawrence Wilkes


Enterprise Mobility – the use of mobile computing within the enterprise – has gained significant momentum in recent times due to the power and increased penetration of smart devices together with ubiquitous connectivity, and the pressure from the workforce to support BYOD (Bring Your Own Device).

Analogous to the early days of PC adoption, it is the end users who are largely creating the ‘pull’ for enterprise mobility, rather than the IT department driving this out from the center. IT departments are subsequently often reacting to individual demands in an ad-hoc manner at the project level, leading to inconsistencies, duplication and gaps in capabilities across the organization. Though this is par for the course with any such new initiatives.  

As a consequence, organizations are increasingly assessing their enterprise mobility strategy.

It is tempting for organizations to try to satisfy requirements by simply acquiring technology and products from their favored IT vendor, who will inevitably claim their Mobile Device Management (MDM) and Mobile Enterprise Application Platform (MEAP) products will cure all ills.

In order to put some consistency behind their EM efforts and to effectively govern them, a good starting point for any organization is to establish their Enterprise Mobility Framework (EMF).

However, perhaps reflecting the maturity of the market organizations won’t find an EMF available ‘off the shelf’ from an industry body or even some dominant vendor, and so must establish their own.

Hence this report sets out to establish the basis of an EMF and outlines some of the key elements. Accompanying the report are an Enterprise Mobility Concept Model and a Capability Model.


There are a number of converging factors driving the momentum behind Enterprise Mobility (EM),

  • Smart Phone penetration.  There has been an explosion in the use of smart phones. Smart phones have recently reached the ‘tipping point’ with over 50% market share in the USA and UK, and still growing significantly.
  • Tablet computers. Now emerging not just as a consumer product but as a potential replacement for ‘traditional’ computers in many user roles in organizations.
  • Mobile Internet. Providing ubiquitous connectivity
  • Apps. The desire for mobile applications, or ‘apps’, that are perceived to improve upon the basic web browser experience and provide a richer and more focused or ‘controlled’ environment for both end-user and customer interaction.
  • BYOD. Consequent demand from employees (who are also consumers) for their companies to permit a ‘Bring Your Own Device’ (BYOD) approach.
  • Smart Systems. The use of devices and sensors to provide automated data collection and autonomous operation and response, will in part be based on mobile technologies. EM should cover more than just the human usage of devices.
  • Mobile Payments. In the enterprise market, especially retail, mobile payment technology such as Near Field Communications (NFC) will be a growing driver.
  • Legacy Devices. Many organizations have large investments in ‘1st generation’ mobile devices that are often costly, proprietary, and out of date and incompatible with new technologies (even barely supported by their manufacturers), that are ripe for replacement by cheaper yet more powerful generic smart devices plus apps. What once required specialist hardware can be replaced by generic functionality built into most smart devices.


Responding to these factors will present challenges to most organizations.

Consumer Driven

The mobile market is driven by consumers. The consumer (led by consumer-oriented vendors) is setting the trends and establishing the de jure standards, not the enterprise.

Inconveniently for organizations, their employees are consumers too – hence the demand for BYOD. Specialist roles aside, IT organizations may find it counterproductive trying to dictate mobile technology to their end-users. This may seem counterintuitive to organizations, but is the lesson they surely should have learnt from the introduction of PCs.

Even if the organization gives their employees a device, the employee will still prefer to use their own. Who wants two smart phones in their pocket?

That said, there will clearly still be distinctions in terms of device provisioning for different sectors of the workforce. Whilst the office workers, sales force and execs may be allowed BYOD, the needs of ‘Shop floor’ and manual workers may still require they are provided a device that is provisioned specifically for their role and which may require specialist hardware or capabilities, as well as being ruggedized (even though those specialist items may simply be wrapped around a consumer device).

Multiple Proprietary Platforms

Few organizations are in a position where they can standardize on a single platform, and is clearly impossible in a BYOD scenario. This will impact both the delivery of applications, and manageability, where multi-platform solutions must be provided.

The application platform for mobile devices is currently dominated by iOS and Android. Organizations may find trying to deliver cross-platform applications sub-optimal, especially when trying to simultaneously support PCs and laptops, which they must continue to do.

Organizations most certainly cannot pick sides. It is a consumer driven market remember. And the demand is increasingly for ‘apps’, not cross-browser websites.

However, the dividing line between laptop PC and mobile device will be increasingly blurred. For example by Windows 8, which may provide a common application platform for both, and by mobile devices that are every bit as powerful and capable as laptop PCs. But Windows 8 won’t replace anything; it will just add more diversity to the mix.

Similarly, manageability must be provided across multiple platforms. Whether it is labeled Mobile Device Management (MDM), Content Management, Asset Management, Configuration Management or Fault Management, it all must be provided on a multi-platform basis.

BYOD Support

Consumer-led technology and BYOD strategies are all well and good, but how does the organization ensure the necessary QoS that end-users will still demand, and particularly minimize the security risks that consumer technology and BYOD may bring?

Security may seem to be the most obvious issue with BYOD, but given the organization’s own devices are far from immune from security violations, the best strategy is to ensure that aspects of security are addressed in a way that is independent of who owns the device.

Manageability of BOYD will be just as challenging. Solutions to MDM, Content Management, Asset Management, Configuration Management or Fault Management must all address BOYD as comprehensively as the organization’s own devices.

However, the key place to start with supporting BYOD is the development of appropriate policies.

What defines Enterprise Mobility?

Organizations may struggle to define the boundaries of their EM. Each organization needs to ask the question of where for them does ‘traditional’ computing end, and ‘mobility’ start? Is it defined by the extent of mobility of their workforce, the way they connect to the network, or is it the platform used? Is a mobile device used in a fixed location still considered mobile? Is an unattended mobile device (fixed or not) that requires no human operation part of EM?

Service Interfaces Inadequate?

Data synchronization and access to enterprise resources will need to be provided via various integration mechanisms. However, existing enterprise resources, or the existing means of accessing them, may not suit all mobile use cases.

Whilst SOA is a key enabler of EM, the availability of existing service interfaces may not fully satisfy requirements. For example, a mobile application may need to be able to work offline using a synchronization approach, but the existing service interfaces that provide access to the enterprise resources it requires may not have been designed with this style of interaction in mind. Hence some wrapper or intermediary must be provided. EM will expose inadequacies in service design.

Not the traditional Enterprise IT Vendor Market

The market isn’t dominated (yet) by the likes of IBM, Oracle, SAP, or Microsoft. Like everyone else, they and their traditional IT department customer, are responding to user demand rather than leading.

The challenge is that mobile-platform provides such as Apple and Google on the predominantly consumer-led device side of the equation have little interest in solving EM challenges, whilst enterprise vendors have little to no control over the device side. Hence enterprise vendor support for the latest mobile features may lag.

However, unlike mobile-platform vendors, independent and Enterprise IT Vendors are more likely to provide cross-platform and platform-independent solutions.

Expect enterprise IT vendors to attempt to gain a greater share of the market, primarily through acquisition.

Establishing an Enterprise Mobility Framework

As stated in the introduction, to put some consistency behind their EM efforts, a good starting point for any organization is to establish their Enterprise Mobility Framework (EMF).

Regardless of the domain, we find that establishing a Reference Framework (RF) works well as it establishes the basis and ground rules for subsequent work. In our experience, many organizations often lack a consistent framework – or conversely they have too many – and effort is wasted trying to apply consistency after the fact.

In any given domain, a Reference Framework (RF) provides a common backplane for consistency, collaboration, sharing, and reuse. Without a consistent framework, the domain in question will remain an interesting concept but deliver suboptimal business value. With an appropriate RF the work of individual projects, programs, divisions and partners will be coordinated with just enough formality to ensure that the many moving parts can fit together when and were needed.

However, EM will not happen in isolation. It will be an adjunct to existing IT and business activities. Hence, there is no need to develop the EMF in isolation either. Rather, the focus should be on the deltas compared to ‘business as usual’. As a result of developing several frameworks, such as our own CBDI-SAE Framework and a RF for Cloud Computing, we subsequently defined a generalized RF and the process for establishing an RF in any domain; and this provides the basis for a version specialized for EMF illustrated in Figure 1.


Figure 1: Enterprise Mobility Framework

The specialized EMF shown in Figure 1 does not imply other elements of the generalized RF are ignored, rather that EM activities would deviate little from standard practices within the enterprise. Tables 1 and 2 provide an overview of the key framework elements that will need to be addressed for EM.

RF Element

Enterprise Mobility Factor

Reference Model

Meta Model or Concept Model

Establishing the terminology and providing a common understanding of the concepts that apply to EM will be key to achieving consistency across an organization.

A meta model also ensures rigor and precision in deliverables, policies, and other artifacts.

Capability Model

It is important to establish a product and implementation agnostic view of the capabilities or functions required to support Enterprise Mobility, as this enables for example a mechanism to establish and match device and application profiles, or to select products or solutions by comparing the capabilities required and provided

Maturity Model

Most organizations will not achieve maturity in EM overnight, but through a series of phases. Understanding what capabilities are needed, and when, is key to achieving goals without making unnecessary investments before there is a real need.

The Capability Model should provide the basis for this.


A set of principles are always a useful starting point. They should be addressed at the outset to define the boundaries and scope of EM within an organization, and help establish what is required of capabilities that are acquired to support EM – in terms of the principles they should adhere to.

Life Cycle

The key ‘assets’ of EM should be traceable, manageable and governed from the time they are planned through to retirement. Documenting their life cycles helps to understand the policies, deliverables and activities that apply at each life cycle state. 


Roles & Responsibilities

As with any initiative, identifying roles and responsibilities is essential. Does EM responsibility fit neatly within the existing infrastructure organization? Perhaps an EM CoE would be more appropriate.



A set of EM-specific policies needs to be established in order to govern EM activities. For example, what policies apply to BYOD, or ensure effective security or manageability?

Establishing the EMF should include identifying the types of policies that will be required

Table 1 – Enterprise Mobility Framework Elements

Reference Architecture

The reference architecture element of the EMF should establish conceptual models as well as any ‘blueprint’ architectures for EM that will help to ensure consistency and completeness across the organization in the delivery of EM solutions.

The reference architecture will be organized by views. The views in the generic RF are applicable, whilst Table 2 identifies views that are going to be most pertinent to EM solution delivery.

Establishing the reference architecture is not about providing the solution to the requirements identified below in each of these views, but providing the conceptual and architectural basis for those solutions.

Hence a key activity is also mapping the following elements from the rest of the EMF against each of the reference architecture views,

  • Policies that apply
  • Capabilities required or provided
  • Roles and Responsibilities
  • Maturity model streams and phases

Additionally, the Meta Model should contain a corresponding package for each view

Over time, a library of patterns, templates and blueprints should be established for each view.

RF Element

Enterprise Mobility Factor

Reference Architecture Views


EM-specific content here should include an understanding of what mobility means to the business, the goals the business and IT hopes to achieve through EM, and identification of the business scenarios and use cases that require EM solutions

Expect that addition multi-channel behaviors will be required and cross-channel processes will need to incorporate the mobile channel.


Addressing mobility in applications is going to be a core activity, not just in terms of development but also acquisition.

For much of the application life cycle, normal enterprise activities should apply. However, there are clearly going to be mobile-specific capabilities that must be supported by applications as well as supporting platform-specific delivery.

Mobility must address both the client device and the enterprise server sides of the equation.

A conceptual Mobile Application Architecture should be developed together with appropriate patterns, templates and blueprints.

Extensions to the Enterprise Application Architecture will be required, perhaps with additional layering.

  • Implementation

The main issue will be balancing platform independence whilst providing platform specific delivery. Ensuring a separation of logical and physical architectures will be key, as will the separation of the functions of the mobile ‘client’ from the enterprise ‘servers’ and other information sources.

  • Integration

An Integration Architecture will be essential to address issues such as data synchronization together with the provision of a Service Architecture and other integration capabilities. Enterprise Mobile Applications must be fully service-based.

  • Deployment

Managing the deployment of devices, applications and content will overlap with normal enterprise activities, but needs to comprehend the use of application stores, and the capabilities of various devices.


EM is highly technology-centric. Consumer adoption is largely driven by new technology which is still changing rapidly.

Establishing the Technology Architecture to support EM is of high importance, and again patterns, templates and blueprints will be useful here.


It goes without saying that mobility raises security concerns, and BYOD will only increase the risks.

Priority will be on establishing policies and providing appropriate infrastructure to manage identity and access, and to enforce the policies.


This section of the EMF should be focused on identifying the capabilities – in terms of methods, tools, languages, frameworks, etc. – together with the best practices required to support the delivery of EM solutions. Whilst MEAP products will provide a solution to some of the requirement, establishing the set of capabilities required first provides a benchmark for selection.  Organizations should buy products to fit the EMF, not the other way around.

As mentioned, for much of the application life cycle, normal enterprise activities in terms of process and deliverables should apply.


Addressing the management of devices, applications and content is a key topic for EM. There are a 101 MDM products and solutions available, and so establishing a product and implementation agnostic view of the management capabilities required is essential to ensure proper coverage.

Table 2 – Enterprise Mobility Framework Reference Architecture Views

This report does not detail the complete EMF, but focuses on some of these key building blocks that will be required.


It may seem counter intuitive to ask what the scope of EM is when it is already embedded in the title!

However, so called ‘enterprise’ initiatives are often less ambitious than the name implies. In a very large organization, the EM may only apply to a division or geography. There is also the common issue of whether such ‘enterprise’ frameworks are interpreted as implying a source of enterprise-wide recommendations and guidance or whether it demands compliance.

Additionally there are alternative approaches to adoption that may be used. Enterprise does not have to imply ‘centralized’, as enterprise-wide coverage could also be achieved via a federated approach.

Ideally an enterprise should strive to have one common EMF and manage divisional or geographical requirements on an exceptional basis. Hence it is important to determine the organizational scope, identifying divisions, geographies, partners, related ecosystems that will need to have some level of alignment with some aspects of the framework.

Therefore it is important to establish the scope of the EMF and its intended audience and ensure that the appropriate governance and policies is established.

Across the enterprise, items that really should be common should include the reference model, core policies that impact cross-enterprise usage, together with patterns, templates and blueprints that should be standardized wherever possible in order to maximize organizational consistency and reuse.

These items form the basis for a common vocabulary that establishes the foundations for an inherently agile enterprise – that can more easily respond to business and technology change because there is a shared language.

High Level Conceptual Architecture


Figure 2: Enterprise Mobility High Level Conceptual Architecture

Figure 2 provides a high level conceptual architecture for Enterprise Mobility. Breaking down the architecture it shows a set of ‘layers’ comprising,

  • Different classes of Users (Actors) interact with Mobile Applications.
  • The requirements for different types of Mobile Applications, defined by Application Profiles.
  • Mobile Applications run on Mobile Devices. The capabilities provided by the different types of devices, defined by Device Profiles.
  • In this way, applications can be matched to suitable devices, via their respective profiles.
  • Mobile Devices are connected to the Network, which also provides VoIP and streaming capabilities
  • The Network connects the Mobile Device/Application to various elements of the Mobile Computing Infrastructure that provides messaging, integration and rendering capabilities.
  • In turn the Mobile Computing Infrastructure connects to the Enterprise Infrastructure that provides the gateway to Enterprise Applications.

Orthogonal to these layers – as they are relevant to all layers – are ‘stacks’ for

  • Security including the identity of users and devices that permits them access to applications and enterprise resources.
  • The management of mobile devices, including the necessary mobile computing infrastructure and enterprise infrastructure components.
  • The management of mobile applications, again including the necessary infrastructure components such as application stores and the possible use of an MEAP.

A key factor in creating such a conceptual architecture is to agree on the concepts and terminology used.

Hence creating an EMF should start by defining the Capability Model and the Meta Model.

Continued in PDF...

Document Download: Developing an Enterprise Mobility Framework


Is your enterprise ready for mobility and BYOD? It is a growing imperative, but not many are. Enterprise Mobility – the use of mobile computing within the enterprise – has gained significant momentum in recent times. This report establishes the requirements for an Enterprise Mobility Framework and outlines some of the key elements.

Type: pdf

File Size: 462KB

Published: 13 Dec 2016 17:39

Enterprise Mobility Framework Resources

Enterprise Mobility Capability Model

This document provides a capability model for Enterprise Mobility – the use of mobile computing in the enterprise. It provides a product and implementation agnostic view of the capabilities or functions required to support enterprise mobility.

Enterprise Mobility Concept Model

The Enterprise Mobility Concept Model defines the key concepts of Enterprise Mobility - mobile computing in the enterprise.

You must confirm your screen name on your profile in order to comment.

Please sign in if you wish to comment.