There are quite a lot of people in the SharePoint community flying the SharePoint Development flag high and proudly. The SharePointDevWiki.com is growing steadily each week and I’m extremely pleased that there are more and more community members submitting content on there.

There are plenty of people trying to take the SharePoint Development approach and using Solution Packages to deploy to the farm. But more and more I am seeing this scenarios below.

Scenario One

• The development team sit down with the client and get the requirements for their new “Intranet”
• Start off with a Solution Package and buildingSite Fields, Content Types, Lists, Pages, Web Parts androlling this into a UAT environment (or worse Production)
• The “Intranet” in UAT then gets a review from the client
• Changes are requested by the client, but the client also wants to have a “play” with the UAT environment
• Developers start off on the right foot and add a few extra Site Fields, amend the List Templates and have tested it in their Development environment
• The Dev team are then ready to deploy this to UAT…but the client has done more than “play” in this environment and wants this content in there when the Developers release the changes.

FIRST TIP: ensure they are aware that anything they do in UAT is not making it to production! UAT is very different from content STAGING environments.

• So the Dev team release the new .wsp solution package to the farm and then run a script to delete the current site collection and create a new one using the new templates and scripts…this obviously deletes any content that was in there.
• This gets a tick in the box and the site goes into Production
• Content is authored in the new production site and they want to add a new Site Field to a list that is commonly used across multiple department sites within the Intranet
• Changing the List Template in the Solution Package and redeploying to the farm will not amend the instances of the List already created. So the Dev manually makes these changes and so the spiral of pain starts…

Take this scenario 6 months down the line, the Dev no longer bothers updating the solution package as he is doing it all manually in production anyway and no need to go back and change it in source control…”that’s not used anymore anyway”.

Scenario Two

Scenario two steps in where Devs originally deployed style sheets to the Style Sheets library using Solution Packages and then someone gets hold of SharePoint Designer and ignores the warnings and modifies the style sheet here. Lots of changes are made…but not put back into the source style sheet in the solution package.
Later that month a web part C# file changes and a new style is added to the style sheet in the Solution package. The new package is redeployed…guess what, it’s going to redeploy the style sheet but not overwrite the one in the site because it’s broken its ties with the original source! So the web part will not find that style and not render properly.

TIP 2: lock down files deployed with solution packages so that they can only be changed via deployment. Do this via ‘sealing’ elements and also via permissions on items.

TIP 3: don’t let developers near the production and UAT boxes. Don’t let their dirty fingers anywhere near the 12 hive directly! Get administrators to deploy to UAT and Production using WSPs and change scripts.

Why does all this happen?

The biggest problem is that developers want to be able to automate the entire setup process especially in a build server scenario and this is why everything initially ends up being deployed via a Solution Package.

TIP 4: draw a line between what is development and what is customisation.

Either do everything in Development or do everything in customisation for an element e.g. don’t build your event receivers in a dll and package with a WSP, and have a List Template in the wsp, but then manually use a tool like Event Receiver Manager to add the event receiver! On creating the list via a Site Definition or via a Feature, use a Feature Receiver to attach the event receiver there and then! It’s self documenting that way!

Whatever you do, document where each type of element sits and where it will be found: in a WSP, update script, command line up, manual steps etc.

Below is an example table that shows the boundaries between elements. Note this is by no means complete, but just to give you an idea…plenty of things in Development may sit in Customisation for a lot of teams. You can also give this to external integrators your team may use for implementations to make sure EVERYONE works the same way.

TIP 6: Remember that changing elements won’t affect their instances e.g. List Templates, Site Templates, Workflow Instances. All the other elements are referenced and linked and will be automatically updated once pushed out into the Farm.

To modify existing instances you will need to provide update scripts using the object model either as custom window console application or powershell script.

TIP 7: Get your dev team to first off create a script that deletes the site collection and recreates the site collection (using custom Site Defintion if approach taken) and then run the scripts to populate content required. Use this script when in own Dev Virtual Machine AND Shared Development Environment AND Build Server.

TIP 8: Always keep UAT and Production one change step away from each other. Always deploy to UAT and Prod using WSPs, but also use update scripts rather than deleting Site collection and creating it again! Have the ability to take the approach of Updating in Shared Dev environment (by taking snapshot of UAT/Prod) to test update scripts before going to UAT.

Conclusion

Well this is the end of this 6 part series on Leveraging the Platform. Hopefully it’s been useful to you. Very shortly I will be placing some more ideas up on the SharePointDevWiki.com around these change control processes to help SharePoint Server teams with these tasks!

We are coming near the end of this 6 part series, but don’t worry, it’s not the last you’ll hear of me! This part focuses on ‘Why develop leveraging the SharePoint Platform?’. This is really targeted at ASP.NET developers specifically, but also other web application developers from other walks of life also. Or anyone currently working with Vanilla SharePoint and wanting to dig a little deeper!

Development Languages

As discussed in the Part 1, SharePoint leverages ASP.NET and NET WF among other languages such as XHTML, CSS, XSLT, XML and JavaScript. Most ASP.NET developers will already be proficient with these languages making the learning curve pretty much around the Framework itself. The Collaborative Application Markup Language (CAML) is about the only new language that is new to SharePoint Developers which is used to build queries in XML.

The SharePoint Framework

One of the first things to remember is that SharePoint is a Platform and NOT a Product. SharePoint is there to be leveraged. It is pretty much useless vanilla out of the box from a fresh installation as an end user. It needs customisation and development implementations for a Solution to be usable and successful.

Functionality already there

As discussed in Part 1 and Part 2, there is a lot of functionality out of the box and it is worth being aware what this is to see if you can get any wins out of reusing this in your solution implementations.

Plumbing already there

SharePoint provides lots of plumbing out of the box that you’d typically be writing yourself or plugging together a bunch of components. Common bits you have to put together are: User interface Framework, Windows Services, SQL Databases, Persistence Layers, CRUD UI screens, Security, Workflow engines, File Upload, Deployment Framework etc. All this is there at you disposal with a few lines of code or clicks in the User Interface. This saves a significant amount of time up front.

Learn the Framework

Like the .NET Framework, some things are hidden away in various namespaces and often you’ll find developers writing functions that already exist. There’s plenty of content out there to ensure you don’t make this mistake. I personally find MSDN currently a bit dry as the structure is based on each object in the object model hierarchy and it’s methods and properties. Often these don’t fit into a scenario where you’d use them in isolation. The scenario based examples are littered all over the blogosphere and more recently being structured on the SharePointDevWiki.com. MSDN do have these scenarios, but they are just written into one long list of articles with no structure which makes it hard to discover what you’re looking for. SharePointDevWiki.com gives you the best of both worlds.

More than one way to do things

As I discussed in Part 4, there is more than one way to skin a cat in SharePoint and it is important to agree on a standard approach within each SharePoint environment for consistency. Being aware of each approach and it’s strengths and weaknesses is just the start of the implementation process!

Infrastructure Handled for You

SharePoint is becoming more and more common across IT infrastructure and you can bet your bottom dollar it’ll only get more common as time marches on. The platform allows you to build solutions and not have to focus on things such as: Scalability, Disaster Recovery, Performance, Interface Design Frameworks, Security and Deployment. All this stuff is part of the plumbing of SharePoint Infrastructure and managed by your Infrastructure team and propeller head Architects. More often than not, they’ll be a few guidelines to follow when building your solution and that’ll be the last you hear of them! Please don’t get into the habit of doing this stuff as well as development, see my recent post on ‘The SharePoint Implementation Market needs to grow up!’ to find out more on this.

Frameworks Evolve

One thing to remember with Frameworks is that they evolve over time. SharePoint has already gone through 3 major versions with another just around the corner in Q1 2010 (SharePoint 14). When you implement your solutions on top of SharePoint, without any extra effort (if you’ve done things correctly) you get a whole heap of extra functionality when you upgrade to the next major version.

Extend the Framework

You’ll find people rewriting functionality because it doesn’t work “quite right”, but realistically people should be extending the framework. Often this is purely down to the skill level as a .NET Developer or in Power Users case…no skill level at all. If you rewrite or hack the current functionality, you’ll find that updates will overwrite your changes, extending the framework ensures they still exist. You’ll probably have to do some integration testing to ensure your extensions still work on top of the new version. This is happening more and more as Power Users find ways to work around the Development approach with tools such as jQuery, see my post on ‘jQuery: the SharePoint Band Aid’ for more information on this.

Maturity of the SharePoint Dev Community

As I mentioned recently the SharePoint Development community has got a long way to grow to be respected. I would recommend reading that post to get a deeper understanding of what I mean. I’ll cover off a few things here that are relevant to the objective of this post:

Rapid Application Development

Like any platform, SharePoint is great a rapidly building applications and is therefore great for Prototyping. Be extremely careful to set the expectations to the End User that these are Prototypes and not the real thing. You will need to build the end solution with a lot more rigour than throwing components together to get an end to end solution running to pilot.

Agile Methodology

Because you can rapidly build solutions you will find development teams having very short iterations producing extremely rich functionality. This lends itself well to an Agile approach to development, which is where the Development Market should really be, moving away from the traditional Software Development Lifecycle (SDLC).

Test Driven Development (TDD)

Andrew Woodward is leading the charge with SharePoint and TDD. There is also ongoing documentation on the community happenings around this on the SharePointDevWiki.com. Eric Shupps has just posted an anti-TDD SharePoint post here which has caused a lot of discussion around the whole paradigm. I take the stance that it is suitable in certain scenarios, those of which I have not had time to define yet, but will do on the SharePointDevWiki.com shortly. If you are currently in th e.NET space and using TDD, the community would welcome your feedback as it is still in limbo!

Source Control

A lot of implementations can be done without writing a single line of code and some can be written with a few. Often it is just all too hard to keep a repository of these “little” changes..but we’ve all seen an avalanche right? Don’t be fooled by teams that say you can’t use source control with SharePoint Implementations or by those who say SharePoint does it for you! That is not totally true! You should place as much in source control as possible outside of the SharePoint environment and it is completely feasible!

Development Tools

Unfortunately the Development tools aren’t what they should be for such a used Platform, so much so that the community has had to lend a hand! I advise you to get familiar with the tools that are available and their limitations. I also advise you to take a look at what could be possible in the future with a community project to build the Ultimate SharePoint Development tool!

There has been some sneak peeks into VS2010 (and VS2010 UI look and feel) as well as the introduction of VSeWSS 1.3 CTP which has come along way from VSeWSS 1.2. But the community still seems to be backing WSPBuilder very strongly due to the limitations of the VSeWSS product paradigm where it doesn’t conform to the 12 Hive structure like WSPBuilder and STSDev.

Community Content

As discussed in a recent blog post, the SharePoint community is simply unprecedented against any other platform out there! I have never seen a community so eager to share their knowledge. Go to Google and do a search for OpenText ‘RedDot CMS’ or ‘SAP’ or ‘Business Objects’ and see how much information is online to help the community on implementing that platform. There are 500+ blogs, forums, the SharePointDevWiki.com, podcasts and webcasts, I listed a few below but keep up to date with this list here.

Blogs

At a minimum you should read these blogs to keep up with SharePoint Customisation and Development:

• Microsoft SharePoint Team Blog
• SharePoint Designer Team Blog
• Andrew Connell (WCM)
• Heather Soloman (CSS/UI)
• Joel Oleson (Architecture)
• Mike Gannotti
• SharePointDevWiki.com
• SharePointMagazine.net
• EndUserSharePoint.com

Podcasts

• SharePointPodShow.com – click here listen to my interview
• MOSS Gone Wild

Webcasts

• Channel 9 – SharePoint
• Mike Gannotti (Webcasts)

Forums

• MSDN SharePoint Forums

Twitter

• Twitter Grade | SharePoint – note to SharePoint Twitterers – make sure you mention SharePoint in your profile!

Training Opportunities

There is an enormous amount of options with regards to training in SharePoint Customisation/Development.

Classroom Based

Classroom based training is spreading like wildfire with a variety of options in most countries across the World. These courses tend to focus on the Framework fundamentals currently rather then leveraging the tools to give Developers a grounding…without this, and knowledge just of the tool would mean that debugging code would be incomprehensible.

Online Based

Microsoft along with other Vendors are providing lots of rich online training, including Virtual Labs. As a trainer myself, I find that online training is not suitable for everyone and that class room training supported by a trainer who knows the platform inside out is a lot more valuable.

As I’ve mentioned before there are some great places to start learning:

• Do Less, Get More, Develop on SharePoint
• Ramp Up
• Patterns & Practices: SharePoint Guidance
• SharePointDevWiki.com

There are paid labs too:

• Microsoft e-Learning: SharePoint
• Ted Pattison Group

Books

It seems every time I check Amazon there is another SharePoint book being released. They are getting more and more specific to the particular capability areas of SharePoint such as BDC, Workflow, InfoPath which allows Developers to deep dive into the areas they are trying to implement.

Check out Amazon for SharePoint or the SharePointDevWiki.com book list.

The Cool Stuff to play with in the Toy Box

There is plenty of cool activity in the development space to keep us Developers happy and challenged…which will obviously need keep passionate about the Platform. It is also a great way to differentiate yourself in the SharePoint Community as mentioned when listing the bloggers out there.

Silverlight

Silverlight is making inroads into the Internet with its powerful Video Streaming technology but also because of the implementation process that separates Design from Development. There has been some posts already surfacing on integrating Silverlight into SharePoint and also rumours of SharePoint 14 improving the UI using Silverlight.

TDD

As mentioned above, TDD is a hot topic, and would also be a great area to focus your existing skills on and apply them to SharePoint Implementations. I encourage you to check out the posts around on TDD.

WCF

WCF is still relatively new and with those long horrible xml configuration files going to take a while for the majority of Developers to move away from standard .NET Web Services. SharePoint doesn’t support WCF out of the box but there are posts out there on this.

Azure

A post for Developers wouldn’t be ‘cool’ if I didn’t mention Cloud Computing SharePoint Online is SharePoint in the Cloud. There are plenty of post on it and what you can/can’t do if the platform is hosted up in the cloud.

jQuery

So I caused a bit of a storm in a teacup with my ‘jQuery: the SharePoint Band Aid’ post. jQuery + SharePoint is not going to go away and there are some great examples of how powerful it can be. Microsoft have picked up jQuery and are running with it for SharePoint 14 also.

PowerShell

PowerShell (PoSH) is another scripting language that seems to have taken the SharePoint world by storm. If you are a PoSH wizard, then you should start showing off your stuff by manipulating the SharePoint Object model. Check out these PoSH posts to see what others are already doing. SharePoint 14 will also have a lot of PoSH stuff going on for you to leverage.

Conclusion

So hopefully this gives you a feel for what SharePoint can do for you as a Customiser/Developer and also where to find more information to help you.

I encourage everyone who is going down this path to help collaborate on the SharePointDevWiki.com to make experiences for new people moving in this direction easier in the future.

It’s been a long while since I wrote the last part and had to find myself reading through all three parts again to realize how much my SharePoint knowledge has matured since then. This is something familiar to a lot of people in the SharePoint community that are evolving at a rate of knots with the Platform.

You may already be aware that I have started a SharePoint Development Wiki that I am encouraging the entire community to contribute to. You can anonymously add comments to any wiki page content or can sign up for free and instantly create/edit new wiki pages. I will reference various wiki pages in this article and encourage you to add comments or content if you have things you’d like to contribute.

The ‘Leveraging Levels’

This part will try and identify the main levels of leveraging the SharePoint Platform. As discussed in Part 3, there are plenty of different SharePoint People/Roles out there which are broken down into how you interface with SharePoint:

· SharePoint Site Web User Interface

· SharePoint Designer Interface

· InfoPath Designer Interface

· Visual Studio Interface

· SharePoint Central Admin User Interface

· STSADM Interface

· PowerShell Interface (direct to Object Model)

As I highlighted in Part 2, there are plenty of “quick wins”, medium term and long term solutions that can Leverage the SharePoint Platform. You may notice that the “quick wins” can all be implemented using the Web Interface, albeit they are made easier by SharePoint Designer and STSADM in some circumstances (mainly for simplified/wizard development interface and automated deployment respectively).
One thing to point out is although it might make deployment more manageable, it does require significantly more skills and more importantly more liberal access to servers.

Limitations of the ‘Leveraging Levels’

I came across a great quote on Twitter the other day which stated that “he spent all his time coding around the limitations of the SharePoint Platform”. I follow the same train of thought as many others on this one and that is that SharePoint is a Platform that is there to be leveraged. It is the building blocks to create solutions and it is not meant to provide full enterprise solutions out of the box on installation. I think this is where a lot of Organisations perceptions of SharePoint are incorrect, as Organisations do not realise the effort that is required to get a full blown solution operational in SharePoint. Organisations overestimate the Platform out of the box functionality and underestimate its complexities and do not provide the correct level of training to the administrators, developers, power users and end users.

On the SharePointDevWiki.com there is a wiki page that outlines the different Levels that you can Leverage the SharePoint Platform and highlights what can be done and can’t be done. What this highlights is that there is significantly more “leveraging” available when you start getting into Solution Packages (.wsp’s) and the Object Model. Please keep in mind that this is only available in the Visual Studio and PowerShell interface (or with Gary LaPointe’s STSADM extensions and other 3^rd Party Products).

When deciding on which ‘Leveraging Level’ you choose, please take into account the limitations – as this will lead to dead ends in your project where you simply can’t push the Solution any further without changing paths and using another ‘Leveraging Level’. Sometimes dead ends can be mitigated by hacking away at the ‘edges of the Earth’ around the ‘Leveraging Level’ you have chosen for the project, but be aware of the risks of these hacks with regards to upgradeability of the Platform. Another useful wiki page is the Comparisons of Implementation Approaches which highlights the pros and cons of using each ‘Leveraging Level’.

Source: SharePointDevWiki.com – SharePoint Implementation Approach Comparison Chart

SharePoint Development vs SharePoint Customisation

Another interesting area that has been discussed recently is related to the ‘Leveraging Levels’ which dictates what the difference is between Development and Customisation. Mark Miller put it well by saying anything that can be done without touching the SharePoint server, for instance, not modifying the 12 hive, inetpub or GAC is a customization. EndUserSharePoint.com focuses on this approach in their articles.

A lot of organizations do not want to run the risk of going further than customization due to the complexities of configuration management. Be aware of the limitations of going down this route. Another common reasons to do it is because of skill sets, when Organisations bring in external expertise to implement a solution, they often want to take on the support internally. This will obviously mean sticking to the skill set of the internal staff which has its limitations also. This is covered in more detail on the Defining SharePoint Development wiki page.

The People and the ‘Leveraging Levels’

As discussed in Part 3, I have found that the People tend to grow with the layers:

From this table you can see that the skills required for each Person outlined in Part 3 varies significantly. This is just one way of slicing through the implementation approaches and its complexities, so please don’t underestimate the intricacies of the Platform.

The ‘Leveraging Levels’ in more detail

SharePoint Site Web User Interface

Requirements

· Local Access to SharePoint Site via Web Browser

Skills Required

· Understanding of SharePoint Site Collection Architecture

Limitations

· Manual stepsrequired, so in a scenario where you want to add a web part to 50 internal Site home pages, the user is going to have to repeat the steps 50 times, once for each Site within an instance of a Site Collection.

Examples of use

· Creating Sites within an instance of a Site Collection

· Adding Web Parts to pages within a Site that is part of an instance of a Site Collection

· Creating List Templates, Content Types, Site Columns in an instance of a Site Collection

SharePoint Designer Interface

Requirements

· SharePoint Designer Client installed locally

· Local Access to SharePoint Site via Web Browser

Skills Required

· Understanding of SharePoint Site Collection Architecture

· CSS, XHTML, ASP.NET (Page Layouts, Master Pages)

Benefits

· The User Interface is a lot more powerful and easier to operate than the Web User Interface and more options exposed.

Limitations

· Manual steps required, so in a scenario where you want to add a workflow to a List within 50 Sites, the user is going to have to repeat the steps 50 times, once for each List within a Site within an instance of a Site Collection.

Examples of use

· Creating a new Page Layout and Master Page for an instance of a Site Collection

· Creating a Basic Workflow on an instance of a List within a Site that is part of an instance of a Site Collection

InfoPath Designer Interface

Requirements

· InfoPath client installed locally

· Local Access to SharePoint Site via Web Browser

Skills Required

· InfoPath development

· VB Script experience

Benefits

· Lots of functionality that is typically required for Business Forms and extremely fast to prototype forms rather than traditionally writing ASP.NET forms.

Limitations

· Often the forms created require extra functionality that is not available without heavily working around the features of InfoPath.

· Manual steps required, so in a scenario where you want to add the Travel expense form in a List to each of the 30 Department sites, you will need repeat the steps to create the List and deploy the InfoPath form for each Site within an instance of a Site Collection.

Examples of use

· Creating Business Forms e.g. ‘Leave Request Form’

Visual Studio Interface

Requirements

· Requires access to SharePoint Server to install Visual Studio on directly (recommend a Development Virtual Machine)

· Requires WSS SDK and MOSS SDK

· Remote Access to SharePoint Server required (for deployment)

Skills Required

· C#/VB.NET and XML experience

· Understanding of the SharePoint Object Model

· Understanding of the SharePoint Solution Package API

· Optional: CAML, XSLT, CSS, XHTML, Web Services

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Limitations

· To do what you can manually do in the Web UI or SharePoint Designer often takes a lot longer to construct in a Solution Package within Visual Studio.

Examples of use

· Advanced Workflow

· Creating Feature Receivers to provisioning elements e.g. in a Site

· Creating Custom Actions to modify user interface of a Site

· Creating List Templates, Content Types, Site Columns programmatically

SharePoint Central Admin User Interface

Requirements

· Local Access to Central Admin Interface via Web Browser

Skills Required

· Understanding of SharePoint Architecture and Topology

· Experience with SQL, Active Directory, Networking , DNS, Firewalls

Examples of use

· Configuring SharePoint Farm

· Configuring Shared Service Providers for Enterprise Search, My Sites, BDC, Excel Services

STSADM Interface

Requirements

· Remote Access to SharePoint Server required

Skills Required

· Same as ‘SharePoint Central Admin User Interface’

· Experience with command prompt and .bat files

· Understanding of STSADM commands available

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Examples of use

· Configuring SharePoint Farm

· Configuring Shared Service Providers for Enterprise Search, My Sites, BDC, Excel Services

PowerShell Interface (direct to Object Model)

Requirements

· Remote Access to SharePoint Server required

· PowerShell installed on Server (included in Windows Server 2008)

Skills Required

· Experience with PowerShell scripting

· Understanding of SharePoint Object Model

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Examples of use

· Programmatically adding Web Parts to Pages in a Pages Library

· Programmatically adding Files to a Document Library from a File Store Directory with Meta Data into the Columns of the List Item

You can see from the limitations that are listed that it highlights the issues of constructing complexed Sites with forms, lists and workflows as one scenario. It immediately highlights the benefits of using Solution Packages within Visual Studio for repeatability and automation of construction of these sites. One thing to take into consideration which comes up immediately with Organisations with more than one environment (e.g. Dev, Test, Pre-Prod, Prod) is the time it takes to do things manually over having these things automated and repeatable.

In Summary

Hopefully you’ll have an idea of the different leveraging levels in SharePoint Platform now. Next month I will place this content on the wiki page to allow others to contribute to the requirements, skills and examples as I’m sure there are many more. This is just a starting block.

This the third post of a six part series on Leveraging the SharePoint Platform. In the last post I explained some of the great things that can be implemented. In this post I will introduce the Governance, the People and the Approach that needs to surround SharePoint.

I hope from reading the first two parts you are under no illusions on the scale of the SharePoint Platform. With this post I hope to point to some great resources out there both from Microsoft and the awesome SharePoint Community.

The Governance

Microsoft defines Governance as “the set of policies, roles, responsibilities, and processes that you establish in an enterprise to guide, direct, and control how the organization uses technologies to accomplish business goals.”.

You’ll notice from a lot of the references I use in the post are all 2008, the reason I point this out is because the latest version of SharePoint has been out since November 2006 and it has taken this long for Microoft to raise their game and provide assistance in this area. SharePoint could quite easily become the next SAP behemoth platform that people talk about and never witness being rolled out nto Production (apologies for any SAP lovers out there – I’m sure you say the same thing about SharePoint).

There seem to be a collection of sites dotted among the Microsoft network regarding SharePoint Governance:

• Code Plex
• SharePoint GearUp
• TechNet
• Office.Microsoft.Net
• and more from the entire Internet at diigo.com/user/jthake/

Microsoft have published a great SharePoint Governance Checklist Guide that offers a lot of information around the Platform. They also have provided a template Governance Plan that can be used at the initiation of the project.

There’s plenty of information in the links I’ve listed above and rather than me regurgitate it all here I’ll let you read these at your leisure.

The People

This is an area that is covered by the Plans and Checklists that Microsoft provide, but I don’t believe they are realistic. The problem I have had with most engagements I have been involved with or witnessed around me is that SharePoint is treated in isolation to the rest of the Technologies around it. To emphasise this point further, most environments I have been in even have a separate SQL Server instance just for SharePoint Databases rather than leveraging existing server infrastructure due to the uneasy nature of DBAs not knowing what SharePoint does because Microsoft state that you shouldn’t touch the Database Schema in ANY way.

With this isolation also becomes resource islands and the common pattern is that the person/role who installs SharePoint, also becomes the person who supports it and keeps it operational. Now in a perfect World, and in Microsoft Plans and Checklists, this would be divided up into separate resources and transitions would occur at various phases to make up a ‘Tactical Team’.

As I highlighted in my first part in this series, SharePoint spans multiple Tiers, so immediately, you can see there’s a lot of specialists skills required that span multiple Microsoft Technologies which alone have their own sophisticated exams and certifications. Various bloggers out there have tried to define this:

• Sharee English
• Becky Isserman
• Eric Harlan

(Please add more in the comments of this post)

All of these approaches are valid and some take it from the Roles and Responsibilities approach and others take it from the Technical Background. Sharee’s approach in my mind gives the breakdown I have seen naturally evolve in various SharePoint roll outs I’ve witnessed.

The biggest problem I’ve seen with the isolation and break down of personnel is that SharePoint always takes the blame, because although it is in isolation, there are some shared resources because it shares resources such as the underlying network, Exchange, ISA, Backup and Active Directory. Also, it just isn’t a full time role for each isolated tier such as SQL, ForeFront, SMTP and Windows Server.

What do I mean by “taking the blame”…so a User submits a support call to say the Company Intranet is running slowly  (typically they even know it’s SharePoint and say it’s SharePoint running slowly), this immediately points the blame at SharePoint. Looking at the tiers in the diagram you can see that potentially it might be the underlying architecture that is the issue. This will involve various experts getting involved and working as a team to resolve the issue. So many times I’ve had experts in particular areas going “everything is fine” to later find out that their area was the reason, because other experts have invested hours of time proving to the nth degree it isn’t their technology.

