SharePoint 2013 "Bring Your Own Device" (BYOD) Best Practices
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Remote workers and internal or onsite workers empowered with “bring your own device” (BYOD) policies can push the boundaries of IT and the typical IT-driven culture. A lot of IT organizations are playing catch-up around governance and their information management policies, and have pushed back on BYOD due to the added complexity it brings and ultimately forces specific polices to be approved.
There is a tradeoff between not allowing BYOD and the work required to actually implement a BYOD strategy verses the risk of users finding shortcuts and utilizing other methods or access points to share files or obtain reports.
Proven productivity increases have been realized by organizations with a BYOD policy and ROI that comes with empowering users. The gains you may see may in some cases may be inevitably offset with some users taking advantage of the added capabilities, but those “one-off” cases should not stifle the overall organization’s momentum towards technology innovations that can keep them ahead of their competitors.
Figure 1 offers an overview of the wide array of devices from which your organization’s users may access SharePoint.
)
The flip side of the coin around BYOD is that it can bring a 24/7 “working window” into the picture that some organizations may see as encroaching on the work/life balance but also what may define the actual workplace or given workday.
One of the major issues involving BYOD has been that the security risks that can be increased. But in SharePoint 2013’s case, solutions such as Microsoft’s System Center’sWindow Intunecan be put in place to assist in resolving some of these challenges. There must be a balance of privacy in conjunction with other obligations such as legal risks that may come with personal or PII\PHI data.
Enforcing a policy, where possible, that makes the user who is requesting the ability to use his or her own device (i.e., BYOD) aware of any possible challenges, sign-offs, or privacy-related data policies is the best first step as there must be expectations from both sides (IT and the business) in introducing strategy such as those concerning BYOD.
EPC Group’s internal BYOD policy follows certain password requirements with a pin addition as well as some layer of file encryption. Our consultants may be onsite at any given client, and require access to a document off our SharePoint Server 2013 intranet or ECM platform that a client requests and we must be able to immediate to meet that request.
The interesting part of developing and designing enterprise-wide strategies around BYOD or even areas such as cloud or hybrid computing does require us to test, perfect, and then implement these solutions ourselves. At EPC Group, the “eating your own dog food” rule most always applies in these technology areas. In addition, we have implemented device locking as well as remote wiping if a device is lost or stolen, as well as secure backups and either certificate\encryption or virus protection.
Understanding Device Channels in SharePoint 2013 (BYOD)
Regardless of the type of implementation your organization is trying to accomplish in phase 1, it is key to understand underlying capabilities of SharePoint 2013 to ensure your initial plans take full advantage of SharePoint’s out-of-the-box capabilities. SharePoint 2013 contains a device channel feature that is part of the SharePoint 2013 publishing infrastructure that will enable your organization to render site content, its images, and even the underlying content type, while maintaining the same URL (Uniform Resource Locator) across a selection of different devices.
On a recent project, EPC Group’s architecture team was tasked with implementing SharePoint 2013 with a specific and aggressive go-live date. This phase 1 deadline was for internal users with Active Directory accounts and was not targeted towards external or “mobile” users of the organization.
It was key to walk through the responsive design considerations with the stakeholders of possible future phases and future mobility needs, as there was a custom branding and user interface (UI) design that their marketing department was having us implement in phase 1.
The design was very appealing and looked great, but it was important to help both IT and the business understand that the “look and feel” implemented should follow responsive design but also take into consideration the device channels or ways the users within their company will access SharePoint long-term so that this branding would be compatible in future phases.
There is a difference in the “desktop version” of the SharePoint site compared to a “mobile rendering” of a SharePoint site. Your organization may initially support mobile devices, as well as those that may be possibly allowed in the future. You will have touch targets as well as navigational elements that will require optimal usability.
When a user from a mobile device (i.e., smartphone, tablet, etc.) opens a SharePoint 2013 site, the device’s browser submits something technically referred to as an HTTP GET request that will include a “user agent string.”
This string will contain information about the device, and that specific browser can then be redirected to a governed and specific master page view for that device (Windows Phone, iPad, Android, iPhone, etc.) Thinking in terms of not only initial users in phase 1 but future phases where mobile devices will be utilized will save a great deal of future time and effort.
In most SharePoint 2013 implementations, the initial strategy will target internal users; however, the mobile or BYOD strategywill quickly follow so it’s key to think in these longer terms regarding design. It’s also important to get an initial inventory and\or develop a “governed device list” for your organization to know exactly how users will be accessing SharePoint content.
Most devices allow for users to go to an app store to purchase or download “additional browsers,” so implementing your “supported” list is key to being able to let users know whether their device’s “entire” configuration is supported by the organization’sSharePoint 2013 deployment.