Category: Architecture

SharePoint or Application Architecture related posts

Site Topology Planning and Taxonomies

In the previous article SharePoint Site Topology Planning I discussed some of the technical implications of organizing the the sites within one or more applications, site collections, and sub-sites.  The article started to get pretty long so I decided to save the taxonomy part of the discussion for a separate article.

Organizing Sites

In the previous article I addressed different types of content and using that to help segment the sites across applications and site collections.  Within a given application it is possible to provide some meaningful segmentation by configuring managed paths. 

For example, you may segment collaboration sites with the following url structure:

  • http://collaborate.company.com – Collaboration Application
    • /Communities – Communities of Practice Managed Path
      • /Proposals – Proposal Community of Practice Site Collection
      • /Procurement -  Procurement Community of Practice Site Collection
    • /Projects – Projects Managed Path
      • /Alpha – Alpha Project Site Collection
      • /Omega – Omega Project Site Collection

Organizational Hierarchies

Most people understand hierarchies, and most businesses (at least in the west) have been organized in hierarchies for many years.  It is natural for people to think of their organization in this manner, but this may not be the best way to plan for the topology of your sites.

Traditional Intranets tend to go from the largest organizational unit down to the smallest.  There may be multiple divisions, with multiple business units, with multiple departments, with multiple teams, with people that actually do the work.  Sites or portals that go 5 or more levels deep can become very difficult to manage and even harder to use.  Modern businesses need to remain agile with teams always being redefined, combined and split up.  In  most situations it is a good idea to fight the hierarchy tendencies and strive for a flatter structure. 

From a SharePoint perspective a flatter structure with more site collections will make it easier to reorganize sites and structure versus a single site collection with 5+ sub-site layers deep.  As previously discussed Site Collections can be backed up and restored with a high level of fidelity (completeness) compared to a sub-site’s export and import options.  The key to usability and manageability is to find the right amount of segmentation and site collection structure.

Finding Sites and Content in a Flat World

An alternative to a rigid hierarchy is adopting flexible taxonomies with tagging.  Tagging provides a flexible and dynamic method of describing the content and sites that can evolve over time.  A great example of this is a site like StackOverflow compared with the rigid structure of the MSDN/TechNet Forums. The flat structure decreases the chance of duplication and provides new opportunities to view the data in new and unique ways. 

The SharePoint 2010 system full supports tagging without the need for custom or third party add-on components.  I fully expect that these will be a popular feature within the new version. 

Summary

Following the guidance between the two articles you should be able to properly plan your site topology.  Assumptions and business decisions do change, but if you establish the right level of granularity with applications and site collections you will be able to migrate and relocate things as needed.

Related Posts

SharePoint Site Topology Planning

This is the next in a series of articles addressing core SharePoint implementation topics.  I hope that this is valuable to both groups looking to implement SharePoint for the first time as well as groups planning planning for an upgrade or migration to SharePoint 2010.

A Series of Containers

I tend to think about SharePoint from a container perspective.  Each of the containers has a set of settings and features that can be configured and administered for all of the containers within.  It is important to understand the boundaries of each level so that you can create a site topology that meets all of your objectives.  I’ll cover a sub-set of these I typically consider while planning the site topology.  The containers I’m going to address include:

Farm – In the context of this article, all of the Applications, Site Collections, and Sites hosted by one or more connected SharePoint servers.  I say “connected” because it is possible, and fairly likely that most organizations will have more than one Farm (Dev, Staging, Production for things like Intranet, Extranet, Internet, etc).  A farm has one or more content Applications plus additional applications for things like Central Administration.

Application – An application would be the top level address which maps to an application in IIS.  For example http://sharepoint.  An application has one or more Site Collections.  The application level is also the level where you have the opportunity to identify one or more content databases for storing the content on the SQL server.

Site Collection – A site collection has one or more Sites also referred to as Webs or Sub-Sites.

Sub-Sites or Webs – This is the smallest container which resides under and can be managed by the Site Collection.

Types of Content

The first step is identify what types of content or site(s) you expect to host.

  • Internet
  • Extranet
  • Intranet
  • MySites
  • Company or Divisional Portal(s)
  • Web Content Management (Publishing)
  • Electronic Content Management (Document Management)
  • Business Intelligence
  • Project Management
  • Team Collaboration
  • Application Hosting

Not all of those types of content apply to every organization, but it should be pretty clear that the content, the update frequency and the manner in which it is used and managed can vary quite a bit from type to type. 

Considerations of Multiple Applications

Very small companies or workgroups may be able to get by with all of the types of content hosted in a single Application, but for anything larger there should be plans to segment it to multiple Applications in the farm.

Here are some considerations when using multiple Applications:

Authentication Model – What type of authorization model will be used?  Options include Anonymous, Windows Integration (NTLM or Kerberos), and Forms Based Authentication (FBA).  Since an Application can only support a single authorization mode, that can dictate additional applications.

Edit:    Anders Rask was kind enough to point out some changes to the authorization model in 2010 that make the previous statements incorrect.

In 2007:  Options include Anonymous, Windows Integration (NTLM or Kerberos), and Forms Based Authentication (FBA).  Since an Application can only support a single authorization mode, that can dictate additional applications.

In 2010: There are two high level options; Classic which supports Windows Authentication only and Claims Based which supports one or more different providers.  Additional information can be found on TechNet’s article Plan Authentication Methods.

Sessions – When a user visits an application a session is created.  It is important to understand that their session is for a specific IIS Application so if they visit the main company portal and then click to see the MySite they may be asked to authenticate again.  With Anonymous this should not be an issue.  With Windows Integrated this should not be an issue if 1) users are using Internet Explorer 2) they access the site(s) with the same account they use to access their computer and 3) their browser is properly configured to pass logged on user information. 

Application Scoped Solutions – Solutions can be scoped to specific Applications which can provide some flexibility in deploying new features.  In a large environment it is important to only show features to the areas where they apply.

Considerations for Site Collections

The site collection has some important boundaries to consider when deciding to use one versus multiple site collections.  They include:

Amount of Data – It is important to keep your site collections at a maintainable level.  There is no hard limit, but as Site Collections grow over 40GB they can get more difficult to maintain and will take longer to restore.  SQL Server tuning becomes more critical with larger databases.  It is a good idea to segment your content across multiple site collections (and across multiple content databases) in a manner that makes sense.

SharePoint Groups – SharePoint Groups can be a good way to organize users, especially when they do not map to functional areas or groups otherwise managed in Active Directory.  These groups are defined and contained within a given Site Collection which means if you want to use them in multiple site collections they have to be duplicated and maintained separately which can be problematic.

Site Collection Administrator – A site collection administrator has great power and control within the site collection container.  A Site Collection administrator can choose themes, manage all security within the site collection, manage activated solutions and potentially deploy other customizations if policy permits.  Enabling content owners should be a top priority, and the Site Collection provides a good container for that.

Quota Management – Quotas are set at the Site Collection level so if granular quota management is required for billing or charge back purposes it may have some impact on how site collections are segmented. 

Navigation – The default SharePoint navigation provider does not span site collections (and therefore applications) which can make a standardized or unified navigation scheme difficult to maintain.  This tends to work fine for team collaboration sites, but can be cumbersome when you need to link many site collections.

Content Types – I think Content Types were one of the most important changes introduced with WSS 3.0 and MOSS.  An entire overview of content types is outside the scope of this article, but keep in mind that within the current release Content Types are created and maintained within a Site Collection.  If a Content Type applies to multiple site collections then it needs to be duplicated.  SharePoint 2010 will support farm level content types which will remove the need to duplicate them.

Profiles (WSS Only) – If you are using WSS it is important to understand that the profiles are stored at the Site Collection level.  If you add custom attributes they will need to be added to all site collections they apply to.

Implications on Backup and Recovery

There are a few different methods to backup and recover SharePoint content.  Within the context of this article it is important to understand the difference between the commands that stsadm provides. 

Site Collection Backup and Restore – Considering the boundaries previously discussed, there is a lot of extra content stored in the top level site of a site collection.  Doing an stsadm backup will provide a high fidelity snapshot of the content, configuration, workflows, and other customizations.  It is important to note that if you are moving the site collection between applications or farms that you will need to install any solutions or dependencies referenced in the current location.

Sub-Site or Web Export and Import – The Export process offered for Sub-Sites is great for archiving, but it does not provide the fidelity needed to move sites around.  It will not save workflow, features, solutions or alerts.  I’ve also had inconsistent results with DataViews on sites being migrated in this manner.

If you think you will need to migrate the content or want flexibility, it would be in your best interest to consider using more Site Collections rather than deeply nested Sub-Sites.

Upgrade and Migration Considerations

The purpose and content within a site collection or site can evolve over time.  Some sites that started very narrow in purpose may change and now warrant their own Site Collection or Application.  When preparing for a migration or upgrade it is a good time to run through this exercise again to validate the assumptions and decisions that were previously made or overlooked.  While it may make the move more difficult the changes will pay dividends over the coming years offering a system better tuned to the user’s needs and more maintainable by the site owners and farm administrators.

Related Posts

My Sites in the Enterprise: Today and Tomorrow

As we inch closer to SharePoint 2010 and the vast improvements made to the My Sites feature set I thought it might be time to revisit some key concepts when looking to leverage My Sites in an organization.  In many organizations I see My Sites as still under deployed and under utilized.  In some cases it is because leaders do not know what to do with it while in others they are not sure how to support it.  I hope to address both of those issues here along with offering some other advice.  By addressing the topic now I hope that business can get a jump on implementing the tools based on the current technology as well as bring it to the forefront of the 2010 upgrade planning so that they will be able to better leverage the tools in the years to come.

What is the purpose of My Sites?

In its simplest form, My Site is a SharePoint site collection owned by an individual giving them the ability to have both personal and shared content.  It also includes the bases for many personalization features including a Colleague tracker, My Links, and the ability to aggregate content like tasks and documents they are involved with throughout the entire farm.  Since the sites can be automatically provisioned in most environments it takes little or no IT interaction for a user to get started.

In some environments the the feature is limited to IT and some power users, while in others the service is available but its benefits have never been communicated to the organization as a whole.  By widening the audience and its participants more value can be derived from the tools.

Enterprise 2.0

These tools are a good foundation for an Enterprise 2.0 strategy helping your users find and communicate with each other.  In most organizations people are already using these types of tools, but they are doing it for different purposes and with tools hosted outside your company’s network.  Look at LinkedIn, Facebook, and Twitter which probably already have unofficial groups or networks organized around your company.  By pulling some of this into your network you can expand productivity around internal information assets, provide some level of information security, and increase the overall socialization activities.

In a recent post I wrote about Overcoming Obstacles in SharePoint and Ent 2.0 which addresses a few of the biggest issues; Fear of Change, Information Power, and Lack of Interest.

Governance

Like most SharePoint topics we cannot have a full discussion without mentioning Governance.  Oddly enough, this is one area that I think perhaps can be over governed.  The cornerstone to Social Computing is social interactions and for it to be social there needs to be room for an individual’s creativity.  That isn’t to say that anything goes, but in many cases things should be generalized into more of an appropriate use policy. 

Personal Photo – One of the most personal aspects of personal computing is the individual’s photo or avatar.  Hopefully within an organization people feel comfortable enough to have a photo or at least an avatar.  While a photo of the person is great it probably shouldn’t be a requirement and hopefully isn’t their mug shot from the badge or security system. 

Dressing up the My Site – The individual should be allowed to change the theme to personalize the color scheme and select a personal icon or banner for the site.  Even if the rest of the SharePoint sites are fully branded with the corporate identity, small things like this can really increase the interest level since it gives them a chance to be creative and truly gives them ownership of the site. 

Quotas – Quotas should be set at a reasonable amount.  Too little and users will end up going back to Shared Drives which will undermine use of the tool.  Of course too much and there is the possibility that storage costs can escalate quickly along with backup and recovery times. 

If used appropriately it should draw down the storage requirements in email and shared drive storage thereby just shifting storage from one system to another.

Taking it to the Next Level

SharePoint 2010 will add in both the Facebook “Wall” concept as well as some enhanced social bookmarking, both of which have been painfully missing from the 2007 offering. 

