I am creating a new SharePoint 2013 farm and am rethinking the way the SharePoint farm should be architected. There are considerable roadblocks to sharing information between business silos. That has been the way business has been done for years, however, should tackling these roadblocks be done by processes and workflows or by the architecture of the farm? I am not sure which way to construct the site collections/sites in the farm because I want to maximize the efficiency and break-down the walls around the existing business units.
1. Should I build our new SharePoint farm with site collections matching the existing divisional business units? This would be easy. If so, then would breaking-down the walls limiting communication be done via permissions, groups and business workflows?
2. Or should I construct the new SharePoint farm organizing the site collections/sites into functional business units to begin with and not aligning them directly with the existing vertical silos? There are similar business functions in multiple business silos. Then all of the sub-sites would share a common interest and can share data. There may be portions of a vertical business unit broken up into different site collections. Is that a problem? Couldn’t the sharing of data be easily done across site collections? Would this organization cause too much confusion?
Thanks,
Alex
In determining the style of layouts for you farms, how do you come to decide on the architecture? What considerations did you work through to determine the best organizational layout for your farm? I have created 2 visio diagrams (not included in this post) for a proposed IA for our environment based off of an Org Chart and then a functional diagram of business processes.
SharePoint is a new technology for our company and nobody has used it before (except me). My goal is to structure our environment for future growth and sustainability. It is very important that we break-down the barriers of communication within our organization and create the best avenue to share and collaborate together. No, I don’t think that SharePoint is the holy-grail, but rather a tool to facilitate business productivity. In that thought, I want to make sure that the organization is done with the most foresight.
The moment we introduce SharePoint to our user community people will have to change the way they are doing their daily tasks. If the farm is not built right, we’ll have to make more changes.
Although change is inevitable I want to minimize those changes. If it is recommended to build our SharePoint environment based on functional usability and NOT based on a strict organizational chart, what are the unperceived complications I may encounter?Â
An example of our Org Chart looks like this:
·        Dept.A
·           – administration work
·           – green widget maintenance
·        Dept.B
·           – red widget maintenance
·           – blue widget maintenance
·           – yellow widget maintenance
·        Dept.C
·           – purchasing widgets
·        Dept.D
·           – purchasing widget holders
·           – admin staff
·        Dept.E
·           – accounting
Â
The re-organization may look like this:
·        Dept.A
·           – administration work
·        Dept.B
·           – red widget maintenance
·           – blue widget maintenance
·           – yellow widget maintenance
·           – green widget maintenance (still managed by Dept.A)
·        Dept.C
·           – purchasing widgets
·           – purchasing widget holders (still managed by Dept.D)
·        Dept.D
·           – admin staff
·        Dept.E
·           – accounting
Â
Here is a list of issues I am thinking of:
·        Managers may have to manage users in different sites or site collections
·        Dashboards will need custom code to pull in data from other site collections for their users
Â
What other complications might I run into?
Thanks.
Alex
Â
