Over the past week, I’ve been posting like mad to the sharepoint_tech mailman list. If you aren’t subscribed, you should consider getting on that list. But don’t worry about missed content, because I’m going to re-post all that stuff here (sorry about duplication, but I think it makes sense for the content to be re-accessible). So expect a torrent of sharepoint related info here soon.
With a bit of my time opening up with the advent of the Nebula domain migration put on hold, I’ve been really digging into understanding Sharepoint 2007. Like everyone else, I’m interested in learning what the buzz is about, but I also bring a focus which is very architecture-centric–the “big picture” if you will. The funny thing about such a “big picture” focus is that it requires both a breadth and depth of technical detail. This is really hard to get with something like Sharepoint, where the feature set is so large. But for the first time, I’m starting to get a sense (dare I call it a vision?) for what the Sharepoint architecture might look like here at the UW.
So there are several fundamentals you have to understand about Sharepoint :
- Almost everything in Sharepoint is stored within a SQL database. There are some exceptions and it’s the exceptions which often drive architecture.
- Almost everything in Sharepoint is a list or an object in a list. The exceptions here aren’t significant.
- There are some fundamental, basic building block, kind of objects which define what most users see and experience. Those objects are:
- Content types. Most everything revolves around content types. If you’re like me last week, you probably don’t know what they are. Content types are the schema component within the data architecture of Sharepoint. So every “item” within every list in sharepoint has a content type, e.g. document, calender item, contact, etc. A large set of the “global” functionality within Sharepoint is targeted at content types. For example, data retention policies are best targeted at content types. Workflows are best targeted at content types. Reuse of a custom list item on other sites requires that you create a content type. So this is one of the basic building blocks within Sharepoint.
- Site templates. This defines what master page, webparts, content types are available by default initially for a new site. You can create new site templates, and you can modify a site based on a site template to be completely different from the initial default state.
- Master pages. These define a template for the pages which are associated with them. They include “content regions” and webparts where you plug in your content. Master pages support styles, aka cascading style sheets (CSS). This is how you’d “brand” the look and feel of web pages.
- Web parts. Web parts are what define most of the core cool functionality users see within Sharepoint. Webparts actively do something, resulting in content which is displayed on the webpage.
- Shared Services. There is a subset of Sharepoint functionality which can be shared between Sharepoint farms/servers. The components of Shared Services are:
- User profiles and Personal sites (My Sites)
- Search (i.e. search indexes)
- Audience definition (to facilitate targeting content dependent on membership in an audience)
- Excel Services (browser based, server processed Excel features. i.e. clients don’t need Excel; content authors do)
- Business Data Catalog (this is hard to explain, and I’ll likely blog about it separately)
Big Picture proposal
So getting back to the big picture, I foresee a central instance of MOSS, which primarily provides two Sharepoint features for everyone:
- Personal sites & profiles
- Search indexing
Nothing else. I’d call this the UW Sharepoint infrastructure.
For all the other functionality, I foresee hosted instances of Sharepoint which consume the shared services of the UW Sharepoint infrastructure. So that’d mean that departments could bring up a sharepoint server and offer whatever combination of features were appropriate for their departments, while getting the benefit of broader UW search base and centrally-provided personal sites/profiles. So a hybrid approach which maximizes where it most makes sense to do the work.
Additionally, I think a centrally *hosted* instance of MOSS is needed to provide the full complement of features for those departments which would rather not run and administrate their own sharepoint server. In some way, this could be scoped to fit into a cost-recovery sort of arrangement.
Finally, given the Sharepoint licensing implications for sites with a public audience (i.e. anonymous access), I think a centrally hosted instance of WSS is also needed. For example, this public blog might go onto that server. Other examples might include public departmental websites. The cost for us to get a internet connector license on MOSS is slightly more than $7K, so it’s definitely cheaper to just buy another server ($3-4K) and put WSS on it.
There’s been some talk about taxonomy and governance with respect to Sharepoint here at the UW. There are some good resources out on the web on this topic (I’ll post them in subsequent posts). One of the beautiful things about what I’m proposing here is that a large part of the painful process of defining the specifics of taxonomy and governance university-wide are side-stepped. It doesn’t all go away, e.g. we still want/need a consistent set of vocabulary that everyone uses and there is still value in defining common roles/responsibilities.
I’d be interested in hearing what folks think of this. Questions welcome. 🙂