Monthly Archives: November 2014

Extending the perimeter – thoughts on establishing Collaboration in cloud vs on-premise

Understanding the file sharing collaborative products available from Microsoft

We tend to split file sharing and collaboration into 2 categories, real-time and non-real-time.

Microsoft’s core real-time tool is a Lync which is available both online and on premise. Lync users are able to is to message each other, people’s availability via real-time presence linked to their Exchange Server calendar and elevate discussions from text to voice over IP with supporting video and/or screen sharing. Lync is a great tool for meetings, team briefings and small groups working together on activities in real-time.

For off-line use the traditional way would be to store documents on file servers and, due to limitation of file servers, distribute documents and other content that needs to be worked on or approved via email. The new approach utilises a combination of SharePoint and OneDrive for Business (which actually also uses SharePoint under the hood). SharePoint allows Microsoft Office documents and other types of file to be stored in libraries and worked on by multiple users at the same time. Some key features include genuine multi-author editing in many cases (up to 16 authors can have the same Word document open for editing simultaneously); support for sophisticated metadata including document status (e.g. draft, awaiting review, published, expired); version control and approvals; the ability to send a link to the document via email without sending the whole document. Collaboration extends to other kinds of content, such as lists of information rather than documents, and can include other things such as shared calendars, tasks and more.

Generally, SharePoint is used for formal corporate collaboration, internal processes and team collaboration. It is possible to include an extranet solution within SharePoint to allow collaboration with people outside the organisation. Recommended best practice is for this to be a separate set of sites within a separate site collection. For this to work with an on premise SharePoint farm there needs to be a route to the SharePoint environment from the Internet through the organisation’s firewalls.

OneDrive for Business can be used to support collaboration with external parties or for informal collaboration activities and is a cloud solution only.

The other core collaboration technology, in our opinion, is OneNote. Our best practice recommendation is to have multiple OneNote notebooks, and to store these in SharePoint or OneDrive. We find that one notebook per collaboration site works very well and provides a real-time information capture, note taking and semi-structured knowledge capture tool.

Understanding the ease of deployment of an internal HyperV cloud based solution,

Although organisations talk about internal clouds or private clouds, the reality is that the crowd benefits don’t really manifest themselves until organisations have large farms running where the individual HyperV servers can take on or switch roles according to the load on the farm as a whole. We rarely see this for farms under about 12 servers, which is substantially more infrastructure and is required for this kind of deployment.

Nevertheless, installing SharePoint on-site requires a considerable amount of investment. Key steps are:

  • design farm architecture
  • provision Windows servers on HyperV
  • source SharePoint Server licenses
  • Install SharePoint Server on HyperV servers
  • configure SharePoint server instances, including permissions, site collections, templates etc.
  • source SharePoint Client Access Licenses and allocate

Only the last 2 items would be required using the Office 365 platform

Once installed, and on premise farm requires around 20% of an FTE to provide ongoing admin for the farm and the application.

Understating the security functionality / configurability in both the HyperV cloud solution vs Office 365 cloud options.

SharePoint security is a massive discussion in its own right. The summary version is as follows:

SharePoint maintains a sophisticated internal security model that provides granular access based on permission groups (which may be tied to or interact with Active Directory groups), supports security trimming (which prevents users seeing any content to which they have no access) and assigns different rights (such as view, edit, approve) to different roles and allows different roles to be assigned to different artefacts (sites, lists, libraries etc.) throughout the application.

Access to SharePoint is via a standard logon process. For on premise solutions this is usually based on the users Active Directory/Windows credentials, providing single sign-on. For cloud solutions there is an option to synchronise these credentials or to employ full Active Directory Federation which gives the same single sign-on option.

On premise solutions (e.g. a HyperV farm) are protected from the outside world by the organisation’s standard perimeter security, i.e. firewalls, threat protection and prevention. While this is often considered to be secure, the issue with this is that any content that needs to be accessed remotely or shared with 3rd parties have to circumvent this perimeter protection and this sharing rarely have strong governance; the extranet option referred to above requires holes to be created in the firewall etc. which can present a risk not only to the SharePoint farm and content but conceivably to other applications as well if not managed correctly.

