The only constant is change

September 19, 2014

It’s been very long time since I last posted anything on this blog. About a year ago I moved from Dell Software’s SharePoint solutions group to take over product management in a company called Netwrix. Here at Netwrix I spend less time with SharePoint, as we do change and access auditing for a number of different IT systems and applications, primarily within Microsoft ecosystem.

To be honest, it was unclear to me what to do with the blog. I am still quite interested in SharePoint governance and management topics, but it is no longer the main focus of my day to day work. So I finally decided to resume blogging, and here’re the first couple changes here.

I am going to use the alias as the main blog URL again. The old alias ( will redirect here, but is no longer describing the main point.

I also renamed the blog to be more consistent with its new (expected) contents :) Even the ancient Greeks knew that the only constant is change (thanks to Heraclitus of Ephesus for making this observation!) – and my interest now is how to give IT and executives visibility into these changes, and give enough info to understand them in context of overall systems security and compliance.

You can expect to see more random thoughts and observations on information governance, risk management, IT security, etc. In the meantime, I still have the warm feelings for SharePoint and the community around it, so you may see occasional notes specific to SharePoint as well. (And while we are at it – I am speaking at SharePoint Conference Ukraine next week, excited to be back in beautiful Kiev!)


Last week I was speaking at SharePoint Conference Ukraine in Kiev. The conference content owners had picked SharePoint governance from my suggested list of topics, and I tried to put together several examples to highlight what governance is and what it is not.

What struck me as I was preparing was the idea that the term itself (“SharePoint governance”) is somewhat unique across all Microsoft applications. Have you ever heard about Exchange Server governance? Or Dynamics CRM governance? Even with SharePoint, the term appeared in late 2007 – early 2008 and was quickly picked up by the community. Thanks to internet search technologies, we can see the relative frequency of use for terms “SharePoint governance” and “Exchange governance” in the IT related sources over time:


You cannot really see ANY mention of Exchange governance – why is this so? Do users share less sensitive content over email? Are there fewer business risks associated with email compared to SharePoint? Less need in protecting personal information, controlling exponential growth, complying with content retention requirements?

Obviously, no. Companies have to govern all of the IT infrastructure to adequately address the business needs and maintain controllable and predictable costs. For whatever reason the term resonated so well only with the SharePoint community.

Does this mean SharePoint governance is only a buzz word that various Microsoft partners are glad to use to sell their services and tools? What do you think?

P.S. In my conference talk I tried to give examples why it might be a good idea to start thinking about SharePoint governance. Here’re the slides (in Russian).

P.P.S. Once again, many thanks to the entire SharePoint Conference Ukraine team and personally to Anton Vityaz. Hope to see you in Kiev next spring!

Someone added an interesting comment to the announcement of my “Backup and recovery planning 101” session at SharePoint Conference Ukraine. The guy said they had a problem recently when a SharePoint restore did not work. So the comment was “backups don’t save you from trouble“, and I think it’s worth looking into in more detail. Here’s the situation as it was described:

  1. Several designers are working on a custom application in production SharePoint
  2. One of them leaves the desk with a bunch of unsaved changes on screen
  3. At the same time, another member of the team makes edits and removes “unnecessary” roles (permission levels)
  4. The first designer comes back and saves objects that are dependent on no longer existing permission levels

Well… of course backups don’t save you from trouble when you did everything to get into that trouble! Here’re my 5 tips that could have helped to avoid the failure – and most of this is not about backups:

  • Never develop or test an application in your live production system. If you think you do not have a test environment, you are wrong – you do have a test SharePoint farm. It’s just by mistake you call it your production.
  • Define roles and responsibilities. These two designers making simultaneous changes to the same app could have probably better split their work to mitigate risks and dependencies.
  • Implement change control processes. With a proper change control in place, all team members would have reviewed and signed off on all of the suggested changes before anyone started editing anything.
  • Assess different SharePoint failure scenarios and their business impact, ranging from entire farm disaster recovery down to a single item recovery. How critical is the failure on each of these levels for the business processes? What happens if all SharePoint services become unavailable? How much data your business can afford to lose?
  • Develop and implement backup and recovery plan based on these findings. Establish a practice for testing backups and performing fire drill recoveries to ensure the plan continues to work as the SharePoint environment evolves.

What we have here is an example of extremely poor SharePoint governance. As much as the term itself may be confusing, the lack of governance is usually obvious. See this great post by Susan Hanley for a broader discussion of governance and guidance.

A proper backup and recovery plan is designed to minimize the business impact in case of data loss or service unavailability, based on the estimated scale of this impact. However, backups are only a part of the organization’s efforts to ensure business continuity. Having a backup in place cannot be an excuse for ignoring the need to properly govern your SharePoint customization and deployment.

Technorati Tags:
%d bloggers like this: