So now the foundation is laid and the argument has been made that Power Users should be allowed to meet their full potential with the aid of SharePoint Designer. The business benefits from this more engaged and empowered work force, and because the tool is only given to those showing an advanced understanding of the platform, the risks have been mitigated. However, as SharePoint maturity grows, there is an even more menacing threat to the business in the absence of configuration management.
Traditionally, configuration management is a process of recording changes in either software or hardware systems with the intent of providing a traceable map of development and/or assets. Most would argue that SharePoint does not fall within traditional software or product categories, but the same principles of configuration management apply perfectly to SharePoint development in that the successful evolution of the platform (in the form of future upgrades) is dependent upon a comprehensive inventory of the solutions it is supporting.
The concept of empowerment may not seem immediately tied to that of configuration management, but the elements of planning, approval, documentation, and change management bridge that gap between business and IT in a manner that is enormously beneficial to both sides. Any time a business-critical solution is created without supporting documentation, the future sustainability of that solution is at risk. The larger the environment, the larger the risk, since the right hand cannot possibly always know what the left is doing, nor why it is doing it, but at some point it will have to be supported just the same.
The concepts introduced here hinge on the fact that the platform is being developed and, as such, that development must be documented, regardless of titles. Some SharePoint developers are quite vocal about the notion of sharing the word “developer” with business users. Squabbling over a title completely negates the core issue of not capturing business and project requirements for solutions that users are dependent upon for their work. Power Users are not SharePoint developers, however they are developing the platform and should be taught the disciplines that conscientious developers know to be fundamental to their practice.
One reason SharePoint does not fit the model of traditional software or product development is because it allows so many to participate in the process; the very reason why a method for managing it is so important. Documenting SharePoint development should be a marriage of disciplines between project and configuration management that provides structure and understanding without being overwhelming to maintain. This central repository should meet the key needs of IT by providing an overview and auditing process, and integrating features of approval workflow and review cycles, while providing business users an educational resource for sharing and expanding their knowledge.
Luckily, SharePoint is perfectly suited to practically any form of content management. The real challenge is in developing the discipline needed to maintain the solution. This is where IT has the advantage in stating, “No discipline? No empowerment.”