This ‘Tactical Team’ would also include Developers who as Microsoft put it:

“Technically talented people both willing and able to customize, personalize, and use SharePoint in a manner that fulfils the business opportunities as identified by the strategy team. This team is a loosely-knit community of developers with varying degrees of proficiency in software development. Members can range from highly skilled programmers to technically savvy end users in charge of personalizing departmental team sites. Skilled developers will handle large change requests, new features, and program management while ensuring adherence to standards.”

This did make me laugh and also made me feel very self important. I’m going to cut and paste this into my Profile for future reference! In all seriousness, I don’t believe that having ‘Developers’ is breaking this role up enough. As mentioned in my personal blog there is more than one way to skin a cat in SharePoint. Most of the approaches set SharePoint Developers apart from each other, these are (and not limited to):

• Web User Interface Developers – everything is done within the User Interface using OOTB Web Parts, JavaScript and done directly into production environment.
• Site Template Developers – slightly more advanced than above, involving packaging up Site Templates that can be reused.
• SharePoint Designer Developers – everything is done from with SharePoint Designer and migrated using Content Deployment API or similar tools.
• Visual Studio Developers – everything is a Solution with Features and Powershell automated build scripts

There’s been quite a bit of discussion on the best approach to actually ‘skinning the cat’ and Chris O’Brien has put some great points forward on the table.

I also believe that with these customisations there is some relevance to what was discussed in the last two posts around the SharePoint Capabilities. Most of the SharePoint MVPs have a specialist area within the Platform and may understand the other areas principles but never implemented them. With this in mind I think it is wise to understand the risks of putting a fresh SharePoint Developer onto their first Business Data Catalogue or Enterprise Search project. The current SharePoint certifications really don’t go deep enough into each capability and I’d like to see more specialisation in each of these with a core WSS Development exam.

Project Managers and Development Team Leaders should be aware of the strengths of their SharePoint Developers and try and identify the gaps in their team based on the requirements of the Organisation. This is further confused by the lack of resources in general in the SharePoint market and the push from recruitment firms and misleading CVs with unexperienced Developers. Joel Oleson makes some valid points about this issue which also has a HUGE discussion thread. Microsoft are also trying to combat this problem by encouraging existing ASP.NET developers to get onboard, this site is a great resource for people ramping up on SharePoint.

Basically, if you have one thing to take away from this section, please be aware of the multitudes of Developers out there and what type is going to suit your sized rollout whether bringing them in-house or outsourcing.

The Approach

Joel Oleson is one of the greatest SharePoint Community Members out there in my opinion and has some great posts around this whole area. Way back in October 2007 he announced the MOSS Deployment Plan sample.  Before you open it, bear in mind that this has the kitchen sink of tasks in there, but also keep your eyes open as this project plan has a total of 6452 hours split between 10 different resources. Again this break down doesn’t seem to align with the other Microsoft Plans and Checklists which isn’t going to make this very easy to use without some work.

Again, with all the references I’ve linked to, I just want to highlight two main core approaches to rolling out SharePoint into the Organisation. You have the traditional Waterfall model and the Agile model. The  Agile model attracts a more iterative approach, which works well with SharePoint due to the features you get out of the box and the speed in which you can get things up and running compared to a more traditional project where you are building everything from the ground up (I will discuss this more in the next part in this series).

As with any Requirements Gathering exercise, Business Users think they KNOW what they want from a system, but often need pushing to be able to explain EXACTLY what they WANT and also sometimes need to be RECOMMENDED what they NEED. Erik Swenson does a great job of highlighting some possible decisions that need to be made simply on the User Interface, before you even start getting into functionality requirements of a particular sub system.  My fellow Perth blogger Paul Culmsee also offers some advice with a great sense of humour and bitterness on this.

By following an iterative process, where you deliver in small chunks what a Business User asks for produces more responsive and early feedback. This allows the system to evolve as the Business User sees the interface working for them with their data. These prototypes can then be taken away to give them stability and shelf life to go into production.

This iterative approach does not lend itself well to the Waterfall method where there is a more formalised process up front of: gather requirements; documenting these into a Functional Design Document; then handing this to someone to produce a Detailed Design of how it will be implemented by the SharePoint Platform.
Traditionally Business Users don’t actually get to see or interact with anything until well after the Detailed Design is complete and the Implementation is in full swing. From here, it is likely that requirements change and scope creep occurs and then Functional and Detailed Design documents are immediately out of date.
A lot of SharePoint projects are very poorly documented due to the ease of which it is implemented and changed and this is something to highlight early on to the entire team…that Documentation is required! It is important to treat Releases as strict as you would a ASP.NET project for various reasons:

• Developers can look in source control and see what’s in Test/Production at any given time;
• A sense of achieving a goal if you have specific release dates;
• Formalised testing done as part of release process;
• If things are packaged and automated properly, SharePoint Admins can be handed the package to run in Test and then once approved run in Production…rather than Developers getting involved;
• Producing an As Built Document of the release, so that if a new team comes in to support it, they don’t have to go digging through code, environments and e-mails to work out what it is doing;
• All of which encourages a formal transition to support for the release.

I would recommend treating the installation of SharePoint as a completely separate project to any Solution you wish to deliver to the Organisation. The main reason for this is that it often involves very different resources than those involved with creating the Solutions on top of this Platform.

The Waterfall methodology does work well when it comes to the Infrastructure and Setup of the Environments. Many Integrators out there repeatedly do this for new customers who have purchased SharePoint licenses and have formalised approaches for this. I would strongly agree using an Integrator, rather than doing this internally as a self learning exercise, due to the complexities of the setup. It may look like a simple Wizard you run, but there are plenty of minor details that can cause all sorts of havoc later down the track. As mentioned before about the isolation, this is mainly due to the complexities of the platform which runs a risk of having more applications servers running on the environment leading to too many permutations when it comes to fixing a problem.

Scenario

At this point I’d like to raise a scenario which I’m sure most SharePoint Integrators reading this will nod their head repeatedly at.

So Microsoft have finally managed to persuade you to purchase the MOSS 2007 Standard/Enterprise license and the IT Manager has the media in his hands. The various technical whitepapers have been read and hardware has been purchased for a Database server and a Application server.

The Server Admin is sent off to install Windows Server on the two servers. The database server is then handed off to the DBA to install SQL. The thumbs up occurs and the SharePoint Admin installs MOSS on the Application server. The SharePoint Admin gives the thumbs up and they all get together to ensure that everything is being backed up.

A quick company logo is added to the header of the OOTB Blue SharePoint Theme and team sites are created for company divisions: Public Relations, Human Resources, IT and Finance. Division Managers are given full control of their Division Team Site and all members of the Division governed by Active Directory are given Contribute access.

Over the course of 3 months, various ad-hoc projects occur:

• Custom Web Parts have been added to particular Divisions;
• modifications are made to the look and feel using SharePoint Designer;
• InfoPath forms are suddenly replacing Word Documents for Time Sheets and Annual Leave forms with custom SharePoint Designer workflow;
• Columns have been added to certain Division Document Libraries;
• And the list of Business  Users with Power goes on…

6 months later, Users start complaining:

• Users can’t find documents in the search; and
• inconsistencies in how Document Libraries are set up make it hard for Users to know what to do;
• Users don’t know the most appropriate Document Library to use because the person who set them all up has left the organisation;
• Users want extra functionality out of the Web Parts/InfoPath Forms that have been installed, but the person who installed them has left;
• Also, Patches are released for SharePoint that need to be put on and fears around customisations that have been created being lost occur.

So a SharePoint Development Team is brought in-house or outsourced to follow up on these requirements. Immediately the team require a Development environment and the Project Manager wants a Test Environment for testing the updates and deployments before they go into Production. Issues are raised on the best ways to get Deployments from Development to Test to Production and also how to get Content from Production down to Test down to Development to give some realistic working data to test on (more on this coming on my blog).

18 months later, the CIO starts to raise concerns about how all this is being controlled and wants to start rationalising what people can and can’t do (from the list above) without going through a formalised process. This in my opinion is too little too late.

What I am trying to illustrate here is that if you put SharePoint into an Organisation you have to start Governing it straight away and take Roles and Responsibilities seriously. To the point where it is defined in Job Roles throughout the organisation and part of the Handover process when personnel move or leave the Organisation. The OOTB permissions that are giving to an “Owner” of the Division is far too much and should be giving to Owners at the IT Departments discretion.

In Conclusion

At this point, it is also worth mentioned that there is a programme that Microsoft have put together called the SharePoint Deployment Planning Services program. Basically Microsoft will pay its Partners to deliver a qualifying SharePoint deployment plan to their customers through on-site consulting sessions. The clients must have Software Assurance and the length of the session (one, three, five, ten or fifteen) depends on the agreement. So if you have Software Assurance please speak to your Microsoft representative and make the most of this opportunity.

