Category: Architecture

SharePoint or Application Architecture related posts

Supporting Multiple Active Directory Domains

In many environments there is more than one Active Directory forest with users that need access to the SharePoint farm. Setting up support for users on multiple domains is pretty easy and can provide new collaborative features for users throughout the extended organization.

Trust Relationship
The only prerequisite is that there has to be a trust relationship between the forests. Users from the other domain(s) will need to be able to authenticate and access resources on the host domain.

If that trust is not in place, here is a good resource: Support for Cross-forest deployments

Setting up the Import
The Profile import settings are in the Shared Service Provider’s User Profile section. Setting up the primary domain, the domain the server is on, is pretty straight forward and the default settings should be fine.

To setup an import for additional domains click on the “View import connections” link from the main User Profiles and Properties page followed by the Add Connection item in the toolbar. Fill in the domain information and click the Auto Fill Root Search Base button. If the SharePoint Administration account does not have access to read from the target domain you will need to supply an account to read the directory.

People Picker Control
If there is a one way trust, or there are duplicate accounts (display names) on different domains it may be a good idea to set some additional properties. In the article Select user from multiple forest domains it provides a path to specify which forests to search, and allows the passing of credentials if the SharePoint Administration account does not have the required privileges.

The platform does a good job of supporting cross domain collaboration, and it is a lot easier to setup than many enterprise systems. In one environment I had to support over thirty domains so the information included above really came in handy.

Search versus Information Architecture

At a recent Triangle SP User Group meeting an interesting debate broke out regarding the use of search to find information inside of a SharePoint system. One person went as far as to say that “search is a last resort” while another said “if a user has to search, you have failed.” Those are some pretty strong positions to say the least. I believe that Information Architecture and Taxonomy are incredibly important, but Search is as well and should not be a last resort. If proper planning is not done in both areas people are going to have trouble finding what they are looking for.

Preferred Method Depends on Context
First I think this debate requires context since the type and the amount of content to look through can range dramatically. Browsing a Wiki with 20 pages is not the same as browsing a Document Library filled with 100,000 invoices. For the former it would seem crazy to need to rely on search, but with the latter it is absolutely essential to most end users.

Users Think Differently
I have had the chance to do usability studies for large SharePoint implementations in a few organizations now. Early on I was amazed at some of the feedback I received with regards to organization and taxonomy. All users do not process thoughts the same way, so while you can work hard to cover all your bases some will still be left out. Put as much time into planning the Taxonomy as possible, and review it on a regular basis as the content and purpose evolves.

Search Needs Tuning
The search service with MOSS can be pretty powerful, but it isn’t something you just turn on and expect targeted search results to be delivered. Time should be spent planning the search system to take advantage of its powerful features including authoritative levels, keywords, best bets, scopes, etc.

As part of this planning effort you should try to identify which sections or sites could most benefit from custom search interaction. If the nature of the data is such that searching is likely to be needed, configure tools to make it as easy as possible to pull that specific set of data. In Mike Gannotti’s presentation, one of the things he suggested was creating a sub-site for each feature or type of list. The advantage of this is that when users search at the “This Site” scope, only data from that level will be returned. With the exception of Wiki configuration, this is not something I have typically done.

Learned Behavior – Browsing versus Searching
After the meeting I reflected on the topic quite a bit, and then a day or two later something occurred to me while working on my Vista machine. When I sent to go open a program I found myself using the desktop search feature to find the programs that were not pinned to the Start Menu. In the past, on previous computers, I had spent an insane amount of time building a system to help organize my program menu. Since I had too many things installed and the menu would wrap, I created a taxonomy with high level categories that led to the program folders (i.e. Dev Tools, Sys Tools, Office). Everyone agrees that browsing to something when you know its exact location is very quick. However, it is quicker still to type in a name and then double click the result returned. Reaching the Event Viewer for example has never been so easy. Without realizing it, my behavior in this OS has changed. While I am not a typical end-user, I believe that I am not unique in being able to adapt to new ways of finding information.

End User Ownership and Evolving Content
Some of the biggest Information Architecture challenges I have seen come from the fact that in most organizations many of the site collections are owned and managed by business units. You can try to educate them on proper planning and maintenance, but in most cases it is far from their top priority even as people complain about usability.

In many cases the purpose of the system changes leaving it out of sync with the taxonomy or navigation design. This is a sure fire thing that pushes users to rely on search.

Best Way Forward
I think the best way to tackle all of these challenges starts with proper planning and site owner education up front followed by periodic reviews of existing sites after the fact. If you can schedule reviews either quarterly or semi-annually as part of the overall service offering it will help you limit some of the issues of End user Ownership and Evolving Content. By keeping the system tuned, users will be more productive, and therefore more interested in using the system which increases end user buy in.

Where Do You Stand?
Where do you stand on the debate? Do you have anything to contribute to the discussion? Is Search a last resort? Is developing a maintainable taxonomy even possible?

Buy versus Build

