Logo 
Search:

MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

What is your collaboration portal IA?

  Asked By: Adrianna    Date: Nov 01    Category: MOSS    Views: 832

I know there really isn't a right/wrong answer to this issue, so I
thought I'd just solicit some feedback on what other's have done.

We're going to be soon rolling out our MOSS 2007 collaboration portal
and we're trying to figure out how to best organize the sites.

Right now we're using WSS2 and have pretty much just kept making
top-level sites. This is getting out of hand, though, so we need
something better.

As we're an organization with 10 regional divisions, I was thinking that
the option we'd use is to have 11 top level sites. One for each region
and one for top-level administration departments.

We'd then hand off admin rights to each of the 10 divisions and
encourage them to build out the team sites into department site
collections, to best pass on the admin tasks down the chain.

The only drawback to this seems to be that we're going to end up with a
rather deep but narrow IA for the portal which could introduce some
issues with back and up and restore from my understanding. The pro seems
to be that it's the easiest way to best create the permission tree with
regional admins at the top and branching out from there.

What have other IA/site structures have people implemented for their
collaboration portals?

Share: 

 

8 Answers Found

 
Answer #1    Answered By: Elisha Abbott     Answered On: Nov 01

I would seriously look at creating an IA that is process-based, and not
organizational. Maybe have some top level site collections/sub-sites for
wide reaching functions such as HR and IT. For example:

http://portal/IT and http://portal/HR are used for public facing
information, but not for collaboration. You could then create a space
for internal processes for a group using a managed path like 'team',
such as:

http://portal/team/IT and http://portal/team/HR . This could be used for
technology sharing, reviews, calendar, etc. I strongly suggest not doing
the bulk of your collaboration  there, however. I would create a
structure similar to the following for the bulk of your SharePoint
content, where 'projects' (or whatever) is a managed path:

http://portal/projects/Project1 , http://portal/projects/Process1, etc.
If all members of a project/process live in the same site, it makes
collaboration and information sharing much easier.

 
Answer #2    Answered By: Naimish Ranganekar     Answered On: Nov 01

I should step back a bit and actually give
a broader picture of what we--er--I (think) we want to accomplish.

At this point, I'm thinking we'd have at least 3 main portals (on 3
separate domains): One being the intranet, which is mainly read only
across our organization. Another being mySites portal. And the 3rd being
the collaboration  portal.

So, something like:

Intranet.ourdomain.gov
Teamsites.ourdomain.gov
Mysite.ourdomain.gov

In training, I was told that one method is to just not have multiple
portals for the intranet and collaboration portal  and instead just
filter everything through extensive roles and permissions.

However, I find that a disaster waiting to happen in terms of end-user
support with everyone confused as to why Mary can access a particular
document while Bob can't. If a site is generally 'public' then I believe
the view should be consistent between users to help facilitate sharing
information on that site.

So, I'm leaning towards the clean separation between intranet and
collaboration portals. Anything posted on the intranet will be assumed
to be available for read-only access to the entire employee base. Of
course, people would be free to link to their collaboration sites from
the intranet if they so wish.

> I would create a
> structure similar to the following for the bulk of your SharePoint
> content, where 'projects' (or whatever) is a managed path:
>
> http://portal/projects/Project1 <http://portal/projects/Project1> ,
> http://portal/projects/Process1, <http://portal/projects/Process1,>
> etc.
> If all members of a project/process live in the same site, it makes
> collaboration and information sharing much easier.

Right. So, all employees would be a part of this 'collaboration portal'

I guess my question is if it makes sense to just have 300 top level
sites for collaboration, or 10 top level sites with 30 subsites each, or
something in the middle, or is it just one of those 6/half dozen issues?

Seems that a wide flat IA is a lot easier to manage backups/restores
with, however I'd have to set up unique permissions for each top-level
site, while a narrow but deep IA would allow me to delegate permissions
from the top down the chain.

Are there other pros/cons that I'm not seeing to these options?

 
Answer #3    Answered By: Caleb Gordon     Answered On: Nov 01

"So, I'm leaning towards the clean separation between intranet and
collaboration portals. Anything posted on the intranet will be assumed
to be available for read-only access to the entire employee base. Of
course, people would be free to link to their collaboration  sites from
the intranet if they so wish."

Other clients are taking this approach, but it does introduce the
problem of users working in two different locations based on the stage
of lifecycle the document is current in. Having said that, the other
method has it's own problems too.

 
Answer #4    Answered By: Christie Carlson     Answered On: Nov 01

We are still using SPS 2003 and are planning the move to MOSS. In
our current environment, I've started setting up top level sites for
each department where the members of the department have contributor
or higher power and "all staff" have read only access. Beneath that,
we have a private subsite for the department to use for their
collaborative "private" work. There are various sub-structures based
on each department's needs, but the basic goal is for them to
distribute info out to staff via their top-level site.

We have temporary, private sites at the top level for basic cross-
department teams.

We also have public top-level sites for different teams and self-
service needs for cross-departmental purposes. We have a training
site, for example, where groups who conduct trainings can post their
materials/handouts for staff to access. We are also building HR and
Finance self-service sites that are separate from their private
collaboration sites.

We are trying to keep all content, public and private, mainly in WSS
sites. We only use portal  (SPS) for general news, personal sites,
search, and of course, the sites list to organize these various WSS
sites.

We used to try to put "all staff" content in a "resources" area, but
we ran into problems w/managing permissions. Departments also feel
like they have more control over their "all staff" content if it's
in a site they manage. They have more of a "web site" where they can
organize their content, have a "who's who" contact list, etc. They
are more likely to keep those updated since they "own" them.

I'm always looking for "best practices" for this type of thing since
I've never fully convinced myself that my approach is the right one.

I'm interested to hear from others as well. Does anyone out there
have the master plan?

 
Answer #5    Answered By: Dorothy Farmer     Answered On: Nov 01

It sounds like you worked through quite a few issues and have come up
with a good solution. Is there anything in particular that makes you
think that there's a better way to go about it? What sort of issues are
you running into now?

 
Answer #6    Answered By: Jacklyn Burnett     Answered On: Nov 01

Well, first of all, I've always been a big self-doubter.

My concerns usually arise when there's a document or something that
could technically "belong" in more than one site. That's when I want
to tear my hair out. :) I've also got taxonomy issues, so I always
worry about the way I'm organizing/labeling/interlinking
information. I need some expertise in that area, and our Knowledge
Manager unfortunately hasn't had the time to lend a hand. I'm
hopeful that we can do some much-needed cleanup and restructuring
during our move to MOSS.

I think the general dilemma is when to use a site collection and
when to create a subsite. Planning ahead seems to be key. There are
times when I find I want to consolidate several top-level sites
under a related "umbrella" site, and other times I want to move a
growing subsite into its own site collection. I try to base my
decisions on both IA logic and collection size.

I'm hopeful that some of my concerns will go away when we move to
MOSS. Some of the new features may solve a lot of problems *fingers
crossed*.

 
Answer #7    Answered By: Breann Beach     Answered On: Nov 01

I'm in the same boat. I keep weighing pros and cons of various approaches
and just have a hard time biting the bullet and picking one. Because
choosing one approach means choosing to not implement things just as valid.
Security vs ease of use. Independence of governance vs consolidated
information.

Great discussion though. Always good to see what other people's approaches
are.

 
Answer #8    Answered By: Timothy Hall     Answered On: Nov 01

In our 5-day admin class, we discuss this extensively. In short, new
site collections are created when new collaboration  paths emerge within
the organization. Some site collections will be based on your
organization chart because these SC's represent natural collaboration
paths. But others will not - especially inter-departmental SC's. And
then throw in My Sites, which represents the 1:many collaboration path
and things start to get muddled.

IMHO, most admins fail at the alter of matching two taxonomies that
should probably be abstracted. Where information resides (what I like
to call "Where does stuff go?) is one taxonomy - the organization of
browsable links to find that information represents multiple, dissimilar
taxonomies and these are probably federated across your portals and root
site collections.

Frankly, I don't think SharePoint admins should waste time trying to
figure out if a new site collection should be created vs. a new subsite
within a site collection. Teach your users the pros and cons of each in
various situations and then let them make those decisions.

 
Didn't find what you were looking for? Find more on What is your collaboration portal IA? Or get search suggestion and latest updates.




Tagged: