Resource tagging in Azure is a critical function. In this article I will cover what tags are, the core benefits of tagging, and some general suggestions on how to approach tagging.
This article will provide an overview for the foundation of an azure cloud governance strategy to support your organization’s goals for cost management, security, and overall management of the cloud platform.
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.
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.
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.
Both Farm and Site Collection Administrators should review the functionality and add its review into their content review and cleanup processes.
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 (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.
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.
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.
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.
Over the past few years there has been tremendous progress in making many components and solutions available in the open source markets like CodePlex, SourceForge, or even individual blogs and sites. Many of these are community driven projects supported by individuals, with some by commercial companies. For some reason many companies avoid or strictly limit allowing these solutions to be installed or used. When approached properly I think these solutions should be considered. This article will cover the advantages as well as outline an approach to make take when evaluating which solutions to install and how to test them.
The first advantage of implementing any solution is that it should make it much quicker to solve a business problem. In some cases it might be a complete solution, like commercial software components, but at the very least it should act like an “accelerator” offering you a springboard to the final solution. One advantage that it has over commercially packaged systems is that you have the source code in case changes, additions, or fixes need to be made.
Another advantage is that it can expose the development team to different coding techniques so that they can better address similar problems in the future. Microsoft has been providing sample databases and applications for years for this very purpose. People tend to learn more by seeing examples in action versus class diagrams.
Review Project Status and Activities
Not all solutions are of the same quality and grade. In some cases there are a few quick samples while in others there was a more formal project with full QA that has gone through multiple release cycles. It is therefore important to review things like the product status and release number. It is also important to review the Issues log to see how much activity there is and how quickly issues have been addressed. You can typically get a good idea about how widely it is used. In some cases you may be familiar with the developers which offers the advantage of discussing questions and issues directly with them.
Approach to Testing
To increase your chance of success and mitigate risk, it is important to always fully test the components to meet both functional and performance testing. With commercial software the expectations are normally pretty high, but I would approach this as if a member of the project team produced it even if no changes were made. This includes specialized testing like the “DisposeCheck” tests typically done to custom code that interacts with SharePoint’s API.
When expectations are properly set, and the solution is fully reviewed and tested, including these open source solutions can contribute to the team’s ability to effectively deliver solutions quickly.
A number of times over the past few years I have stumbled into discussions (in person or online) about how to automate the creation of MySites for all users in the organization. Creating the sites programmatically is actually pretty simple, but the real question is “Why do you want to do that?” There are advantages and disadvantages to automating the process, but for me it almost always comes down to two big things; Governance and Business Reason.
MySites present an interesting challenge with regards to governance. While most of the topics are outside the scope of this article there are a few important topics that relate to the number of MySites within an organization.
Storage Considerations – Even with quotas in place it is easy to see exponential growth for the storage requirements. In larger environments with 1,000s of users serious planning needs to take place to build out a SQL environment to support the site collections. Planning should also be done to manage the number of sites per content database to ensure long term maintainability.
When you provision all of the sites at once all of the planning has to be done up front, where conversely if you provision the sites slowly over time you spend a little time planning out the long term assumptions and then tweak the strategy over time as the sites and their usage evolves. It is much easier to make corrections with the slow approach.
User Support and Training – A MySite is very different than an email account which is something nearly all computer users are familiar with at this point. The average SharePoint user has never received any formal training and has little understanding of the capabilities of a site collection. Without proper training it is unlikely that user will be able to take advantage of any of the real benefits of the MySite leaving them to just use it as a replacement for a personal network share (see Storage Considerations above).
In my experience site owners or administrators for traditional collaboration or department sites are much more likely to have success and less likely to need extra support. That narrower group of people is a much better starting point, and they are also sophisticated enough to initiate the automatic provisioning process themselves.
Each organization should develop a user story for what the purpose of a MySite is within their organization. Like any site collection, it can be used for many different purposes such as; Landing Page, Dashboard, Personal Site, etc. The user story may help establish how the MySite will be used, who is expected to use it, and ultimately if customization is needed to provide the functionality and content. The answers to those questions should help guide the decision about how to provision the sites.
While I tend to like the go slow and make adjustments path, there are valid reasons for needing to auto-provision sites for large groups of users. Hopefully the guidance here will help to guide the team through proper planning so that the implementation can be successful.
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.
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
- /Communities – Communities of Practice Managed Path
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.
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.