Term sets or External lists in SharePoint 2010?

Term sets

Term sets are an interesting concept within the Managed Metadata Service (there's a great walk through of the Managed Metadata Service, including term sets by Andrew Connell). I particularly like the distinction between local and global term sets as it allows the specification of terms at a global level that can then be consumed across separate site collections.

How could you use this in the HE context? Well, potentially you could create a term set that contains the Faculty<->Department relationship such that anyone looking for content regarding a specific department could have assistance when using search because those adding content have assistance when completing metadata.

You could also potentially recreate the entire course catalogue by subject area (a Courses term set subdivided by course area and then listing each course) and this itself could be made useful when listing data elsewhere on the site.

The risk to me with term sets is that they could potentially tread on the toes of LOB data, leading to inaccuracies and inconsistencies across pure LOB systems and those based on the SharePoint platform. Sure you can put synchronisation in place, but it strikes me that unless the business data only exists inside SharePoint, then an external list is probably a better option than attempting to keep term sets in sync with external database (or other) content.

External lists

External lists are nice, but do have the overhead of requiring you set up an External Content Type. Fine if your data environment is a simple one (for pulling a list of sales countries out of a sales DB, for example) but not so simple if your data contains complex relationships.

If all you want is for users to be able to use that list as a read-only source of metadata terms, you'll probably be able to get it working readily even in complex scenarios, but external lists give you the option of CRUD functionality and somewhere down the line you just know your users are going to say "we like this AJAX rich UI environment, please can we update stuff here rather than in the grey box of our MI system?" (ok, they're unlikely to put it like that, but you know what I mean!) There are some very useful resources on creating external content types with CRUD methods but to claim it's a straightforward process would be rather misleading. As a dev I tend to underestimate the impact that breaking open Visual Studio has, but let's be honest here, if you have to go there it's going to take longer and more time = more resource cost, resource that from the businesses point of view may be better spent elsewhere.

Conclusions

So, where does this leave us then? Typically with the SharePoint stack: stuck in the middle. 2010 is a frustrating release in many ways, it gives us that extra step along the line in a number of areas (BCS is a million times more attractive than BDC ever was, for example) but still there are points where you just wish that the SharePoint product development cycle was aligned better with the .Net framework development cycle at MS HQ. One of the reasons that BCS isn't quite there yet is entirely due to the fact that it can't use any of the nice Entity Framework stuff introduced in .Net 4 and that's because 3.5 was the nailed down version for the development of SP 2010.

SharePoint is such a great platform that I get quite annoyed when MS drop something in that looks on the surface like an out of the box feature that works as a great short-cut to a time-consuming Visual Studio based process; I know by now that, if not properly prepared for, those are the features most likely to lead to scalability and performance issues further down the line. This for me is the number one question that every SharePoint dev should be asking of choices between routes like Term sets vs External lists (btw I'm not suggesting this is a blanket either/or in this case, just for this example of lookup data): if I take route A (the short-cut) am I potentially compromising the usability and scalability of my SharePoint application once users really start using it? Of course the most annoying thing about attempting to answer this question is knowing what the issues are with route A. Funnily enough MS are slow to point out the short-comings of its new feature set and the community can only work so fast to unpick them all for you. It can be a painful process figuring it out but as always with these things: test, test and test again. Then have a beta, then test again...

SharePoint short-cut features tend to encourage the quick roll-out of very useful functionality, the giant caveat emptor that should always be in play is "what's my scale up route?"