IA for SharePoint and Office 365
In Part 1 of this blog series of 3, I outlined what an information architecture (IA) is and some of the basic principles of why you need one.
In this blog I want to expand on the subject to cover how to go about creating an IA for SharePoint and Office 365.
As a starting point, it is important to remind ourselves that an information architecture needs to provide a detailed plan for such elements as data locations, applications, features, functionality, business processes and activities (based on business requirements).
One of the key things to remember is that an IA (though initially often created by IT or by a limited set of stakeholders) must incorporate the needs of the business.
This cannot be stressed enough as many organisations forget this and, as a result, user adoption and usability suffer. The people involved in the exercise must have some expertise or experience in guiding and defining an IA along with facilitation, communication and SharePoint skills.
Note: This exercise isn’t about asking the business what SharePoint features they require, its much deeper and requires an approach for work modelling and building consensus regarding requirements.
In my experience many organisations fail miserably at this for a variety of reasons.
IA. What is the goal?
Understanding and being clear about the goal of an information architecture is an absolute must if you are to be able define one that is fit for purpose, understandable and adaptable.
For the purposes of this blog (and in general), the goal is to document your organisations taxonomy (some organisational lingo) and incorporate data and security policy as well.
The desired outcome from this is a design that incorporates a series of statements and concepts (typically captured in a document or set of documents) that will help you make decisions, set and enforce policies and enable you to configure your SharePoint and Office 365 environment accordingly.
Why do organisations often find this difficult and why does it get overlooked?
The definition of an IA requires a specific and unique skill set very different from the typical IT skills of technical infrastructure and applications.
It requires an understanding of such areas as library science, facilitation and domain (e.g. Local Government, Not for Profit, Housing etc.) knowledge because you’re dealing with information, its value in relation to job activities and its classification so that the way it is created, stored, discovered and protected can be leveraged to provide the maximum value to the organisation.
The value of such an undertaking depends on how your organisation views the value of its information, how well it complies with regulatory guidelines, how well it passes audits successfully and its ability to leverage its information assets.
The value is compounded when you introduce cloud technologies because now the organisation has numerous ways and locations for storing data on a service outside the organisational firewall boundary – which introduces additional considerations including data protection risks.
Ok, so how do we actually get started?
In order to make this as simple and straightforward as possible (given the challenges I’ve already outlined above), I have set out 5 simple steps below that I have used to help organisations begin to define an IA for SharePoint and Office 365.
The assumption here is that a number of workshops will be required to carry out these steps, each requiring some initial planning and agreement over objectives and topics.
Step 1 – Bring a team together that consists of people (as far as possible) that have the required skill sets e.g. IA, technical infrastructure, project co-ordination, communications and business representation.
If your organisation is smaller this team might only consist of an Office 365 Administrator, Project Sponsor and a couple of representatives from each business area.
If your organisation is larger or more complex, the team might consist of a SharePoint Service/Office 365 Product Manager, Records Manager, Compliance Office, Security Officer, and several representatives from each line of business or service management team (operations teams and or service providers).
Step 2- Review your organisations security policy and understand how that policy applies to protecting information – location, tagging, permissions and data ownership.
This information can be collected from a couple sources such as the Security team (who should be able to provide data security guidelines and or policy documents and control plans). Also, auditor reports may also be made available which can provide insight regarding how your environment scores from an Auditors perspective.
In general, auditors dislike the distributed permission controls within SharePoint and the lack of ongoing data scanning and policy enforcement (they generally like everything to be described under a ‘control plan’ – more on that later), and often view SharePoint as a ‘black hole’.
Step 3 – Review your organisations data policy and understand how that policy applies to retaining information, tagging and classification.
This information can be collected from a couple of sources such as the Records Management team (who should be able to provide data protection and retention guidelines and or policy documents and control plans).
Step 4 – Work with representatives from key business areas to understand the data and content, documents, applications, people etc. they work with to get their jobs done.
This exercise should be conducted with the major business areas and departments initially and then refined as an ongoing activity by working with department SMEs.
For example, when thinking about corporate information, the following questions come to mind:
- What information does the business collect and how is it used?
- How much of it is stored and where?
- Why is it kept?
- For how long?
Here are some additional slightly more focused questions that will help to keep in mind it may be necessary to enlist the skills/services of someone who has done this before successfully:
- What are all the different types of data and how are they classified? Do data owners exist for each data type or aggregated data collections?
- How is data obtained? From whom? Why? What are the associated business processes and or tasks?
- What format is the data in? Applications? Documents? Staff contact details?
- How is data shared? With whom? Why? What are the associated business processes and or tasks?
- What are the business information availability requirements? Why?
- What confidentiality, integrity, and availability requirements apply?
- What is the legal environment surrounding the organisation’s industry and the data it uses?
- What issues has the organisation experienced in the past?
Step 5 – Create a draft baseline IA design
Once steps one through four have been completed (as at least a first pass exercise), the information architecture for the SharePoint and/or Office 365 environment(s) should be documented to include the environments purpose (e.g. OneDrive for Business for peer-to-peer sharing and collaboration, SharePoint sites for internal team document management, Microsoft Teams for internal and external team collaboration or business partner collaboration etc.).
The initial design should include logical structures for each type of data, activity and location and should identify requirements for such elements as:
SharePoint sites (team sites, communication sites, hub sites etc.)
- Site templates
- Naming conventions
What about governance I hear you cry?
Additionally, the design should incorporate requirements for a baseline governance framework, detailing the information architecture maintenance roles and activities (e.g. data owners, provisioning, exception handling, monitoring (site security and data scanning).
It should also reference how enforcement and reporting will be handled so that the organisation has a clear understanding and agreement about how the environment will be governed to steer and enforce the Information Architecture.
The design should also highlight any risks (where feasible) that have not been addressed and assign ownership of these risks to an executive sponsor whose mandate is to comply with data policies and maintain the end user experience.
It’s important to note that an Information Architecture will evolve over time, refining it is very much an iterative process. As they say you can’t boil the ocean and if you try, it will be a frustrating and unsuccessful experience.
Hence why a diverse team and executive support is so important. Most of the organisations I have worked with often start with the technical implementation of SharePoint and Office 365 and don’t focus on the user experience from an information and content perspective.
What’s the use of a highly available, flexible environment if the content is hard to find and is of little or no relevance to the business?
This will be covered in part 3 of this series: “How to use Information Architecture to support user adoption in Office 365 and SharePoint”.
We host regular events so please do check our schedule of current seminars, webinars and events. We also post regular blogs on the latest updates and expert advice on Microsoft 365, Cloud and Hybrid IT, User Adoption and the Power Platform, so please do follow us.
Please do use the form below to get in touch with any questions or queries.