Cloud solutions, including Office 365, generally has a much more sophisticated perimeter security solution. Furthermore the physical security of the server farm is far greater than can be easily achieved by most organisations with an on premise solution. Communication with the cloud solution is encrypted via SSL certificates (https:) and there is an option to enable encryption of the database. There is also an option to employ 2 factor authentication, which is achieved using a one-time code delivered via text message or using an authenticator app on a smart phone. We recommend using this sparingly as is option interferes with the ease of access to information for users, who will typically revert to less secure methods in response. The cloud solution includes an option to enable external sharing without compromising any of the organisations applications; Best practice still needs to be adhered to to protect the content within the SharePoint environment as noted above.

Security within the SharePoint application is, to all intents and purposes, the same whether on premise or in the cloud. In most cases an Office 365 environment is as secure as an on premise environment; while it is exposed to more potential threats from the intranet this is balanced by more sophisticated threat prevention built into the environment. In cases where the solution is only required for internal, on premise collaboration an argument could be made that an on premise solution can be made more secure; however when external sharing is required Solution has the benefit of segregating itself from other business applications, reducing the threat surface and avoiding compromise to the organisations network perimeter while enabling external collaboration and remote working.

This position is backed up by a number of security certifications for Office 365 and other cloud solutions. This includes an announcement from the EU in April 2014 that Microsoft’s cloud contracts and infrastructure comply with EU privacy laws and the UK data protection act across all of their infrastructure (data centres in the US and Singapore are treated as being within Europe for these purposes under this clarification). Details can be found here: http://blogs.microsoft.com/blog/2014/04/10/privacy-authorities-across-europe-approve-microsofts-cloud-commitments/

Organisations are wise to do appropriate diligence and research on the security capabilities of cloud offerings. However cloud services have matured over the last 5 years and the Microsoft ones are considered to be particularly strong. There are few reasons to reject cloud solutions out of hand on the basis of security; many financial institutions, multinationals and other organisations with commercially or legally sensitive information are committing their content to the cloud, with appropriate safeguards (which can include tools such as AvePoint’s compliance Guardian which can monitor what is being uploaded).

In reality most organisations employee local security and network security that is, at best, no better than cloud solutions. As ever the single greatest threat is the action of staff, and this needs to be addressed equally strongly regardless of the location of the application.

Leave a comment

Filed under Cloud, SharePoint

SharePoint – a strategic platform for business optimisation. Part 3 – Adoption

Adopting SharePoint

There are a number of important activities to consider in order to drive success of the SharePoint implementation. These include seeking appropriate user input in the early stages, continuing to obtain user feedback for an extended period of time after deployment and being seen to act upon feedback, setting out a policy and set of standards for the way the solution is used, enabling a steering board to take decisions on the way intranet and the organisation should interact and, of course ensuring that users are appropriately trained.

Although SharePoint solutions are mostly intuitive to use the business processes that they model are often not; furthermore SharePoint introduces new capabilities which allow the adoption of new, more effective practices which users are likely to be unfamiliar with.

A good example is the replacement of familiar folder structures for storing documents with apparently flat document libraries containing hundreds or thousands of documents. The careful use of metadata allows this large quantity of documents to be presented in views that rapidly let the user find and focus on what they are looking for without having to trawl up and down to an arbitrary directory structure; this approach also eliminates the problems that are unavoidably associated with hierarchical taxonomies such as the case where a document could legitimately exist in more than one folder, or where people are excluded from accessing particular files because of their location and the permissions applied to folders.

Avoiding the old ways

A combination of training, policy, good practice guides and support our needed to transition users from the old ways of doing things to the new, more effective options. This is especially true in the early days of adoption in order to avoid users reverting to old habits or replicating poor structures that are difficult to later unpick. It is helpful to have a business analyst/evangelist who can actively promote the new ways of working through hands-on, day-to-day interaction with users in the early phase; this role also is instrumental in identifying undisclosed business needs and with confirming whether the decisions made on features and strategy are correct and effective. The role typically transitions to a more (no code) development focused one over this period of time.

Creating the new

One of the things we really like about SharePoint is a tendency to make people consider their existing processes. There is a reasonable view that if you don’t need to change things you don’t need to introduce a new technology. So conversely introducing a major platform like SharePoint should for things to change and not simply provide a new way of doing what you are already doing. If the introduction of a SharePoint solution doesn’t shake things up you probably shouldn’t do it!

Use the rollout of the new application platform to explain to people how things are going to change, to overtly deal with their reservations and persuade them of the value of doing things differently. Understand adoption curve (diffusion of innovation) and be ready for pushback and the tension between early adopters and Luddites. Decide if this addresses a business critical activity that needs an overhaul, a tool for creating cultural change in your organisation, is a new strategic direction, or is just someone’s pet project. In three out of four of these cases you will need to push staff into adopting the change and abandoning the old ways quickly; and you have the luxury of being fairly uncompromising on this, after all it is their job to do it the way the business mandates. The new ways of doing things that SharePoint engenders are genuinely powerful, create new capabilities and solve problems for users (even if they didn’t realise that they had the problem). Just remember that by adopting this slightly new way of doing things it may be somebody else you’re mostly helping rather than yourself. I’d like to think that we worked in organisational cultures where this is perceived as a good thing.

Leave a comment

Filed under SharePoint

SharePoint – a strategic platform for business optimisation. Part 2 – Implementing SharePoint

Implementing SharePoint

In many regards SharePoint is remarkably straightforward and flexible for developing solutions with; very many applications can be developed by simply selecting appropriate features such as lists and libraries, configuring them using metadata and views and aggregating these within a variety of functional sites within a portal. All this can be done by super-user staff (rather than a technical expert or developer) directly through the browser without the need for a separate development and environmental tools.

However the very breath and flexibility introduces complexity and a depth of knowledge and experience in order to effectively plan and build solutions in an efficient and supportable way. There are many ways to make mistakes and while SharePoint itself is a resilient and forgiving environment, badly built solution will both fail to meet the business needs and disappoint or disenfranchise users.

 

Finding the right people?

When building sophisticated solutions it is best to start with someone who already has the skills and experience to deliver configured SharePoint applications; ideally they should have some knowledge of the solution that needs to be developed as this both exonerates the availability of the solution and minimises the risk of building it wrong. To this end it is often appropriate to engage a partner or highly experienced contractor, if they have existing experience. In order to ensure the solution is supportable in the long term it is also appropriate for knowledge transfer to the internal team to take place during the development. This way they understand it and can develop it further themselves without resort to 3rd parties.

It is also appropriate to develop the business analyst skills required to assess, triage and specify new solutions internally, as well as be able to provide guidance and support to users. Keeping the partner or contract on hand has value but it makes more sense to have internal skills backed up by external experts.

 

Making a plan

Of course it’s really important to plan your SharePoint project and specify the application trying to build. However SharePoint projects are not best suited, in my opinion, the pure waterfall project approaches and rigid specifications. Although you can get reasonable clarity on functionality and features required it’s difficult at the outset to define exactly how that will be achieved, or the user experience should be like and how best to mould the feature set to solve the problems or address the needs. SharePoint projects lend themselves to agile processes. There is much to be gained through iterative development with ongoing user input and evolutionary definition of the requirements. The simple reality is that the users really don’t know what they need in detail until I can see it and touch it, at which point they will think of new things that they want, change the things previously stated as requirements and rearrange the things that they see or have prioritised. The trick is to see this is a healthy activity and build it into your development plan. Fortunately SharePoint is largely very forgiving of this kind of development model, however there are still things you need to get right at the outset, such as defining the overall site structure and information architecture and really understanding the combination and quantity of lists and libraries required to store the different types of information and the relationships between them. Don’t be afraid to build a proof of concept and throw it away, but don’t be surprised if your proof of concept tries to involve itself into production environment. Know when to stop.

We also recommend trying very hard indeed to avoid writing any new code. It’s amazing how many business solutions can be solved simply by configuring the capabilities that SharePoint already has or, with a newer versions, by plugging in a SharePoint app or third-party technology. Custom development is fully supported in SharePoint that brings substantial issues around ongoing supportability and upgradability, often with little benefit.

Leave a comment

Filed under SharePoint

SharePoint – a strategic platform for business optimisation. Part 1 – What is SharePoint

What is SharePoint

SharePoint is a Microsoft platform technology, running on servers or in the cloud, which allows a large range of business solutions to be rapidly built, deployed and managed for any size of organisation.

It includes a large number of capabilities as standard focused on, in our view, 5 core business activities:

  • Content – it provides a means to store a very wide variety of information, including documents and files, webpages containing text and images, flexible lists of information and more. Advance content management features supplement this providing version control, approvals, publication schedules and expiry, information management policies and more.
  • Communication – it provides very powerful means for presenting content, with sophisticated methods for navigation, grouping and filtering of information, notifications and alerts via email, etc.
  • Collaboration – it includes worksites that group information, content and processes together and allow groups of users to interact with these and each other in real time. Advanced capabilities include things like multi-user editing which allow multiple people to edit the same document at the same time, eliminating the need to collaborate via email. It interacts with other collaboration technologies such as Microsoft Lync and provides tools such as active task lists, statuses etc.
  • People – SharePoint has built-in social features, user profiles, contact lists and a variety of tools to enable people to find each other, for each other’s activities and interact in ways not available without such technology.
  • Business process – the above capabilities are often combined with SharePoint’s electronic form capability and workflow capability to develop and manage sophisticated business processes.

Other important features include ubiquitous enterprise search, the ability to apply branding and rich user interface elements, connectivity with line of business systems, business intelligence capabilities and deep integration with other parts of the Microsoft stack, especially Microsoft Office.

SharePoint presents its features and the information it stores via any standards compliant browser; it is also able to integrate with the Windows file system so that document libraries appear to be almost the same as saving to the local hard drive or fileserver for end-users; it provides provides other rich capabilities directly to other applications in the Microsoft technology stack, including Microsoft Word, Outlook, Access, Dynamics CRM, Excel etc.

Structure

Most elements of SharePoint are grouped together within a hierarchy of “sites” within a “portal”, with each site grouping together sets of features (such as document libraries, custom lists, views of information, calendars, navigation and links) and providing secure, permissions-based access for groups of users. Behind-the-scenes it supports sophisticated information architecture concepts such site collections (which act as silos of content and users), site-wide metadata, taxonomies and managed terms, permission groups, content types (which grouped together metadata, security and document templates in order to define a class of document or content, e.g. a report type or a project initiation document), information management policies and other nuanced structures.

When thoughtfully architected, these different capabilities and the solutions developed using them form the basis for an enterprise intranet or other application that can transform the way an organisation operates. When fully adopted, benefits include paperless working, agile remote working in collaboration, single point of access to all organisational information and processes, and assured single version of the truth, rapid search and discovery of organisational knowledge, access to people, management processes and the ability to continue to develop streamlined solutions to emerging business needs.

As a platform, SharePoint is considered to be best in its class and is the most broadly capable technology platform available from any vendor. SharePoint and the Microsoft stack appear in the top right-hand portion of the Gartner Magic quadrant for most of the things SharePoint delivers. (https://www.google.co.uk/search?q=gartner+sharepoint&biw=1745&bih=862&tbm=isch&tbo=u&source=univ&sa=X&ei=73JjVLjSK7T57Abw3ICoCg&sqi=2&ved=0CFEQsAQ)

Common Business Solutions

Some typical business solutions that are commonly found running on SharePoint include:

  • department and team working areas
  • corporate document and information stores
  • staff social areas
  • policy management and publication
  • project and programme management
  • corporate library
  • events management
  • meeting and boardroom management
  • newsletter publication and comms
  • corporate video, image and media management
  • staff directory and phonebook
  • personal working areas and storage
  • electronic form and workflow enabled processes

Leave a comment

Filed under SharePoint

15 Reasons Not to Use Folders in SharePoint (and 3 reasons why you could)

I hate folders as a means of organising content. It’s a deeply broken approach and carrying it over to SharePoint is one of my pet hates. I have even written a song about it. So I pulled this together from my involvement in various conversations and involvement in a discussion arising from an article written by Gregory Zelfond. http://sharepointmaven.com/12-reasons-folders-sharepoint-bad-idea/

  1. No right place – this is the biggest issue and most easily understood; folders force you to put a document or file in a single location, even if it might legitimately be associated with several places. A project report could be put in a folder with all the other documents for that project, or in a folder for reports, or in a folder for documents that are archived; in reality it should be in all three but that creates duplicates. SharePoint metadata would let you tag the document as being a Report, associate it with a Project, set its status to Archived and more. Different views would let you see (or hide) all Archive documents, all project reports, all documents that are not in draft that have be modified by me in the last 7 days and include the Technology tag, etcetera, etcetera. And you can switch between views with a single click.
  2. Usability – Unless you have a rigorous and actively managed file plan (and, let’s face it, no one actually does this well) then the folder structure is only known to the person/team who created it. Everyone else has to inefficiently browse the contents hidden in the folders in the hope of finding the document or file.
  3. URL length limitation – SharePoint builds the URL using all folder and sub-folder. However the URL length is limited to around 255 characters; beyond that you get an error. Deep folder structures simply break in SharePoint.
  4. Unfixed URL – Moving a file from one folder to another changes the file URL, so any fixed links to it will break.
  5. Security – You can use folders to define security for groups of files in SharePoint, however ongoing management of this is as big an administrative nightmare as it is on file servers.
  6. User experience – The user experience (UX, navigation, finding the documents) is marginally worse than it is on file servers – it’s slow, content is hidden until you open the folder. Moving content within folders is terrible within the browser, navigating between folders is horrible too. (though you can open the library in Windows Explorer).
  7. File duplication – Folders actively cause file duplication, partly because there is no one, right place for a given document or file (in fact you often have to put a file in multiple paces because folders are so inflexible), partly because you can’t see that the file already exists elsewhere. If you are striving for a ‘single version of the truth’ then creating duplicates immediately undermines this principle.
  8. A single view – One of SharePoint’s many great features is the ability to have multiple views of content, with the flexibility for users to filter and modify the view on an ad hoc, temporary basis. But not with folders, in a folder view you get just one view of your content and it is pretty poor, for the reasons above and below. Using metadata, you can create unlimited number of views by whatever properties you have setup (i.e. organize documents by date, by customer, by project, etc.) .
  9. Can’t Sort & Filter – Burying files in folders means you can only benefit from the sorting and filtering capabilities of document libraries and metadata navigation within the folder you are in.
  10. Inflexible – It’s hard to change the folder structure (though again you can use Windows Explorer), while changing metadata is easy and can be done as bulk actions.
  11. Lost documents – It is so very easy to misplace documents by putting it in the wrong folder and not knowing where it is. So then you create a duplicate copy, and the mess begins.
  12. Navigation – When you are in a particular sub-folder, there is no easy way to tell which folder you are in and no easy way to navigate to the parent folder, a sibling folder etc. since there is no breadcrumb trail or tree view by default.;
  13. Cost – If all you are doing is recreating the same mess of nested folders you had on file share within SharePoint all you have done is increase the cost (SharePoint infrastructure is more expensive than a file server) and you have cunningly avoided almost all the benefits of SharePoint.
  14. Visibility – the only way to know how active a folder is/how many documents it contains is to open it. It could be empty; it could have ten thousand documents; you just don’t know. A grouped SharePoint view in SharePoint using metadata shows many docs are in each group (and lets you carry out counts and other basic arithmetic on column values, such as Average file size). If there are no items in a group then the group doesn’t clutter up the screen.

    The power of SharePoint views - who needs folders when you can have groups, filters, metadata navigation and more?

    The power of SharePoint views – who needs folders when you can have groups, filters, metadata navigation and more?

  15. Data Integrity – There is little control over the naming of folders, so you can have spelling errors, non-standard conventions, unhelpful abbreviations etc. Metadata driven views can be driven by lists and taxonomies to avoid this.

Exceptions

The big problem is that folders are traditionally used to categorise content, whereas they were originally designed to group content. Just because we have learned to use folders inappropriately doesn’t mean we should continue to do so. However folders have some legitimacy for their original purpose. If you genuinely need to group files together then you can use a folder in SharePoint; this is usually because you need to perform a group action on them, such as delete them all. Similarly folders may be used (despite point 5 above) to assign grouped security to the content – simply moving a file into the folder gives it some security; as long as the security rules are very simple to apply and understand. In both cases you still should avoid folders – use a Document Set instead, since they are much more powerful, intelligent and intuitive. Even then we strongly advocate having only a single level of folders and never, ever more than two,

The only other reason for retaining is that you can’t get users to adopt the new, better way of doing things. At this point you have to use your judgement – generally staff work for the company and the company can dictate ways of working; there are rules for not operating machines without guards, even though they can be somewhat inconvenient for operators (until it saves one losing an arm); the digital health of your knowledge is as important. However if a team or individual chooses to stick with folders for their own content then that may be OK; as long as it doesn’t disadvantage other staff and that they aren’t wasting company resources (working time, support desk resources, computing time) in the process. A suitable policy for use of your intranet can address this – shared content, core business processes, managed information should not allow use of folders in libraries; personal and team working areas may use folders, but should avoid deeply nested folders, should also use flat views (where the folder structure is hidden) and must be actively managed by the team to avoid duplicates and misfiling.

1 Comment

Filed under Improvement, Intranet, SharePoint