The SharePoint Environmental Shift from Centralized to Decentralized
In an article I wrote for SDTimes.com (SharePoint Architecture: Centralized or Decentralized?), I tried to make the case that most companies struggle with the design and architectural decisions around SharePoint, and, more specifically, that they 
have a difficult time decided whether or not they should mirror the more traditional structure and permissions of their internal portals, or fully embrace the ad hoc and collaborative model of My Sites. Centralized is generally interpreted as a traditional, top-down managed portal, whereas a decentralized environment is equated with user-driven collaboration and a more innovative environment (and sometimes doing what they want, regardless of company direction). If you follow technology news, the way that the next generation of employees work is evolving, and with the seemingly relentless barrage of social media tools hitting the enterprise, the move is towards a more ad hoc, decentralized environment. But how does this impact your SharePoint architecture?
Companies struggle with the decision of centralized versus decentralized for good reason: these decisions determine how the environment will be managed, the governance policies enacted, how customizations will be supported, and the level of difficulty of future upgrades. However, with the introduction of centralized services in SharePoint 2010, the definitions of centralized and decentralized as they pertain to structured and ad hoc environments, respectively, no longer apply. But there are still some considerations that need to be made around environmental changes before you determine your path, migrating or deploying to the latest version of SharePoint.
I call this paradigm shift the "environmental shift" in how you think about your SharePoint deployments, where the size of your environment, the server footprint, or the traditional views of security and centralized management have little to do with the topology and functionality used. Centralized does not necessarily equal a small, static footprint, just as decentralized does not mean a more expensive and expansive deployment of servers to support a more dispersed array of end users and functionality. Instead, the size of your environment depends more on the additional services used (BCS, Performance Point, Project Server, FAST Search), the performance needs of the organization, and how the environment is designed for scalability -- regardless of how the environment is being managed.
This environmental shift in your thinking must be reflected in your planning efforts before moving to SharePoint 2010. Whether moving from multiple farms to a single 2010 farm, expanding from a single-server install to a more stable configuration, expanding your content databases, or adding additional servers to support plans around additional SharePoint services, the key is to review your architecture, build a platform that meets your business requirements, and optimize the platform for your performance needs:
- Define the additional service applications to be deployed
- Utilize these service apps to simplify governance and management
- Model your environment for scalability
- Understand site administration requirements
- Define and communicate roles, site permissions, and boundaries of security trimming
- Understand growth needs for your content databases, structure appropriately
- If preparing for a migration from 2003 or 2007, take the time to clean up your taxonomy and metadata prior to your move, so that you can take advantage of the full capability of 2010
In my next few articles, I'll discuss the cultural, governance, and social informatics shifts in thinking around the move from a centralized model to a more decentralized design, allowing you to better plan for and leverage the collaborative features in SharePoint 2010.