SPTechCon The SharePoint and Office 365 Conference Logo

What’s the Cost of Not Laying Down A Good Information Architecture as You Build Out SharePoint Sites?

What’s the Cost of Not Laying Down A Good Information Architecture as You Build Out SharePoint Sites?

by: Marc D Anderson, President, Sympraxis Consulting 01 Feb 2019

Information architecture is one of those phrases you hear tossed around a lot with platforms like SharePoint. It doesn’t matter if you’re in the cloud or on premises, SharePoint gives you some powerful tools to manage your content. The power of the platform is making it reflect your organization, though. The information architecture Microsoft gives us out of the box is a nice start, but it isn’t your information architecture.

Depending on who you talk to, you’ll hear some or all the following things when you discuss information architecture.

Site Topology

In classic SharePoint, the way we laid out our sites made a huge difference, since the notion of inheritance – of design, information architecture, etc. – from .NET was hugely in play. In modern SharePoint, since we are now aiming at a flatter topology and the underlying technologies have changed, these decisions are simpler, but they still matter. Make sure you make your decisions with an eye not just to how your organization is structured today, but what might change that structure in the future. Using Hub Sites with their ability for you to restructure the relationships between your sites is very powerful.

Managed Metadata

The Term Sets we create which are syndicated by the Managed Metadata Service serve purposes both broad and mundane. Having a common ontology or vocabulary means our organization can converge on name and synonyms for concepts which improve the likelihood that we understand each other. On a much simpler level, we have a place to store commonly used terms for easy reuse.

Content Types

Content Types are the ipso facto building blocks for all content in SharePoint. Everything we store in SharePoint uses a Content Type, from the simplest Item to a Document, to the Content Types we define. It’s that last idea that’s most important. I can’t tell you how many times I’ve seen critical Document Libraries (often the default Documents) where everything is just the default Document Content Type. In that case, we have no way to tell the difference between the hundreds or thousands of objects. With no specific metadata or Content Type names – which are themselves metadata – the only thing we know about each document is its name, who created or edited it, and when.

Site Columns

While I usually talk about Site Columns after Content Types, the two concepts are inextricably linked: Content Types are built out of Site Columns. Reuse of Site Columns is one of the ways we can achieve economy of scale in our information architecture. Imagine what a mess it would be if the Title column in every list and library was an entirely different entity. We couldn’t search by Title, we couldn’t sort by Title, and we couldn’t apply rules to all the places we use Title (like its length, its field type, etc.). Those same benefits accrue to any Site Column we create. Site Columns also provide another way for us to think about concepts consistently. A column called Date of Entry is probably the same thing as Entry Date, so let’s be sure to use the existing column rather than creating a new one with a different name, since to SharePoint they would be entirely different entities.

Content Type Hub

Now that we are moving from pyramidical Site Collections to a flatter topology in modern SharePoint, the Content Type Hub is a more and more important tool to implement the Content Types and Site Columns for our information architecture. It used to be we could implement Content Types in the root Site Collection in our pyramid, and those Content Types would be available throughout the Site Collection. With every modern site being a Site Collection unto itself, this no longer works, so we must turn to the Content Type Hub. The Content Type Hub allows us to syndicate our Content Types to all Site Collections. Let’s just hope Microsoft gives the content Type Hub some love to allow it to scale for this increased workload, as it doesn’t serve its purpose as well as it should.

Search Settings

Search is a topic unto itself but understanding ideas like search scopes, Crawled Properties, and Managed Properties is key to effective findability. (We don’t ever want to search - we want to find.) If you define your information architecture clearly enough with Content Types and common Site Columns, your search configuration flows naturally. Most search attempts sound like “What contracts have we written for client XYZ?” or “What service tickets do I need to work on because they are due by today?” The nouns and objects in these sentences are unfathomable without good information architecture.

Site Scripts

A relatively new capability, Site Scripts allow us to stamp out common containers, content, or user interfaces in modern SharePoint. These scripts can now be run not just when you create a site, but also afterward. This means we can add a set of lists and libraries to new sites, but also add additional content containers later, as we identify new requirements. In other words, we can use site scripts to help spackle the holes we’ve left in our information architecture in our early passes at it.


Each of these concepts is important as you think through your information architecture, but some more frequently fall by the wayside than others. If you think through the implication of your decisions for each of the above choices, you should easily see that a decision not made today could have significant impact down the line.

Fixing bad choices later is far more difficult than getting it at least significantly right in the first place. But don’t panic if you don’t know exactly what all the answers should be. Make mindful decisions based on the best information at hand and understand that you’ll be adjusting over time.

With information architecture – as with so many things – the 80/20 rule applies. This rule is used and misused in many ways, but the way I apply it to information architecture (and many other technical disciplines) is that you get the biggest bang for the buck for getting 80% of the functionality in place. The other 20% is the harder work, and as you approach 100% (an asymptotic function!) it gets more and more expensive to move the needle.

So, what’s the cost of ignoring information architecture in the early days of working with SharePoint? Well, you won’t get the true benefits of the platform. You’ll have to do more work later to retrofit - it’s much harder to apply information architecture to a large corpus of content than it is to pour content into a well-designed information architecture. But most importantly, you won’t achieve your goals for using SharePoint in the first place. Your end users may well abandon the platform because it makes their work harder rather than easier. And that would be a crying shame.

View all Blog Posts