Tag: Enterprise

SPS Bermuda Wrap-up

I think everyone had a fantastic time at the inaugural SharePoint and .NET Saturday Bermuda event.  I’m honored to have been able to participate.  The hospitality on the island was fantastic, and while the event was small, there was good participation in the sessions.  I hope everyone got a lot out of the day.

I’ve uploaded my deck to slide share so it is available below.

 

I look forward to future events!

Commentary on Purpose Based Licensing

Dan Holme recently had an interesting piece of commentary in the SharePoint Pro magazine titled It’s Time to Break Up the SharePoint Brand in which he advocated breaking the product into purpose based bundles instead of the behemoth platform it is now.  I agree with much of what Dan wrote, including his two main points that it is not a single purpose platform and operates more like a modern OS. 

As I consider the points though, and my own experience evangelizing the platform with customers large and small, I would say that there is already serious confusion about the licensing.  As Microsoft attempts to transform itself to a services based company, I would actually recommend a different sort of licensing move that is even more radical.  When buying server based applications like SharePoint, there should be no need to also individually license the pre-requisite dependency technologies; specifically Windows Server and SQL Server.  These are needed to run the system, so if a customer has a six server farm and busy six licenses of SharePoint Server, then they also require six licenses for Windows Server as well as at least one SQL Server license.  As the number of SharePoint licenses increase, so would the associated Windows and SQL licenses. 

While I think this move makes great sense for customers I am not holding my breadth that Microsoft will make this move any time soon.  I think the biggest reason is the confusion of how to then map revenue back to the other divisions such as the core server OS group, and the database group, but really there should be a set percentage that they can agree on.  I believe that this service or purpose based approach would simplify things quite a bit and should also apply to the other server applications like Exchange, Systems Center, etc.  Of course there will still be a need for stand alone Windows Servers for traditional server things like AD, DNS, Web Sites.

As the move to the cloud continues to evolve this may become more of a moot point for many, but it is unlikely that even half of customers will be running all of their applications primarily in the cloud in the next five years.

A Portfolio Approach to Developing Workflows and Processes

One of the common pitfalls I see with process optimization projects is that they tend to focus on a specific process at a time.  This may be ok when you are just starting out, or working with informal processes, but as the number of complex processes improves it is important to try and take a step back and look at things from an overall portfolio perspective.  In many cases processes overlap or are interrelated.  I most often see this in finance processes because they are so common in all organizations.  Something like a Check Request process should be a pretty standard, well defined process but it is often part of a number of other process flows.  It is easy to ignore the fact that the same steps and activities are followed elsewhere, but that leads to a lot of extra work for the process designers and administrators as well as non-standard activities for your process workers to follow.

To overcome this, it is important to consider the following points when analyzing and designing the process:

  • Is there a natural collection of steps or activities?
  • Are these steps also done to support another process?
  • Is a different group or department responsible for those steps?

While performing the process analysis and design, some activities may form a natural grouping.  It could be a set of steps that are referred to under a particular label and they are likely to be assigned to or processed by a specific group of users.  For large complex workflows, it may be a good idea to make that a sub-process that can be referred to as a set unit.  It is important to talk to the stakeholders that perform those tasks and understand if those same tasks or processes are are also performed to support another process.  If they are, then it would be better to design a standard sub-process that is called from the other processes than to build in the specific steps into each process.

The Check Request example I mentioned before is one that I have seen come up in more than one organization.  There is a set of common steps where requests have to be approved, logged, and then processed.  Standard compliance activities are another example of a common central process that may be leveraged by a number of other processes.  Some times these opportunities present themselves early, but other times you have to dig to identify these sub-processes.  In cases where there are multiple groups involved the main process owner or stakeholder may not fully understand the details of how every step is executed so it is important to interview the actual project participants to understand what they are doing and other processes that may use those steps.  Within the Check Request example, it is unlikely that a process owner in Operations understands all of the various corporate activities that may generate a check request, they only understand that it is part of their one process.  By talking to the process workers in Finance, the other perspective can be considered.

By taking a Portfolio Approach in this case, you can potentially make real improvements that extend the process design and automation benefits not just to the one process, but to multiple processes across the entire organization.  Those processes will also get easier to expand and manage as they can leverage common sub-processes and existing functionality.

