Tag: Governance

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

SharePoint Dev and Customization Paths

Microsoft’s technology stack has traditionally offered a lot of good options leaving the developer or architects to choose the best path.  Even still there there have been people camping out on one side or the other.  In the early days when VB first came out the hardcore devs didn’t take it seriously, and I remember hearing a lot of negative comments from traditional C++ developers.  VB devs didn’t have to understand concepts like threading and memory allocation and the VB code was bloated leading to “poor performance.”  While those statements are true, not every deliverable has the same grade requirements and in many cases businesses were more than happy with the code that was delivered faster and for less money than what C++ developers could provide.  I think this is a very good analogy to the current SharePoint development and customization paths.  Microsoft has worked hard to position SharePoint as a tool that can be leveraged and customized by power users as well as developers.  I think this is both a strength and a weakness; a strength because there are options, but a weakness because many of the people doing the work do not understand the implications of their decisions.

Understand the Scope of the Solution

The first thing I think about when I get a request is the scope of the solution.  I think through the questions below and choose a direction that makes sense in order to meet the requirements in a cost effective manner. 

Who is the audience? – The larger the scope of the audience, the more robust the solution should be.  A solution created for a work group is probably very different than one used enterprise wide.

How many users will need to use it? – Similar to the previous question, but a little more concrete.  Do you expect 10 concurrent users, 100 or 1000?  Company or enterprise wide means different things in different environments.

Where will the solution be used? – Deploying the solution on a single Project or Team Site is very different than deploying it to 100 sites, which is very different than deploying to the front page of a company’s Intranet.  If it is for a single use the Light Dev and Customization path can make sense.  If it is meant to be reusable, then it warrants more time and attention to make sure that it is the best it can be.  If it is use on a top level or heavily used page or site then performance is even more critical meaning a more robust solution should be developed.

How long is it expected to be in use? – Try to have some understanding of how long the solution is intended to live.  Assumptions may change, but make an informed decision based on the information you have at the time.  If a newly acquired third party tool will be providing that functionality in the next 10-12 months there is no need to overbuild the solution.  Likewise, don’t take short cuts on a critical project that can undermine peoples’ understanding of the capabilities of the platform.

Who will maintain the solution? – This is a tricky one.  Not every company has a large staff of qualified developers waiting in the wings.  There is normally a large backlog of work waiting for them.  If you are a consultant then you might look at whether you are handing over the support to the internal team or if your group will continue to maintain it.  The group isn’t capable of maintaining a solution and doesn’t have the tools and environment in place to do the work then full scale development may be a bad idea.

Are there performance requirements? – If there are performance requirements then those should be planned for from the start.  Stats like page load times, and an agreement on what constitutes the end of a page load are important.  In most cases I have not seen this requirement.

Light Development and Customization

Light development and customization includes features and solutions dealing with SharePoint Designer, DataViews, Content Query Web Part and the Content Editor Web. 

More than anything I see this being for the benefit of Power Users and site owners who can apply customizations within the scope of a site collection.  While there are many that want to outlaw SharePoint Designer and these solutions in their environment, I think they risk eroding the value and impact of their SharePoint platform.  I see SharePoint as a tool that enables content/site owners without needing to rely on a central IT group.

I tend focus on this part of the stack when dealing with solutions targeted to small teams or with small requests that do not need a full blown application.  There are definitely lots of opportunities for simple, high impact, one off solutions. 

This however is probably not the appropriate set of tools for org wide workflows, complicated forms, or even displays on heavily trafficked pages.  The Content Query Web Part (CQWP) for example is not the most efficient way to aggregate content so pulling something like project status information from 50+ project sub-sites is likely to end in frustration.

Robust Development

Robust development includes features and solutions dealing with Visual Studio built applications packaged and deployed via the solution framework in SharePoint. 

This really should be the starting point when reviewing any project of real significance.  The developer has a lot more flexibility and control in what can be implemented and it is much easier to centrally track and manage what is deployed to the server. 

I think that it is important to note that poorly developed VS solutions are at least as dangerous as anything that can be done using the Light Development and Customization technologies and techniques.  Failing to dispose of objects or inappropriate CAML queries can bring down a server or cause all kinds of havoc.

Mixing Approaches

There will be times when it is necessary to blend the two approaches.  Within a given project there are features that are core to the solution and some that are in more of a supporting role.  Admin or reporting features are a good example of that, where using a DataView may be easier to maintain than a custom Web Part to display content.

The Business Does Not Always Understand

Customers, project stakeholders, and other decision makers do not always know what is best.  I’ve seen many cases where even sophisticated development shops do not fully understand SharePoint development paths and fully leave the decision up to the developer.  Like any project using any technology, risks should be identified and discussed before things get too far.  It is irresponsible to deliver a solution that you know cannot be supported or maintained after you sneak out the back door at the end of the engagement. 

Administrator’s Perspective

From an administration perspective, I do not want to manage more solutions than I need to.  There is a balance between wanting to know what is deployed to the environment and wanting to touch everything that is installed.  If there is a fairly ridged change control process in place it can be time consuming to submit and deploy minor updates to small, narrowly scoped solutions.  Again, my approach comes back to the scope of the solution preferring to focus on widely scoped, high impact solutions.

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

The SharePoint in the Cloud – SharePoint as a Service

The cloud debate continues to rage in the offices of many business and IT executives.  They look for it as a way to control or reduce costs and to better focus on their core business functions instead of managing complex IT systems.  As a technologist though I see the cost benefit not just in dollars but in opportunity and the potential for the system to enable the organization to innovate and collaborate in ways they were not able to in the past.

I see plenty of value in SaaS for commodity systems, with email being a great example of that.  Email systems both large and small can be expensive to run and there can be very little difference in the service if it is run in house or in the cloud.  Is SharePoint a commodity system though?  Certainly some organizations are doing their best to not customize it.  Last year’s AIIM survey results reported many organizations underestimating the cost and effort to customization and integration which I’m sure will scare executives of any new implementations.  As a developer and integrator I have seen tremendous valued gained from implementations that are extended to work with other enterprise tools whether it is an ERP, HRIS, CRM, ECM or 3rd party BPM/Workflow systems.  The level of effort to implement and maintain those environments does need to be included in the decision process.  The cost is significantly higher than a vanilla SharePoint implementation so the value derived should also be measurably higher. 

If it is a plain vanilla environment then it is a great candidate for SaaS including MS Online.  The new “Sandbox” feature of SharePoint 2010 may help to provide a mechanism for minor customizations and an “App Store” that could benefit users of a hosted SharePoint environment.  This should definitely simplify the process for making some customizations possible. 

It will be interesting to see how the SaaS and hosted solutions evolve over the next few years and how they are perceived by organizations.  It will also be interesting to see if the Sandbox feature is made available to those services and what kinds of solutions are made available through that interface.

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.

Reworking SharePoint Security – Fixing a Bad SharePoint Implementation

This is the first in a series of posts relating to topics that may need to be addressed to recover from a bad SharePoint implementation.

SharePoint security continues to be misunderstood by many SharePoint power users and some Administrators. It was designed to be flexible, and in doing so can lead people down a road to ruin. One of SharePoint’s greatest assets is that it enables site and content owners to maintain their own permissions. Gone are the days that every request has to be routed through a central IS/IT group. Unfortunately I have yet to see this reach its potential. There are numerous reasons; some site owners do not receive the proper training, some are too busy, some just do not buy into the ownership, and others inherit previously built sites.

To take full advantage of the platform’s capabilities owners need to understand and be committed to following through.

Reinforce the Site Owner Contract
Make sure that Site Owners know what is expected of them. If they are responsible for maintaining security for their site(s), then reinforce the specifics since in some cases this may not be fully understood. This should also carry into that group’s resource planning. If people are informally assigned the ownership tasks it may not be figured into their normal work schedule. If it is not part of the resource planning shortcuts will inevitably be taken. Furthermore, I have seen a few site administrators cut during downsizing without any visibility to those responsibilities. What is worse, in many cases nobody assumes that ownership after the resource leaves the organization.

Training
When developing Site Administrator or Site Owner training, be sure to address proper security. Show examples of where it is done correctly, but also where it was done horribly wrong. Be sure to provide different types of training; in person, written, and interactive.

The Microsoft Office site has a great overview that is easily consumable: http://office.microsoft.com/en-us/sharepointtechnology/HA101001441033.aspx?pid=ch100649861033

Perform and Audit
The best way to get a handle on what the current issues are and to generate a plan to resolve those issues is to start by performing an audit. Look at the site collection and subsites and determine what is set to inherit and what is set to be unique. Then look at the individual lists and libraries to review the same.

Most of the issues I’ve seen come from site administrators breaking inheritance at the list/library level without understanding what that means. I have also seen issues in libraries where multiple levels of folders are in place with security being set differently at each folder level. Hopefully groups are used to control the access, but in many cases it is individuals. The easiest way to resolve these issues is to just start over. Work with the site owner/administrator to understand the intent and set it to inherit from the parent object and then go back through the steps to setup the specific permissions required.

Groups versus Individuals
Wherever possible, use groups to provide access to the securable objects. Adding individuals directly to an object does not promote reuse or central management. This creates many of the maintenance issues that lead to problems as sites and content evolves. Using SharePoint Groups versus Active Directory Security Groups has been widely debated so I will not cover it here. Use what is appropriate for your environment.

Summary
Following these recommendations will help transition the system from chaos to something that meets the site owner’s requirements and promotes maintainability. The next post in this series will cover navigation and Information Architecture issues.

%d bloggers like this: