Apps for SharePoint 2013 carry their own set of implementation risks
Despite what I refer to as a near “binary” presentation, where the strengths of these app models (the “pluses”) are presented in direct comparison with the weaknesses of their full trust solution ancestors (the “zeroes”), readers with similar interests will benefit if they include a governance plan for customization along with the other migration components. Here is why:
The negative impact of these conflicts is greater when a central IT organization steps back and opts to empower line of business (LoB) units to build their own customizations for an on-premises complex computing platform like SharePoint 2013. On the surface this approach may look to be the correct one to take, especially if this stance has evolved after several years of an active BYOD policy.
Some proponents of Dev/Ops may recommend this kind of flexible posture on the part of enterprise IT. But if there is no central control over how jQuery libraries are to be implemented, then the risks of a breakdown in computer processing take on a more palpable shape. A far better policy calls for enterprise IT to directly arbitrate with LoBs on the question of how customizations are to be managed. In fact, enterprise IT ought to publish a set of standards for how customizations are to be built with SharePoint and/or Office apps. Finally, a set of tools should be implemented (and developed if they are not found to be available given the unique needs of a specific organization) capable of detecting processes running on internal on-premises computing systems to ensure any/all examples of app customizations are in conformance with this policy.
Without this kind of governance plan, larger organizations will face much the same odds of poor return on development investment from app model efforts, as would be the case if they simply proceeded with “legacy” customization techniques.
Ira Michael Blonder
© IMB Enterprises, Inc. & Ira Michael Blonder, 2015 All Rights Reserved