Quota Management and Storage Reports in SharePoint 2010

A few years ago I wrote an article about how to enable and work with the Quota Management features in SharePoint 2007 (click here for article) which proved to be a popular post.  Quota Management is a pretty important topic when it comes to SharePoint Governance and overall maintenance of the platform.  While the overall Quota Management features in SharePoint 2010 were maintained, there was one big feature left out when SharePoint first shipped, and that was the “Storage space allocation” page also known as StoreMon.aspx page that was available to Site Collection administrators from the Site Settings page.  

New Storage Metrics

With the release of SharePoint 2010 SP1 (download here) the feature returns, but in a much different format and vastly improved.  The page was renamed “Storage Metrics” and it is a gold mine of information since it provides a way for Administrators to navigate through the content locations on the site and provides details for the item’s Total Size, % of Parent, % of Site Quota, and Last Modified Date.  This makes it easy for administrators to identify where content is concentrated, and can also show an exceptionally large lists, libraries, folders, and documents. 

There was one aspect of this that I thought was helpful in 2007 that is no longer supported, and that is the ability to view the number of versions of a given document right from the report.  In many cases I’ve seen versioning turned without any limits, and some popular documents might have 1,000s of versions.  The report used to provide a way to find those exceptions so that they could be cleaned up.

 

Performance Improvements

From what I understand, it was removed because it proved to be extremely resource intensive and information was gathered in real-time so it could cause service stability issues in very large environments.  With its return is a completely revamped gathering process that relies on timer jobs, titled Storage Metrics Processing, resulting in much faster page loads and no risk of crashing the server just by viewing the report.  These jobs will pull data every 5 minutes but like all timer jobs, the frequency can be adjusted to better meet your needs and environment.  For larger environments, it might be a good idea to reduce that frequency to avoid the extra overhead.

Configuring Quotas

As with the 2007 version, this feature is only available if quotas are enabled.  In cases where quotas are not currently being used and proper limits managed, the safest bet is to establish a quota that cannot be met.  This will enable the features without the risk of triggering a warning or locking a site that exceeds the thresholds.  Locking the site is the only risk with quotas, there is no risk of data loss.

Summary

Both Farm and Site Collection Administrators should review the functionality and add its review into their content review and cleanup processes.

SharePoint Saturday Atlanta

I’ll be presenting at SharePoint Saturday Atlanta on Saturday May 7th.  The lineup is impressive and this is sure to be one of the bigger SharePoint Saturday events in the region this year. 

Session details:

Getting the Most from the User Profiles
This session will help you maximize the power and value of the SharePoint User Profiles available in SharePoint Server. We will cover strategies on how to approach defining and maintaining custom attributes, how to approach synchronizing content with other business systems, and how to leverage the information to drive business processes both inside of and outside of SharePoint.

Hope to see a full house, if you are in the Atlanta area be sure to stop by and say hello!

SharePoint Governance and Continuous Improvement

There are a number of reasons why I have seen SharePoint Governance stall in many environments, but one of the most common reasons and the one I would like to address today, is the problem of trying to take or address too much scope at once.  There are a lot of topics that roll into SharePoint Governance; the SharePoint Governance Framework we use at my company identifies over 50 distinct topics.  In most cases it is not practical to take the full list of topics and work through a governance plan in one pass.  Instead, I advocate for an iterative approach starting with a selection of core topics and finding a pace that matches your organizations cadence to continue solidifying the process.

Continuous Improvement

Continuous Improvement (CI) is a concept that relates to Lean, Kaizen or TQM practices and is intended to use small, incremental changes to bring big results instead of trying change everything at once.  There are many advantages to this approach but the one that resonate most with me is that the incremental investments could be very small, but you start to see gains quickly.  I believe this relates very well to the process and concepts of SharePoint governance.  As you start to gain momentum you are much more likely to get stakeholder involvement which is critical to any governance effort.

Selecting Topics

The selection of topics is important.  There are some topics that lay the foundation for everything else.  I typically start with the core topics that are needed to define the service and system to be implemented (or that has been implemented).  I then move to the most critical items that are needed for managing the system such as touching on the core Information Architecture, Site Topologies, Site Creation Process (who/how/where) and Permission Management.  Over time, and definitely in more mature organizations, you can start to tackle some of the more subtle topics.

