Udostępnij za pośrednictwem

SharePoint Best Practice: Start with just one portal

  • Artykuł

This post could be a little controversial, however I’m going to put it out there, put my head down, and then look forward to hearing responses from others. Let me start with this statement:

“In an ideal world, all customers would deploy just one Portal”

There, I said it, in fact, the whole principle of a portal is that it provides a single place on your intranet for you to find things. It does this by providing the following key facilities:
1. Search
2. Browse
3. Aggregate

It seems to me that as soon as you start to introduce additional portals, then this all starts to break down. Why? Fundamentally, it’s because all of a sudden you no longer have a single place to go, you have multiple places to go. This is compounded by the architecture of SharePoint Portal Server. While we happily let you create as many portals as you like (to a point) some of the above facilities become a lot less useful across multiple portals. To illustrate my point lets take a couple of examples:

1. I have seen many customers deploy the classic “Corporate Portal” with child “Divisional Portals”, using “Shared Services”. This is a model we describe in the “Microsoft Solution Accelerator for Intranets”, and for some customers it works really well. The problem I have with it, is that companies rarely stay the same, what is a division today might be a department tomorrow. By going with the “Corporate-Divisional” model it means you have already set off down (at least) the “Organisational Topology” path, however, with multiple portals you are limited to only being able to move areas (perhaps representing departments) within the portal, in this case a division, not across portals or divisions. So, if a department is moved from one division to another, you are stuck with a complicated migration job. If however you implement the same organisational model, but within a single portal, then such a re-org poses no problem at all, you just drag and drop your areas until they reflect the new organisation.

2. The SharePoint Object Model is a very rich method for accessing data in SharePoint, it’s especially useful for aggregating information. That is, sourcing information from other places and summarising it so that it can be more easily understood. Working with information contained in areas, lists and document libraries within a single portal is a relatively easy process, you have a single unified namespace in which to work. Aggregating the same information from multiple portals is a lot more challenging, most likely involving the development of specialised web services.

These two examples, and there are more, are compelling reasons for trying hard to restrict deployment to just a single portal. In fact I find few real reasons for deploying the “Corporate-Divisional” model, and with it, the underlying “Shared Services” functionality. Interestingly, the key scenario where I feel it could have helped a lot, that being in geographically dispersed environment, is not a supported scenario, but thats another story….

Now, here are my escape clauses. I’m not saying never deploy multiple portals in a single organisation, far from it, but what I am saying is that you should always start from the position that you are going to deploy a single portal, then put the onus of justifying additional portals on those who believe they need them, and be tough. To help you out, lets look at some of the good and bad reasons I have heard:

First, three bad reasons:
1. Because we are a very big company, we require “Shared Services” to achieve the scale we need.
You would have to be one of the biggest companies on the planet for this to be the reason, and really, scale is not why this functionality is included in SharePoint.

2. Because we are special and unique butterflies in this division, we must have our own.
This maybe so, but first I would look at those special and unique requirements to see if others can benefit from them too, usually they can.

3. Because we love to play with all the features of a product.
Hmmmm….said in another way “Because we can”

Second, four good reasons:
1. Because we have a legislative requirement to keep this data separate from that data.
For example “Chinese Walls” setup in banking to prevent fraud

2. Because we have serious political reasons to hand over the management of this portal.
For example “companies within companies”, divisions that operate with a great deal of autonomy

3. Because we have a need for a specific solution that is based on SharePoint.
This includes Document and Records management solutions, workflow solutions and others that use SharePoint as a “platform” to meet a specific business requirement.

4. Because we need to support multiple languages

This actually requires a whole seperate farm, but it's a good reason none the less.

Something that is often discussed when talking about creating a single portal is “but we don't want everyone to go to the same homepage”. Regardless of the model you chose, “Shared Services” or not, you don’t have to, because of course each area has it’s own URL (highlighting the importance of my “URL’s Matter” post). There is absolutely nothing to stop you making the divisional “Area” their home page. In fact with some creative use of the Breadcrumb web part, and its “Anchor Category” property, you can even make them feel like they are at the top of the hierarchy.

One of the reasons an organisation I worked with (a very large customer) deployed SharePoint was to actually bring the organisation closer together. It standardised the way the various parts of the business presented themselves to the other parts of the business. This made sticking to a “Single Portal” strategy very important. We had a lot of pressure from some parts of the business to deploy multiple portals, and in many ways it would have been easier, but today when I look back, it was the single best decision we made.

In summary, keep a close eye on how many portals you deploy, and make sure you have a really good reason for deploying multiple portals, and the “Shared Services” model that goes with it. There really is no point in making the infrastructure more complicated than it needs to be, and you may be missing out on some of the great benefits a platform like SharePoint provides.

Comments

  • Anonymous
    September 07, 2005
    I totally agree. While this can't always be the case for implementations due to the ugly rearing of corporate politics, I whole heartedly agree that one portal can serve all needs.
  • Anonymous
    September 15, 2005
    The comment has been removed
  • Anonymous
    September 15, 2005
    The comment has been removed
  • Anonymous
    April 07, 2006
    Well, it's been 2 years of Point2Share!
    I'm a little late with the Anniversary, but it seems I started...
  • Anonymous
    June 18, 2009
    PingBack from http://patioumbrellasource.info/story.php?id=78