So I wanted to talk about ensuring you put a formal definition of your “Service Level Agreements (SLAs) in your governance documentation. Many IT folks can quote their companies SLAs without even having to go to materials, but the business is where you get caught on this. Why?
When did you hear an executive secretary for the Senior VP of Marketing quote IT on expectations of service…lol. Sure and I expect that VP to just say OK, I can’t do my job, I will patiently wait for MySite or data……Seriously if you have that environment…congrats.
But in the other 99.999% of organizations, the SLAs are what assist everyone to understanding what they get. Think of it as a Social Convention ensuring IT does not go crazy trying to support 5-9’s. I wanted in this post to give you some Bullet Points that you can use, or alter in your governance. “Actual Language”.
Technical Requirements
So I the Technical Requirements will focus on the IT side of life. Making sure that the business understands what to expect when something happens, or what IT is doing to support the business. Don’t get preachy in here, and don’t over commit. Give hard information, and numbers. I am not a fan of actually putting fluff for the case of page fill. If you only have 2 bullets here, fine, but make them quality.
Monitoring of Production systems, ensuring outage or system issues are detected leveraging monitoring tools, alerting, or staff interaction.
Health-based application monitoring (synthetic transactions which proactively identify downtime and performance identified at the page level)
Disaster Recovery – Disaster recovery environment setup in alternate datacenter to avoid further points of failure due to acts of God (flooding, fire, tornado, hurricane, and extended state wide power outages)
Recovery time objective 4 hours or less for non-catastrophic outages and 24 hours for catastrophic outages. (Recovery/Failover datacenter should also contain dependent services including SMTP, Active Directory/Authentication services, DNS, and SQL Server storage)
Recovery point objective for intranet portal is 4 hours or less. (Requiring full logging and more frequent incremental backups.)
The hardware needs to scale and support company growth. The initial deployment should support at least 300 GB of data with the ability to grow to 1 TB over the first year. Storage area network (SAN) storage for SQL Server needs to support 5 TB at maximum capacity.
Design requires avoiding all single points of failure including storage
Business Requirements
So a lot of time when you hear SLAs you only see what the business is expecting out of IT when they pick up the phone to “Phone a Friend”, or just freak out. Seriously it is also very important to allow the business to put on paper there expectations. Now what is a critical challenge is this area is a “Moving Target”, or a team can let it get that way. As the business uses the tool, they define new requirements, new business needs and challenges. The SharePoint team needs to weed out chaff and do what is good for the business and the solution. Those that are implemented, if so big and impactful, should also be added here. So in many cases this page in my governances, also becomes a living wiki page in our SharePoint IT Support page.
Search requirements – Enterprise search as a service will be provided on the top intranet portal and departmental portals. The SharePoint Administrator will support the gathering of Web Analytics and Usage Metrics. Scorecard metrics are to be established to help determine the evolution of this environment. Application of these findings into Keywords, and Best Bets on the Search Results will be applied as value is determined.
Login and authentication – Seamless login on intranet and simple login for Internet access. Users should be able to use their existing NT Active Directory accounts. No additional accounts should be required. External employee access through VPN connectivity. Non-Active Directory account holders (manufacturing, etc.) have the ability to leverage kiosk and group account access.
Site Life Cycle – Content expiration will be limited to site collection expiration policies enforced by the SharePoint Operations team. No site will be deleted permanently without first notifying the primary and secondary owner, and then after some agreed-upon time the site should be backed up for quick retrieval prior to anything being deleted. These “archived” sites will be retained for a period of 1 year after being removed from the production system and restored upon request of either the site collection owner(s) or by approval from the general manager or higher for the business unit to which the site belongs. If the out of the box solution needs additional capabilities, partners such as Digital Macgyver can provide a Governance programmatic solution that complies within the businesses policies for customization.
Editing/Design/SharePoint Designer Usage Policies – Master pages will be authored by a single design team. SharePoint Designer will be supported only by those “certified” by the IT team where the tool deployment will be tracked and managed. SharePoint 2010 offers additional granularity on what modifications are allowed within Designer 2010.
Auditing – The default auditing settings will be turned on consistently across all sites for the purpose of tracking item deletions and auto expiration policies.
Site Templates – For the first phase, the business units need the OOB Templates ie.(Team site, the Enterprise publishing Portal, Internet Portal, Document and various Meeting Workspaces, and Wiki). No other templates are required at release.
Workflow – Enhanced workflow solutions. Workflow solutions on top of SharePoint Server are being evaluated with limited SharePoint Designer access and a requirement for more powerful solutions right through the browser. SharePointReviews.com is being used to narrow the leaders in this space with on-site validation of the top three candidates.
Costs and Considerations
So now that you have put in 2-20 bullet points in your governance SLAs, what is the costs? That is really where you need to be careful. Consider the above bullets,
You have committed to a monitoring method (not part of SharePoint), you have a DR plan outlined (offsite DR), you have a recovery model (redundant systems, and recovery), storage commitment (SAN likely, so plan for storage growth), and no single point of failure (redundant systems). Now some of that is just normal components of your existing IT Strategy, so you can extend your DR program to include SharePoint. It could also be part of your Storage Strategy so no worries. Make sure your language matches your level of IT commitment, skills, and budget. If you do not plan to by a tool like Control Point, don’t put in a monitoring or management bullet. (sorry for the product plug, could not think of a free tool).
Second is the business costs, don’t let the business just drive the bus, QUALIFY business requirements, make sure they fit the NEED, LIKE, MUST HAVE levels. Remember that the SLAs are defined in the governance are deemed must functionality. Some of these requirements, will also translate into soft costs such as training, or mentoring. So prepare for your SharePoint IT team to provide, or direct the business to a knowledge resource. Understanding Worklfow for example is a must to be clear on Custom/Enhancement, to some everything is an enhancement. Be clear here.
Conclusion:
If you are an existing IT shop you should have SLAs you have documented for other solutions, or have SLAs with your vendors. Use these as a reference, don’t try and create these from thin air. They are binding with your customers (your organization), and they will hold you to them. Make sure you have vetted them with your Steering Committee, and Governance Committee as they are also committing to spend funds, and time to support them.
I cannot say this often enough…..K.I.S.S. applies to not only building SharePoint it applies to language, do not get wordy, and don’t over commit.