SharePoint Best Practice: Start with just one portal


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 (9)

  1. 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.

  2. L says:

    Daniel,

    You have brought up an interesting topic.

    1. I agree with that it is important to create one face towards the organisation.

    2. It is also very important not to create a taxonomy that is based on an organisational structure that often has a quite limited lifecycle.

    However,

    I feel that there is some limitation when deploying only one portal in an organisation with a lot of quite separate divisions or business areas. One important example is the navigation in SharePoint. I want to be able to use both the horizontal and the vertical navigationbar in order to create an effective and well structured taxonomy in the portal. I would also like to be able to do this for different parts of the organisation (for instance for different divisions). Today, SharePoint out of the box only makes this possible by creating several portals (and then you are more or less "forced" to use shared services in order to get a manageble portal environment (and then you lose the possiblity to submit documents, etc. to portal listings from a WSS site that belongs to Portal A to Portal B, which is very sad…and there is even more functionality that is lost…topic assistant, etc.)

    What is the best solution in order to get the best of both worlds?

  3. Hi L.

    The first thinig to say here is that the navigation in SharePoint is simply the result of some fancy .NET controls that take advantage of the underlying SharePoint Object Model, so there is nothing at all to stop you writing your own. Of course I know thats not "out of the box"…

    Further than that, the navigation controls that do actually ship with SharePoint provide more flexibility than it might first appear.

    This is why I mentioned in the above article "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."

    In a big implementation I worked on, the horizontal bar across the top was very static, it gave you access to the sorts of things that were "taxonomy neutral", like Team Sites, News, other taxonomies (eg. Geographical) and the org internet site. The left hand navigation was then modified so that instead of being "anchored" at the "home" area, it was anchored at the "Divisional" area, in this way it made it look like there were 6 portals to end users, but it was all under the one umbrella.

    Some of what I did there you can find in my branding whitepapers:

    http://blogs.msdn.com/danielmcpherson/archive/2004/12/09/278966.aspx

    Anyway, this is getting to be a long discussion, perhaps I need to roll some of this up into a blog post.

    Let me know if I have understood you question right.

    Daniel

  4. Point2Share says:

    Well, it’s been 2 years of Point2Share!

    I’m a little late with the Anniversary, but it seems I started…