Depth for Topics

When reviewing a topical area, it is important to iterate there as well.  For example, when starting an implementation stakeholders may have a decent idea what the service definitions and SLAs might look like, but this will certainly change after it is in use for a while and perhaps became mission critical for core business processes.  As these requirements and needs evolve, additional iterations are required.  This fits very well with the CI concepts mentioned above.  These iterations continue to deliver more value to the stakeholders in small increments.

Finding a Pace

Finding the pace for the governance work can be difficult.  I think the pace for change in any organization is heavily tied to the organization’s maturity.  Anyone that has been IS/IT or IS/IT management for while should be familiar with the Capability Maturity Model.  In Level 1 organizations things are completely chaotic, with ad-hoc efforts which means you are constantly chasing a moving target.  As you progress up the maturity model though, there should be more discipline and an ability to stay focused.  In these organizations it is possible to iterate more frequently and potentially to tackle more topics in parallel.  There is no doubt that more mature organizations work more efficiently.

Other Considerations

Governance should be an ongoing process and the document should be a living document that continues to see change over time as the organization and it’s needs evolve.

It is also important to note that groups should not take a shortcut and try to minimize the stakeholder involvement to simplify the process or to quicken the pace.  Stakeholder involvement, specifically non-IT, is critical to these efforts and it could be argued that you really do not have any governance without this involvement.

Summary

Governance is a key aspect to success with SharePoint and by taking the right approach, and one that is in sync with your organization’s capabilities will greatly increase the likelihood that your governance effort will be successful.

Keys to Long Term SharePoint Stability and Success

Recently I have been called into a few environments where the customers were having some serious performance problems or had features that were no longer working.  It really nailed home the point that Capacity Planning should really be Capacity Management as Microsoft now refers to it in their Capacity Management and Sizing Overview guidance for SharePoint 2010.  These environments also tend to have some other issues with patching and large un-used content databases.

The Keys below will help establish long term success for your SharePoint environment.

Initial Design and Planning

The planning and design work that typically goes on prior to an implementation is based heavily on assumptions and the understanding of current requirements.  In any environment where an application like SharePoint takes off, those assumptions change quickly, the needs of the business evolves, and therefore all of those requirements change.  In many cases though, the SharePoint farm topology is not changed and can no longer meet the needs.  With the current state of IT many resources are stretched and do not have time to make major changes to the system, but in many cases a few proactive changes would remove some of the ongoing system support and troubleshooting efforts.

Continued Monitoring

Every system needs regular monitoring.  The frequency and depth of the reviews depends on how complicated the implementation is, but below I have listed out some generic topics that can be reviewed.

Quarterly Review

  • Memory and CPU Utilization
  • Patches – Review new patches and install if appropriate

Semi-Annual Review

  • Review Content Databases – Number of Site Collections per Content DB and the size of each Content Database
  • Search Index Health – Number of items in the index, length of the crawls
  • Average and Peak Usage Stats – Review the average and peak user stats and add hardware if needed.

In addition, in some cases new features are enabled or leveraged months after the initial implementation.  If for example you are going to use SharePoint to host your BI solutions additional capacity may be needed.  If the system was initially designed for a pretty basic Intranet and the BI capabilities are added then the system may not be able to keep up.

Patching

Patch management also contributes to keeping your SharePoint installation stable and high performing over time.  Installing Service Packs or the bi-monthly Cumulative Updates can be difficult in some environments where maintenance windows are tight, but these patches will also help keep services running smoothly and bugs at bay.  I worked in one environment where at least three major issues were all resolved with previously released patches.  Unfortunately a lot of time was spent troubleshooting needlessly.

Prune the Hedges

Most information stores get bloated over time, SharePoint is not immune to this.  IT groups have been fighting this for years with shared drives and mail servers.  It is important to have some good retention policies in place to make sure you are keeping the right content, but also getting rid of the stale content.  At the very least you can implement an archiving solution that can move the content to cheaper storage, while keeping it accessible.

Summary

Following these recommendations will greatly increase your chances for maintaining a highly capable, well performing environment.

%d bloggers like this: