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).
For anyone working with software systems will know that there is nothing on the planet that is so completely frustrating, as a solution that does not work. Downtime leads to increased overhead costs, lost productivity, lost customer satisfaction and lost revenue. This hits business users of course, but also those who are there to support the business.
Small business users are especially hit by this since they are completely dependent upon the technology. Take into consideration therefore that if businesses do not understand the provisions of support for a cloud service that they will particularly suffer, especially since they will not, in the main have direct access to IT staff to aid them.
Office 365 carries with it solutions (SharePoint, Lync, Mail, Yammer, Office) within a significant number of feature such as Identity, Exchange, Rights Management, etc. Just think of what a small business will need to go through to start to raise a call concerning an issue if there is a problem with one or more of those solutions. And those with internal IT teams to help will fair no better. Having an IT team to turn to, without understanding that self service is available, that tools, troubleshooting techniques, videos, forums that are available, does not warrant a successful support structure. Additionally, the support level in Office 365 needs to marry with expectations from the client. You can only do that by understanding the provision of support provided.
So, here’s a call to action. For those utilising Office 365, or even providing Office365 to clients, I would strongly suggest that the following article is read and understood. And, before you start saying ‘this will not apply to me because I am using SharePoint 2013 on-prem, and I might be using an Office 365 tenant’ – it does!
The article describes:
- Community and self-service support options – describes the various resources that can be used to provide self-help.
- Pre-sales support – describes the various assistance provisions for understanding features, benefits, plan comparisons, pricing, licensing, etc.
- Billing and subscription management support – describes the kind of assistance for signing up, renewing subscriptions, paying bills, etc.
- Technical Support – describes what areas of support will be covered and how.
- Shared Support Responsibilities – very important for those who will need multiple roles in their Office 365 administration and support management scenarios.
- Additional support options – describes three other levels of support like Microsoft Cloud Vantage, Premier and Professional Direct Support, including partners, developers and volume licensing.
- Features – describes the support options, like phone support, technical, billing, pre-sales, etc. against the differing licencing options available for Office 365.
So check out the article on this link: http://technet.microsoft.com/en-us/library/office-365-support.aspx
Bold statement time. The Internet is a collection of machines – and there is more data generated by machines than humans. IOT (Internet Of Things) is connected devices providing data which will simplify, enhance, and enrich our lives. Already connected devices are beginning to revolutionise our lives; but to understand the nature, challenges and opportunities we need to understand how we can take informed decisions concerning this technology and trends.
Things like how the data our devices upload and download is shared, used, managed, controlled with clear data integrity. What should be our focus, what and who can help us understand this technology. IOT has implications for those working within the SharePoint sphere. As SharePoint workers, we will need to roadmap and further refine data provided (from internally or externally provided systems harvesting sensor data) to define an IOT strategy.
We will need to learn how to promote use of devices used within organisations, so they become smarter devices thus turning our companies, and ourselves, into smarter people. The article I have written for TechNet, aims to describe, simplistically, the nature of IOT, some of the key opportunities realised by Microsoft and others, the challenges we may face in control, management, security, privacy. The article suggests some take-aways in what we may need to address to support the infrastructure and manage the data.
Sometime ago, I also wrote about the skill-sets coming into the fold of data analysis (the Data Scientist). We are already seeing the emergence of the CDO (Chief Data Officer) whose skillset will become more and more entrenched in helping people make decisions on data coming from sensor feeds and the management of IOT in organisations.
Even my kids know about IOT and sensor technology. My eldest daughter, an ardent follower of fashion, running her own shop, mentioned to me that she was really into reading up and working on opportunities concerning nano-technology in clothes, as she thought it definitely the future. I thought that nano-technology in clothes was a myth; that it simply didn’t exist (showing my age I suspect) – but I was astonished to find on IET an article talking about just that, even to the point where engineers were busy creating clothes and being designers! Imagine, nano-technology in clothes; that would be able to determine the colour and provide better waterproofing in clothes – wow…. Surely then, we can’t be far away from having our clothes change colour based on the time of year, or maybe even inform how many washing cycles clothes can take before needing repair / replacement? So that means sensor technology in clothes must be a reality…
Anyway, I just had to do more digging. I am sure there are implications from a systems analysis, and service delivery perspective, particularly for data management. I found myself absolutely fascinated by the impact of IOT. From discussing with other techies in this field and more, I was able to put together an article which I’ve had posted to TechNet. Please go read the article here.
Microsoft has today released the Office 365 for business public roadmap. The Office 365 for business public roadmap provides customers with a way to learn more about upcoming change and updates before the change impacts their service.
Go here to see the Office365 for Business Public Roadmap
The public roadmap will be closely coupled with the larger Office 365 Change Management strategy, including integration with Message Centre and the Office 365 direct to admin communication channel.
This is an extremely important and very useful service delivery mechanism to ensure you know what services will affect Office 365 customers – the roadmap page is split into sections allowing you to see what features are launched, rolling out, in development and cancelled.
Another very important read is the Improving visibility to service updates blog which gives more information concerning the concepts behind the Office 365 for business public roadmap.
So what is the public roadmap?
The Office 365 for business public roadmap is a web page on Office.com that provides customers with a list of new and updated features being released to the Office 365 service. The website will list recently launched features, features still rolling out, and features that are still in development. The website will launch with a monthly update cadence.
Note that the public roadmap does NOT commit Microsoft to specific timelines for delivering service updates. It follows a set of policies for what should and should not be included based on when an update is expected to being rolling out and previous disclosure of a particular update. The content goes through a quality assurance pass bi-monthly as part of previous NDA roadmap activities.
Why is the public view of the Office 365 roadmap being created?
As both engineering and marketing move to a services operating model, Microsoft are changing the way they approach customer communications. Part of this transformation is going directly to customers and scaling communications to every Office 365 customer from the individual business owner with 1 employee to the largest enterprise or governmental organization with hundreds of thousands of users.
From examining customer data it has been seen that customers expect a “service” to behave like other services in their life, such as cable or mobile phone subscriptions. They expect notification and communication about any changes to their service. PSAT data, focus groups, and OneList items all show the high cost in the old operating model that erodes customers’ trust and confidence in Office 365.
So what’s next?
Microsoft will be listening closely to customer, partner, and field feedback for improvements that fit within policy guidelines. Improvements currently being evaluated include localization into tier 1 languages, notification or tracking capabilities for the site change log, and expanding to include out-of-scope Office 365 instances. They will continue to refine the update tracking process and use the Office Release Roadmap as the single source for data related to service updates.
I was absolutely delighted to have been part of an exceptional line up at the European SharePoint Conference 2014 this year. The conference took place in Barcelona, Spain from the 5th to the 8th of May 2014 and was Europe’s largest SharePoint event, bringing great sessions and the latest innovations from Vegas. The conference programme included over 110 sessions, keynotes, and tutorials, including topics covering the latest news from SPC14 including what’s new with SharePoint 2013 SP1 – Office Graph/Oslo – new Office 365 REST APIs – Access Apps – Cloud Business Apps.
I conducted a session on “Ten Steps to Creating a SharePoint Support Model” aimed at Business Decisions Markers and End Users – description follows:
“There is nothing like a smoothly running SharePoint support environment but is that possible? In creating a great support SharePoint environment helps foster great user adoption and great SharePoint champions. This presentation attempts to show a strategic approach where the questions to be answered on how to build a true support model for SharePoint be based on “What has to happen, why and where?”, and attempts to describe a basic support model of ten key steps; from knowing what resources make up your SharePoint environment to keeping in contact with customers.”
I had awesome fun conducting the session, and have been inundated with requests for the slide deck – you can download if from here – if you need any other formats please contact me.
Ten Steps To Creating a SharePoint Support Model Slide Deck
Additionally, a resource associated with this session, the 2013 Helpdesk Template, is available for download here:
SharePoint 2013 Helpdesk Template
Enjoy!
I was privileged to be speaking at the Workflow for Everyone, Everywhere conference hosted by Nintex at Microsoft UK in London on Wednesday the 16th of April. I shared the stage with Pete Hampton, Productivity Specialist Sales Manager at Microsoft, Nintex and an elite team of industry experts, Microsoft SharePoint specialists and MVPs. This was a free, one-day seminar that showed how to get more out of your existing workflow investments, and showcase ways to help create integrated, on-premise and online workflow solutions.
It was a great event. Attendees found out how their industry peers have improved their businesses, got exclusive industry insight and best practices, and saw for themselves how Nintex solutions keep work flowing for users – wherever they are, however they work.
In just one day attendees learnt:
- How to create efficient processes – Find out how to automate everyday processes for rapid ROI
- How to get more from SharePoint – Get the inside scoop on how to get the most out of your SharePoint investment
- What the industry really thinks – Industry experts take on market trends, solutions, and more
- SharePoint best practices – Hear from SharePoint MVPs and specialists on how to integrate your business processes with your cloud services and beyond
- What your peers are up to – Network with your peers and hear their real-world success stories
- How to empower everyone, everywhere – Integrate and extend your business processes on-premise, in the cloud, and via mobile, and social
I conducted a session on Cloud Solution Sustainment which was my take on the current Cloud situation, its impact on the delivery process, and what IT and the Business should do to ensure that whatever cloud solution they take on follows a process of evaluation and provision.
The slide deck (in PDF format) is available here:
Sustaining Solutions for Cloud – Service Delivery Perspective
The ‘Prezi’ presentation is available below – Enjoy!
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.
This article is part of Delivering SharePoint Solutions – Areas of Importance.
A challenge that SharePoint organisations have who are actively involved in the creation, then management, of SharePoint solutions, is then applying a process of delivering those solutions, and then using the same defined process. And note, we are not talking complex or simple SharePoint solutions, these solutions could be as simple as configuring a SharePoint site with repositories to provide a records management experience, or to provide a method of filling in on-line forms, or a business automation solution utilising workflow templates, or even taking on a third party app in a SharePoint 2013 online site, etc.
More often than not, those who do not apply any process involving any kind of systems analysis and design, then through to administration of SharePoint solutions usually end in disaster because:
- The level of support provided is inadequate to the solution can be scaled
- The deployment process has not been followed, for example, in an ‘on-premise land’, ‘let’s build the lot on production…’
- It’s easier to start building the solution virtually identical to one already in use, than working from the design of another likewise solution, because it is not possible to locate the design for the existing solution.
- Solution ABC is nothing like another solution whose focus is virtually identical and has been built from scratch
Some customers when quizzed speak of their alternatives to delivering a solution, and some are nothing short of astonishing – here are some examples – prepare to laugh:
- Get a third party organisation to put the solution in for us because we do not have the time to follow any delivery process – but we want to control everything and be able to support it ourselves
- Build a delivery process, show that there is such a process in place, but don’t actually follow the process
- Let’s simply get on with it, build the lot in a ‘fly by night’ fashion, we will deal with all the issues as they arise
Ok, laugh over… Let us quickly see why alternatives have been addressed which simply do not work. The main reason appears to be that organisations find it difficult to build let alone understand a delivery framework surrounding SharePoint solutions. This may be due to having one person to provide the entire solution start to finish with no proper support, or a lack of skills concerning how to provision a solution (because their background is programming), or even that the current process does not map to SharePoint.
If you happen to work in an organisation where there has been SharePoint solution success; for example, you have been on or lead a team responsible for delivering a SharePoint comprising of a number of tools and services, you will be in no doubt that the following areas would have been addressed:
- Service Testing
- Deployment
- Versions
- Support
Conversely, you may have been in a situation where there was deployed a SharePoint solution which had failed because it had not addressed the above.
Am going to try to help out then. I am going to describe four areas which relate to the practical work required around delivering SharePoint solutions – every SharePoint solution being conceived must:
- Be Usable
- Be Repeatable
- Be Supportable
- Be Extensible
If any one of the above areas is not fulfilled then the adoption of that solution will fail.
For each of the four areas I will describe some actions that you should consider. The topics will be written in a way that is SharePoint version agnostic and generic and can be applied to your organization.
At the end of each section will be a Deliver Actions section which will show three areas of concern related to the topic:
- Implementation – what actions needs to be done to ensure that the relevant framework section is in place.
- Consumption – what resources will benefit from the relevant section and what resources should be used to help place the framework section.
- Administration – How you will ensure that the service delivery model relevant to the section includes an element of management. This will ensure the sustainability of the relevant section.
Please note though, describing these areas is not easy. I have even have difficulty amongst other solution architects in explaining the concepts, because of statements of SharePoint service delivery which is all over this article, and the fact that the areas covered in this article may touch all parts in an organization, which therefore increases complexity. So, to those new to SharePoint Service Delivery, as well as reading the guides, I suggest that you:
- Get help. Seek a SharePoint solutions architect to help you meld the service framework to match your organisation resources.
- Ensure that to back up the SharePoint framework that you have / using a methodology that allows the framework to connect to, that also allows a logical and structured approach.
The areas being described are separate articles as follows – please read them (when they are available) and they will be listed and categorised on the site (when they are available):
