By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Think of SharePoint Server as plastic. If you have a vision for what you want SharePoint to become and you carefully define that mold based on features in the product, then you can mold SharePoint into virtually anything you want.
But what happens if you don't have a mold? It turns into goo.
Think of SharePoint service models as the molds. IT shops have turned to service models to give SharePoint consistency and standards. Service models work hand in hand with governance to shape each SharePoint deployment into a unique installation that meets business needs.
And what happens if you have no service models for SharePoint or rules for IT governance in place? You will likely experience "SharePoint anarchy."
The problem lies with those who underestimate the power of a SharePoint deployment and its influence on an organization. They plan their entire deployment as if it's another one of those wizard-based click, click, next, next and finish. There are many systems integrators there to help, but a lot of times IT shops don't even realize that they need help.
The easiest way to recognize chaos is when your users start complaining about junk. When search returns junk as relevant, you know you have problems. The way to bring it back is to analyze your provisioning. Ask yourself whether it's too hard or too easy. Take a look at your information architecture. Can people browse and find information they seek? How about your storage allocation? Are sites too small or too big? And life cycle management— is the data part of old files that should be archived or deleted?
IT managers once empowered with reports and metrics can react better to their environments. This data can help improve the service offering. If the chaos involves poor custom coding practices, then starting from a clean environment and moving over only what's required, tested and signed off on can help IT better manage the solution.
When the IT staff thinks of SharePoint as a service, then they can begin to decide whether they need things like quotas, whether they plan to support self service or if they intend to charge back for site collections. IT may decide to host a portal with sites for each of the business units—not for content storage or collaboration but for publishing. Types of deployment vary so much in both information architectures and in security levels and self-service provisioned objects. Choices will be different in each situation and based on individual needs.
To simplify these choices, I've put together the cheat sheet below.
Now that you've begun defining a service offering, and IT is listening to the business side of the house while it gathers requirements, there will be times when two different business units will not agree on what this SharePoint service offering needs to provide.
Ask yourself: Are we saving money and going with a single server? Or are we going for high availability with load-balanced Web front-end servers and a clustered or mirrored set of SQL servers? The difference in cost is easily evident, and the complexity of support and operations for the staff just jumped in magnitude. The importance of the service has become apparent, and the business now shares in a significant investment in IT to house corporate assets like no previous deployment.
When the finance department gets excited about Excel Services and HR is looking for integration with a legacy information store using the Business Data Catalog, it will be the service owner or service manager who helps provide answers based on a governance plan. A service offering that has clear policies on customization, provisioning and development is the key to a successful deployment.
You'll also need change advisory boards and a true staged deployment that includes development and a production environment with testing and validation for infrequent changes that have impact, such as solution deployments and service packs. These help the various support teams that are responsible for the reliability and availability of a SharePoint deployment.
Choose a framework and fit it to your company culture. Microsoft Operations Framework 4.0 supports both development lifecycle and IT service management. It's a great place to start. It doesn't need to dictate your every move, but it can help you establish valuable IT assurance.
Setting up a governance plan that supports your objectives for a SharePoint service offering will help you achieve a balance between users and business units while helping you mold what SharePoint can do.
Achieving balance through governance is the goal. Balance means providing for the growing needs of the business while bringing about economies of scale with IT. The bottom line is to do more with less.
|Joel Oleson is an independent consultant involved in training, speaking, technical evangelism and product management for a variety of companies including Nintex. As former senior technical product manager for Microsoft Office SharePoint Server, Oleson focused on topics related to enterprise deployments of SharePoint, such as performance, scale, backup/restore and high availability. His blog is SharePoint Joel's SharePoint Land.|