Issue 44

The market is telling us something about content architecture

I’ve noticed something in job descriptions lately. It surfaces in two different manifestations, but together they reveal some important insights.

The first thing I see is content design job listings emphasizing systems thinking and structured content. (And I see content designers saying “see, that’s what I’ve said all along.”)

The second thing I see is job listings for platform engineers whose responsibility includes designing and maintaining scalable content models.

As a content architect, my knee jerk reactions to each aren’t admirable, to be honest.

When it comes to content designers, the systems thinking and structured content focus is stretching what content design is. We have content engineering, after all. But I’ve spent a lot of time talking about how the space between content disciplines is fuzzy, which I use Venn diagrams to portray.

And regarding developers, this is another data plot on the “Everything is engineering now” trend.

But with a little breathing room, I look past those irritations and see larger truths.

The shift in content designer and platform engineer job descriptions is an indicator of progress for the very thing I love doing—the very thing I’ve said we need more people skilled at.

Companies are starting to see that the outcomes they care about are driven by meaningfully structured content. Those outcomes might be flexible omnichannel experiences that drive conversions, trust and relevance seen via LLM citations, lowered support costs, shortened time-to-publish, and so on.

It goes deeper, though, and I find it fascinating that we see something profound revealed not by “thought leaders” but by the market: Content models are not byproducts of CMS work. They are foundational to CMS work.

Mapping content on a webpage to fields in a CMS is where many content professionals start with structured content. This is a good starting point, but it’s exactly that: a starting point.

You can level up your content structure by focusing your modeling efforts on defining complete, meaningful, standalone “chunks” of content and the logical connections between those chunks. After you get the chunks defined, then you can figure out the fields that each needs.

If you’re a content designer who wants to really excel at building content models, then make sure you understand how to build query-friendly content models for developers, how to build author-friendly content models, and how to find a balance between meeting the needs of developers and authors who work with the CMS.

Many developers have experience working with data models, which serves well—to a point. Data modeling and content modeling overlap, but they aren’t the same thing.

Data models and content models need to be built for queryability. With a headless CMS, you’ll be building experiences based on queries. Another similarity is that content and data both have a lifecycle, and both need governance.

When you understand the nature of content, though, you start to understand the difference.

Developers work with data, they can easily compare, aggregate, and losslessly transform it, because it’s unambiguous.

Content is much more ambiguous. For instance, the content value of right could mean at least eight different things. If we place that in a content type of Response, we know a little more of the context, but we don’t know if we’re answering a question about placement, about validity, with sarcasm, and so on.

With semantically rooted content models (and taxonomies), we can encode more meaning to our right entry in our Response content type. It’s the difference between treating content as strings and treating it as things.

It may be disguised as content systems thinking or scalable content models, but it seems that content architecture is having a moment. What should we do about it?

Let’s realize that we have new allies in our work. Let’s build on that momentum and help designers, engineers, and others build their content modeling literacy.

Ironically, we can learn from our data peers who now see broad support for their work across organizations, with buy-in for governance and tooling and staffing. Like the data community, the content architecture practice will get stronger as more disciplines understand it.

Managing Enterprise Content: A Unified Content Strategy by Ann Rockley and Charles Cooper

Top of mind

• Best thing I read in the last 2 weeks: Aurelien Georget, co-founder of the Strapi CMS, was addressing the trend to ditch the CMS (see below). “Strip the hype and ask one thing: What would the junior dev and the engineer with 20 years in prod both land on? Answer: just use a CMS.” Georget went on to address the real impact of AI on content management: “So it was never CMS or no-CMS. It's whether yours can be edited by a human or an agent AND read by a human or an agent.”
• Something that made me smile in the last 2 weeks: Last week, my younger son and I drove 3 hours on a school night to watch his Washington Nationals play the Texas Rangers in Arlington, TX. While we root, root, rooted for the visiting team that lost, we got to witness and celebrate the 2,000 career strikeout by Texas Rangers pitcher Jacob deGrom. It was a cool moment, but the father-son time “collecting” a new ballpark was best. (I’m often plugging sports in this spot, I notice. Maybe there’s a pattern there.)
• A pattern I noticed recently: I continue to see organizations question their need for a site builder or CMS when AI coding tools can do so much, so quickly. It’s an extension of the pattern of technological optimism wherein organizations turn to a new tool or platform to solve what is, at the root, a more complex problem.