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!
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.
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?
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
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).
Support service development for SharePoint is crucial to ensure sustained SharePoint Governance and User Adoption. I had the situation where in building a SharePoint support service that a customer needed the provision of support to be handled differently for a newly delivered SharePoint solution, and also needed that to be documented and agreed by the SharePoint sponsor. The reason for this is that they needed the support service to be measured against the supply of support to that solution, which was critical to the department and the organization.
Any SharePoint solution has to be usable, by the users and by the support team who addresses those challenges posed by the users, and by those who delivered the solution to ensure that enhancements and modifications can be applied. The solution must be usable, irrespective of what that solution is. For example, there would be no point in building a SharePoint platform unless you followed some design standards (or even had them applied), like service account naming, DNS naming, taxonomy, search topology and more. There would be no point in building a document library which has several global workflow templates assigned unless there was a consistency in development standards, which was defined and applied.
If the solution is usable, the provision of the solution repeatable, it can be supported and scaled with minimal effort, then the solution is deemed successful in terms of its provision.
To understand whether your SharePoint solution is usable, consider these service delivery concerns:
Design Standards. The process by which the solution is designed impacts on its usability
Development Standards. The process by which the solution is developed impacts on how extensible it will be and how effective the support
Commonality. The look and feel, the components used whether they are SharePoint, third Party integrated, or a combination
Consistency. The expected outcomes impacts on how the users learn about how the solution works
Tools. Choosing the tools necessary to design and build the solution impacts on the support available
Cross platform and environment concerns. This is related to all of the above points. For example, what happens if you have more than one SharePoint environment to deliver to? What security constraints are there? Are there dependant systems involved?
Design Standards
Designing a SharePoint solution is akin to carrying out systems analysis which results in a blueprint of the solution, which is then communicated to the client. Once communicated, the client can agree to the design. The communication can come from a workshop or series of workshops, for example.
The solution is deemed designed when the design layout is acceptable to the client, acceptable based on the resources provided, and acceptable in terms of being provided by those responsible for delivering the solution. Unfortunately, however, there are many instances where design standards are simply not adhered to.
I have witnessed examples of where the design of a SharePoint solution has been completely bypassed. One of the reasons is that there is an assumption that the user will be able to use the solution, without needing to ask what the user actually needs, without needing to document how / why / which / what. Yes, this sounds crazy, but I have witnessed clients faces of amazement when they are told that a new SharePoint site (being the solution delivered) has been built, and to get on with using it, without any mention of the value gained, the benefits that will be delivered, or even the reasons why the solution was created in the first place.
The reasons why this mistake was made could be one or more of the following:
Those responsible for delivering the solution did not follow any systems analysis and design – instead, they jumped in and built the solution ad-hoc
Those responsible for receiving the solution were not concerned of the lack of systems analysis, in other words, were happy to just ‘get’ the solution, even if it was built ad-hoc
Design standards are seen as something that takes people a lot to learn, ties them down, and does not offer flexibility
A laissez faire approach to design standards results in a SharePoint solution which will not be useable.
Following a design standard creates consistency that will help your users, and will save you pain and will save money. Additionally, following a design standard actually makes upgrading the SharePoint solution a lot easier.
Following a design standard needs to be done by those delivering the solution and clearly understood by those who will be receiving the solution. A good resource to get further information on this is from “SharePoint Customization Impacting User Adoption”, Chapter 10, in the book “SharePoint 2013 User Adoption and Governance”. This covers deciding when you should and should not customize SharePoint, choosing the correct resources, development options and more.
Development Standards
Once the design of the solution has been agreed upon, the development of the solution can get underway.
Development does not mean “Yaaaay…. Visual Studio! You’re mine now, let’s jump in, slam some CODE”.
Again, based on the usable concepts described in this section, the solution being developed must be usable when delivered, and must continue to be usable until it reaches end of live (the customer is no longer using the solution). That means the solution needs to be stable, easy to maintain, scale with the changes to the platform which it relates to.
Therefore, a ‘dive in’ and ‘gun-hoe’ approach is not going to make a solution ‘usable’ to ensure the solution lifecycle, without a development process being followed.
A development process begins with understanding the limitations of the resources available to develop, both person and tool inventory. The process also includes ensuring that there is a correct fit between the tools being used and the resources being applied.
Amazingly, following a development standard is sometimes not addressed by the over-zealous developer and/or the over-zealous customer who has not been made aware of what is currently available in SharePoint. Examples of this are where developers have been brought in to provide functionality to SharePoint which could have been achieved using out of the box tools and components. Other examples of ‘epic fails’ concerning solutions being provisioned as ‘usable’ include customers who ignore the features of SharePoint and request third party tools be bolted on ‘because they look nice’ and spending far too much money and resources on ‘look and feel’, instead of functionality of provisioned solutions (and the process). Other examples include developers who are unclear of the aspects of SharePoint that should and should not be targeted for customization; this being due to those developers not aware of the resources available.
So, to correct this issue, the first standard needs to identify what resources are available which then defines the tools that will be used to develop the solution.
If the requirement can be met using SharePoint built in features then build the solution and integrate into the inventory
If the requirement can be met using an existing solution in the current inventory that the organization has and that existing solution can be applied then requisition that solution from the library, configure then integrate into the inventory
If the requirement can be met using a third party package or application then obtain, configure and add it into the inventory
If the requirement can be met by customization through development then author the solution and add it into the inventory
And, even if the above has been done there are plenty of things to consider to ensure that a standard is being applied when actually considering or doing development in SharePoint, irrespective of whether the development is based on using built in features, custom coding using the API, web service development, Javascript, jQuery etc. Thank goodness that Richard Harbridge has provided a great resource that identifies development standards here which I strongly suggest you read and digest: http://www.rharbridge.com/?page_id=259
Final point in this section, if you are new to development standards from a higher level and wish to know more about how management is applied to these standards check out the following:
15288 ISO/IEC 15288 Systems and Software Engineering; establishes a common framework for describing the lifecycle of systems created by humans. It defines a set of processes and associated terminology.
ISO 12207 ISO/IEC 12207:2008 Software Life Cycle Processes. ISO/IEC 12207:2008 establishes a common framework for software lifecycle processes, with well-defined terminology, that can be referenced by the software industry. It contains processes, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products. Software includes the software portion of firmware.
Commonality
In order to build a usable environment the need to create a design based on the same methods used before is important. There is little benefit in choosing a different method to build a solution, if the solution will be planted into the same environment.
An example of this is having a garden where you need to plant two trees upon request from your partner who gave you the trees. You locate a spot, then dig a hole, put the tree in the hole, fill in the hole and water the tree. That’s it. No rocket science needed. Ok, so there will be a need to water the tree after, choose the right spade, etc. However, the process is a common one in terms of planting anything in the garden, whether it is a tree, a flower, or a scrub.
Now imagine if you will, having to plant the second tree, but instead of digging the hole, you simply throw the tree onto the spot, then water the tree. By not using the common method, a number of things will occur:
The tree will die
Your partner will be very angry
A lot of weeds, with probably no tree
Let address this from a SharePoint perspective. Imagine that you have developed a collaborative site in an organization for a department of ten people. The site has a graphic on the right, the quick launch bar on the left, a calendar in the centre, and an announcements list at the top. Assume that a new site needs to be provided for another department in the same organization. Some of the users of the new site already access the current site. Do you:
Design the new site so that it has the elements of the current site (calendar, quick launch bar, announcements etc) applied in the first site is applied to the second OR
Go for a fresh approach, because you wish to boast of some SharePoint wizzy features
Going back to the analogy of the tree, the site will either (a) not be used (b) the users will get frustrated because it does not look and feel the same from site to site (c) the site will have a lot of features but not meet the actual requirements (i.e. that it is simply a SharePoint site).
So, by providing a common approach in all aspects of SharePoint solution delivery is a key aspect of ensuring the solution is usable, from the design, to the build to the deployment of the solution. This is not just from a UX design perspective, but also from even the requirements gathering of the solution in the first place.
Consistency
The consistency in the approach used to provision a SharePoint solution is another important aspect in ensuring that the SharePoint solution is usable.
For example, take a SharePoint site which has a piece of Javascript in place embedded in a Content Editor Webpart. The person who put that Javascript has since left the company. There is no documentation concerning how the Javascript operates. Another person decides to modify the Javascript, finds they lack the knowledge and instead downloads another piece of JQuery. Meanwhile, unknown to them, that same Content Editor Webpart with the original Javascript is in use elsewhere. Then, later, someone downloads a SharePoint app which supersedes the need for the content editor Webpart.
Let’s take another example. Your client wishes to have another SharePoint farm in addition to the current in place. The original documentation concerning the design, build and deployment of the current SharePoint farm is used as a basis to provision the new SharePoint farm.
Now, take a look between the two examples above. Clearly, the second shows more consistency and at least an approach. Why is this? Is it because there was documentation? No. It is because there is an approach already in place which IS documented. The good thing about that is that the solution provisioned in the second example is usable straight away, simply because the approach will to a large degree take into consideration all the other aspects of service delivery; is the solution supportable, can the provision be repeated, is it usable, can it be scaled.
Tools
A distinct aspect of a solution being usable are the tools used within the construction process. However, we will need to be clear on what we mean by tools when talking about a SharePoint solution. That is because SharePoint includes tools which can be combined to create a solution.
In particular, take SharePoint 2013 with the terminology ‘App’ being applied to repositories (commonly known as document libraries and lists). So App is short for application, meaning that the document library is in fact a configurable aspect that can make up the solution. On the other hand, a tool could be the use of a programming tool like say Microsoft Visual Studio, or even a third party tool deployed into SharePoint, like a workflow tool, or a form building tool, or even a digital signing tool (ad infinitum). Irrespective of the tool used to create the solution, care needs to be taken that the right tool is selected, and that training, support and adoption is factored into the choice of those tools. This is because there is a danger that in order to produce the solution that meets all the business requirements that a complex web of products needs to be employed which in itself requires a host of tools to help configure the solution.
Delivery actions
To recap, all solutions created for the purpose of being used in SharePoint must be usable, repeatable, supportable and extensible. In this section, I’ll give you the implementation, consumption and administration tasks that will need to be carried out to ensure that the service solution being delivered is ‘usable’. Usable Implementation deals with ensuring that the way the solution is going to provisioned follows a known standard which can be managed, and that the deployment for any solution can be repeated.
Implementation
Examine the most successful implementation of a SharePoint solution, and then identify the standards used to put it in place.
Ensure there is a bank of tools available which are documented in terms of what they should be used for, including examples and an inventory of solutions which have been constructed using the tools
Document policies which describes the software development policy which stipulates the process under which solutions will be system analysed, designed, constructed, released, supported and maintained going forward.
Consumption
People are required to ensure that a solution is deemed ‘usable’. If you consider that when you have provided a something in SharePoint designed to improve the productivity of the users involved, that you have already addressed an element of what is considered for the solution to be ‘usable’. So, you will need to know what audiences are involved, since at the very least they influence the usability of the solution provided.
IT Support
Software Developers
SharePoint Architects
SharePoint Support
Administration
Build a SharePoint site for each of the third party products. Use that site to house solutions created using those third party products
Build a repository to hold source code
Identify valid sources of libraries which hold validated tools
Record key resolutions to typical problems concerning the use of the available tools.
Lets take a look at developing Road Maps for SharePoint. Now, before you start yawning and thinking ‘Like I need to know about Road Maps?’ – Well, let me tell you that whenever you deliver solutions in SharePoint you should at the very least be thinking of how not only what the capabilities required to build those solutions, but also consider support, user consumption, and administration of SharePoint solutions in an ever changing organization technology landscape (whew). That means building Road Maps.
If you design SharePoint solutions, you will at least be thinking, ‘I want the solution provided to my SharePoint users to last as long as SharePoint does’. If that’s not your thinking on delivering SharePoint solutions, one might say ‘Why are you delivering solutions for into SharePoint in the first place’?
The challenge is what process do you adopt to even start thinking of Road Maps for SharePoint? When talking about this to other SharePoint solution architects they generally have their own ideas, but it is a massive topic to consider. This short article therefore is to look at what layers need aid Road Map development in SharePoint. There will be following further articles looking at each of those layers, describing detail behind each, along with key actions that are required.
The Challenge
A SharePoint roadmap takes the relevant customer goals, prioritises them into short, mid and long terms and defines a plan that provisions those services. You do this to ensure that the solutions being provisioned within SharePoint, whether they be default, third party, internally developed, integrated meet the customer needs and at the same time helps planning future SharePoint developments. This is not to be confused with simple SharePoint implementation; developing a road map for SharePoint requires a thought process which encapsulates the fundamental goals of the customer in utilising the relevant technologies in order to fulfil the key SharePoint premise: “To create and manage content in a website”.
Through engagements and interactions with customers over the last couple of years, I have recognized a need to document the capabilities required to aid the development of a Road map for SharePoint. For example, one client had a hard time appreciating the need for site design and user experience. They were quite content using automated tools to drive site development without challenging those requirements or even managing the process. Through explaining the importance of delivering solutions through a modular approach it has helped the customer not only understand but engage with the development of processes manage site design and user experience in SharePoint for their user-base.
My challenge though has always been mapping SharePoint requirements to not simply refer to a technology release, but into a Road Map which ensures the future-proofing of that SharePoint solution. So, that means not simply looking at SharePoint in a gold fish bowl. It is taking into consideration all other services and processes that the client has through their use of the technology available to them, and making sure that whatever solution is provided follows a defined method of delivery.
I found that it is important to recognize that not all capabilities of the solution being delivered are driven by the actual service owner, or the provider of the components being provided in the solution. For example, if an app that allows automation of a process is deployed in a SharePoint site, which does not necessarily mean that the exact same app can be used in another site meeting all the requirements of that new site. No two sites are identical – the reasons for their existence are never identical, even the support matrix for each site is never identical.
What Capabilities are needed
So, let’s firstly take a look at the three perspectives that aids the development of a Road Map for SharePoint.
Implementation. This relates to the development and the deployment of the SharePoint solution and from only the providers perspective. This area is the one virtually all organizations appreciate by default and requires the least of clarification. For example, when procuring a third party application which provides SharePoint capabilities, there is an assumption that the implementation process is documented, and can be adhered to (assuming that the SharePoint organization does its home work and identifies these things up front beforehand!). Likewise, developing a solution in-house that relies on several SharePoint components, third party apps and data-sources internal to the organization needs to follow an implementation process that can be repeated. Again, this is something that the customer assumes will take place, and it is highly unlikely that the provider would not define a method of implementation.
Consumption. This relates to the consumers of the services provided by the SharePoint solution, thus making the solution easier to implement and successfully adopted. Of the three capabilities, this is the area that I have found is somewhat neglected by customers. In other words, customers are simply not leveraging the services provisioned through the SharePoint solution, or, there has not been enough work to identify the value that the service will provide to the customer. Check out the Value Management in SharePoint article for further information.
Administration. Any solution in SharePoint needs to follow an operational management procedure to ensure stability, and adheres to several governance rules that are both organizational and platform related. This will include proactive monitoring, support, automation rules, reports of usage, etc. The fact that user analytics is seen as an important measure and driver to adoption, and the fact that SharePoint provides usage information (and a number of third party products also provide this and more), means that this perspective is now recognized and appreciated. That said, more needs to be understood about its value and impact.
These capabilities are needed within all SharePoint solutions. It is important to realize that an organization can choose to focus on one or two of the capabilities listed above, but the overall maturity of the SharePoint solution, and hence, the overall value of the SharePoint services, depend on all three. Neglecting any of the three will have consequences – some more readily apparent than others.
To put this into context, appreciate that all services that are in the Road Map need to be extensible, supportable, repeatable and usable. Administration, Support and Implementation are all factors to consider for each service as stated. As an explanation:
Extensible means that the SharePoint solution is capable of aggregating services and extending its use beyond its own borders. From a simply perspective, take a basic SharePoint site. Then, by adding components to meet the user requirement the SharePoint site grows. However, extensibility is not just growing a site. It’s managing the growth in such a way that the service grows using mostly enterprise technology.
Supportable means that the SharePoint solution can effectively be managed even when services are increased against relevant SLAs.
Repeatable means that SharePoint solutions can be implemented by reusing standard and defined processes. It also means that those solutions can consume and reuse relevant services efficiently and consistently. Examples of this includes using third party apps to deliver SharePoint productivity and ensuring they are set in such a way to provide the likewise functionality in other SharePoint solutions.
Usable means that SharePoint solutions can if necessary use standard mechanisms to connect to enterprise technology. This is very important in order to keep pace with changes in SharePoint and connected technologies.
The four topics above, Extensive, Supportable, Repeatable and Usable are vital aspects in SharePoint service delivery. I use them as a mantra when designing, developing, and implementing SharePoint solutions. They will each have an article devoted to them where I hope to go into more detail on what each means and how you can apply them to your SharePoint solution delivery processes.
Conclusion
As pointed out in the start of this article, the topics discussed in this article will be expanded in future articles (particularly Extensible, Supportable, Repeatable and Usable). The capabilities whose thinking needs to be planted into your SharePoint Road Map are:
Implementation. Ensuring that the design and development of all SharePoint solutions is optimised.
Consumption. Ensuring that the services can be used by others which includes all aspects of continual service provision, like support, adoption, training, roll-outs of enhancement services, etc.
Administration. Ensuring that the SharePoint services being provided are stable and governed. That means proactive monitoring, ownership, configuration management.
This (short) article has been an attempt at describing the key facets that help build a SharePoint Road Map. While it is important to know where you are (hence the reason for starting to build a Road Map in the first place), getting an exact bearing is less important than identifying the capabilities needed to address, so you can continue the advancing the value of SharePoint in your organization. As long as you are willing to ask yourself some hard questions in an objective manner across all the relevant SharePoint services, including third party, integrated and internally developed, you should be able to get a good understanding for your current challenges. If you apply the strategy and objectives of SharePoint, you will be able to identify which capabilities you will need to address in the short, mid and long term.
Take control of user adoption and governance processes in your next SharePoint 2013 deployment—whether it’s a specific site or complete farm solution. In this book, you’ll learn proven techniques and methods that will help you better manage the entire project lifecycle concerning SharePoint implementation from a practical standpoint.
Discover how to:
Align organizational goals and requirements
Define the full scope of the project
Set up a team to deliver a SharePoint solution
Effectively communicate with and include your stakeholders
Prepare for user feedback and adoption
Establish and maintain governance through the entire project
Use web analytics to provide substance to governance
Confirm readiness for delivery to the organization
Many organisations, taking SharePoint on for the first time, opt to go for a single server instance deployment of SharePoint. However, they find it easy to forget in the heat of getting a single SharePoint production environment deployed, that without defining a fully available topology that one may be creating a single point of failure scenario.
SharePoint Implementation concerning the ten key steps required to successfully deliver SharePoint to an organisation, available as a map on this link: http://www.geoffevelyn.com/mmap/spimpl/spimpl.html
