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
what kind of access need to have for other dept users in green widget maintenance.
The concept is to organize sites by job function under a common site collection. There are several different sub-departments that perform similar job functions but in different areas. If we organize the site of users based on function then all “purchasing” roles will be under a single roof. The thought is to organize SharePoint for a universal scalability. This would allow for scalability and growth without re-structuring (maybe) the site/sub-site layouts. The navigation to the sites would need to be managed programmatically so that all the links resolve to the correct location. That is our thought process.
We are not sold on this idea yet so if there are objections or roadblocks we would encounter, please let us know.
Hi Alex,
Go by the First Option. it will more easier to Maintain the contents.
Also Why you want to move the site which is owned by One Dept. to under the hood of other dept.
If SharePoint is new for your Company its best to bring the goodies on an interval Basis ………..like Blog, Community site etc…
if you give everything its very hard to digest for them as SharePoint is a very Big Platform….
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
Â
