ITIL (Information Technology Infrastructure Library), as defined on WikiPedia, is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business. ITIL also aims to create accountability within IT organizations. Sounds all fine and dandy, right?
Well, my experience with ITIL so far has put some problems in place that are nearly impossible to overcome, especially in a SharePoint environment... and I do mean PROBLEMS.
1. ITIL creates needlessly BLOATED IT organizations. There is a job description for nearly every role in the ITIL structure, and many companies and government enterprises feel the need to put a warm body in every seat defined by ITIL, just in the name of being ITIL-compliant, whether that warm body is genuinely needed by an organization or not.
2. ITIL draws lines between organizations that should be working side-by-side with each other and sharing certain responsibilities. Often times developers and systems administrators have both skillsets and responsibilities that overlap. The strict demarcation that an ITIL-compliant enterprise places between developers and sysadmins can reduce teamwork and collaboration between the two, and worse yet, an atrophying of the skillset that the other possesses. Another unforeseen side effect is that SharePoint Administrators get divided into different levels, leading to expertise in one layer or another of the SharePoint administration hierarchy, but with this focus comes lack of use and loss of familiarity with the the layers above what that administrator has access to (ie. someone whose level of access only goes as high as the Web App or Site Collection).
And worst of all (and a problem my current organization is facing),
3. An team that controls one component of a SharePoint implementation can completely de-rail progress made by the other teams. For instance, the team that is responsible for physical or virtual servers chooses to not upgrade a server whose upgrade is needed to go to the next version of SharePoint... whether that be Windows Server versions or SQL Server versions. All it takes is ONE of the teams not cooperating and poo-pooing the progress of the others by saying "no, we're not going to do that" to bring mission-critical initiatives to a grinding halt. And no one holds the offending group accountable, which defeats the accountability portion of the primary goals of ITIL.
4. Virtualization snapshots are NOT a Disaster Recovery (DR) solution for SharePoint and Microsoft Premier Support does not support SharePoint farms that have been rolled back on VM's! Try telling this fact to the shop that controls all of the enterprise servers... 'Nuff said.
Many companies and government IT organizations are requiring ITIL certification for their administrators,developers, managers, and support personnel, and I think it is somewhat wise to be knowledgable about the intent of ITIL, but most take the concepts too far.
So, to those apologists and die-hards that think ITIL is absolutely the greatest thing, please please PLEASE make sure that you're implementing it in a way that avoids the pitfalls I've listed above.
Well, my experience with ITIL so far has put some problems in place that are nearly impossible to overcome, especially in a SharePoint environment... and I do mean PROBLEMS.
1. ITIL creates needlessly BLOATED IT organizations. There is a job description for nearly every role in the ITIL structure, and many companies and government enterprises feel the need to put a warm body in every seat defined by ITIL, just in the name of being ITIL-compliant, whether that warm body is genuinely needed by an organization or not.
2. ITIL draws lines between organizations that should be working side-by-side with each other and sharing certain responsibilities. Often times developers and systems administrators have both skillsets and responsibilities that overlap. The strict demarcation that an ITIL-compliant enterprise places between developers and sysadmins can reduce teamwork and collaboration between the two, and worse yet, an atrophying of the skillset that the other possesses. Another unforeseen side effect is that SharePoint Administrators get divided into different levels, leading to expertise in one layer or another of the SharePoint administration hierarchy, but with this focus comes lack of use and loss of familiarity with the the layers above what that administrator has access to (ie. someone whose level of access only goes as high as the Web App or Site Collection).
And worst of all (and a problem my current organization is facing),
3. An team that controls one component of a SharePoint implementation can completely de-rail progress made by the other teams. For instance, the team that is responsible for physical or virtual servers chooses to not upgrade a server whose upgrade is needed to go to the next version of SharePoint... whether that be Windows Server versions or SQL Server versions. All it takes is ONE of the teams not cooperating and poo-pooing the progress of the others by saying "no, we're not going to do that" to bring mission-critical initiatives to a grinding halt. And no one holds the offending group accountable, which defeats the accountability portion of the primary goals of ITIL.
4. Virtualization snapshots are NOT a Disaster Recovery (DR) solution for SharePoint and Microsoft Premier Support does not support SharePoint farms that have been rolled back on VM's! Try telling this fact to the shop that controls all of the enterprise servers... 'Nuff said.
Many companies and government IT organizations are requiring ITIL certification for their administrators,developers, managers, and support personnel, and I think it is somewhat wise to be knowledgable about the intent of ITIL, but most take the concepts too far.
So, to those apologists and die-hards that think ITIL is absolutely the greatest thing, please please PLEASE make sure that you're implementing it in a way that avoids the pitfalls I've listed above.
No comments:
Post a Comment