Designing information architecture (IA) for your ECM solution is always challenging especially when content needs to be created and consumed in many different ways. Two potential approaches to design IA are: structure driven and search driven. In following lines, we will see pros and cons of each approach and then we will see how both approaches can be used to design IA which will adopt to changing business requirements over period of time:
Structure Driven IA:
By structure, I mean deciding sites/subsites, libraries and their hierarchy. It may be inspired by business departments, locations or timeline. Typically, any proposed structure will have biases towards a specific type of use cases. Secondly there is limit how you can balance needs of content creation and consumption. This is because, over period of time, it may change how content is being used. It is not a question of right or wrong, instead how aligned structure is with requirements at hand.
Pros:
- Useful for implementing security. You can control access at site/library level.
- May be useful to reflect your business architecture initially.
Cons:
- If no one can find the content because it is buried under multiple level of folder hierarchy, then it is of no use, and eventually you may reinvent the wheel.
- Once you have huge volume of content, changing structure may not be an option.
- Defining accurate taxonomies requires specialized skills and it may be time consuming/never ending process as well
Search Driven IA:
Another approach to IA design is search oriented. Here, instead of fine tuning structure to fulfill ever changing requirements, you focus more on making it search friendly and make your content discoverable.
Pros:
- Search may provide content you are not even aware of it.
- Search may be useful for large volume of loosely connected content
- Search may enable content reusability across multiple scenarios. e.g. Same product description may be used in help documents as well as ecommerce site.
- Search analytics can help to refine content by enriching it with more metadata or fine tuning relevance configurations.
Cons:
- Search may provide too much information. Not all of that information is needed. It simply makes difficult to find right information by avoiding information overload
- Finding relevant content is always challenging. Context — like time, location or user –plays a bigger role in upcoming search technologies to provide more relevant search results
- Security: All of us can tell stories show sensitive content becomes available through search. I remember noticing an excel sheet with financial information being used by our customer to manage multiple vendors including us or you may find salary sheet of your boss in search results.
Since each approach has its value in specific scenario, It makes sense to use both approaches to support two different views. Structure oriented view can be created for content producers. It may help to implement appropriate access controls and workflows. However, structure should not be designed to support immediate usages scenarios. What is needed here is to capture enough metadata which can last long enough during content life cycle. In SharePoint, features like Taxonomy, Term sets, and metadata columns, libraries and folders, can used to implement this approach.
Search should drive content consumer views. Based on the specific needs at hand, appropriate views can be created using search technologies by utilizing content metadata. It this way, if business requirements change or new usage scenario emerge, your content will be able to support it without requiring restructuring. Microsoft SharePoint 2013 has introduced various features like Content Search web part and metadata driven navigation, to support this approach.