Storyblok: choosing one or more spaces

At Iquality we like to share our knowledge and experiences. We often see that CMS devices are regarded as an afterthought and therefore do not work. In this blog we explain which considerations we make within Storyblok to manage content from one or more spaces.

Within most headless CMS systems, there are two organizational layers. The first layer is often the level at which the subscription is established and where the details of the organization, which enters into the contract, are fixed. The second level is the level of content, called space.

Organization
The organization is the highest level or top layer of a headless CMS. Within this layer, the data of the organization is recorded, but also, for example, the billing data and the accounts that have access to the CMS. What is also managed within the organziation are the one or more spaces.

Space
A space is a so-called content repository. A space can be seen as an isolated environment where content can be managed. In practical terms, a space often serves a specific purpose, for example, content for the public Web site or content of the services department.

Important note: if you want to relate content to each other, e.g. link an author to a news item, you can only do that, within Storyblock, if the content is present in the same space. Content or media cannot be linked if it’s in another space.

Why multiple spaces

First, the question: why would you even consider putting your content in multiple spaces at all? An architecture where you choose multiple spaces is mostly about governance and scalability. Although Storyblok has quite a few functions at the organizational level, for example accounts, there are also many things around governance that can be configured within a space. For example, within a space you can configure a specific content workflow, set up the backup plan, create specific roles and content types. Workflow is a typical example of governance. For example, a workflow ensures that content must be created and approved through a certain 'flow' before it is available to the buyers, for example a Web site.

Scalability is important as the content model grows. In this case, if you choose to handle everything within one space, there is a risk of ending up with a large and cluttered content model. In addition, managing content will also be more difficult because of the lack of structure, which can lead to errors and a less pleasant environment to work in. In such a scenario, it is more obvious to split your content into multiple spaces.

Disadvantages of multiple spaces

In addition to reasons for opting for an architecture with multiple spaces, there are also definite disadvantages. First of all, one that was mentioned earlier: it’s not possible to make a reference to content outside the space. When you choose multiple spaces and therefore isolated content, you also choose that this content is reusable only within the same space. Initially this seems often the best choice but after a while it turns out that the content should have references. Take the earlier example of a news story and an author. Suppose that the technical documentation of an organization is stored in another space and you also want to link authors to it. At that moment there is a risk that the authors will also be added to this space. From the 'single source of truth' perspective, you shouldn't want this: managing the same content in multiple places is error-prone and creates additional content management activities.

A second disadvantage of multiple spaces is the cost. Storyblok is a SaaS (software as a service) service and therefore, like most headless CMS systems, a product with a consumption-based pricing model. An extra space means more consumption and therefore higher costs. The price of an extra space (within the 'enterprise' and 'enterprise plus' subscription includes 3 spaces as standard) is significant.

Important note: This blog post disregards the concept of multiple technical environments (e.g., development, test, and adoption). Some headless CMS systems, such as DatoCMS and Contentful, have the concept of environments within a space. Within Storyblok, multiple technical environments generally means multiple spaces. Over here you can read an interesting article on this subject.

Multispace architecture for different technical environments.

Choose multiple spaces

Based on the above, it seems clear to me that there is no 'one-size-fits-all' approach. If you choose to go for a multi space approach, how could you make your split?

Spaces per departement

In this setup, you choose to create a separate space for each department or 'business unit' within an organization. In some cases, departments work autonomously, in this case they have their own governance and the content is also very unique per department.

For one of our customers we had the use case where their global marketing department operates completely independently of the services department. Moreover, they both had a separate 'channel' on which the specific content was presented. Ultimately, this led to an architecture with different spaces: a space for global marketing and a space for the services department:

Multi-space architecture based on different departments.

Spaces by location

In this setup you choose to create your own space for each market or location. For example, if organizations are internationally oriented, this can be a good choice. Certainly when, for example, the business objectives are very different and there is great autonomy per location, it makes sense to opt for this. In this scenario, a separate space will be created for each geographical location in which content can be managed, often by the location itself.

Space per channel

In this scenario you choose to do the division of spaces by channel of experience. It sometimes happens that large organizations have different teams, each of which is responsible for its own channel, or simply a scenario in which the channels differ so much in terms of content and governance that this also justifies a split. Suppose you have two large, important channels as an organization: your all-encompassing corporate website and a 'my' environment for your customers. If these channels are also managed by two separate, independent teams, it is a good idea to split spaces into channels in such a situation.

The example below is such an architecture that we have set up for one of our customers. This customer has two major channels: the corporate website and a customer portal. The corporate website is the responsibility of the sales and marketing department. The customer portal mainly shows information about the purchased products and related services. The responsibility of the portal lies with the services department.

Multi-space architecture based on different channels.

Global spaces

When you opt for a setup with multiple spaces, a situation will always arise in which content will be shared, perhaps not immediately, but perhaps at a later time. Of course, this content can be duplicated within the different spaces, but this is not a good idea from a 'single source of truth' point of view. Things such as company information, privacy statements are good examples of the type of content that you would like to manage globally at an organizational level.

Conclusion

Unfortunately, there is no clear 'one-size-fits-all' approach that dictates how to deal with a split into multiple spaces. When the conditions stated in this blog are met, it is in principle a good idea to go for a multi-space architecture. On the other hand, the disadvantages as mentioned are significant. Our advice would be to start with one space as much as possible and only switch to multiple spaces if there are clear 'governance' reasons for this or if the content is not related to each other and is completely 'unrelated'.

We often see that the design of a (headless) CMS is left to inexperienced developers. We see this differently within Iquality and the design of a CMS is essential and requires a well-considered plan. Thanks to our years of experience, we set up a CMS in such a way that content managers can really do their job.