A discussion broke out on the MSDN/TechNet SharePoint Forums this week that started to approach the subject of build versus buy. It is something I have had to put a fair amount of thought to in the past so I decided it might make for an interesting blog post.

As a developer, I enjoy developing. It is always fun to dig into code and solve a problem or fill a need. Unfortunately I don’t get nearly as much time to develop as I used to or would like. It ends up being something I do between meetings, on weekends, or in support of a project when the other developers are not available. As I’ve moved through the roles of developer, team leader, architect / program manager I have had to look at things from different angles including that of what is best for the company or the users the solution is being deployed for. Sometimes those personal goals and enjoyment have to be set aside in support of the company’s and users’ best interest.

One of the main trends of computing over the past 10+ years is the move towards interchangeable components, services, etc that can be stitched together offering reuse and decreasing the total cost of managing systems. SharePoint is a great example of this as a platform that has a rich market of third-party vendors. There are 100s of available solutions, web parts, etc that are publically available.

Here are some considerations when evaluating whether to Buy or Build solutions.

Requirements – Is there a solution available that meets the requirements? Is there something close enough to consider as an option? If not, and its needed then its clear you would have to develop it.

Initial level of effort – Do you, or does somebody on the team have the skills and know how to develop the solution or is this a learning opportunity? How long do you expect it to take? If it is full of unknowns or if the projected cost based on a standard rate ($50 an hour?) comes to 80% or more of a commercially available solution it probably isn’t something that should be custom built.

Are there other things that are a better use of your time? The last few organizations I’ve worked with I’ve had a running backlog of projects averaging two years. It is normally easier to purchase components than it is to add to the headcount. Purchasing components or solutions makes it that much easier to deliver value quickly.

Ongoing maintenance and support – Do you or does the group have the time to support the solution going forward? You may have time now, but if you squeeze it in what happens when they come back for changes or you need to upgrade? Will you have time to work on it? You can rely on the vendor for this in most cases if you purchase support for the solution.

On the flipside, make sure you take into account the vendor’s stability and history and make sure that they will support the solution going forward and/or still be around. I have made the mistake of purchasing a solution from one company that sold me a dead-end product that was replaced.

Quality / Grade – Do you, or your team have the skills to meet the needed quality and grade of the solution? In most cases the commercially available solution has a team supporting the development effort to include qualified quality assurance professionals.

Budget – Do you have funds available for the purchase. In some cases there just is not money available, we are in a recession after all, but smart businesses will find the funds if the solution does add value and save time. Mature organizations probably understand this a little better, and therefore tend to have larger budgets to support the purchase of technology.

By taking these considerations into account it will help you make decisions that add value to the organization and its end users.

Finding Success with SharePoint Deployments

Finding success with SharePoint or any other collaboration software can be a difficult thing. It has less to do with the technology than it does the people and the way its implemented. Its not that people have bad ideas, they may just underestimate the amount of effort it takes to reach the promised land. There is no silver bullet or application that you deploy and it just magically solves all of the organization’s problems. In many cases the software is deployed as part of an formal or informal effort to breakdown longstanding silos within the organization. Breaking down those silos is difficult and that road is filled with hazards.

A good first step is to clear identify and validate the goals of the implementation and get an understanding of what the expected level of effort is to reach those goals.

Easy Win or Easy Implementation?
The best way to get an easy win or have an easy implementation is to install SharePoint as a workgroup solution. Its very easy to do, and if based on Windows SharePoint Services (WSS) it can be done with existing equipment. Each department or workgroup can then do whatever they want and get as little or as much localized value out of it as they want. The people may seem to be happy with that, but there is a real limit to the amount of success and productivity. Also, it does nothing to promote sharing and collaboration throughout the entire organization. In fact it further reinforces those silos.

Enterprise Needs Governance
If you talk to any long time SharePoint architect or evangelist one of the primary topics is Governance. Its not just a buzzword, it is the single most important determining factor for success in a large organization. It is the glue that holds everything together and gives you the ability to manage the environment without it breaking down into petty fiefdoms. Getting agreement is never as easy as making an independent decision and then acting.

In an enterprise deployment it should support localized management in support of global standards. Just because Governance is in place does not mean that everything must be managed centrally.

Here are some suggestions
– Get executive sponsorship. Organizational change cannot happen without executive sponsorship. State the case with realistic benefits and get buy in.

– Involve as many stakeholders as possible. Like any change people are more likely to adopt it when they have a say in what is done. Not everyone will like every decision, but hopefully they will feel good enough about their involvement that they will participate.

– Address Governance from the start. You cannot easily retrofit these ideas or policies into an established system. The change would be costly and the need to retrain everyone pretty severe.

Benefits to Enterprise versus Workgroup Solutions?
Enterprise deployments benefit organizations by supporting cross-functional collaboration. It also provides a platform for some of the social enterprise capabilities such as central profiles fed with data from sources like Active Directory, HRIS Employee Data, and other data sources particular to the organization. These tools can help make people more productive, but also help to find internal resources and subject matter experts.

Another benefit is that you are more likely to see funding for integration efforts into other enterprise systems such as Business Intelligence (BI), Enterprise Content Management (ECM) or Business Process Management (BPM) solutions. Being able to leverage these other integrations should more than make up for the lack of control the individual organizations’ are asked to give up.

The SharePoint Cloud

This week while discussing some open development projects the conversation turned towards some architectural topics and what the purpose of SharePoint is. I feel confident in saying that SharePoint can be used for so many different things. It got me to thinking though, what if it were treated as an early cloud platform? The more I thought about it, the more it made sense.

Imagine a large complex organization with a central IT group that provides services to the different business units.

Independently Deployed Apps
Independently deployed applications would include custom development or packaged software applications. There could be many dozens of web, app, and database servers scattered throughout a data center. Each system is managed independently, potentially by different groups.

Setting up or deploying a new application could take weeks as servers are deployed, software is installed, and access rights are given. If the load of an application is too much then it needs to be reviewed to see if another system can be added for load balancing; hopefully its stateless. This can be a very difficult process with custom applications, and impossible with some packaged applications. Since storage is managed independently each system has to be reviewed or monitored separately.

Many companies operate like this to some degree. It can be very expensive to manage which is what brought on the Virtual Server revolution. Virtual servers reduce hardware, but in most environments they do not reduce the number of systems on the network.

SharePoint as a Cloud
SharePoint deployments can be setup to handle 1000s of Site Collections, and provisioning can be automated. Storage can be handled centrally and allocated as needed with support for quotas and standardized usage reports. There are some great mechanisms in place to easily add a new web front end quickly allowing you to scale out a farm to handle higher user loads with the use of a load balancer. Using virtual server technology this can also be automated. There are also administrator tools that make deploying components, site definitions and other solutions relatively easy.

Developing on the SharePoint platform can be a transition, even for .NET developers, but with the addition of the Business Data Catalog, InfoPath Forms Services and the Workflow capabilities there really is a rich feature set to work from. When compared to the two previous versions, I think the current version (WSS 3.0/MOSS) has made development a bit easier since its based on ASP.NET and exposes a familiar object model.

One of the recent developments I find interesting is the technique of using JQuery to interact with SharePoint’s API or any other web service without the need for server code. This can simplify development and project deployment efforts quite a bit, while delivering the same robust functionality.

While developing and delivering applications on top of SharePoint platform may sound far fetched to some, there are already a number of companies delivering vertical solutions and application frameworks including Open Text, Quest Software, and KnowledgeLake.

While the future promise of the cloud is to move that infrastructure and management of those servers outside the walls of your enterprise, I think many of these same concepts can be applied inside those walls now using SharePoint. This could bring easier maintenance, administration, and a substantial cost savings.

Planning for Separate Site Collections

When planning out the site structure of a new SharePoint system, here are five things I take into consideration. Taking these into account during your planning phase will hopefully reduce the amount of rework needed as your system evolves.

Amount of data

If you are expecting a large data set, perhaps you are scanning all supplier invoices and using SharePoint for Content Management, its important to consider the size of a Site Collection and the underlying Content Database from an Administration standpoint. Larger Site Collections and Content DBs require more care and attention along with a more advanced skill set. There have been a number of discussions on what the guidelines are, but I aim to keep Content DBs under 40Gb unless there is a real exception. In this case, the size of the data over rules any of the other answers.

For site collections I expect to grow large, I set them up in a dedicated Content DB right from the start. This saves the trouble having to move it to a different content DB later which can take some time with large sites.

Type and Purpose of the Sites

In a small to mid-sized organization I typically treat sites that support Intranet or department level collaboration a little different than cross-functional or project type sites. Its easy to define the groups around the functional areas and you can reuse those groups in other sites where there is overlap.

In larger organizations sites typically require more isolation. There may be a some interaction between the groups, but not within divisions. In this case the Site collections can be structured to support the organizational boundaries.

Groups Definition and Membership

Groups are defined within the site collection container. If you setup a group called “Management” in Site Collection A, it wouldn’t be available to Site Collection B unless its setup separately. It may not sound like a big deal, but it gets very tedious when you have to manage the same group in multiple places. To make matters worse administrators often take for granted who is in the group based on the name. When setting Site Permissions a group’s members is not directly visible.


WSS and MOSS have some good out of the box navigation systems. They are limited though when it comes to trying to tie together multiple Site Collections. There are solutions like defining custom providers but then you are introducing sophisticated customizations that not every company can support. A last ditch option is to manually link to sites and resources but then everything becomes much more difficult to manage.

If it is important to have a consistent horizontal navigation scheme, look to keep as much as possible within a limited number of site collections.

Aggregating or Reusing Data

One of SharePoint’s greatest values is in its ability to support syndication and aggregation of content to deliver it where the users need it. You can aggregate the content using tools like the Content Query Web Part or DataViews. These techniques get a little more complicated when content is in different site collections. Custom code or third party tools are then required to accomplish bring things together.

Agree? Disagree? Let me know, I would love to hear your feedback.

%d bloggers like this: