SharePoint Requirements Analysis Guide
SharePoint User Requirements Analysis is vital; the corner stone in developing, deploying and providing a properly managed SharePoint environment.
Service Delivery and Automation
Oh yes, I love automation. Having a mountain of robots, and building them (especially my DR Who full sized dalek), fascinates me in the wonder how invented things can move without human intervention (except I suppose the dalek because I will be driving it – haha).
There are various products which all elude to automation in my arena of Microsoft Office systems and services. And now that they are being brought all together under the Office365 hood, now is the time to understand the nature of Service Delivery and Automation.
This quick article is my take on what it is from my standpoint giving some arguments as to what it means from a basic viewpoint. Note that this view is one I have had for many years, because the model, and my notion, stems all the way back to my Systems Analysis days.
Ahem, a little check first… Automation and associated service delivery has been around in systems since the age of software. It is not new. Unfortunately, by many, it is an art which is glossed over, and as such, when someone says ‘lets automate process using powershell’ that’s only a small link in chain mail armour. But now, we have entered the realm of convergence, the advent of ‘connected’ systems. This means automation takes an evolved step, into the land of systems with software beyond human reach, beyond scripting, beyond coding, beyond one platform (e.g. SharePoint), beyond Office365, into and beyond cloud services, to the nether regions of connected systems and connected data. The fact that more data is available to be accessed which can then be scrutinized, re-modeled and then used to automate other processes makes this an exciting time in the land of software design. The fact that time-to-live for the company process becomes shorter, the re-use and revamp of automation becomes an enterprise imperative, and the need for a complete ‘coded’ approach is not the answer. Also, the following video gives even more reasons why automation and service delivery are becoming more important.
Why Service Delivery and Automation is important
As a younger lad, having been introduced to Systems Analysis and Design (which includes programming in a multitude of computer languages using a multitude of platforms and technologies), as I see that as time marches on with new technologies, so does the increased need to maintain and therefore automate, endpoints of legacy with endpoints to current with endpoints of the ‘external’. Critically, and in every solution devised, there is service delivery. The absolute imperative to ensure that whatever solution being devised is maintainable, available, repeatable by design and resilient. This resiliency is not just to do with things like Disaster Recovery or Business Continuity, it goes right to the heart of making sure that the solution is fit for purpose. Service Delivery flows through every part of enterprise architecture, from the idea, to analysis, to design, to production, to support and thrives within that solutions and connected solutions lifecycles. It includes the physical and digital technology that makes up the solution – yes, the servers, and the software, and the storage etc. That means, that even more crucially, it does not matter whether you are a business analyst, a programmer, an administrator, an engineer, a product manager or programme manager. You will be thinking service delivery in whatever you do, whether you like it or not. As you may know, my site is a haven to all things service delivery and includes another passion of mine, which is automation. Why? Because automation is the connector that allows the solution to be flexible, to scale, to morph, to carry out processes without human intervention (which then means better accuracy) – it supports service delivery. Of course, I don’t aim to create a wonderful robot of automation to win a prize, but am absolutely keen to learn and use my integration expertise with it! 
Anyway, lets go back to why you should understand the importance of service delivery automation. For example, lets quickly mention Office 365 as an example. Any administrative process that you are carrying out when interacting with the admin centre of Office365 carries out a robotic process. A robotic process is one where you interact with the product, and yet, the back end product is not wholly under your control. Rather, you are automating the software to carry out functions, as opposed to you directly influencing the software. You do not have access to any server based tools – you are automating those tools to carry out a process, in fact, you are being non-invasive – that’s robotic automation. Robotic automation also includes things like system upgrade, data entry and transactional processing. And the high chances are that you will not have direct access to those systems in a multi-departmental organisation. Robotic automation is definitely coming on leaps and bounds in a multi-server environment where you need information from a collection of systems. I spoke to a company which has a desire to manage specific services wanting to not only control web services on a particular group of pre-production servers, but also wanted to store results securely online because they had support groups which did not have access to those servers.
Automation comes with a price
But automation carries with it a price. The increase in automation has a detrimental affect on wisdom, that is, it will curtail the ability to continually review an already automated created process. Reasoning is that once something has been automated, it is then difficult and/or cumbersome, and therefore not desirable (particularly for large automated processes), to alter that process, without then impacting on other processes connected to it. Take for example the process to automatically upload data into SharePoint which then automatically stamps metadata on that data. Lets assume for a moment that it starts off as simple as this:
- Get a file from a network share
- Upload that file into a SharePoint document library
- Set metadata, the Title becomes the filename
Sounds simple? Yes, until you add a simple automation with that file, like:
- Once the file has been uploaded, alert the members
- Gather details from the file to pass onto a data management system
For alerting, sounds simple because you would simply set an e-mail alert, yes? But it is not so simple if that alert needs to be customised beyond what SharePoint does, or if the alert needs to trigger some other process, like having its contents interrogated to be used in another system. And as for the data being passed onto a data management system, that means additional management of ensuring the right data gets across. Then there’s the service delivery angle, ensuring that the automative process continues to be maintainable, available, resilient and supportable. So that means, either code it, or use say a workflow to customise a notification that fires as soon as the file is added and carry out other functions. The point is this. Once something becomes a target for automation, the human desire to do more with it comes arises, but that impacts on wisdom because the need to change things does not happen at the same speed as when the process came into action. This speed decreases with every new connection to systems and other processes, because of amount of work required to identify and service deliver all steps in the process end-to-end. This affects wisdom, as the sheer added number of steps in a process make it more cumbersome to confirm things like performance, audit, human response tracking, etc. Of course, one may argue that certain workflow tools tracks performance in each step. But that rarely comes from a central point – that generally comes from the application system running that step. If are able to centralise all processes under one system banner, then maybe, well done! But, I am not talking about just one tool. I am talking about automation that does not just include that tool working in one system, but all the other systems that tool may be a part of in an automative process (that is, all endpoints).
Automation is not just writing an app to display a form or a workflow
In essence, automation is one of the keys in which systems work in harmony to fuel a seemlessly connected process, machine driven and harvesting intelligence. Service delivery automation encompasses all parts of a process that requires automation in order to meet one or more of the imperatives at the bottom of this section. It is more than simply the need for someone to fill in a form (that is simply an aspect of a process).
For example, if HR wants an individual to fill in a form online once they are on-boarded, that form must be sent to specific individuals, then to other departments to assign resources, then needs to be stored, and needs to be applicable to audit (or used again when that new person changes departments or even leaves the company). So writing an app to get someone to fill in a form is not automation of a process, it is a step in that process. Another example. You want to be able to collect information on the status of all servers in your estate – specifically, the status of specific services and want to display that centrally. You don’t have access to SCOM (System Center Operations Manager), and you don’t want to code it. Again, writing an app to display the status of all the services is not automation of that process, it is a step in that process, because automation of display of that information does not end with it simple being displayed. You want to be able to act on the data, or take some automated action to resolve issues if the status is not as expected.
Automation using any technology is decided upon because one needs to address all of the following, but only works if by connecting technologies using automation techniques minimises disruption:
- Quality
- Speed
- Accuracy
- Productivity
- Efficiency
- Scaleability
- Flexibility
Don’t automate everything!
Just because you have a bicycle does not mean you fix it so it rides itself. By doing that you miss the simple enjoyment of doing anything physical, like exercising your legs. The same thing comes with automation. Just because you want to cut costs to achieve additional benefits by reducing or eliminating human involvement doesn’t mean you should immediately automate the process. A factory which distributes milk has automated the entire factory floor so that robots move the milk containers around the factory. But they still need humans to keep an eye on the robots. Certain processes you will want to be operated by humans, because at the very least you will still maintain some modicum of control, and to mitigate risk. Otherwise, you might as well consign yourself as a cyborg or a member of the Borg from Star Trek. You only automate things that you think will reduce time around time, or will reduce the requirement to chase actions. But improving things to simply reduce headcount is not going to solve anything, unless you can absolutely guarantee that nothing will happen to upset the automated process. Some companies where automation has been a success is were they actively introduce business continuity. I’ve even seen companies use a back to paper continuity plan if the automated process through computers fail. This is where, for example, they utilise legacy equipment and where they need to guarantee a process if that legacy equipment fails.
Conclusion – and a new beginning?
If you are not thinking automation for your technology set, you should be. I think that it is time to take stock of your automation alternatives. Automation of an enterprise solution using multiple technologies requires an adoption of an suite that allows you flexibility. Remember that using a tool within one platform is not enough. Maintainability, Availability, Resiliency and Supportability is key. Automation in the SharePoint space is already taking place, is driven by transactional processes across systems, to ring-fenced workflow against specific processes, to Web Analytics across Office365 and on-premise SharePoint. As this increases, so will be the need to review automation tools. On my voyage of discovery, a few of the companies I have surveyed taking automation seriously have mentioned to be a product called Automate 10, owned by HelpSystems LLC. This product provides a none scripting platform to integrate and automate a myriad of services from Amazon through to FTP through to WMI automation and across multiple servers and services in the enterprise. Am running some demos of this myself and the product seems to be very useful. Check out some automation case-studies from some products which I recommend if you are considering enterprise wide automation (not sticking to one technology or one sticking to one scripting language). Click the below screenshot to see the number of services (note – Azure is also listed!). 
There are other links to articles you should also check out, to see how some other organisations are dealing with automation.
SharePoint and the Workflow Conundrum
When utilising a collaboration tool the key productivity rationale is to automate processes through the content stored within that collaboration tool. SharePoint has a number of platform flavours (on-premise, hybrid, online) and has integration points which is only limited by creativity it seems (not simply confined to Microsoft products). Therefore, it is crucial that when thinking of what workflow tool should be used to automated business process that you understand also the options, strengths, weaknesses of the various workflow options that can be utilised with SharePoint.
Having had a lot of fun trying to fathom, making mistakes along the way of course, I got together all my notes, including querying lots of knowledgeable people (thanks to you all) – and put together an article; published on Tech Net blogs and also on DOCS!
The article is quite large therefore I had it split into four parts (great idea from Charlotte C at Microsoft – thanks)
Sections in Part 1 are:
1: Introduction to the business process automated
2: What does a workflow system need to accomplish
3: Mind set of developing workflow
4: Types of workflow
5: What does the full article cover in terms of product, scope
Sections in Part 2 are:
1: Options for workflow with on-premise SharePoint
2: Options for developing custom workflows using SharePoint Designer / Microsoft Visual Studio
Sections in Part 3 are:
1: Options for workflow in SharePoint Online through Office365
2: Options for workflow in hybrid situations
3: The ‘workflow manager’
4: Publishing workflows to Azure
5: Workflow options available through third parties
6: Strengths and weaknesses of covering all options
Part four completes the article by summarising the key take-away – what tasks should be carried out concerning an approach to choosing the workflow solution that suits you and the customer
Happy reading!
SharePoint and the emergence of the Data Scientist
As the use of content management systems evolve with users adding more, ahem, “content”, the organizations accountable for those content systems will need to ensure that they build in people resources who can manage that content, and particularly people who can find insights in that content for the benefit of the organization.
Business intelligence requirements and implementations are growing faster than ever before, particularly due to the rise of cloud computing and more cloud services. There is now much more pressure on ensuring that customer interactions are tracked as a key aspect of business intelligence data gathering. This is one of the most critically important ways of working out the value that cloud services provide.
The blog article has been written for TechNet and is available on this link.
Related articles
How to use Service Assurance in Office365
One of the challenges concerning those implementing Service Delivery with Office365, is building proof that Office365 complies with regulatory standards and legislation. Service Assurance in Office365 is a primary goal, and if it vital that you understand how Office365 protects your data, especially since Office365 concerns email access, team communication, collaboration, content storage and specifically content viewed and edited in a browser. Service Delivery includes Service assurance, which is an organisational primary goal, and is directly aligned to the C/I/A triad (Confidentiality, Integrity and Availability), being key aspects of information security.
Office365 contains a Service Assurance area which allows Administrators to setup and provide resources to carry out risk assessments and audits, and includes a wealth of reports covering security, and the relevant legislation and standards that Office365 adheres to. I wrote an article for TechNet Blogs which gives a great overview on how to use Office365 Service Assurance (within the Security and Compliance section) here, go check it out!
Understanding Personal Data in Data Processing
Personal data (also referred to as PII – Personal Identifiable Information) identifies an individual. In that personal data, a name by itself is not enough to identify an individual, however, a name including the address would. For example, when you are called by an operator in a call centre, you will often be asked for your name, address and date of birth. That is an example of personal data. What they do with your personal information goes into data processing, that is, to store, sort, workflow (further processing) and retain till archive (disposal) that data. The controller of that data (that is, the owner of that call centre) is responsible for ensuring that data is stored securely on their system.
However, no matter how secure the system is, or in fact, any data processing system is, social engineering attacks is a key threat vector. The weakest part of an system is the people, since they are the easiest to deceive and manipulate. One of the weakest aspects is through impersonation attacks. Impersonation attacks are where someone plays the role of someone who is likely to be trusted (whose personal information was obtained through data processing). In other words, one of the ways to get enough personal information of an individual to impersonate is through getting their personal information in the first place, and, to a large degree, ‘data processing’ is where that information can be obtained.
Through the data processing, there are three key elements:
- The Subject, who owns the data.
- The Controller, who is responsible determining how the data is processed.
- The Processor, who is responsible for the data processing of the subject data.
This can be represented in virtually any process, let’s take a basic SharePoint example:
- The Subject uploads data into a SharePoint site.
- The Controller manages the site where the data is uploaded and determines how the data is processed (also known as a data owner on the site)
- The Processor holds that data from the point where it has been uploaded, to the point where the data is disposed of (this is generally some technical processes in the repository where the content has been uploaded, e.g. storage, workflow, disposition, security).
There are some assumptions to the above example in terms of the management of Personal information:
- The Subject assumes that the data being uploaded is securely managed (it can be security classified, can be readily accessed, and remain intact).
- The Controller assumes they are accountable to that data being serviced by making sure the processor is sufficiently set to securely that content and marked with an identifier of the subject. A basic example in SharePoint is that data uploaded gets marked with the name of the individual uploading the data, the time when that occurred and history of working with that data is recorded.
- The Processor assumes that it is designed in such a way that personal information is secure; that any alterations, changes, modifications, workflow is known to the subject.
A conundrum is the sheer collaboration aspect; that is, who has access to that data, and, unfortunately, that some controllers misunderstanding that security is somehow, the product. It is not. Any system can be bypassed using social engineering if that data is compromised. The personal information of the Subject can be accessed by anyone who has the view access to that data. For example, in the case of SharePoint Online, when a Subjects name is clicked in a repository, a list of other documentation recently uploaded / accessed is visible, along with a link to getting more information through Delve. Additionally, on the Delve screen is a further link to the Subjects’ OneDrive, and from there visibility of the Subjects’ team. In terms of technology this example works slightly different in SharePoint On-Premise, however, the outcome is the same.
The challenge is that irrespective of the tools used to provide the nature of storage, availability, integrity of data that there needs to be some thinking in managing the security of the data as well as personal information. Lets’ look at some of the requirements on those three elements:
- From the Subject, there needs to be understanding of how much information they enter about themselves using Delve (About Me, Projects, Skills and Expertise, Schools and Education, Interests and Hobbies) as this affects PII.
- From the Controller, they need to provide awareness to the subject that the data they provide is secure, and the level of accessibility to that data, and where that data is located.
- From Processing, the design of repositories needs to include the management of storage of data, classification, workflow relevant to how personal information is passed. For example, the use of a form to capture information relevant to content uploaded may require the subject to ensure personal information, maybe even beyond what is already supplied in Delve. If this is the case, the Controller should make the subject aware of the kind of information gathered, and what the Processing element will do with that data, and how long that data will exist in the repository. Another example is where the data uploaded includes Personal Information and through machine learning metadata is extracted and posted as viewable column data in a repository. And this does stop at metadata. The very design of code used to carry out further processing through workflow should be scrutinised since the level of Personal Information recorded needs to meet legislative laws; in particular, the Data Protection Act 1998 UK law covers this including sensitive personal information to which you should have the Subjects consent beforehand to process.
Summary.
Managing Personal information is a crucial aspect data security; the key aspect to understanding how to prevent breaches of personal data through impersonation or masquerading.
This short article is designed to get you thinking of the actual service delivery in managing personal information not just for SharePoint (either Online or On-Premise); even beyond to endpoints connected to it; and then even beyond into the roadmap surrounding Office365. In a data processing system, the fundamental requirement is to secure the content through its lifecycle. The challenge is ensuring that the features of the tools involved are fully understood when it comes to the storage of personal information, and that security awareness, policies, and training is provided to subjects and data controllers. Legislation is important to understand in this area and a good checklist to start from is here.
The key element, the Subject, can be made more aware of storing personal information in content they upload. A good article for working say through a Word document and removing personal identifiable information is here.
A distinct point to make is that Microsoft cloud applications are by their very nature tools used to upload and transmit information by customers through their relevant tenants. For example, whilst Azure services covers tools for system maintenance, infrastructure, security, record retention, information management, system development, there are data processing activities which the tenants manage. They must ensure that they are responsible for ensuring that information stored or transmitted through the services is securely managed, in that they at the very least should have carried out a security risk assessment against any data processing / controlling surrounding managing personal Information. The key thing to remember, is that security is not a product – the responsibility of securing data through its processing lies with the Controller of that data – the tenant owner, the SharePoint site owner, and therefore the organisation responsible for providing those sites.
Microsoft SOC and ISO Audit Reports Available
One of the most useful documents in my view in planning implementations of Office365 is understanding data encryption and data backup and the standards applied. Microsoft have provided audit reports covering their cloud stack (Dynamics CRM, Office365, Yammer and Azure). These SOC and ISO reports include testing and trust principles in these areas:
- Data Transmission and Encryption
- Security Development Lifecycle
- Data Replication and Data Backup
To access these reports, you will need to access the Security and Compliance area in your Office365 tenant.
As said, these cover the Microsoft Cloud Stack, however, the two key documents for Office365 are:
Office 365 ISO 27001-ISO 27018-ISO 27017 – this is an audit document confirming whether Office365 fulfils the standards and criteria against ISO 27001, 27018 and 27017.
Key points:
- PII is included in Office365 because it is run over Public Cloud for multi-tenant customers.
- Cloud Security is included in Office365 because it is defined as a SaaS (Software as a Service)
- All encryption adheres to TLS requirements and hashing (specific)
Office 365 SOC 2 AT 101 Audit Report 2016 – this is an audit document looking at the controls relevant to Security, Availability, Confidentiality and Processing Integrity.
Key points:
- Details on the services concerning planning, performance, SLAs, hiring process (including background checks of staff) are provided.
- Control Monitoring, Access and Identify Management, Data Transmission (encryption between Microsoft, Client and data centres) are described.
- Project requirements through to Final Approval concerning the SDLC process is described
- Availability, Data Replication and Backup is covered.
Summary
The above SOC and ISO are extremely useful in aiding any risk assessment that you should take to confirm the service assurance of Office365 going forward. Risk assessments are not a ‘one shot’ task. They should be carried out on an annual basis. The Office365 service is a rich offering of Infrastructure, Software, People, Procedures and Data. Each requires security controls and confirmation that they meet standards which can be dovetailed into your organisation. The audits go into great detail concerning the controls (especially things like Data in Transit / Rest – SSL / TLS). A lot of questions is asked by customers concerning security controls – the video below is a good method of getting you to understand (and your clients) how Microsoft ensures proactive protection, and you should definitely check out the Microsoft Trust Centre for great information concerning encryption.
Content Management Systems – Principles and Concepts of Information Assurance
A major challenge in businesses is a misconception, that data is 100% secure concerning any part of its data processing within that business. This data processing concerns the content management lifecycle; from creation, to storage, to distribution, to workflow and eventually archive of that data. The misconception? “Security Breach? Its not going to happen to us” mentality. It is vital that there is an understanding of Information security and Information Assurance in content management security. As an information security professional (or Architect covering security), you should be prepared for any aspect of secure breach can happen that can affect the confidentiality, availability, and integrity of the data. Any service delivery disruption caused by a security breach is harmful to the profitability, and has far reach consequences which could include liability, status and much more.
Office 365 Monitoring using System Centre Operations Manager
One of the most compelling challenges for Office 365 is centralised monitoring. Those working in the SharePoint arena will know only too well importance of monitoring and reporting across the platforms they manage. This is not simply from a technical but also from proof of service; the availability and evolution of those services.
SharePoint Configuration Management
Platform Governance is there to help bridge the communications gap between the business and technological groups; ensure ROI, mitigate risks associated with IT Projects impacting SharePoint, and provide a key cog for SharePoint Service Delivery, capability of service.
When a SharePoint solution is delivered, you need to ensure the continued availability of that service to related customers. You will need to protect the integrity of that SharePoint solution. You will need to prove that the SharePoint solution is capable (that is, that things like Change, Risk and Issues concerning the SharePoint solution are managed and communicated and documented).
Take this scenario:
Fabrikam is a manufacturing organization and has a project management office. Their IT team gets SharePoint and installs a site for the project management office. The company culture isn’t strict in terms of website control, and the IT team do not create documentation concerning the design or installation. The small site expands as more projects are added, and more features are added. Again, no documentation concerning changes was made. Six months into the project management office site, and there is a request to add more functionality which will change the way in which the project management office runs. However, in order to do that information is needed about the features applied and the reasons behind why they have been applied. Chaos ensues as no-one has any idea on how the sites evolved; the IT team is squarely blamed for not having adequate documentation about the sites history
Check out my book 'Implementing and Managing SharePoint Projects 2010'
This section comes from my book, Implementing and Managing SharePoint 2010 Projects, which is a great read covering lots of service delivery topics to aid SharePoint programme delivery.
Clearly, not a scenario that you would ever like to find yourself in! Therefore, you should use Configuration Management techniques to control specifications, drawings, software assets and related documentation which define the functional and physical characteristics of a SharePoint solution, down to the lowest level required to assure standardization. Control of those elements also means you control the SharePoint solutions and its Platform, under a Change Control regime and to control release of SharePoint solutions into your SharePoint platform. This enforcement of change control is linked to Platform Governance. The Configuration Management (CM) process also provides a documented, traceable history of the development lifecycle of SharePoint in an organisation, including any modification, upgrades or variants, and should be used to hook into your Change Management processes with SharePoint.
SharePoint when implemented is defined by identifying configurable items based on its technical, administrative and maintainability criticality. The selection process is one of separating the elements of SharePoint on a hierarchical basis for the purpose of managing their baseline characteristics.
Any item associated with the SharePoint solution, including deployment and any associated asset is subject to Configuration Management.
The diagram below illustrates the degrees of control applied to a configurable item during its implementation lifecycle.
Initially an item is uncontrolled whilst under development by the author. It becomes controlled once a unique identified has been allocated and the item is subject to review. Once the development of an identified configurable item is sufficiently stable to declare a baseline standard, it will be subject to configuration control processes. On small projects, configuration management techniques may be applied by the project staff using a simple SharePoint list to control baselines and record the version / issue status of the identified configurable items.
On larger projects, particularly where a large number of hardware drawings or modules of SharePoint features have been produced, Configuration Management may be delegated to specialist staff. The advantage of a central site CM facility, with its own specialized staff and archive, is the long term maintenance of project configuration records. However, the production of SharePoint add on features (e.g. Web Parts, Automation, Branding, Site Definitions etc.) is particularly well suited to the use of configuration management and tools, remaining under project control.
Check out my book 'Implementing and Managing SharePoint Projects 2010'
This section comes from my book, Implementing and Managing SharePoint 2010 Projects, which is a great read covering lots of service delivery topics to aid SharePoint programme delivery.
How to apply Configuration Management in SharePoint
To apply Configuration Management in SharePoint you will need to state a policy for its use and its procedure. You will need to ensure that any deviation from this policy, together with designated configuration management authorities for the SharePoint delivery program is documented. Other configuration management details may be contained in a separate configuration management plan, depending on any contractual arrangements or the size and complexity of SharePoint being implemented.
As the SharePoint Delivery Planning initiates, so should Configuration Management. You must choose a set of methods, procedures and tools to satisfy the requirements below. If the client organization does not have any Configuration Management processes in place you will need to create those processes. A method of recording these is via a central SharePoint site for the purpose of storing CM documentation and history of changes to the solution. If you intend on doing this, and if the client does have a full configuration management process running, investigate and find out if either (a) there is connectivity between that and the SharePoint site and/or (b) that the configuration management process in place includes the requirements below:
- Enable unique identification and description of the SharePoint solution and components
- Enable the evolution of products and their components to be controlled and traced
- Enable identification and control of the means by which products will evolve in order to satisfy their requirements
- Record securely and maintain all the information required
- Provide validated, identical copies of products
To satisfy these fundamental requirements, the configuration management system should provide the following:
- Methods for unique identification and version control for all products and all components of a product
- Methods for receiving and acting on observations concerning a product and for recording and controlling changes arising
- Methods for keeping track of all items being produced or utilised by a project, including items inherited or sub-contracted
- Methods for defining the means by which a product may be build or re-built and which must include any special requirements after delivery or after project completion
- Methods for marking, storage and handling of all required media types
- Procedures for controlling replication and distribution of products
Configuration Management Applies to SharePoint
Configuration Management is mandatory for all SharePoint Delivery programs. You cannot have a controlled SharePoint environment without records concerning is makeup and traceability concerning changes made. Even from the perspective of a handover of a SharePoint solution, as a Delivery Management you cannot simply handover a SharePoint solution by stating “I’ve finished implementing SharePoint for you, off you go”. CM provides a structured system handover meaning everything that the delivery program can be audited on, everything that the delivery program has an asset of (and that includes all documentation, technical specifications, software assets etc.)
Configuration Management is needed for any deliverable of hardware or software or where there is a change to either of those in a production arena. Configuration Management applies to configured items that are used in the development of a SharePoint product but are not a deliverable in their own right. Typical configuration items include:
- SharePoint specification (design, topology, network connectivity)
- Test Plans
- Drawings (overall and detailed)
- SharePoint Software Assets, and if any additional development applied to SharePoint, any code, program listings, associated documentation
- Service or User ManualsOther items to which Configuration Management applies must be identified as part of any SharePoint solution delivery and subject to review.
The Delivery Manager Specifies the Configuration Management Policy
The Delivery Manager is responsible for creating a configuration policy and the techniques to be applied. If this policy deviates from that stated in the Configuration Management procedures, those deviations must be defined in the SharePoint 2010 Quality Plan.
Additional issues that also need to be recorded are:
- The designated configuration management authorities for the project
- The identity of the root document or source from which all configuration status records can be traced
- The Delivery Manager should appoint a configuration authority who will control the CM activities (SharePoint Solution Architect).
Configuration Management Glossary of Terms
| Configuration Item | An item selected for configuration management. Configuration Items are established on a hierarchical basis with one item comprising the complete product (hardware / software). This is then broken down into its lower level constituent items or parts, each with its own reference number |
| Configuration Baseline | A specification or product that has been reviewed and agreed on that therefore services as a basis for further development. A baseline can be modified only through formal change control processes. |
| Controlled Item | An items that is not identified as a Configured Item but still requires controlling in a formal manner |
| Configuration Control | The systematic evaluation, co-ordination, approval and dissemination of proposed changes and implementation of all approved changes in a Configured Item |
| Master Record Index | The index(es) to the master set of drawings, specifications which define the configuration item. This term is used generally to refer to a set of indexes that provides a record of the Configuration Items. |
Bring the SharePoint Item under Control as it Develops
The following diagram illustrates when a SharePoint item should be brought under change control (note – whilst it refers to SharePoint 2010, the process is agnostic of SharePoint version):
Check out my book 'Implementing and Managing SharePoint Projects 2010'
This section comes from my book, Implementing and Managing SharePoint 2010 Projects, which is a great read covering lots of service delivery topics to aid SharePoint programme delivery.
The diagram above shows the passage of a configurable item from its generation to the point where it comes under customer control through change control. Each of the vertical lines represents a formal stage in the development of the item. Once the internal review cycle is complete the item will be raised to version 1, or, if being updated, to the next appropriate version number and issued for external use. From that point on its status shall be recorded in the Configuration Baseline Index and any changes to the item must be introduced via formal configuration control procedures (see the below section Changes to Configured Item Must be Controlled). When the client takes delivery / control of the product, there will be a need for a formal Master Record Index to be generated for each Configuration Item.
Control the Item Prior to Configuration Management
Whilst a configuration item is being developed during the pre-configuration stage, the author is free to make whatever changes that may be necessary on a day to day basis. Understanding the development of the item is still important and significant changes should be recorded as part of the configuration item.
Historical information needs to be maintained for Configuration Management auditing purposes. In SharePoint, you could, as shown in the above diagram, construct a list with Version Control switched on utilizing Minor and Major Versions. Those allow you to enter comments as the item moves from draft to draft version until it becomes a configured item.
Bring the Configured Item under Configuration Management at the Right Time
As the development of the item stabilizes, the baseline standard can be declared and the item brought under configuration control. Each configuration item must be given a unique reference number. All configurable items must be regularly reviewed. The review record may initiate further changes to the item, causing the draft number to be raised. Maintaining all the comment copies of a technical document is not necessary, provided the record and / or minutes are maintained to provide the traceability of the review process
Establish a Configuration Baseline for Each Item
A configuration baseline index shall be formally maintained as a status and history record of the project’s configuration items. The index must include the hierarchy and inter relationships of the items.
At appropriate points in the project development and certainly when the product is ready for delivery, it is necessary to product an index of all the configuration Items. This index is often called the Master Record Index (MRI). For software products, a Build Definition which defines the software and computing content of the release must be prepared.
A Configuration Status Account Provides History
Configuration status accounting is a mechanism for providing records of the current status of all the projects configuration items. The configuration status records provide complete traceability of what has happened to the configuration to date. These records can be centralized into a SharePoint CM site. For example, you could have an item subject to version control and carrying metadata – a multi-choice column called Configuration Status, for example. This configuration status column could have values defining the configuration level of the item. This means that not only do you have traceable history but you can also identify when and who made alterations to the configuration status and if there were any comments made at the time they would also be available.
Changes to Configured Items must be Controlled
Once an item comes under configuration control, changes can only be introduced by means of a formal change control process. All items in a SharePoint production and SharePoint User Acceptance come under configuration management. The following example of a processing chain concerning SharePoint Delivery through Change Control is shown in the below diagram:
Check out my book 'Implementing and Managing SharePoint Projects 2010'
This section comes from my book, Implementing and Managing SharePoint 2010 Projects, which is a great read covering lots of service delivery topics to aid SharePoint programme delivery.
Summary
Every item concerning SharePoint running in a production environment is subject to configuration management; whose rules are bound by Platform Governance. You may wish to argue that Configuration Management is overkill; that there is far too much ‘process’ and it would hamper SharePoint delivery. My response is the following question:
How do you know who created what?
If you cannot answer what constitute SharePoint operations under change control you do not have an environment under control. You do not have an environment duly documented to show the purpose, premise and operation of your SharePoint environment.
Configuration Management manages and records and brings a logical change control process, so that anything that takes place to deliver a product has a history from the point it was designed to the point it was implemented. SharePoint configuration management defines processes that describe the following:
- Makeup of Infrastructure
- Software and Hardware Assets
- Modification
- Procurement and Delivery (for example, third party solutions).
- Tracking and AuditUnderstand the ComponentsItem Identifications
- The basic or lowest level of configuration items for SharePoint under which configuration management (CM) will apply is the software under which SharePoint operates. However, any feature that comes off that is an item under CM process. For example, the Initial design of a site if not under strict control does not need to come under formal configuration but you should use sound judgement and identify whether changes to the site in the future could impact on customer experience and satisfaction.
- Ensure that you know what makes up your SharePoint platform. Even before providing a SharePoint solution (even if it is the platform itself), and even before someone mentions – “hey what kind of solution do you want?” You need to document what makes up the SharePoint solution. Assuming that you have done that and have defined the specification, you then need to ensure you that the level of documentation is sufficient not just for you, but for anyone whose services you consume, and for those who would need that information as part of the CM process.
Delivering a SharePoint ‘Data at Rest’ Encryption Service
Compliance Importance
Service delivery includes the protection and the integrity of content created. Like security, compliance is cross platform, cross industry. It does not matter whether you are simply using SharePoint, or using multiple platforms to service content into SharePoint.
Compliance concerns:
- Monitoring, isolation, automated operations, secure network and encrypted data.
- Security best practice, and the customer controls.
- DPL, audit and retention, eDiscovery and Data spillage.
- Standards such as ISO 27001, FISMA, HIPAA BAA, EU Model Clauses, and the CSA.
Note – this article is geared to looking at SharePoint on-premise. Office 365 is pretty much covered on encryption technologies. There is a wealth of information concerning this and more the Microsoft Office 365 article on this link: Data Encryption Technologies in Office 365. Also, there is also a huge amount of information available in its Trust Centre. There is a specific section concerning compliance on this link: Continuous Compliance in Office 365
Encryption is a solution against Data Breaches
Data Breaches are not simply relegated to external infringement of data by those who should not have access. This is an ongoing problem, and regulators are ramping up audits and confirming standards to ensure companies are taking heed. Some data breaches can occur for any of the following reasons:
- Data copied and taken off premises
- Downloading information then emailing the data unprotected to external parties
- Saving content to a folder which is publicly available online
- Provisioning of production data in test or development systems
Protecting against data breaches therefore must consider the data at the location where it is saved. Encryption of the data is without doubt the highest level of protection the data can get to prevent that data being subject to a data breach. However, the human culture of how they handle security matters is also extremely important.
SharePoint Data Security
When data ends up in SharePoint, the content is stored in SQL (at rest), except in the case of RBS (Remote Blob Storage). The data in SQL is ‘unstructured’, meaning, that it is not ‘easy’ to simply dive in and set security on specific bits of data. The data is also ‘unknown’, meaning that it is not also ‘easy’ to identify what data relates to what area and in what context – and even if you could, securing that would be a difficult in the extreme.
SharePoint, ‘Out-Of-The-Box’, provides access controls only to protect the data based on the role of the user. These access controls include:
- Permissions access to the data
- Auditing controls, stamping of data, lock down.
However, there are data encryption components provided ‘Out of the Box’ for SharePoint. Data could be read in a number of ways (described below). And again, confusion reigns from people trying to get to grips with the options. Some people even confuse authentication with encryption. I have even heard a client state that surely provisioning SSL will provide encryption. That client had to be informed that SSL only secures the network connection to the link where the data can be accessed (that is, Data in Transit, NOT Data at Rest). It does not protect the data from being ‘read’ at its source. Anyone unsure of this should check out this article Do you need SSL?
Compounded is the challenge humans the culture they apply to security – it is not simply a ‘one hat fits all’. From people I have spoken to and worked with on this topic, it is generally stated that users are simply not taking enough security measures to protect the data. Yes, one could very easily apply role permissions to ensure that individuals cannot read, write, or even upload. Provision of auditing tools to alert individuals of unwanted access is possible. Locking down of data so that the data cannot be modified or downloaded is possible. However, those solutions is not on the same plain as the protection (encryption) of the data where it is stored. For example, if a disk holding data was subject to attack / access from those who should not be able to read the data at source, then surely that is an out of compliance and classed as security risk. Indeed, taking a SQL SharePoint content database off a disk, and then applying that content database into another web application in another farm is relatively easy. Even if that operation takes place unless under strict and controlled circumstances (note that in some cases a challenge to implement, especially when working with multiple technical teams like a separated team for SQL, Windows, SharePoint, etc.) the mere fact that the data is in a read-able form when transmitted could be still construed as a data compliance issue.
The solution is looking at the data within SQL; that requires ‘security hardening’ and encryption solve these challenges.
Implementing encryption for Data at Rest starring SQL
As pointed out, SharePoint data resides in SQL. That is the point where encryption should be brought into play. Microsoft recognised this way back with the implementation of SQL 2008 and provided two technologies to protect ‘data at rest’ meeting various compliance standards. Thankfully, the architecture is in place to provide, since SQL provides the ability to have the data encrypted, using the following technologies:
- EKM – Extensible Key Management
- TDE – Transparent Data Encryption
Details of these technologies are available here:
Understanding Transparent Data Encryption (TDE)
Switching on encryption is not just a ‘fire and forget’ action. A number of tasks must be completed beforehand in order to deliver the service:
- The environment must be modelled first; for example, identifying the number of users, size of documents, underlying infrastructure, specific technical roles and skill set.
- Disaster Recovery environment and enabled technologies. Check the infrastructure applied to the SharePoint farm concerning DR. Check whether RBS is in use which will impact on how encryption is to be applied – note that TDE does not apply to content in a file stream because that content is not encrypted in SQL so additional encryption methods would have to be applied.
- Key management – who is responsible for managing the key – is it the SharePoint team? The SQL team? The Security team?
- Advise your corporate security team including any stakeholders of the impact of encryption. There is a technical as well as business impact. The technical side is a degradation of overall performance. From investigations I’ve been advised this could be up to 2% overall. On the business side is an impact on support, particularly from SQL and Security, since they have an extra accountability to the management of the encryption. Note also, that you should test this thoroughly in a isolated test environment and against DR and run DR tests.
- Apply Encryption at Rest for SQL, and for this, TDE must be implemented. Remember, TDE is used to prevent the restoration or attachment of databases into another SQL instance. This means that a master key needs setup, the database requires configuration, and the encryption password (stored in the certificate) must be backed up. Then, all must be tested (i.e. backup, restore – which should fail – then restore again along with the key – which should work).
- Ensure connections to SQL are encrypted. This means protection from those attempting to use tools to get at the data. This means forcing encryption settings to enabled for the SQL server and applying the certificate.
- Prevent other machines accessing the SQL instance (i.e. attempting to connect a different farm, or a machine outside of the ‘allowed server authentication list’ to a SQL instance being protected), you would setup isolation rules by configuring the firewall on the relevant servers themselves.
Note – doing this by yourself in a company with multiple teams looking after the infrastructure is unwise. You should seek aid from your SQL teams, as well as advice from Server teams.
To get detailed information on how to technically deliver encryption for SQL as well as isolation, step by step, check out the excellent article on this link:
Securing SharePoint: Harden SQL Server in SharePoint Environments
Conclusion
A key aspect of Data Compliance is the protection of data. Companies use data compliance to protect data, provide policies, processes and systems, and this stretches to governments and individuals. This is cross platform, and cross technology.
In Sharepoint, in order to meet data compliancy challenges and provide solutions through service delivery, there must be understanding that there is encryption tools available to data where that data resides. Encryption is the keyword here, since through this article I have explained how data can be securely stored and protected from unwarranted access.
SQL provides encryption and key management tools so that the data becomes unreadable to anyone except those who should have access to that data, using key management to automatically convert data back to its original, readable form. There are additional opportunities available to harden the SQL platform so that there is isolation and authenticated access.
The implementation of encryption though, whilst relatively easy from a technical viewpoint, provides many challenges to overcome in implementation. Security awareness, and identifying shortfalls in the surrounding infrastructure is vital, along with the marrying up of the roadmap of SharePoint. Implementing future technologies down the line will have an impact on encryption, so ensuring that you continually review encryption usage and change management is necessary.
SharePoint Security and helping users become more aware
A key aspect of implementing SharePoint in an organisation is relevant to security of content. The success of SharePoint in an organisation is due not only to how comfortable users are with using their current technology with SharePoint, it is also down to ensuring that the users are comfortable knowing the data they manage on their SharePoint sites are secure…
Port, Pies and SharePoint Support
Merry Christmas Everyone!
As the seasonal period quickly approaches, the discussions concerning what happens to supporting SharePoint over the holiday either approaches, or has been covered, or even assumed. The Christmas period is of course where your SharePoint sponsors are more likely to show a little more concern than normal about how their SharePoint platforms are going to be monitored over the period.
So then, lets remind ourselves of the holiday period in question – basically, the days that will relate to anyone, is the week of Christmas starting from the 23rd through to the 28th. There are two days pretty much important to us guys in the UK over the seasonal period, especially in Scotland – Christmas Day and New Years day. Then there is Boxing day when it’s likely that you would be relaxing in front of the telly, or sledging, or skiing – using that day to wind down after the Christmas day madness. Then there’s the two days after boxing day, the 26th and the 27th, where relaxation, relief and playing with the various presents, and getting stuck in to food 🙂
So that means that over the period you are likely to do over those two days, probably a combination of one or more of the following not be in the Office, switch off the mobile, inform people you are not available?
So chances are, that on the days in question, you will be chilling out, and possibly even like me having a choice Mince pie, a Glass of port (or more – like Rum)…
But this is not about what you will be doing over those periods away from the office. It is about how you are going to support SharePoint, isn’t it?
First, let’s consider the available types of support:
- On Premise SharePoint Support / IT Support combined / Outsourced
- Off-Premise Office 365 Microsoft provisioned Support
- Third party product support
-
Throwing caution to the wind
My dad once said to me when I was a lot younger that in order for Santa Claus to know what present I would like, that I should write a letter, and throw it into the wind when it was blowing north, so that the letter would reach the north pole.
Of course, by doing that I eventually realized that the letter would not get there, unless my dad without me seeing ran like the clappers to retrieve the letter once I threw it out of the window.
Clearly, I was throwing caution to the wind, assuming things would happen – luckily for me, most of the times when I did throw that letter, things would work out – but only because there was a contingency – my dad, running like the clappers.
This relates in a way to the lack of responsibility those charged with SharePoint management judge the level of the support needed to ensure the availability of SharePoint services over an important period, like Christmas! There is not enough preparation carried out preceding the Christmas period by some organizations, to ensure that there is adequate coverage of SharePoint support. In some organizations, instead, there is a laissez faire approach, by simply throwing caution to the wind. Or, worse still, their IT support departments will not think to include SharePoint as system that should be monitored, and instead not including those with basic knowledge of SharePoint on the support desk.
Take this real scenario which happened a while back. Fictional company used though, however, if their now SharePoint support individuals are reading this article, they will definitely remember this event!
Five days leading up to Christmas day. Fabrikam has an IT Support department, and a number of individuals who are tasked solely with looking after SharePoint, called ‘SharePoint Admins’. These SharePoint Admins look after the platform solely, there are no monitoring systems in place except for the server monitoring systems (alarm bells ringing already – no pun intended). A member of IT Support asks what the SharePoint Administrators will be doing on Christmas day.
“We won’t be around, that’s for sure…” … “SharePoint looks after itself” – pipped the SharePoint Administrators. “We will just take a peek at midday to make sure all is well”.
IT Support reports this discussion to the IT Support Manager. The IT Support Manager waves his arm saying ‘that’s not a problem, we have IT Support people on the desk who know a little of SharePoint, nothing can really go wrong’.
Over the next 4 days, no more is mentioned as the company ‘winds down’. On the 23rd of December, the CEO puts a Christmas message to the communication team who then puts the message in an announcement list on the Fabrikam SharePoint Extranet.
Christmas Day. At 9.30am that day, the CEO of the company, with his family in the Seychelles, decides to show a friend the message that was put on the SharePoint Portal on the 23rd. When attempting to display the announcement, the web page displays an error. Concerned, he raises a call into IT Support. IT Support try to get hold of the SharePoint Administrator, who has switched off his mobile because he is at the top of the hill where he lives, sledging. The CEO asks whether there is anyone else who can help, but IT Support have no knowledge of anyone and neither do they have any other contact number for the SharePoint Administrator.
The SharePoint Administrator calls in at midday to find chaos. The CEO is fuming because he has no idea whether anyone saw the announcement, and even if they tried saw the error which was embarrassing. IT Support have stated to the CEO that they do not know how to fix the problem, which is embarrassing. And, guess what, the SharePoint Administrator, who fixes the issue in minutes finds that the rest of his day is spent building confidence with the CEO and IT Support – he is embarrassed.
That SharePoint Admin threw caution to the wind. And in doing so, assumed the following:
1: No one will care whether SharePoint is available or not
2: The SharePoint Admins does not care whether SharePoint is available or not
3: The SharePoint Admins assumed that the problem will ‘fix itself’
4: The SharePoint Admins assumed that they will eventually be told or will find out themselves that there is a problem, and that no one will moan when they do, or how long it takes to correct the problem.
5: That if a problem occurs where SharePoint is not available that there is no financial impact or otherwise
-
Preparing for Christmas
You must prepare your SharePoint environment to be supported over the Christmas period. This is just like preparing for Christmas itself. Doing things like putting up a Christmas tree, carefully putting up decorations without falling off ladders, writing Christmas cards, posting them, wrapping presents (carefully) without getting the sellotape stuck on the wrong part of the wrapping paper and making a mess. You put effort into doing all of that because you want to make others comfortable and yourself prepared. Therefore, there is no difference when it comes to SharePoint support.
There are a nine things you could put in place, so that you can ensure that SharePoint is supported over the Christmas period:
- Make it clear the days when there will be SharePoint cover over the period. When on holiday, for example, ensure that there are phone contacts and that is communicated to IT Support and your SharePoint sponsor.
- Ensure that the contact details have a backup. One number is not enough. Consider adding on the home phone number or the number of the place you will be staying / visiting on the key days. Reasons for this could be bad mobile coverage, or you could be travelling
- Ensure that there is a remote method of you accessing the SharePoint environment. Most organisations using on-premise SharePoint have a method whereby individuals can log in over the Internet using say a Citrix / VPN / Xen Desktop etc. connection.
- Ensure that a member of the IT Support team is aware of any resolutions that can be used for ‘possible issues’. For example, one issue could be that in order to quickly reset an application pool for a SharePoint site to go into IIS on a relevant server, etc.
- Ensure that there is a list of the infrastructure, and details of any specific login information.
- Based on point (3) above, try to log into the SharePoint environment at least once a day to quickly check the status of the environment.
- Ensure that relevant third party information concerning their levels of support is listed and the details made known to IT Support.
- Provision monitoring systems for IT support which includes the status of key services to the SharePoint platform (on-premise).
- Provision monitoring services which includes the status of services for Office 365 Tenants
- Make it clear the days when there will be SharePoint cover over the period. When on holiday, for example, ensure that there are phone contacts and that is communicated to IT Support and your SharePoint sponsor.
-
On-Premise and Off-Premise Support are that different
At a very basic level, the provision of support for SharePoint over a Christmas could be divided two segments – the SharePoint ‘supporter’ – the associated services ‘supporter’.
For on-premise SharePoint, the levels of support are:
1: The SharePoint ‘supporter’. The person(s) responsible for managing the products provided in SharePoint services.
2: The Associated services ‘supporter’. The person(s) responsible for providing support for the infrastructure and associated services.
The interesting aspect of Off-Premise (e.g. Office 365) Support is that there is in effect, also two levels:
1: The SharePoint ‘supporter’. The person(s) responsible for managing the products provided in the Office 365 tenant – e.g. SharePoint Team Sites and relevant products in those sites.
2: The Associated services ‘supporter’. The person(s) responsible for providing support for the Office 365 tenant.
Both of these, on-premise and Office 365 have monitoring tools. Both have the priorities and service delivery of support defined to SLAs, which is communicated to the person responsible for managing the products provided. This information is then cascaded in an understandable form to the client.
There is a huge amount of monitoring tools available to on-premise SharePoint support (default and third party provisioned), which I will not go into (and there are a huge number of articles that describe them). SharePoint Online now has a good amount of services and tools for monitoring. The Office 365 Admin app for which allows those responsible for supporting Office 365 to connect to their organization’s Office 365 service status on the go. The app enables them to view service health information and maintenance status updates from their mobile device. You can also filter information by service subscriptions and configure app data refresh intervals.
To get the app, go here:
https://www.microsoft.com/en-us/store/apps/office-365-admin/9wzdncrdtbmj
Office 365 also has the Office Message Centre. The Message Centre is located in the Microsoft Online Portal. The Message Centre is the central hub for communicating with you about Office 365. And in there you will find the topics including those in the Admin Task Newsletter, messages on new feature releases, and other important information. The Office Message Centre also links with the Office365 Admin app, so you can have messages concerning the state of services sent direct to your mobile device.
More information about the Office Message Centre: http://blogs.office.com/b/office365tech/default.aspx
There are also methods of logging transactional data through code. Microsoft is releasing the Office 365 Management Activity API which allows visibility of all user and admin transactions within Office365 covering activity logs. These logs would include information like tenant, service, action, object, user location, IP Address and more.
More information about the Office 365 Management Activity API: https://blogs.office.com/2015/04/21/announcing-the-new-office-365-management-activity-api-for-security-and-compliance-monitoring/
Additionally, for those who have access to Microsoft System Centre Operations Manager, there are of course services available to monitor SharePoint on-premise, and to monitor Office 365. For those who have not done this before, or need to get further information, I wrote a blog ‘Office 365 Monitoring using System Centre Operations Manager’ located here:
-
Conclusion
I hope by reading this article you have understood the importance of providing adequate and understandable SharePoint support over the Christmas period. The ability for you as a SharePoint ‘supporter’ to be forewarned of issues so that at the very least clients can be informed is vital. For on-premise, the ability to be contacted, or the ability provided to IT support to be able to deal with common issues, provides a service which in the eyes of the SharePoint sponsor is ‘good’. So I do hope that you are able to take points from this article and apply them to your SharePoint support cover proposals….
I’d like to finish up by wishing you and yours a wonderful holiday season!
What is Microsoft Office System Service Delivery?
This quick article is going to explain the basis of Microsoft Office Systems Service Delivery (centered a little on SharePoint, ahem) and why it is so important to have in your organization. Also, check out my book (on this link) which covers a lot more on this topic.
7 ways of identifying a Super-Duper SharePoint Support Person
Look through the job advertisements for any online job site or computer journal for an indicator of what most organizations seems to regard as a key attribute of SharePoint support staff. The need, desire, and hunt for technical knowledge seems to jump out at you from the pages. I have seen advertisements for SharePoint members that reads like a list of SharePoint third party products and affiliated integrated Microsoft products. The closest match of the candidate to that list is the first step towards being interviewed.
Indeed, even Microsoft seems to lay great store by this. Microsoft provides a range of qualifications which can be pursued. These qualifications become a marketable commodity; a SharePoint support person whose technical competence is measured by a Microsoft endorsed certificate commands a higher salary and is in greater demand than one whose ability is not so endorsed. In fact, an entire market is already in operational to provide Microsoft recognised training courses, with a range of quality, pace and price to suit most pockets.
This makes me suspicious about the training courses just mentioned. Of course, they create some kind of measure of a support person’s technical knowledge, and that is a useful aid for an organisation seeking to employ a proven SharePoint support individual. However, a Microsoft certificate is rarely a true indicator of real knowledge. It is an indicator of the individual to get through the relevant training programme. Additionally, the knowledge learnt is transient. In six months, Microsoft will probably have another version of the relevant product. In two years, the product may well look and operate very differently to when the original course was taken. Nevertheless, the certificate will still be valid even if what it is being measured against is no longer valid.
With certification programmes, SharePoint software producing companies have nothing to lose, and so very much to gain. They can sell training courses, appoint recognised trainers. They can ride on the back of the hype the qualification brings in its wake. They can reduce their support burden by encouraging customers to pay to be able to do their own support.
Even so, organizations generally face issues in finding the right level of technical support for their products. SharePoint could be considered to be different in the mix of Microsoft products because SharePoint is a platform. That means more interaction from support level to the business, not just solving technical issues. The support the business is after from a SharePoint perspective goes beyond into the land of solving business challenges. Questions like the following are normal directed to SharePoint support:
- I need to provide a method of people to collaborate in a single location
- I need to store and manage my content
- I have trouble understanding how to do something
- Can you fix the issue I have
But what exactly makes up a great SharePoint support person. Is it simply technical? Definitely not. This article attempts to answer the fundamental questions concerning how to determine what constitutes a ‘super-duper’ SharePoint support person. To do that, I am going to break the article into seven points. Each point relates to an attribute that a SharePoint support member should have. I have also tried to keep this article version agnostic. I will not be going into any particular version of SharePoint, or product.
So, let’s kick off with a basic statement. SharePoint Service Delivery is about capability. The solution being provided to users must be capable of fulfilling their requirements. At the same time, the relevant solution needs to be supported by individuals who will be able to provide help and aid to those using the relevant solution. Therefore, it goes without saying that the skills of those who need to support users’ needs to go beyond just technical aspects of the solution being provided.
A 2013 Gartner report called “ITs Aspirations Require Addressing Current Realities” described a disturbing trend:
“CIOs have consistently reported a lack of skills as the single biggest factor limiting IT’s successes”.
The report goes on to say:
“One in four CIOs believe that the IT labor market is ‘working’.”
That can mean at least two things. First, that those being recruited to provide support are not skilled enough. Secondly, that the recruitment process in identifying the right person to provide support is not working. And, the key to organisations having the right people is based on their capability to provide support services.
In addition, the constantly changing face of technology as it expands and morphs will lead people to become continuously productive as explained in this article:
http://www.businessinsider.com/next-generation-of-tools-make-us-constantly-productive-2013-9
This will therefore impact on how support is provided, particularly for those products which are in the centre of collaborative tools. In order for SharePoint to be capable of providing a support service to the user base, the user base needs to be adequately supported. The environment in which SharePoint can be employed, for example, on-premise in an organization, off-premise through Office 365, and on any mobile device, being smartphone, tablet, etc. means that the environments in which SharePoint support could be employed is also varied:
- Telephone Call Centres. SharePoint support is provided in an environment where the call is likely to be solved over the telephone, or escalated to another tier in the support organization.
- SharePoint Support provided by the parent organization. Typically for on-premise, though for a hybrid support is provided by the same SharePoint Support provision.
- It Support provided by third party. An third party SharePoint support provision is on-contract to an organization to provide a level of support.
- Through an Internet Service Provider. The Internet Service Provider provides the platform and also the support required for users to collaborate within the platform provided. Generally, those users then provide, or are automatically ‘set’, to have administrators who provide a first level of support.
Irrespective of the environment (which may in fact be a combination of the above), SharePoint support persons require particular attributes to ensure that a SharePoint service can be effectively provided.
1: They can do multiple roles
As a member of SharePoint Support, part of the job is to support end users and troubleshoot various types of tasks. However, their tasks involve much more than simply resolving a problem. They must be able to listen to a user, gather information from that user, diagnose and resolve the problem (or escalate the problem to a senior technician or system administrator), and properly document the resolution of the problem in the manner dictated by company policy.
A SharePoint Support team member is expected to fulfil a number of roles in the support environment. A good SharePoint Support team member must possess both technical skills and non-technical skills, such as interpersonal skills that are necessary for building rapport with the user to better troubleshoot and resolve the user issues. Some of the primary roles of the SharePoint Support team member include:
- A public face for the company – in most cases, the only human point of contact
- A knowledgeable resource who is familiar with the product and able to perform hardware and software installation tasks and system monitoring and maintenance
- A source of information, because even if you do not know the answer, you know where to get the answer or to redirect the end user
- An effective communicator, because customers are not calling to be sociable – many of them are distressed or upset, and you will need to manage the interaction effectively
- A good trouble-shooter who is able to quickly diagnose the issue by performing specific tasks
2: They get back to basics
As stated in the section “1: Carry multiple roles”, a SharePoint support persons job is to provide end user support in a At a high level, the SharePoint support person should be prepared to perform the following tasks:
- Perform general troubleshooting of SharePoint and integrated applications and solutions that will be used with SharePoint
- Provide customer service, including listening to the customer, defining and solving the problem, and educating the user on how to avoid the problem in the future.
- Install, configure, and upgrade packages and solutions.
- Monitor and maintain the SharePoint platform
- Document calls and close them or escalate them as required by company policy and time limits set by Service Level Agreements (SLAs).
Note that whilst the above appear to be technical, the key is to support the customer. The mission statement simply means ‘Quickly Resolve the Problem’:
- If a SharePoint solution is unavailable, service restoration is the first priority
- Incidents, problems and known errors must be clearly distinguishable from one another
- Service levels are governed by an SLA
- Customer interact with the SharePoint support for the resolution of problems
- Electronic self-help does not make human representatives obsolete
Within IT Support, there would generally be a support model. This covers, problem, service management and IT helpdesk support. Without going into any detail concerning how the IT Support model operates, the key is to understand that it is the duty of any member of SharePoint support is to provide a service understood by their customer. Therefore, for every issue to be resolved SharePoint support persons must get back to basics with every customer (and non-customer).
Here is a scenario:
Fabrikam is a coffee research company with offices in London and New York. They have a SharePoint installation which is supported by a SharePoint dedicated team. Fabrikam, at the start of setting up the SharePoint support model was aware of the time difference, and elected to have SharePoint support provisions in both time zones, but managed by IT Support. All calls would be logged centrally so that all IT Support teams and SharePoint support teams could see the work being carried out in New York and London.
The above scenario is a simple reminder that in order to have adequate support you need to understand the working time zones of the users. There is little point of proving that all your users are supported if your SharePoint support team is asleep when customers using your SharePoint provision need support on the other side of the planet. However, the above example is general. Let’s take the example back to specifically why it is important that each member of your SharePoint support team takes things back to basics. I have a large lawn to mow at my house. I use a lawnmower provided by a company in my nearest town. That lawnmower always breaks down, and generally, it’s my fault. Either I hit a stone, try to cut grass that’s far too long that plugs up the grass scoop, and more besides. I am getting better at working with that lawnmower, and that’s because the guys who supplied the lawnmower, who seem to fix things faster than you can say ‘Jack Robertson’, will always pass on a good bit of information when it is fixed, will always ask ‘what was you doing before the problem started’, and will always give demonstrations of using parts of the lawnmower which I didn’t think existed.
So, why is that important? Well, imagine that you are new to SharePoint. You need to upload a document, but cannot remember how to do that. You call your SharePoint support member. The SharePoint support member responds with something like this:
‘You dolt. It is easy to upload that file. Just click the New Document link. Why bother me with that’ – mutter… mutter…
In terms of even a relationship with SharePoint support that response guarantees service delivery ‘epic fail’.
Good SharePoint support persons get back to basics. They ask what the user was trying to do. They give step by step information on how to upload documents. They inform the user that there are places where the user can go to get more information. They state alternatives to using the New Document link in a document library. They empathise with the user (more on that later).
This does not mean that when the user calls SharePoint support that they have to wait while SharePoint support scrolls through a list of possible solutions or navigates around a decision tree, especially if the payoff does not appear to come quickly.
The reason why it is so important to go back to basics, is simply not because you want to teach SharePoint 101 basic stuff to SharePoint people. It is because the comfort factor of those calling SharePoint support increases. If that increases, they become more confident. If they become more confident, they learn, and want to learn. If this is not done, you will start seeing users ‘switch off’ from using SharePoint support. Or even worse, they will inform other users not to contact SharePoint support and will use other methods of finding out how to do things. Or even worse than that, they will stop using SharePoint all together!
3: They turn customers into enthusiastic customers
Imagine you set up a SharePoint support service. You may find that many customer simply will not call that support service. Some will not call because they do not know about SharePoint support. Some may even complain about SharePoint when it does not do what they expect it to do, but they will not call because of their experiences with any other customer service, whether it is a airline, telephone company, car park fining, cinema ticket purchasing, etc.
A successful SharePoint support service has enthusiastic customers. There are so many ways in which SharePoint support team members can make customers enthusiastic customers. First, let me describe what it is that defines an enthusiastic customer.
Humans are forever needing to find easier ways to get things done. They love shortcuts. This is because at work humans are doing multiple things and making multiple decisions. And because they are doing multiple things, when they are shown how to increase the speed (and productivity) of certain things in their daily tasks, they will become more enthusiastic. This goes with any software application, or any business process they work in. The key however, is to not get technical, don’t use jargon. Speak in their language. Here is a scenario.
Scenario: Telling something to a customer that helps them associated to the problem at hand. User tries Search for the first time in SharePoint and whilst they understand how to use the interface, you ask how they carry out searches without using SharePoint. Customer states that they have used the Explorer to search for files using Windows 7. You state that by using the search option “Search in Windows Explorer” in Enterprise Search that the user is able to ‘connect’ Windows Explorer Search to SharePoint search.
The result is a customer who has learned something new, and passes this onto other customers.
4: They are prepared to take the blame
Scenario: Customer calls into SharePoint support stating that they were working on a document which they had ‘checked-out’ from SharePoint, then something happened on their computer forcing the application to crash, and now they could not re-open the document because it was already checked out. The customer tried various ways of attempting to open the document, but had given up and called SharePoint support. By the time they did, they were angry, frustrated, and even more frustrated when they found that they had to wait for over an hour before anyone called back.
The point here is that first SharePoint support takes the blame. Irrespective of the problem, whether the user is at fault, whether SharePoint is at fault, the key is not to identify who or what is at fault in the first instance. The key is to get the customer to calm down, and to understand that you are the face of SharePoint and that you will resolve the issue one way or another.
To relate to this, another scenario is where a customer, in a restaurant, states that the service provided has not been to their approval. The restaurant manager, instead of apologising and stating they will seek to address the issue, says the customer is wrong to state the service is at fault, and instead states that the customer should not have come to their restaurant in the first place. Clearly this is the wrong move, because the customer can then easily state to others that the service was bad and no one took any attention to sort out the problem.
5: They are prepared to say the things they don’t want to say
When someone complains, its easy to get caught up emotionally in the situation. This is particularly when the very thing you are supporting is the thing that the customer is complaining about.
Scenario. A customer calls stating that their document library displays an error every time they attempt to upload a document. The customer is quite frustrated and says that SharePoint is “rubbish”.
As a SharePoint support individual does not immediately become furious and state ‘How dare you say that?! I have never had a complaint from anyone else!’. Instead, they say ‘That’s terrible, please tell me what happened so I can make sure it never happens again’.
6: They create a career path
SharePoint support individuals will require technical abilities; however, that does not mean they come from a technical background. Organisations choosing SharePoint support individuals would be looking for the appropriate personal skills to deal with the users. That is because the users come first.
Training is another area to consider. Check out this article here: https://serviceautomation.online/articles-2/training/
There is something that I think all SharePoint support persons should be aware of. And it is a certification called MCDST. MCDST stands for Microsoft Certified Desktop Support Technician. I did this when I was running a IT Support department, and needed to ensure that all my technicians did that course and the exam. I also did the same course and exam.
For more information on MCDST, check out this link:
http://www.microsoft.com/es-es/learning/certification/mcdst.aspx#tab3
The reason why I did the course was twofold. Firstly, to understand the issues concerned with providing support for the current operating system. Secondly, to understand the implications of providing a service to end-users. And do not be deterred by the fact that the course covers operating systems. A key element of the course is understanding customer service and what it means to be in support.
7: They put themselves in the customers shoes
SharePoint support people understand their user expectation. This ‘expectation’ is rational, reviewable and realistic. Rational because support can understand how the user uses SharePoint, and therefore, is able to estimate the needs of their users with a degree of accuracy. For example, if the usage patterns of SharePoint appear to be heavy on a Thursday, but Friday is quiet – but Monday is difficult because that’s is when all the queries come in regarding any issues on Thursday, then SharePoint support can glean that carrying out maintenance on a Thursday, and testing on a Friday is best.
Conclusion
Relentless pursuit of technical acclaim distracts so much from the attributes we really want in our SharePoint support staff. If SharePoint support individuals only ever dealt with SharePoint technical issues and the servers SharePoint runs on, then technical ability is all we could ever reasonably ask of them. But they do not – they deal with people. This is particularly in the wake of support being provided through Office 365, where there is far less emphasis on technical ability on working with the SharePoint server side, but an increased awareness required on integrated products like Office, Exchange, Lync. Irrespective of the knowledge required to provide support, SharePoint support must be dedicated to maintaining continued, hour by hour productivity through user support. Therefore, what is needed is people and methods that increase or maintain user productivity. User productivity is not just an “I’ve got a bug in this SharePoint site” issue. It is a “Help me to know how I go about producing the output I need using SharePoint” issue. The first query requires technical ability. The second query requires technical knowledge coupled with an ability to convey that knowledge in terms the user can understand and believe in.
Therefore, to back up the 7 ways of identifying a super-duper SharePoint support person, there are the 7 attributes as follows:
- Patience – to be able to listen to a user describe a situation
- Thoroughness – to give the user confidence in their ability to solve the problem and to ensure that the job is done
- Enthusiasm – to enjoy the job and stay motivated
- Responsibility and Empathy – to be able to take on the burden of a task, and to be able to put oneself in the users position
- Technical knowledge – to have acquired the sort of knowledge the job requires
- Communicative ability – to be able to use language well enough to convey confidence
- Works well under pressure – to be able to remain positive
Value Management in SharePoint – Part 1 of 3
This article, split into three blogs, goes into detail on describing Managing Value for SharePoint, and the basis of the two key tools to Managing Value. To help you understand the concepts, I will be drawing on real life projects and showing how using the techniques described was able to determine the best solution.
Creating a Repeatable SharePoint Solution Delivery Process
This is the second part of the article concerning the delivery of SharePoint solutions. I will start by recapping on why I have produced these set of free articles, which will combine into an e-Book soon, check out this article. In essence, a successful solution delivery process encapsulates a design, creation, provision and support framework – that’s what makes up a SharePoint solution.
As stated in the first article, I am not designing a new process, rather, giving ideas surrounding theory, and actions for the reader to use.
The first article in the series, first looked into the understanding of creating a Usable SharePoint solution. A usable SharePoint solution takes into consideration the service standards applicable like design, development, commonality, consistency, tools and cross platform standards that can be applied when working with SharePoint. In learning the standards relating to usability, repeatability, supportability and extensibility you will be able to continually provision solutions easily, slicker and also help the client learn how to manage the solution once handed over.
A danger in writing these kind of articles is that the reader may be fooled into assuming that this is a business article, and somehow, not related to anything technical in SharePoint. In fact, service delivery is combination of the two – known as Systems Analysis which has been around as long as software has!
This is the second article in the series, concentrating on the key aspect of providing a sustainable solution – repeatability. In essence, this is the use of common processes, components, and products to build SharePoint solutions; continually – meaning using a repeatable method. Before thinking ‘this isn’t for me’ – wrong. As a SharePoint worker, you will be using a ‘repeatable’ process when even the simplest of SharePoint site solutions. For example, a document template re-use is defined as using a repeatable process. A web service that provides solutions such as say copying files from one place to another can be set to carry out the same process on another source and destination with minor customisation. Even a SharePoint site carrying a common structure can be easily created using a template, such as a Team Site Template. Apps are ‘repeatable’. Other examples could include workflows which are re-purposed, like Approval workflows.
The challenge is that most people, faced with constructing a SharePoint solution using components do not understand the principle of re-use which is a key aspect of a repeatable SharePoint solution delivery process. They may understand that something such as a template can be used again and again of course; however, they do not understand why a process ensuring why and when that a re-use management process can be applied; from the lowest component, to sites, site collections, web applications or farms. Even the provision of an Office365 tenant to a client is defined as a repeatable process. If there is no understanding, even a laissez faire approach, no standard or structure applied. And, as time marches on, as components morph, change and multiply, the potential for chaos ensues, where people simply have no idea what component should be used for what solution – instead, a patchwork of ‘guessing’ takes place!
Time I think to put a spin on helping you understand the principles of a ‘repeatable’ SharePoint solution. Again, this is a really challenging article to write, but an enjoyable one as well (like all my articles!).
First, time to get back to basics. Am going to start this section with a strange analogy – IKEA tables.
I went to IKEA Edinburgh last week looking for tables. My partner wanted some new tables to brighten up the conservatory, the kitchen and the cinema room. Now, browsing around IKEA for tables (well in fact anything in IKEA as I am not a great shopper) can be a bit of an experience, and sometimes, an annoyance. Trying the find the right colour, size took a huge wedge of the day to find what would look right.
So, in the end after hunting for tables in IKEA, we decided on three tables, put them into the horsebox and drove back home with them. Once home, I spent the following day putting the tables together. The first attempt at building a table was a nightmare. Yes, the instructions are easy to follow, but unfortunately I am not that great in following IKEA instructions; I dove in blindly with the screwdriver – then once I started getting things wrong, I went to the manual. It took me over 3 hours to build the table. Finally, I managed to put the first table together. Then, onto the second table. This was easier to put together, simply because I remembered all the wrong things I did about the first, and because I followed the manual :). The third was such a blur of activity – I simply didn’t need the manual, and I placed all the components in the order of building – the time taken to build was a fraction of the time to build the first.
Of course, stating that building tables is not a great and wonderful idea of delivering SharePoint solutions using repeatable exercises. But it is a great analogy because of two key reasons:
- All components fit together because the form an object
- A manual is there to guide you through the process
That means this two simple reasons can easily be applied to SharePoint to ensure a repeatable process. Surely it is easier to put a SharePoint site solution together if there are common components that can be reused at will? Surely, if there is a documented process that aids the creation of the SharePoint solution which utilises those common components, then that defines a repeatable method of creating those solutions. However, the concepts I have mentioned are unfortunately not carried out, or is a challenge to understand how to put them in place – and this is because the capabilities that describe how a SharePoint solution can be made ‘efficient’, through its delivery process is not at hand. I am going to attempt to address that, by describing the key capabilities that make the SharePoint solution efficient in terms of its development, deployment and maintenance.
The capabilities that you should consider, which in my view help you create a SharePoint solution (requiring the roles of Systems Analysis, Development, Architecture and Administration) and by definition can help build a ‘repeatable’ framework are:
- Create Service Blocks. Service blocks are a common set of high level components that can be reused. Examples of these are pre-configured Apps (site, repository, third party products and integrated services, workflow templates) which can be combined build SharePoint solutions. A great example of this are workflow templates that can be constructed by the fabric ‘or snippets’ from other workflow templates (Nintex provides a great way of doing this).
- Set a Common Schema. Creating a common format that can be applied to multiple solutions. Examples include branded custom pages, format of the quick launch bar, top line bar, enterprise taxonomy, navigation, etc. House the combined solution designs in a central location armed with keywords and categories to identify them.
- Discover and build the skills necessary. Creating a common set of training and guidance material for the solution that allows the user-base to learn the product, explore and use the relevant possibilities that are available.
- Ensure products can be Self-Provisioned. Users are empowered if the solutions they have constructed can be re-used to solve likewise problems for themselves and others. This aids the productivity of the individual, their peers and enhances the ability of support.
- Build Enterprise Policies. The creation, re-use and management of policies which will aid in the adoption, design, structure, implementation and deployment of the solution.
- Factor in Deployment Management. Drives the configuration management process whereby a SharePoint solution can get from idea to Test to UAT (User Acceptance Test) to Production. Aids the version control management of the solution in terms of how the solution can be updated and upgraded. Aids the document and data control process so that the solution can be adequately documented.
Service Delivery
Service delivery of the relevant solution needs to be efficient. This means being understood and managed by the stakeholders, since they are responsible for managing / devolving the management of the solution going forward.
For Service Delivery to be efficient, the solution delivery mechanism needs to be carried out in a sequenced and logical approach that the customer will understand and be part of. For example, if SharePoint is going to be employed in an organisation, the client needs to understand the part that SharePoint is going to play. This means understanding the information framework, and applying that, including controls for managing and locating that information. The fact that SharePoint is going to be used is irrelevant at that stage, since through the evaluation of the information flow in the organisation, the tools being used, the culture of the organization, amongst other key issues like control, security will influence the platform being employed.
So, a service delivery mechanism which encapsulates vision, decision, design, build, support, sustain, control needs to be defined first. A key outcome of creating a service delivery mechanism provides the stakeholder with the knowledge and comfort that an understood process (which they will manage) is clear and can be adhered to.
This means providing a number of service blocks that can be provided whenever releasing a SharePoint service. Examples of this are:
- Maintaining and managing a list of owners that also concerns who the owners are, the key stakeholders and users.
- Maintaining and managing a list of the key resources used both SharePoint oriented and people who will be using the solution
Efficient Service Deployment
There is confusion on the terminology surrounding the term ‘Service Deployment’. It seems that it is a technological term, and therefore, something related to getting some software from somewhere and installing it. I have witnessed situations where someone says ‘We are going to deploy the software service by following the installation process given in the manual’. In other words, download the product from somewhere and follow the automated installation process by clicking ‘Setup.exe’….
No.
Service Deployment is the process under which the SharePoint solution is deployed from a full implementation perspective and involves all resources necessary for that to take place. That means including people. That is the first simple rule. Keep the users involved.
Example. An app has been sanctioned to be deployed to a SharePoint online team site. The procedure that was followed to get the product sanctioned is a tried and tested method of user requirements, testing, user acceptance.
Efficient Service Deployment is part of a Software Delivery Process. A process by which the deployment of the solution is simply part of its lifecycle. That lifecycle includes the design, build, maintenance, support and any other aspect that defines the solution.
Henceforth, knowing what makes up the SharePoint solution is vital since that naturally produces the information required to ensure that the solution can be deployed. There are a number of documents which should be created:
- Hardware Components
- Software
- Installation Guide
- Related Productions
- UAT Provisioning
- Release Notes
Capability
Because the people must be capable in using the delivered SharePoint solution. Therefore, the solution must be capable in enabling and enhancing business productivity, knowledge, and solving information and management collaboration challenges.
So, in order to repeat the process of creating successful SharePoint solutions, the capability (structure, roles) of the support service team responsible for designing, crafting and, deploying and most likely supporting the solution must be repeatable from solution to solution.
This means that:
- SharePoint support services must be capable of supporting the delivered solution in line with customer expectations
- SharePoint delivery teams must be capable on delivering on the promises that were made about time and quality
- Any relevant SharePoint support services must be capable of standing over any key performance indicators or service level agreements.
Scalability
Scenario: You are going to deliver a SharePoint platform to a client. You gather their information requirements and process. You provision a ‘Proof of Concept’ SharePoint platform open to key stakeholders to showcase, demo, and gather further requirements. The client wants SharePoint. From there, you provision a UAT (User Acceptance Test) environment which maps to their requirements in terms of infrastructure, availability, scalability, extensibility, support. You then open that up to key stakeholders. Workshops ensue. The client still wants SharePoint, the UAT environment provided appears to meet functional and system requirements. You then provision a Production environment which matches the infrastructure provided at UAT level, and then deploy SharePoint services to the client as prescribed in UAT.
The above is a simplistic approach concerning the delivery of SharePoint to a client, following a design, build, deploy process. A repeatable SharePoint Service Delivery mechanism focusing on implementation.
However, the point being made about the scenario given about is a word which encompasses the delivery – future-proofing. ‘Future-proofing’, means that the solution being provided will not only meet the client requirements at the point of inception, but can also in the future because it can be scaled, and therefore will continue to meet changing requirements.
Scaling a SharePoint platform and any relevant solutions is not a single event exercise. Any alteration, addition or deletion to the solutions provided within the SharePoint platform requires a review to determine the impact on the scalability of SharePoint. For example, take the addition of a third party app to SharePoint, which becomes important, an app which the users cannot do without. The impact to the scalability of SharePoint comes into question if, for example, that app cannot itself scale to the next ‘hotfix’ of SharePoint, let alone the next version of SharePoint!
Actions
A lifecycle of delivering SharePoint solution needs to be based on being repeatable. Reasons for doing this have been stressed in this section, but to summarise:
- Stakeholder map per solution. Carrying analysis on the gathered maps will show connections between the common components being used across multiple solutions and also the key individuals helping to create a focal / champion group.
- Efficient Service Deployment. Due to re-use, there will be reduced requirements to bring in key resources build likewise solutions and components leading to reduced cost and management issues.
- Efficient Maintenance. Updates to repeated solutions can be applied generically, change management is easier to define, business policies and rules related to the solutions are easier to enforce and get buy-in.
- Capability. Users and Support gain knowledge and maintain that knowledge more readily than disparate solutions non repeated solutions.
- Scalability. Easier to plan, coordinate and carry out configuration management processes on repeated solutions.
In the Scalability section above, I gave a simple scenario based on deployment of SharePoint and boiled this into a repeatable solution exercise. That’s not the only scenario that uses Repeatable as a method to service deliver SharePoint solutions. SharePoint provides virtually all the components and tools that allows components to be configured, connected and scaled. SharePoint provides the ability for modules of functionality, developed internally or externally to the organization and contained in Apps. Apps that can be re-deployed, and further enhanced based on changing needs of the client, and can be deployed centrally from a bank of other Apps. For example, a simple document library App may alter need the ability to be connected to a third party tool, or may require further enhancement concerning views and sort, or may be required to lookup information from another repository. When completed, the entire configuration of the document library can be transformed into an ‘App’ which can then be redeployed elsewhere without having to re-develop from scratch. Other Apps include Site Apps, and Third Party Apps.
Third Party Apps throw a different kind of repeatable solution scenario because of the added dimension in providing automation, which then leads to the ‘Supportable’ element of the SharePoint Service Framework. This is simply due to the fact that Third Party Apps cannot be successful unless there is a support group. The sheer number of Apps available from the Office Store for SharePoint compounds scenarios concerning re-use, consumption, implementation and administration.
As per all things when implementing a solution in SharePoint, the answer to solving business and information challenges requires you to continually and critically review the requirements to find nuggets of functionality that has already been created. Analyse thoroughly the various elements of the SharePoint solution, so you can identify common areas that can be defined generically and as repeatable components. Harvest them into deliverable chunks and rework to see if they can be repeated. Remember the DEV to UAT to Production model – this applies to any kind of solution (design, develop, test, make it live).
If this sounds a little convoluted, remember the client perspective. Generally, they will not care what the resolution is made up from, is as long as it works – however, they will care, if the solution is usable, whether the solution once implementation can be repeated to meet a likewise requirement elsewhere without having to pay extra, whether the solution can be supported and whether the solution can be extended as the SharePoint platform scales.
Before going onto the relevant actions concerning what you need to implement, how the customers can consume, and how you can administer a SharePoint solution that can be repeated, check out these articles which all have a bearing on this section.
- Road Map Perspectives for SharePoint Service Delivery
- SharePoint Communication Message Framework
- What is SharePoint Service Delivery
- Some Thoughts on the Process of Building SharePoint Solutions
In conclusion to this article, which I will continually come back to update, you should also consider the three actions that you should consider in building a ‘repeatable’ SharePoint solution framework – Implementation, Consumption and Administration.
· Implementation
- List the common attributes of ALL solutions and group them into the four key aspects of SharePoint service provisioning – Support, Automation, Management, Reporting
- When designing solutions, record aspects of those solutions (if not in their entirety) that could be included in other solutions into a knowledge base.
- Record the aspects that allow third party products to export configurations that could be re-used. For example, you could develop a simple SharePoint site that houses developed and them exported Nintex workflow templates, thus making them accessible for re-use to others. In other cases, you could even export workflow templates and have them available for download in other sites.
· Consumption
- Build a process whereby users can provision solutions which are available in a library.
- Communicate available solutions and review all solutions in that library so that you can be sure they are being used effectively
- Record usage of the solutions in terms of where, how and popularity of the solution
· Administration
- Create enterprise policies that ensure users follow rules in terms of re-using ready-made solutions and link them to support
- In relationship to consumption, associate business rules and policies concerning the solutions that are in your library of solution
This article is part of Delivering SharePoint Solutions – Areas of Importance.
Implementing SharePoint – a ten step guide
Hi there folks!
Sometime ago I created a quick ten step guide and had it published on TechNet – amazed to find so much interest, and great comments! ShareGate contacted me and asked if they could turn it into an info-graphic (which looks great); now available on their site and is displayed below – enjoy!
Office 365 Customer Success Centre Available
When delivering an Office 365 service, you will need to ensure that the customer has access to resources to help them understand and get up to speed. As seen with SharePoint ‘getting the users on-board’, there is always a danger of ‘recreating’ adoption content, simply because information is non-centralised – that also means having to spend time gathering and crafting that content so that it is visually appealing (for example)..
A checklist for consideration when creating a SharePoint Platform
I have often been asked; “Hey Geoff, what points do I need to take into consideration whilst creating a SharePoint platform service”?
Configuration Management is the answer – “the combination of technical documentation, product pack information, user rules, continuity planning; – which helps create platform policies, platform change management rules and helps sustain the platform in its lifecycle”.
In ‘creating’ a SharePoint platform service, and I am purposefully ignoring high level ‘so called’ business points, no-one in the right mind would stick a SharePoint install DVD, or mount a SharePoint install image, click Next, Next and Next again, enter some configuration details without recording anything (using the ‘It’s Easy so why do I need to write anything down’ excuse), and then announce to the client “Eureka! I have given you a SharePoint platform – I declare that it has been successfully implemented!” (and real-world I have actually witnessed this).
SharePoint configuration management is the answer. Why? Because decisions concerning the implementation need to be recorded, as it is likely that the implementation configuration of SharePoint will change, or referred to, or added to in its lifecycle. So that means, you need to have a reference to each of these points in at the very least your Detail Level Plan for your SharePoint platform. Those should be then referred to in associated user policy documents as necessary.
So, here’s my take: (Note – most of these are technical checklist items, for the business side, see the user requirements checklist. Additionally, this refers to SharePoint 2007, 2010 and 2013 so examine each point as necessary and apply it to your version of SharePoint).
Governance and Culture Planning Points
- Can users access information via Web folder clients?
- Can users create and manage their own Web sites?
- Is the administration of mission critical data distributed?
- How are records and documents described using metadata and is that consistent across departments, divisions and agencies?
- Have you trained end-users on how to administrate sites before they need to manage them?
- Have you decided on who will assign users and permissions in SharePoint?
- Have you decided on who will create and approve content for portals?
- Have you decide on who will be able to create new sites?
- Have you decided on who will be able to publish content to web sites?
- Have you decided on who will be able to customise sites?
Naming Conventions
- Database Names?
- URLs (host headers)?
- Stand-alone site collection URLs?
- Managed path names and if so what are they?
- Document Library names?
- Active Directory SharePoint accounts?
- Content source names?
- Scope names?
- Server names?
- Web application names?
- Web application folder names?
- E-mail enabled list names and aliases?
- Have you ensured that names are kept relatively short, easy to remember and unique to avoid conflicts or confusion. Note that URL lengths including filename as are restricted to 260 characters
Extranet and Security Planning Needs
- Have you considered and anticipated password and account support for nonemployees who access extranet sites?
- Are there groups you need to deny at the Web application level?
- Are there unique permission levels you need to apply to individuals or groups at the web policy level?
- Are there unique or different authentication mechanisms you need to implement for extranet users?
- Do you need additional Shared Service Providers to associate with your extranet Web applications?
Search and Indexing Planning Issues
- Have you structured the content that needs to be indexed in terms of priority?
- What information do you need to crawl and have placed in your index?
- What content sources are needed to adequately crawl the information that needs to be placed in your index?
- What will be the Full and incremental crawl schedules for each content source?
- Do you have adequate server hardware to crawl all the content sources in your current schedule?
- Do you have adequate bandwidth available between your index and your content sources?
- For each content source, what rules, crawler settings and crawler impact rules are needed?
- Who will troubleshoot failed crawls or information that does not appear in the index?
- Who will evaluate the content sources so that the crawl criteria are configured efficiently?
- What will be your search scope topology?
- Do you need additional iFilters?
- Do you need additional Protocol Handlers?
- Do you need to add File Types to SharePoint?
- Do you need to add icons to SharePoint?
- Do you need to use OCR features?
- Do you need special accounts to crawl certain content sources?
- Do you need to create any Best Bets (2007 / 2010) / (Promoted Results 2013)?
- Do you need to group any Crawled properties?
- Do you need any special Server Name Mappings?
- Have you established primary, secondary, tertiary and demoted sites for Relevance?
- Have you ensured disks are optimised for Search?
Disaster Recovery Planning
- Have you set deleted retention policies for the two-stage recycle bin in document libraries?
- What are your plans for single site and site collection recovery?
- What are your plans for server recovery?
- What are your plans for farm recovery?
- What are your plans for data-centre failover?
Staffing Needs
- Do you have at least one architect who knows SharePoint at a granular level?
- Do you have at least one developer who knows customisation at a granular level?
- Have you provided excellent training materials and trainers for end user education?
- For large indexing environments, have you considered a FTE for search and indexing?
- To ensure robust taxonomy implementations, have you considered 1-N FTEs for content types?
- To ensure robust customised scenarios and/or complex workflow, have you considered 1-N FTEs for application and workflow development?
Personalisation
- Have you defined what Active Directory attributes you want to import from Active Directory to help build your profiles and audiences?
- Have you defined what profile attributes you want to populate for the user’s profile?
- What is the profile import schedule?
- What is the Audience compilation schedule?
Document Library Planning Issues
- How will you educate users to create document libraries based on a naming convention you propagate?
- Where will you enable the require document check out for editing option?
- Have you ensured that the number of documents in a view or folder are within best practice thresholds?
SharePoint Capacity Planning, Reporting and Monitoring
- Have you run performance counters to establish a baseline of performance counters?
- Have you accurately mapped your Web applications to your application pools?
- Have you planned the managed paths for important web applications?
- Have you estimated data requirements for SharePoint, ensuring you have enough disk space in your topology to accomodate growth?
- Set database size limits by implementing Site Quotas plus Site Limits on the database
- Have you established monitoring at the server, IIS, SharePoint and ASP levels and know what acceptable and unacceptable results are for each counter?
- Have you considered using external tools for monitoring SharePoint and if so what are they?
- Have you defined scheduled downtime periods for maintenance?
- Have you communicated the procedure to report unscheduled downtimes?
- Have you considered server redundancy, SQL clustering, Imaging and Windows Load Balancing if you need high availability on one or more SharePoint services?
Plan site quota templates
- Have you defined auditing reports at the farm and site collection levels?
- Have you established storage usage reports?
- Have you established required activity reports?
- Have you established SLAs for performance?
Branding and Consistency
- Will you avoid making changes to site definitions when they can be made with features?
- How will unique features be created?
- What are the documented processes from which to create workflows?
- What master pages will be needed for consistent navigation and branding?
- What content types will be needed consistent metadata, site templates, and workflows across documents?
- What rollup features, assemblies, and changes in solution deployment packages are needed?
Criteria for creating a web application
- Does the group have unique security needs?
- Does the group have unique information consumption needs?
- Does the group have unique taxonomy needs?
- Does the group have unique collaboration needs?
- Does the group have personnel they can assign to site collection management?
- Is creating the web application the right thing to do politically?
- Does it make sense to create the new Web application?
Additionally, you should take a look at this:
User Requirements Checklist – this is a further set of areas that you will need to address which when completed gives you a better idea on user requirements. In my book – Managing and Implementing SharePoint 2010 Projects (which applies to SharePoint 2013 as well), I went into much more detail about these including a process to capture the results from each of the decision points (Chapters 4, 10, 11 and 12).