Microsoft have also released this PDF on Risk and Health Assessment for MOSS Server by Microsoft as part of their Premium Support package. This again is probably to combat those environments that just aren’t set up correctly, for example hitting 100% CPU with 5 users or Maxing out on RAM.

The recent success of the Best Practices Conference in the US last month also pays testament on the awareness being raised within the Community. I have also noticed that plenty of training companies out there are also offering specific SharePoint Planning and Governance courses such as Ted Pattison , Set Focus, Mark Schneider (please add more in comments below).

The next part in the series will talk more in detail about the tools out there and how to leverage them.

Until next time,

Jeremy Thake

http://wss.made4the.net/ | http://www.readify.net/

This the second post of a six part series on Leveraging the SharePoint Platform. In the first post I introduced at a high level the Capabilities, the Editions, the Infrastructure and the API of the SharePoint Platform. In this post I will give my own opinion on what capabilities to start with and what ones to use Open Source/Partner Solutions with or to wait for SharePoint 2009.

I’d like to point out up front that this is my own opinions on what capabilities to start with. All organizations may start with a particular Solution in mind which has got them the budget to go ahead and implement what they require using the SharePoint Platform. These recommendations demonstrate the maturity of the Capabilities of the Platform and it’s complexity/immaturity in others.

In terms of leveraging Open Source and Partner Solutions on top of SharePoint Platform, I’d also like to point out that this series is by no means going to be a full listing of available options. When I stated ‘best of breed’ solutions in my previous post, I wasn’t intending to include all of them. The Solutions that I listed are the ones in my mind that are getting exposure in the 300+ blog feeds that I read every week as well as in case studies and the local Australian marketplace.

OK, so now that I’ve covered my bases on those points, lets get started I guess. As I discussed in the previous post Microsoft try and make SharePoint out to be everything to everyone. Reading through their six Capability areas it pretty much covers off most things you’d want to implement in your business. What Microsoft don’t really tell you is what is there “out of the box” with a little configuration, and what takes a degree of effort, to fulfil your needs. This extra effort can involve considerable planning utilizing the OOTB technology or having to expand on top of what is there with custom development involving specialists resources.

As I have quoted in many user group presentations and client meetings…SharePoint is not best of breed in a lot of the areas it markets itself in and only really ‘ticks the box’ in terms of functionality in some, the big advantage is that it is a unified Platform. The unified Platform argument doesn’t really stand up for itself as well as it used to though when you think of Wikipedia, Digg, Twitter, Blogger and other consumer platforms that happily coexist and also with the large Enterprise push on Service Orientated Architecture.

I will try and elaborate and provide sources of information by breaking up the capabilities and their sub areas with reference to various case studies and articles. As with most organizations that invest in a technology they wish to see results and fast…so as well as highlighting the strengths of the platform I will also highlight the ‘Quick Wins’ of each capability area to further point your rollouts towards a high ‘SharePoint Adoption’ with visible Return on Investment.

I’ve also added some star ratings in the Quick Wins to show what I would say are the easiest things for an Organization to plan and configure based on no experience in SharePoint with someone who can follow instructions. 1 star is easy and 5 stars is most complex and really needs someone with SharePoint experience. In later parts in this series I will elaborate more on this, it basically gives you a more realistic view of what is something Business Users can do over what requires “SharePoint Ninjas”.

Collaboration and Social Computing

Quick Wins

Project Site

There’s no story more compelling than “eating you’re own dog food” so why not use SharePoint to plan and manage your SharePoint rollout? Obviously this does entail some prior planning to get the hardware and installing it somewhere. It doesn’t stop you having a small WSS 3.0 instance on a Windows Server 2003 machine with it’s own Db to start with and migrating it later. There are lots of advantages to this, the one that comes to mind the most for me is that it gets you and the team rolling out SharePoint as consumers to the platform rather than understanding the technology and never actually using it day to day. For instance, one thing that I realized very quickly is that OOTB SharePoint Calendar’s don’t aggregate in the web interface, but Outlook 2007 has a way to load up multiple calendars and overlay them.

Incoming E-mail

E-mail integration is a very powerful way of collecting information and can automate a lot of processes where a Admin Assistant would be taking received email and saving the attached files to a file share/document library. Once you have incoming email configured on your server at installation and set up delegation in Active Directory it’s once configuration step away from any list in SharePoint acting as a drop box for email.

• Incoming Emails

Surveys

As well as running the SharePoint rollout project within SharePoint, there are other technologies you can leverage early on to gain feedback. SharePoint Surveys for Quick Polls are extremely easy to setup and report on. I will point out here though that the rendering of these surveys are very very limited and please don’t think this will replace tools such as Survey Monkey with branched questions etc.

• A useful article on customizing views on Surveys

Famous 40 Templates

If someone can point me to a SharePoint blog anywhere that doesn’t have a post about the Famous 40 Templates I’ll buy them a beer! It’s pretty much where all “dabblers” start off. These templates are not only a good way to kick start a particular themed solution, but for developers are a great way to look under the hood and see how it’s all hooked together.

• Microsoft SharePoint Templates

Medium Term

People and Groups

The ability to have Groups within SharePoint containing Users (AD Users or AD Groups) and allowing End Users to manage them is a large jump. Management of Active Directory is a beast of it’s own and this is typically controlled by Operations…so why would this be any less scary? Unless you can have extremely clear guidelines on this it will turn ugly and will lead to a phenomena not far from Facebook “Friends”. How many of you just permanency add Facebook Users you see but never actually go back and look at their profiles etc. These people can see your entire profile, imagine that concept internally to an Owner of a Site that has Information there and has control of who can and can’t see it by adding Users and Groups at their disposal. I would recommend keeping Operations control over security and permissions of SharePoint based on AD groups and roles until the Information Architecture matures and stabilizes.

• Security Planning

Long Term

Presence

Presence is something that if you’re a early adopter of Unified Communications, this is a great Quick win, but more likely this will be something to further leverage the SharePoint Platform when your organization finally gets approval to roll out UC.

What to wait to mature

Wikis

The Wiki technology in SharePoint is one of the biggest features I would claim is a “tick in the box”. In comparison to most other Wiki platforms out there this is extremely week. The HTML editing and ability to insert pictures/objects into pages pushes people away to using other platforms or Microsoft tools such as OneNote. I would recommend either waiting for this to improve or looking at 3rd Party Products.

• Wiki

Blogs

This is another “tick in the box” for me, yes you can have multiple blogs and yes they’ll support RSS feeds like all SharePoint lists, but OOTB you cannot get RSS feeds for categorised posts and you can’t have more than one category per post.

• CodePlex CKS:Enhanced Blog Edition

Tagging + Rating

Pushing further on blog posts and multiple categories is the whole social space around tagging items. Take digg, diigo, de.li.cious as good examples of this technology at work. OOTB SharePoint doesn’t cater for this but fortunately the Open Source community at CodePlex have started to offer solutions.

• Tags
• CodePlex Rating

What to avoid early on

Wikis + Blogs

Not just from a limited functionality perspective, but also from a paradigm…these technologies are not something that will be easily adopted in an organisation. My suggestion would be to get people comfortable from the move away from File Shares and E-mails for storing Information before suggesting anything as “high-tech” as wikis and blogs.

Portals

Quick Wins

Intranet – Phase 1

It is important to set very tight scopes of work when creating your Intranet and not to try and produce the masterpiece in your first attempt. I would recommend starting with the usual: HR site as a like Employee Self Service Information pages; Corporate Affairs posting Organization news; and then a very basic site template with a homepage for each individual Business Unit where they can upload Static Documents, that have been approved externally to SharePoint, that may be used by the Organization e.g. Finance for Expense Claim forms etc.

Mobile workforce

This is a great quick win for any Organization with a mobile workforce. All the SharePoint interfaces will work on a mobile operating system, and especially so on Windows Mobile Platform (no surprise there). Admitted it isn’t the best interface in the world, but at least the information is out there for these devices to consume.

Document Aggregation Web Parts

Not for one minute am I saying that Document Aggregation Web Parts are the answer to your Document Management issues, but in the sense that you can use them to show views of multiple areas within the Intranet in one location will make findability that much easier.

3rd Party Web Parts

Most Organization will have a bucket full of systems and most major systems now have some sort of integration with SharePoint and they don’t currently, are racing away in the developer dungeons to get some. This again, is a great way of presenting information in a unified place without too much effort required.

Medium Term

Intranet – Phase 2

After the initial phase is ticking over nicely and you have Business Stakeholders in place for your specific areas (dependent on the taxonomy you go for), you can now start to increase the functionality available to them. I would start by allowing them to make requests for particular systems to be migrated underneath their areas such as Image Libraries, specific Custom Lists to store information usually stored statically in Excel spreadsheets etc.

MySites Phase 1

I think the general consensus is that most people out there now are comfortable with Facebook and the concepts behind having a profile. MySites give Users their own profile within SharePoint. I would start by giving all individuals in the Organization a MySite and limiting their Site Allowance to an agreed Mb allocation. They can then go in and utilize the area to update their profile information, groups and colleagues from here. Providing a simple Document Library will also give them an area to start to get comfortable with the process of working on documents within the SharePoint platform rather than within their specific area site visible by everyone.

• MySite Architecture
• Customising Look and Feel

Long Term

MySites Phase 2

Once Users are comfortable with editing their profile you can start opening up the functionality available to them to creating their own sub sites/workspaces and ability to create multiple pages. These sites can then be opened up and Users given control of who can see their sub sites/workspaces to allow them to collaboratively work together and take ownership of the areas.

Role Specific Sites

As with the Famous 40 Templates, there are some example Roles based templates available. These give you a great indication of the power of having Roles based views of Information. The reason I say these are long term solutions is that it takes a large understanding of your User base and Organization to come up with segments and views of Information that will be valuable and worth investing time to develop.

• Roles-Based Templates for SharePoint My Sites – Under the Hood

Extranet Portals

Not for the feint hearted because of all the dependencies on Firewalls, HTTPs, Certificates etc., but can be extremely beneficial to expose Information that is stored internally to the Organization to external parties. There is serious consideration needed here on how this is implemented as there are so many scenarios.

What to wait to mature

“Colleagues and Membership”

This to me is another “tick in the box” area of SharePoint where they wanted to get something similar to LinkedIn and Facebook but just didn’t quite get anywhere near it. I would definitely hold off for SharePoint vNext because I’m sure this will be pushed harder with stronger functionality about the connections with colleagues and also how groups communicate with each other in Team Sites. For now, it gives the ability to add yourself to a group and link to colleagues for everyone else to see.

What to avoid early on

“Biting off more than you can chew”

Global domination within SharePoint is only recommended to the fully trained SharePoint Ninja’s of the World. My only advice here is to start small and tackle one problem at a time rather than pitching SharePoint as the answer to every problem in your organisation. Small goals will lead to small rewards that are tangible and occur quickly, large goals may take years and with little visibility of results until they are fully implemented.

Enterprise Search

Quick Wins

People Search Phase I

By far the easiest win out there is the People Search when you already have Active Directory in place. This can replace your Company Phone list. It is great for finding people by location, department, role or title. One warning though is that it will highlight issues with AD information that may not have surfaced before to End Users!

• Customise People Search Results

Federated Search

SharePoint’s ability to crawl content sources and provide a federated search across all of them is another powerful way of bringing all the Organizations Information together. This information can be web sites (existing Intranets/Internets, custom systems, public Internet sites) and file stores.

Medium Term

Search Results

SharePoint search can also allow you to customize how the search is rendered. This is great if you want to display more properties in your results without the Users having to click into the actual found item to see information on it.

Tailored Searches

Start to provide some tailored Advanced Searches as custom Web Part forms to users that can find those Minutes for a Sales Meeting last month where “Fred” attended. There is a lot of power in presenting different ways of discovering Information in SharePoint.

Long Term

BDC Search

Expose information from external sources via the linked in search capabilities of BDC. It allows Users to be able to get at information that would normally mean logging into another system with another set of credentials. It also means that the  Organization doesn’t have to roll out the thick-click application to all Users machines if there is enough Information exposed via the SharePoint web interface.

What to wait to mature

Faceted Searches

This is an area that crept in during the SP1 upgrade and started life as a sub project on CodePlex and wrapped up into the update. I would suggest not pitching this as the killer app within SharePoint just yet, it’s got some great features that will no doubt continue to mature with the passion behind who’s developing it in future releases.

What to avoid early on

Information Overload

One thing that I’ve noticed on various implementations so far is that often people Index too much information. You may be saying “there’s no such thing”…but there is. Users will use very open ended searches, like they do in Google, and find too much Information. As an Organization you have to be responsible for training Users on finding Information via Advanced Searches and Scoped Searches. There is a lot of great syntax you can add to trim down your results without a advanced search screen. Try and work out some key scenarios of what Users will want to search for.

• Box Fox is in the middle of a great set of web casts on Findability which tries to tackle this.

Enterprise Content Management

Quick Wins

Document Management Phase 1

With a simple Site created you get a Document Library that you can upload Documents to. To familiarize your Users I would recommend starting off with something this simple without complicating the issue with too much with asking for MetaData. Get the Users comfortable with uploading and editing Documents in a web interface rather than a File Share. Organisations often assume that Users will pick all this up quickly but this is not always the case.

WCMS Phase 1

The ability to create an Intranet/Portal and provision various inter-related sub sites comes hand in hand with managing the Content on the pages of these sites. The Web Content Management System functionality migrated from MCMS 2003 have taken full advantage of the Master Page/Page Layout architecture of ASP.NET 2.0 as discussed in Part 1. The ability for Users to use the Page Editing Toolbar to edit pages in designated Web Part Zones can let them go for Gold adding Content. The Users can be as creative as they like by using a Rich Text Editor Control in a Editable Content Area on a Page Layout or they can add a variety of other Web Parts from the Gallery. I would recommend training Users on the basic of Page Editing and showing them how to utilize the basic Web Parts and Editable Content Areas of Page Layouts. Unfortunately there is no easy way to control what Roles of Users can see what Web Parts in the Gallery, it’s all or nothing. I would also limit the Users in Page Creation here and hold this control at Operational level to let them make the decision of whether it’s a page, sub site or existing item etc.

One thing that people do take for granted is the fact that you can integrate WCMS functionality with DMS functionality which is rare in most other competing products such as Documentum and Opentext. This is a great advantage to end Users as the same system training can cover both applications. It almost fuse them as one which is a lot easier for Users because other systems seem frustrating to them with such clear separation where they want to link the two.

• SharePoint WCM
• Andrew Connell’s blog is the best place to start for WCM

Medium Term

WCMS Phase 2

Once the Users are comfortable with WCMS basic functionality you can start opening up the Page Layouts to give them more options. Developing customized Web Parts for displaying videos and flash can give Users a more interactive experience. You will find that giving the Users specific training in further Web Parts available to them will empower them to develop more complex Content Pages…these Web Parts have always been available to them but the majority of Users won’t be comfortable “playing” until they’re shown.

Document Management Phase 2

SharePoint has extremely powerful integration with the Microsoft Office 2007 product line. For instance, when opening a word document, the metadata stored for the Document in the SharePoint List is integrated in the same window, rather having a separate web or windows interface for filling it out. Checking in and checking out documents and other workflow tasks can also be done without reaching back to the web interface.  With this integration it can make moving towards storing Metadata for documents as well as introducing Workflows a slightly smaller step. Again, phasing metadata and workflow separately can also help the learning curve.

Long Term

Information Rights Management

This is definitely something you just don’t turn on. It needs some planning, ownership and control around it. This is something that really should only apply where the functionality is required and lends itself to Records Management which I discuss next.

What to wait to mature

Records Management

It is widely documented and I agree that Records Management was another “tick in the box” for SharePoint to get the Enterprise Content Management capability in play. With no OOTB functionality for Transmittals and Compound Documents you will find most Records Managers not wanting to touch SharePoint with a barge poll. There has been some work to get DoD certification, but this has not been publicly released.

• Records Management Guide for MOSS 2007

Document Imaging

OOTB SharePoint does not have any components that handle Document Imaging. There are plenty of Products out there on the market that can handle SharePoint Document Libraries being the repository for the scanned images and processing them. I think this is an area that Microsoft will want to get into though at some stage.

Multi-Lingual Web Sites

Multinational organizations wanting a full WCMS platform often require Multi-Lingual sites and SharePoint has not got a fully versed answer for this with its Variations functionality in my mind. This functionality will mature in time and come to be more competitive to other stronger WCM products out there.

What to avoid early on

Accessible Web Sites

There are plenty of public Internet web sites out there on the SharePoint Platform but a lot of them have accessibility problems and if they don’t are certainly not using the OOTB JavaScript, Web Parts, Master Pages and Page Layouts provided. There is considerable work involved in getting an accessible web site out of SharePoint currently.

• SharePoint Accessibility

High Load Web Sites

As stated above, there are plenty of public Internet web sites out there now and a lot of them have sub second response times. There is significant work involved in getting these rendering times down this low and mean not using a lot of the OOTB technology. There are various Caching approaches in the Platform that can aide here, but this will only take you so far.

Large File Document Repositories

I remember when the SharePoint 2007 was released and the Database Administrators (DBA’s) of the World were up in arms over the proposal of storing everything in a SQL Database. BLOBS have always been a contentious issue between Developers and DBA’s and this didn’t help the matter. There are plenty of White Papers out there on this, but it really needs considerable planning and effort to ensure that performance of 10Mb+ documents are close to User expectations. With the abilities of SharePoint Search, it is not necessary to store ALL your information in SharePoint and this is something definitely worth bearing this in mind.

• SharePoint and Large Files
• Is the file server dead?
• Configuring Large File Support

Business Process and Forms

Quick Wins

Data Capture with Simple Web Forms

InfoPath is a great tool for getting Developers to build Data Capture Forms quickly. Organization tend to start with simple forms such as: Annual Leave Forms, Time Sheets and Safety Reports. With InfoPath Forms Services it allows these forms to be hosted as a web page rather than being reliant on InfoPath Client. This stops the reliance of a roll out of InfoPath to occur. One thing to bear in mind is you don’t necessarily have to keep the submitted InfoPath form xml in a Form Library, instead you can push data directly into SharePoint List or external data system via web services etc. So the InfoPath Form is simply a dumb entry screen that submits the information collected in a validated way.

• InfoPath Development

Medium Term

Workflow based forms

Once you’re comfortable with capturing information using InfoPath forms you can take the next step into modeling your Business Processes using workflow using SharePoint Designer. This allows you to control the statuses of a form submission such as the Annual Leave form from the Employee to the Line Manager, then to Payroll. The trick here is to keep these processes simple and not to overcook them! Utilizing the creation of tasks in task lists can also prevent the reliance on workflow emails as the only way for people to track what responsibilities they have in the process.

• InfoPath Workflow

Long Term

Empowering Users to Create Forms

With InfoPath comfortably in the Organisation and Users aware of where it can be powerful you can start empowering Users to generating their own InfoPath Forms for their Business Areas.

Visual Studio Workflows

Visual Studio workflows are basically .NET 3.5 Workflow Foundation technology and are a little more involved than SharePoint Designer workflows, requiring .NET Development experience. This allows more controlled deployments of workflows and the ability to extend process steps to do such things as call off to web services or store things in databases that aren’t available with the out of the box SharePoint Designer Workflow Activities.

• SharePoint Workflow

What to wait to mature

Methodology for version management of forms

As mentioned above, .NET 3.5 Workflow Foundation technology is at the core of workflows and can be considerably scary when it comes to version management. For instance, imagine you have 50 annual leave forms submitted and the business decide to add another approval step…does this mean that all existing instances of the workflow need to have this step or just new ones? These kinds of decisions take some “tweaking” when you deploy the package and are things not often thought about until they occur. Some prior planning and waiting for some best practices to come out around this space will assist in the future.

SharePoint Designer Custom Workflows

A drawback with the power of allowing Users to create their own workflows in SharePoint Designer is that they’re not portable and are attached to an individual Form Library List for an individual Site Collection. So designing these workflows in one environment and deploying to another is not possible. This doesn’t fit very well with Enterprise rollouts where testing is required, especially when modifying workflows that are in Production!

• Porting a SharePoint Designer (SPD) Workflow to Visual Studio.Net – Part 1

What to avoid early on

Complex Processes & Large Forms

One thing to bear in mind is that there are limitations of what you can do in InfoPath, simple forms are easy to put together…but more complex forms aren’t! There is certain functionality that doesn’t work when hosted as web services. Also, large scale InfoPath forms can have rendering performance issues and you may want to consider breaking down the data capture over a number of forms rather than one large one. These kind of things take some experience and more than likely some bad experience.

• InfoPath Forms vs. ASPX Pages in SharePoint Designer

Transactional Processes

SharePoint does not have built in support for Transactional processing as a Platform. It is common for various Business Processes to require this especially in Commerce type Systems. It is recommended to leverage a Platform purposely built for this, such as Commerce Server 2007 and simply use SharePoint as a presentation layer which interfaces to trigger such external processes.

• Microsoft have published a White Paper on Configuring and Integrating MOSS 2007 and Commerce Server 2007

High load business Systems

As discussed in the first part of this series, SharePoint can scale out onto multiple servers to allow specific Roles to be isolated and to spread the load of web requests to Sites. Microsoft is building more and more information around this area, but it is recommended that you speak to a Microsoft Partner with experience in this area to ensure that you get the full potential out of your SharePoint Farm.

• Planning and Monitoring SQL Server Storage for Office SharePoint Server: Performance Recommendations and Best Practices and Working with Large Lists in Office SharePoint Server 2007
• Joel Oleson has some great articles around this space.

Business Intelligence

Quick Wins

Excel Services

Have you ever worked somewhere where Excel spreadsheets seem to store the most important Information? Have you ever found they get sent round in e-mails and multiple versions start cropping up and suddenly it’s in a mess? Excel services allows you to web-enable Excel using Excel services. This is an extremely powerful tool and can often simplify who actually needs the ability to change formulas etc in the spreadsheets and who is just a consumer to them. Simple Web Parts can be added to Pages that point to spreadsheets hosted in Document Libraries.  This is a very quick and easy way of getting those Dashboards that all Sales people are talking about these days. Excel services is new in 2007, so expect a host of new features in vNext and therefore expect limitations in how far you can push current functionality.

Filter Web Parts

Filters can be placed on Pages where the Excel services Web Parts are and this will allow End Users to dynamically add filters to the Information be reported on within the spreadsheets hosted in SharePoint.

Medium Term

Key Performance Indicators (KPIs)

Just because the SharePoint Platform can handle generating lots of KPI dashboards, doesn’t mean you should start throwing them together. This needs a true expert in the area of Business Intelligence to ensure that the data is accurate and doesn’t mislead people with incorrect wording. The last thing you want is for your CEO to start quoting how wonderful sales are going, to find out later that the dashboards were taking into account various variables because implementing this was too complicated.

Long Term

BDC Data Web Parts

The Business Data Catalogue not only has hooks into the Search capabilities of SharePoint, but also has functionality for CRUD (create, retrieve, update, delete) type operations with external mapped sources such as ODBC databases. It allows you to display views of data and empowers the User to be able to operate on this data within the SharePoint interface. This means that rather than developing a ASP.NET/Win Forms custom interface with Business Layer and Data Layer type approach, you can leverage the BDC repeatedly for each data source.

• Sahil Malik has a great introduction to BDC

What to wait to mature

Business Data Catalogue

The concept behind BDC is great, unfortunately it is a lot of “heavy lifting” to get the XML up and going for this. Fortunately there are some 3rd Party products out there to help you in this space. I’m sure that Microsoft are busy working in the background to make this easier to work with.

• BDC Metaman has some great articles as well as a strong Product in this space.

What to avoid early on

BDC – Large/Multiple Repositories

When looking at BDC to target multi large repositories of Information and aggregate this within the Search or connecting to it using the Data Web Parts you will have to be cautious. I would advice starting off with some smaller scoped repositories before trying to consume/manage Information from large back-end sources. It is worth bearing in mind that BDC was designed for “Knowledge workers” and not full developers and therefore is not designed to scale or handle complex situations.

• Further Information on a more complex and scalable alternative to BDC is blogged about here.

Platform Services

Quick Wins

Custom Lists

Custom Lists have a lot of functionality that can often enforce structured content for data capture. These features are available in all Editions of SharePoint and can act as a great quick win within an organization. Think of how many “lists” are currently stored in unstructured forms, Excel spreadsheets and Access databases. This can be replaced by SharePoint Lists with Content Types…for securer, versioned, permission based, workflow driven, single source of truth of Information.

Medium Term

Site Provisioning

Many a Developer has spent nights writing code that SharePoint does out of the box to build team sites. Large Enterprise Software houses have also tried to create these, but none are quite as extensible as SharePoint and also don’t leverage the powers of ASP.NET to the level that SharePoint does. This in itself can be a huge advantage to leveraging SharePoint for this type of functionality.

What to wait to mature

Security and Permissions

As discussed previously, the security model can easily get out of hand in SharePoint and one thing you’ll find happening quickly in your Service Desk is support calls raising issues about access to Sites etc. The OOTB tools for discovering permissions for a particular User based on their SharePoint Group Memberships and Permissions applied to these as well as Active Directory Groups is extremely limited. Fingers are crossed that this will be adjusted in vNext, but just be aware of the issues around this and try and keep to a very strict basic security model to save these pressures.

• There are some great tools to help in this space such as Barracuda Tools and Universal SharePoint Manager.

What to avoid early on

Heavy Customization of Master Pages / Page Layouts

There is plenty of Information out there on how to customize the SharePoint look and feel. I would recommend when you start not worrying too much about making it “not look like SharePoint” internally within the Organisation. The main reasons for this is that a lot of the End User training for SharePoint available on the Internet will be easily to relate if the interface is similar to the screen shots in the material they are reading.

• There is no better place to start than Heather Solomon’s blog on SharePoint Design

Until Next Time…

Ben Bradley’s post on ‘What is YOUR Firm’s SharePoint Balance?‘ touched on some great issues around what I would call ‘SharePoint Adoption’ and the balance of ‘SharePoint Power’ between the ‘End Users’ and ‘Administrators’ of the system that is running on top of the SharePoint Platform. In Part 3 I will be explaining in more detail the array of ‘SharePoint Roles’ and in Part 4, I will explain the different ‘SharePoint Powers’ that can be given to these Roles.

http://wss.made4the.net http://www.readify.net

• Part 1 – What is the SharePoint Platform
• Part 2 – What capabilities to start with
• Part 3 – How to start with the SharePoint Platform
• Part 4 – Levels of leveraging the SharePoint Platform
• Part 5 – Why use SharePoint as a Development Platform
• Part 6 – Lessons learnt from Leveraging the SharePoint Platform

What is the SharePoint Platform?

The SharePoint 2007 Platform has been sending a buzz round the IT industry now since November 2006 when it was launched, I won’t go through the history of SharePoint in this series, but it is beneficial to understand how the platform has evolved since it’s introduction in 2001. Marc Andreessen, of Netscape fame, defines a Platform succinctly:

“A “platform” is a system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate.”

This definition is very much targeted at cloud based platforms in the consumer market such as Facebook, Amazons’ S3 and Ning. I think it is a very fitting to description of SharePoint…the amount of times I have been asked “can SharePoint do x?” and thought quietly in my head…”well yes…but it depends how far you want to go with it…”. In this series I hope to get people thinking in structured ways of how they can leverage the SharePoint Platform with some experience and advice to point people in the right direction.

The six SharePoint “Pillars” / Capabilities

SharePoint Capabilities

The six core pillars/capabilities of SharePoint are a good basis to start thinking about what the Platform has to offer. The Microsoft SharePoint site describes the platform in these sections and has case studies focused around them. Below I’ve covered them off in less sales speak and in terms that people outside of Microsoft terminology will understand with direct comparisons to commonly know consumer platforms.

Collaboration and Social Computing

Real time presence; Standard Site Templates; Wikis; Blogs; People and Groups; Calendars; Email Integration; Task coordination; Surveys; Document Collaboration; Issue Tracking; Social Networking

With all the buzz around about Web 2.0, since the evolution of the consumer Internet with platforms such as WordPress, Blogger and Wikipedia, it is no surprise that Microsoft have bet on Enterprise 2.0 being the next big thing. Each of the areas of this capability are by no means “best of breed”, but do cover basic functions expected. The issue here is the expectation of the user base exposed to more feature rich consumer platforms and also the take up of these without mature enough governance.

Portals

Mobile Device Support; Office 2007 Suite integration; My Site personal sites; Content syndication; Privacy and security; Site Directory; User Profiles and the Profile Store; Audience Targeting; Site Manager; Portal Site Templates; SharePoint Sites and Document Aggregation Web Parts; Colleagues and Membership Web Parts

As with the social computing aspects of the first capability, consumer Platforms such as Facebook, MySpace and iGoogle are leading the way here. This area focuses on the Personalization and Customization features commonly found in Portal technology products by providing the ability to create personalized spaces for users. These spaces can be driven by roles based rules, as well as user behavior and user preferences.

Enterprise Search

User Interface; Search results; Enterprise content sources; Relevance; Administration and Management; Indexing controls; Security; People search; Business data search

Enterprise Search has been a large talking point for generations of Platforms. The frustrations around the assumptions that Internet Search Engines find information so easily from millions of pages online when Enterprise equivalents fail miserably. The SP1 and Infrastructure Updates extend these capabilities further with faceted searches and a more advanced administrative web control panel. It also leverages core base platforms such as Active Directory with People Search functionalities.

Enterprise Content Management

Business document workflow support; Document management site templates; Integration with Microsoft Information Rights Management; Document Information Panel; Document Action Bar; Retention and auditing policies; Records repository; Email content as a records; Legal Holds; Navigation controls; Content authoring; Content publishing and deployment; Site templates; Page layouts; Site variations; WYSIWYG Web Content Editor; Slide libraries; Policies, auditing and compliance

Enterprise Content Management has been the driver behind a lot of the major players in the Document Management space swallowing up their smaller competitors such as: IBM with Filenet; OpenText with Hummingbird; and EMC with Documentum. This capability covers three main areas: Document Management; Records Management and Web Content Management.

Business Process and Forms

Browser based forms; Centralized forms management and control; Design once development model; Form Import Wizard; Integrated deployment model for “no code” forms; Comparability checker

Business Process and Forms capabilities focus around InfoPath Forms being hosted within the Office Forms Services as web pages. There are some features of InfoPath Forms that mean that they won’t host as web pages, but this is an extremely powerful way to build basic forms fast and integrate them within SharePoint Lists and therefore fully utilize the Platform Services. Remembering the InfoPath Forms store data in an XML format, it allows powerful manipulation of collections of forms and the ability to use this XML data within the List Column data (metadata).

Business Intelligence

Integrate, flexible spreadsheet publishing; share, manage and control spreadsheets; web based business intelligence using Excel Services; Data Connection Libraries; Business Data Catalogue; Business Data Web Parts; Business Data actions; Integrated Business intelligence dashboards; Report Center; Key Performance Indicators; Filter Web Parts

The Business Intelligence capability focuses around the hosting of Excel spreadsheets online. This has been a feature that really hasn’t made too many ‘blog’ headlines as yet, but once the product has matured I’m 100% positive that it will be a highly used capability of the platform. The Key Performance Indicators (KPIs) and integration with SQL Reporting Services allows for Executive Dashboards makes for a compelling platform of choice.

Platform Services

Configuration management; Administration user interface; Delegation; Re-parenting; Provisioning; Usage analytics; Monitoring; Alert Notifications; RSS Feeds; Rights trimmed user interface; Automated bread crumb; Quick launch bar; Top Navigation bar; Accessibility; Recycle bin; Backup/restore support; Document Libraries; Metadata; Content Types; Application templates; Object Model; Web Services; Change Logs; Job Service; Feature Framework; Solution Deployment Model; Single Sign On

The base Platform of which all these capabilities surround has been extended significantly from SharePoint 2003. The core of which surrounds itself around the SharePoint Object Model of Site Collections, Sites and Webs and the security around these objects. The base concepts of the Platform Services area are where most people will find themselves configuring and creating instances of objects for their solutions. I will be focusing a lot of this series around these core concepts.

The three SharePoint Editions

SharePoint Editions

The above diagram illustrates the difference in capabilities at each Edition of SharePoint. Windows SharePoint Services (WSS) 3.0 is available as an installation for Windows Server 2003 for free. Microsoft Office SharePoint Server (MOSS) 2007 Standard and Enterprise Editions are based on a licensing model (which I will not go into here…best place to start is to talk directly with Microsoft on this one). Microsoft has a more detailed page describing the granular differences between each Edition. To summarize, Enterprise Edition allows Business Intelligence and Business Process and Forms.

Later on in the series I will be referring to these capabilities and when they are typically utilized during the maturity of the implementation of the Platform. One thing to bear in mind is that because WSS 3.0 is free, you do get a significant set of capabilities to leverage that would typically take weeks to build in ASP.NET/SQL traditional development platform. So you don’t necessarily have to jump straight into the large edition to get the functionality you require, that said, to scale your farm out from a one server role to multiple roles requires a MOSS Edition.

SharePoint Architecture

SharePoint Infrastructure

This diagram illustrates the architectural structure of the SharePoint Platform. SharePoint is simply another layer built on top of the .NET Framework and as with any typical dynamic ASP.NET web site, it runs within the Internet Information Services (IIS) 6.0 and connects to a SQL Server 2005 database. Both of which are hosted on a Windows Server 2003 machine.

This series talks about how you can leverage SharePoint and in doing so leverage ASP.NET 2.0 technologies such as Master Pages, Page Layouts and Web Parts that the Platform implements. It also leverages the Windows Workflow Foundations of the .NET 3.0 Framework with a custom SharePoint persistence database. This allows Microsoft professionals to become familiar with the environment based on experience around these technologies, although there aren’t many of us out there who are well rounded in all of the technologies in this architecture. This series will hopefully give you some understanding of the issues in the marketplace of sourcing SharePoint people and also getting the correct fit for the task at hand.

The SharePoint Object Model

Without going too far into the realms of the Object Model, I just wanted to promote the fact that most of the capabilities mentioned above basically are developed using it’s own Object Model which is made up of SharePoint Sites, SharePoint Webs, SharePoint Lists and SharePoint List Items. Thinking in these four terms you can start to structure your solutions to advantage of the methods and events available out of the box of each and also extend them if necessary. In this series I will be describing solutions and how they fit into these four simple objects – trust me it’s not as complicated as 1st Normal Form Database Design!

SharePoint Object Model

Trying to be everything to everybody

From reading this first part, you will probably realize that the SharePoint Platform is trying to be everything to everybody just like the other juggernauts in this space such as Oracle, SAP, IBM, EMC Documentum, OpenText and open source vendors such as Alfresco. This is a big jump from the previous 2003 version that was simply a Portal/Collaboration application and has now incorporated the ASP.NET 2.0 Framework, as well as amalgamating the Microsoft Content Management Server technologies. SharePoint vNext will surely mature some of the new entries into the WSS 3.0/MOSS 2007 version such as Business Forms, Business Intelligence and Search.

As I have mentioned before in my previous posts around the capabilities some of them are simply no where near the best of breed applications that focus on one core capability. Microsoft Partners will continue to build successful solutions on top of the SharePoint Platform to further extend the capabilities such as K2 for Workflow, Nintex for Reporting, Bamboo Solutions for Portal Web Part enhancements, Colligo for Offline Document Management, NewsGator for RSS Readers and Atlassian for WIkis.

The next part in the series will talk more in detail about the out of the box (OOTB) capabilities and how leverage them.

Until next time,

Jeremy Thake
http://wss.made4the.net/ | http://www.readify.net/