Information architecture is the design of the structure which classifies information across an organisation. Information can take many guises: spreadsheets, presentations, documents, forms, web pages, videos, images… the list goes on. We at JFDI are predominantly SharePoint experts. Every successful SharePoint document management project is underpinned with a great information architecture design.
Taxonomy and Information Architecture
An information architecture usually includes at least one taxonomy. A taxonomy is a hierarchy of terms that can be used to classify various types of information. One we have of all learned in school biology classes is the classification of living things. This includes domain, kingdom, phylum and class, and goes all the way down to genus and species.
Taxonomies that you are more likely to encounter in the workplace might include Department and Geography. Department might contain a list of various departments within your organisation. Information Technology, Human Resources, Sales and Marketing, Research and Development. Geography might include a list of cities where you have offices. Where possible, users should be offered choices from centrally managed taxonomies, rather than keying in free text. This cuts down on errors, and makes information findable.
Structured vs. Unstructured Data
The information that we produce comes in two main flavours. Structured data and unstructured data. Structured data, for instance, might be columns of data in a spreadsheet, or columns of data in a database. These are usually easy to query and retrieve. This is what we term “high context” information. Unstructured data, on the other hand, you might find in the pages of a document, the printed pages of a book, the content of a video or image. We call this “low context” information. To be able to query and retrieve information from these types of data requires the kind of processing that only Bing and Google are capable of.
But there is a middle ground, and we call this semi-structured data. Semi-structured data is essentially unstructured data such as documents and videos where we have increased the information context by adding what we call metadata. Metadata, or quite literally, data about data, allows us to store extra properties about those documents to help retrieve them and to help save them in the right place. Examples of these extra properties include author, title, company name, department, and so on.
Information Flow, Security and Navigation
Information architecture also covers the study of the flow of information. This answer to the questions: who produces the information? Who consumes the information? What security requirements are there for the information?
Information Architecture is also concerned with how information is retrieved. This means we need to consider matters of navigation, website or intranet structure, to what degree search is to be relied upon, and so on. Also key is the way things are to be stored, and how easily users can find the right place to store each item of information.
Information Architecture Processes
Per business function, or per department, key individuals should be identified that know enough about the way that their information is structured, that a series of relatively short and non-intrusive gathering sessions can be established. Where this knowledge is a little bit more widely spread in a team or department, it may be a better idea to use requirements gathering workshops to find this information.
Next comes analysis and careful thinking, in order to rationalise this information. This entails searching for suitable candidates for company-wide taxonomies. For instance, perhaps your organisation has a list of company names that need to be canonical; wherever a choice of company name needs to be inserted into a document, perhaps this should come from some centrally managed list? Maybe you should also have a canonical list of your departments.
Where do opportunities exist to have central lists like these? Where is duplication necessary? With rationalisation of these requirements, comes deduplication and resolution of conflicts. This then needs to be played back to the organisation, socialised and bought into by the key stakeholders. The best information architecture in the world can still fall by the wayside if no one is prepared to use it.
Managing the Information Architecture Gathering Process
Gathering an information architecture can be a time-consuming undertaking. However, it need not put the brakes on the implementation. If at all possible, cross-department and inter-divisional taxonomies should be identified as early in this process as possible. This can be done through discovery sessions with key stakeholders such as information workers and compliance officers in the early stages of the gathering process.
After this is complete, departmental or team level gathering sessions can be held, with each culminating in analysis and design, feeding in to a parallel stream of ongoing implementation. This brings more agility to the information architecture process. For even more agility, you can consider enlisting the help of the organisation. A divide-and-conquer approach can accelerate the adoption of taxonomy. By identifying key people to own and to manage relevant lists of terms, even large scale organisations can map and manage their taxonomies.
Information Architecture and Technology
Up to this point you may be forgiven thinking that information architecture has very little to do with technology. Whilst an awful lot of information architecture is technology agnostic, and applies to large a variety of different technological and technology-free solutions, a fully-fledged information architecture needs to take into account the strengths and limitations of the relevant technology platform being used.
SharePoint is no exception to this rule. A common misconception is that you can take an information architecture, crank a handle, and end up with a perfect SharePoint implementation. This could not be further from the truth.
SharePoint and Information Architecture
SharePoint, in common with most document management platforms, has limits of scale and supportability that can be worked with to make the product scale to meet your organisation’s requirements. SharePoint can be made to scale from document repositories of a few gigabytes through to the most robust of requirements of hundreds of terabytes of storage. Getting this right in SharePoint is a truly multidisciplinary exercise.
Any SharePoint solutions need careful architecture whenever data volumes get large. If designed poorly, “large” can be a remarkably small amount of data. If you plan on storing more than a few hundred gigabytes of documents in SharePoint, it needs careful consideration and design. In the SharePoint world that means judging correctly how to use:
- Content Databases
- Site Collections
- Libraries and Lists
- Folders and Metadata
- Content Types and Site Columns
- Custom Code
This requires several different skill sets. Your SharePoint team needs a vast array of diverse skills:
- Infrastructure Design, including Windows Server, Active Directory and SQL Server
- Information Architecture
- Solutions Architecture
- Cloud Architecture
- Enterprise Architecture
- SharePoint Development
- Business Intelligence
The JFDI Difference
Each JFDI team member is a highly skilled multi-specialist. All our consultants are skilled in multiple aspects of SharePoint implementation. SharePoint is unique amongst the Microsoft product set in its vastness. Our experience and our knowledge in the field is what sets us apart from the rest of the pack. Our people can be summed up by the phrase “jack of all trades, master of a few.”
We have our own approach to information architecture and its implementation. SharePoint need not be an expensive platform to implement. Let us help you extract the value from your investment. Information architecture may seem expensive to do right, but that is nothing compared to the price of not implementing it.