By John Hodges, VP of Global Account Product Management, AvePoint
A recent survey commissioned by AvePoint EMEA asked more than 700 IT professionals across various industries about their primary use of Microsoft® SharePoint®, and Collaboration led the pack.
At nearly every company you will find at least one employee who owes some amount of personal success to SharePoint’s collaboration workload. A friend of mine working at a major financial institution indicated that he believes he owes his current title to the visibility his project received using SharePoint’s native features.
According to another recent study, having a common framework for collaboration resulted in an increase in productivity by 20 to 25 percent. With numbers like this, it’s clear that enterprise collaboration software platforms like SharePoint are here to stay, as organizations are seeing real results when it comes to data and knowledge management.
As collaboration grows, so do the costs associated with storing and maintaining the data used every day. IT administrators are tasked with meeting content lifecycle management needs of the business without driving up storage costs. When meeting with a company in the United Kingdom responsible for managing a SharePoint deployment growing at 50% year-over-year, I learned that they were at capacity in their current data center and needed to retire legacy storage or platforms to regain costs!
Infrastructure might not be the elegant side of SharePoint, but it defines the profitability of your investments in information workers responsible for the revenue and upkeep of your company. We don’t want to minimize the profitability of their ideas by burdening our collaboration system with enormous overhead on storage, development, or other IT services. Like buying a car – you want the productivity of getting from Point A to Point B, but if you don’t take care of the engine, you’ll be shelling out way more money than it’s worth. So how do you prevent this from happening with your SharePoint deployment?
In order to understand the fundamental IT infrastructure issues, we need to think like an information worker. While this might be an extreme oversimplification of the problems at the heart of collaboration software, the information management lifecycle is not unique to any platform and provides a good foundation upon which to build. You can summarize the main stages of collaboration as Birth, Life and Retirement, but embedded in each might be additional Enterprise Content Management workloads features like versioning, workflow, publishing, records management, eDiscovery, and other common activities.
Migration to SharePoint
Project Kickoff Meetings
Team Sites / Intranet
Publishing & Migration
Replication & Availability
Supporting users throughout the creation, distribution, and expiration of content places different burdens on our services, but also more importantly on the storage we choose. Creation of the content is generally focused, high performance read/writes in the geography of the team working on the content. Once information is publicized, the burden now becomes distributing content to a global user base consisting of largely read-only consumers. In an end-of-life scenario, the data is now limited to access by only a few, typically from legal queries.
The issue: the standard SharePoint information architecture designs dictate the creation of databases, site collections, and web applications by business unit or organizational structure, not by how active that content may be. As an example, Microsoft itself placed a substantial emphasis on “in place” records management with the launch of SharePoint 2010. But in doing so, we’re cheating ourselves out of cost optimization. A disk with the highest read-writes for active content is a poor home for long-term records, many of which can be stored on disks under high compression.
You want to provide all global users with fast access times to SharePoint content, but still maximize cost of your infrastructure. How? The simplicity of an information architecture divided by business units lets me provide different levels of service to different users, and shouldn’t be changed - this architecture has been a best practice for SharePoint for several generations now. We need a solution that can let us craft and carve our storage costs within the same SharePoint location, and Remote Blob Storage (RBS) provides that ability!
Some tips for minimizing the total cost of ownership of your SharePoint include:
· Identify content for RBS using business rules determined by activity, tag, and location to determine the state of the information lifecycle
· Connect to existing file share drives to avoid time- and resource-intensive migration
· Reduce cost by moving storage heavy, unstructured data (BLOBs) from expensive SQL Server content databases to lower tier storage
· Archive dated and inactive content to cheaper storage
· Automate backup, storage optimization, and reporting jobs as well as adopt user-driven site creation and lifecycle management technologies
· Anticipate costs and create charge back models with comprehensive reporting that helps predict storage growth, user activity, and appropriate level of service
· Move to a cloud-based infrastructure with built-in global redundancy
Assuring a repeatable, predictable, and governable center of information collaboration allows organizations to drastically minimize their total cost of ownership. This allows organizations to recognize full value from their SharePoint deployments, ensuring SharePoint operates with optimal efficiency while supporting the complex business needs of today’s global organizations.
John is Vice President, Global Account Product Management at AvePoint, and works directly with the company’s product management and research & development teams in the design and implementation of new SharePoint solutions that help organizations solve the business challenges they face every day. John has been actively engaged in the SharePoint community for several years, working with many Fortune 500 companies to develop successful SharePoint solutions that meet their unique and stringent business specifications. John received his engineering degree from Columbia University, in New York City.