While both of those features are welcomed additions, there are more opportunities to extend the system as well.  One of the things I like best about systems like Facebook and LinkedIn is there are all kinds of tools that have been created to help interact with the platforms.  This includes everything from mobile browsers to make posting updates easier to the LinkedIn Outlook Toolbar that can expose user’s LinkedIn profile, status, and network information in Outlook.  The Outlook team has responded by offering the Outlook Social Connector which promises to offer an extensible provider platform for integrating with multiple social platforms including SharePoint 2010 as well as Windows Live and anyone else that can create a provider. 

Other extensions and tools are still needed though.  In the past I wrote a bookmarking component that supported adding items to My Links from both inside of SharePoint as well as other ASP.NET applications.  As soon as I get a handle on the final features of SharePoint 2010 I plan on updating that and making it available as a project on CodePlex.

Simple content components like a Quote of the Day or slide shows can also increase the personalization of the system. 

Isn’t this for Business?

This is for business, but it can still be fun.  Increasing the fun factor will get people to be more engaged and interactive.  Also, it is a proven fact that teams that know each other at a personal level and can maintain relationships function at a higher level.

Related Posts

Overcoming Obstacles in SharePoint and Ent 2.0

One of my favorite general IT blogs is Michael Krigsman’s IT Project Failures blog.  Michael provides a balanced view with great insights into the failures of many organizations.  These are lessons that every implementer, integrator, or system stakeholder should pay attention to.

In a recent post titled Resistance to change:  The real Enterprise 2.0 barrier Michael discusses some of the challenges to implementing Ent 2.0 systems.  As always it is a great and relevant read, but I think it matches much of my experience with implementing SharePoint in the Enterprise.  The top obstacle listed was Resistance to change.  The capabilities of the tools are not the biggest limiting factor, user adoption is.  Some of the reasons discussed include fear of change, the power of information holders and lack of interest.

Fear of Change – This is a natural human response.  Much has been written about how to drive change in an organization, but I think the most critical technique is end user involvement.  When people are involved they are much more likely to have a positive view of the change and you are more likely to value insight into how things are actually done in practice. 

This also provides a good opportunity to fine tune your feedback collection techniques so that all stakeholders continue to have a voice after go live. 

Information Power – In some organizations there is a culture in place where people feel like they have to be a gateway to information.  With the recent economical downturn people are all the more desperate to be seen as irreplaceable.  Organizations need to work towards transparency and openness.  A positive side effect of this is better use of the subject matter or domain experts who are normally over worked in closed organizations and frequently have to answer the same questions repeatedly.

Lack of interest – Lack of interest can definitely have an impact on the life of a system.  Some users still do not understand or have any interest in Ent 2.0 systems.  I think easiest way to get passed this is to show sustained value.  It is easy to establish and maintain interest with small groups, but it gets exponentially harder as the size of the group increases.  Keep the tools current, and show incremental advances to keep stakeholder interest.

I’ve also seen turnover in key positions or management impact a groups use of these tools.  It is important to work with the new stakeholders to review what is there and what can be done to align it with any changes to the group’s direction.

Closing

I’m always interested in hearing feedback.  Do you agree, disagree?  Have any other tips to decrease the resistance to change?

Related Posts

Site Requests, Provisioning, and Governance

Yesterday I posted a link to Michael Sampson’s survey on Site Creation Rights which is intended to collect information on the process and governance around who can request new sites and how they are provisioned or “actioned.”  This is an important topic, so I’m looking forward to seeing the results.

This is a topic I have had to put a lot of thought around recently in my current organization.  Like all things Governance, there is no one-size-fits-all solution.  Instead there are topics that needs to be discussed in the context of the organization to determine an appropriate path.

 

Some items to consider:

Who can create a site; Anyone, Project Manager, Manager and above?

True collaboration doesn’t always happen based on a mandate from above.  Whenever possible, it is good to encourage and accommodate requests from anyone that will use the service.  Some of the most innovative sites I’ve seen were lead directly by information workers sometimes even without the knowledge of their supervisors.  If there is a charge to the site, this may not be possible.

Does a site request require approval?

Does a site request require approval from a manager of the requestor’s group or from IS/IT?  If so is it for financial reasons, or does the scope and purpose of the site need to be validated?

What types of sites can be created?

Are there only certain types of sites supported like Division, Department / Functional Area or Project?  What if somebody wants to setup a site to organize the Bowling League or discuss Social Media’s place in the organization?

Where are the sites placed and how are they organized?

Are all sites placed into the generic “Sites” path or are they logically grouped in containers that represent the org structure or purpose?  This can definitely have an impact on the process if sites are automatically provisioned. 

If they are logically organized, you need to make sure you have a plan on how to move the sites and content if the purpose of the site or the organization changes.  These sites need to be dynamic and adapt to change.

Does the site need to be logged somewhere like a Site Directory?

If one or more Site Directories are used, the provisioning process should include steps to list the new sites. 

Does anyone need to review the site’s Design, Structure or Security?

This question is pretty central to the Governance process.  If you establish standards or guidelines you want to ensure people follow them, but it is also a good idea to have some form of a review available so that advice and best practices can be exchanged to help maximize the value the group derives from the site and system.

The scope of this review can run the gamut, I’ll save that as a topic for another day.  I will however say that it is important to the overall success of the platform unless the capabilities and understanding of the site owners/administrators are very high.

 

Site Requests and Provisioning in the Small Organization

In small organizations it is pretty easy to handle things manually.  Site provisioning really doesn’t take that long so it is easy to help the site owners/administrators along and get things organized correctly so that it meets the group’s information architecture objectives and is easy to use.

If the process is automated in a small organization it is likely to be a pretty simple process.

Site Requests and Provisioning in a Large Organization

In larger organizations it quickly becomes apparent that manual processes cannot scale and at least portions of the process need to be automated.  Depending on some of the topics above relating to charges, approvals, and topology the process can vary quite a bit from organization to organization. 

If the Governance model is properly though through it should be easy for people to request sites, and they should be provisioned in a way that offers additional value. 

 

End Notes

Thoughts, feedback, critiques?  I’m always eager to hear other people’s thoughts on this topic and eagerly await the results of the survey.

Other Uses for SharePoint Search

SharePoint Search can be used to power much more than just ad-hoc searches. The standard web parts are highly customizable and there is also the option to create your own that leverage either the Search API or web services.

Search Core Results
I really like that the rendering of the results can be completely customized by updating the XSLT. This provides quite a few opportunities for custom uses without having to recreate all the web part’s plumbing.

By using the “Fixed Keyword Query” option you can pass in static queries. This is especially powerful when interacting with the User Profiles in MOSS. I have been working through some uses with this to provide a dynamic department lists that link to the user profiles. In the past I have seen groups use the regular contact lists, but then owners have to duplicate all of the people’s information that is already stored and maintained in the user’s profile.

Interact with Very Large Lists and Libraries
When working with very large lists and libraries, this can also provide a simpler, more responsive interface making it much easier for users to find what they are looking for.

Summary
Spend some time in the sandbox to get a better idea of the available capabilities. I think you will quickly see how they can be applied to your environment and your projects.

SharePoint Resources and Knowledge Management

Lack of “proper” training is a common end user complaint in many SharePoint environments. Hopefully training plans have been developed, but in addition to formal training I have also focused on providing online resources for task and audience based training.

Going through this exercise can also provide a great introduction to Knowledge Management concepts that can be applied to other aspects of your business and processes. SharePoint includes many core features that are very well suited for Knowledge Management and that can be easily configured to match your requirements.

Microsoft has many good resources available on their Office Online website. I’ll frequently identify specific content that is especially helpful and provide links to that content.

A good place to start is to include the following content:
• SharePoint Contacts
• Video Tutorials
• Task Based Instructions
• Training and Event Calendar
• Helpful Links
• Frequently Asked Questions
• General Discussions

When identifying content, try adding custom properties to help organize it based on the Audience (User, Power User, Site Owner, Developer, Administrator) and maybe some categories (Documents, Lists, Wikis, Blogs, Security, etc).

Identifying the content is a good start, but in the second phase look for ways to deliver that content targeted to the specific audiences or categories. For example if you provide a filter web part with the list of Audiences you can connect the filter to each of the list views. It is also a good idea to try and keep the content fresh. Add additional information as needs arise and try and get involvement from the user base.

I would like to thank Laura Rogers a.k.a. @WonderLaura for inspiring this post after a brief tweet this week about updating a SharePoint Resources site in her org. The mere mention of this topic opened the creative floodgates.

%d bloggers like this: