I worked with a customer recently on designing the Information Architecture for a Contracts Management site. This consisted of identifying document templates, meta data, workflows, notifications and retention policies.
The IA was depicted in a Visio diagram as it gives the end user something to visualise how the features of SharePoint will be used to deliver their solution; a screenshot of this is shown. A spreadsheet accompanies this to define all the content types, site columns, libraries and lists, workflows etc using the Microsoft Services Ready Excel template.
I digress from the main topic of this post which is how you’re perfect IA might not be implementable in SharePoint 2010 as you had planned.
The basic plan for the IA was to use the document centre template for each business area that used a document set to encapsulate the meta data about the contract, related documents and provide a means of approving and reviewing contract information as a single entity. It’s important when designing an IA for SharePoint to have a depth of understanding around the document management features so one of things I was very conscious of when doing the design was the limitations and boundaries of document sets which are essential folders on steroids with some initial guidance from Paul Culmsee. On completion of the IA I handed this over to a SharePoint Developer (Me) to implement thinking I’d made allowances for known features.
So where did my design fall down? External Lists.
Each contract had a supplier name attached to it and this list could be sourced from JDE. In my design I specified an External List that would retrieve data from a SQL Table populated with data JDE. This would mean all contracts would be attached to a known supplier and consistently used for all contracts and for other content in the future. This makes perfect sense from an IA perspective.
First of all the external list was too long so I hit the 2000 item limit so wrote some stored procedures to do paging (talk about this in another blog). The next issue I encountered was that Business Data columns can’t be added to content types which meant I had to add the column to the library in the document centre instead. I could add it as a lookup field but then you don’t get to pick from a list by filtering. I went back and update the IA documents but no needed to change my overall plan.
Then came the content query web part which in the wireframes showed a roll up of all contract document sets I was the owner of at the top of the site selecting by content type. Unfortunately it doesn’t like Business data columns. If I added a display value in the Item Style the CQWP would request the field in the new Edit Web Part properties but wouldn’t except the name of the field. Doh. I shouted at the screen and complained at my own ability to design something I couldn’t implement.
In the end I had to create a list in SharePoint and have the lookup column attached to the document set. Later we’ll have to hook up the list to JDE by using a transformation probably in SQL Server Integration Services.
Moral of the story is if you have used a feature in SharePoint before, make sure you can implement the key components of your IA design before creating the perfect solution.
Diagram of the Contracts IA created in Visio. You could use other tools such as Balsamiq mockups but I find the use of SharePoint Icons helpful to explain the features and relationships that will be implemented in SharePoint.
ECM Team Blog 