How to Build Your Content Stack

Strategy - Architecture - Workflow - DevOps

Jump to a Section

• Overview
• Content Strategy
• Content Architecture
• Content Workflow
• Content DevOps
• Conclusion 

Overview

When building Content strategy within an organization, content management strategists often refer to the “Content Stack.”  Here at Agility, we more specifically refer to 4 separate components within the Stack: Content Strategy, Content Architecture, Content Workflow and Content DevOps.

Building out your Content Stack is possibly the most important operation you can undertake as a modern organization in our connected world.  How you are able to promote your brand and communicate your message is directly related to how your Content Stack performs, which translate into more engagement with increased traffic and, ultimately, more conversions. Building an effective Content Stack allows your organization to move quickly, and with greater reliability in terms of your brand messaging.  Let’s take a look at each component of the Content Stack.

The Content Stack is a top-down construct.  We start at the high-level components and then work towards defining and implementing the lower level elements.  It’s important to note that changing a higher-level component AFTER we’ve implemented those lower level pieces can be very expensive and time-consuming, so we want to make sure we get off to a smart start.  It’s also important that we strive to keep simple things simple and to try to break complicated problems down into smaller, simpler pieces.

The highest level is the Content Strategy.  Our strategy speaks to the needs of the business and states what the top-level goals are; we need an overview of how the system is supposed to work.  After defining our strategic vision and goals we can look at the where work starts, where deliverables end up, and all the tasks and checkpoints in between. 

Our goal is to script a compelling, comprehensive narrative guiding the creation of an architectural model of the different content elements.  This becomes the Content Architecture.  

Next, we’ll need to think about where we want that content to end up, which we will refer to its destination or outputs.

Invariably, we will end up changing our architectural models as we continue to examine the specifics of what each endpoint requires.   As we work through all the places your content will flow, we should also ponder what the future might look like – are we making decisions based on a technology that might disappear or drastically change soon?  How will we respond to these changes? How can we build resilience into our system to allow for this sort of flexibility? 

At this point, we have to consider the question of who does what with which elements of content and when:

• Who composes content?
• Who approves it?
• Who triggers the events that cause content to flow through to an endpoint?

This is called Content Workflow, and it’s all about the people side of the equation.  It’s vital to keep in mind that these folks are the lifeblood of your Content, and their experience matters.  We need to make sure they are set up for success.

Now we can begin to work through our ideas about HOW our content will flow in our stack to its various outputs.  We refer to this as Content DevOps.  It might mean tools that we integrate with, application protocols that provide us data or that we feed data to, or software development components that need to be implemented.

Let’s dive a little deeper into each of these four layers of our Stack, starting with Content Strategy.

Content Strategy

The first and arguably the most important component in your Content Stack is your Strategy.  Think of it as an ongoing birds-eye view of how everything is supposed to work.  Building out your strategy is an opportunity to determine all the really high-level questions that matter most to you:

• What are your strategic goals as a business (or business unit)?
• How does your creative content fit in with that strategy to provide value?
• What areas of the organization will benefit from having this strategy?
• What teams will be needed to implement and maintain the strategic integrity of our strategy as time goes by?

Coming up with these questions (and more) will provide the building blocks for the main elements of your Content Stack.  It truly is a top-down scenario; the better we are able to define what will make you successful moving forward from a high level, the easier it will be to continue to be successful over time.

There are 3 strategic areas upon which to focus:

Instances

“Instances” are the building blocks or your Agility account, and provide a way for you to split your content into logical pieces. 

For example, in the diagram above, we’ve used 3 instances for all of an organizations data, with a “Main” instance for Corporate Data, Branding, as well as lists for News, Blog Posts and Press Releases. You might also want to use Agility’s instances for Products & Services and Events & Contest.

Tools

The tools for working with data are changing rapidly, but we’ve seen some top players emerge, especially in the 4 categories shown above:  CRM, Email Marketing / Marketing Automation, and a broad category we can refer to as “Workflow Automation”. 

Agility integrates easily with these platforms because it is so flexible. Part of your Content Strategy must address how you want to implement platform integration, what data you would like to have flowing through which tool, and what processing that data will need.  For example, you might want your blog posts syndicated onto your social media accounts, or you might want your logo and branding files managed centrally.

.

In the diagram above, we can map how data might flow from your main Agility Instances into the various tools and output destinations across your organization. Note that this is just an illustration of one possible scenario – your own structures will be unique to you. Which is why the process of building your Content Stack including a detailed Content Strategy so important.

Teams

People are any organization’s greatest assets.  Those who work with you day in and day out are the ones responsible for driving your organization forward. How well teams operate both externally and internally will determine the success of any Content Strategy. 

In the short term, it’s important to determine what roles and responsibilities you need to have filled in order to get started. Keep in mind the likely responsibilities necessary for long-term success. Consider these roles and make decisions on whether these will be external or internal responsibilities.

You don’t need to get everyone in a big room all at once, but it behooves you to build rapport between these groups.  It’s much easier to do a great job on your own work as an Approver if you understand the strategic goal of the content, who Composed the content, who Edited, whom the Developer works for and with, and so on. 

Once you define teams and assigned roles, you are ready to tackle Content Architecture.

Content Architecture

Creating an effective Content Architecture that will stand the test of time is never easy, but with some guidance and a solid understanding of who will be working with what content (detailed later in the Content Workflow) and what they need, we should be able to craft a scalable structure.  Remember, hard work here will pay dividends later, as our initial Architecture plans will become the foundation for how the organization manages content.

Until you define your Content Workflow in terms of human resources and stateful mechanisms, you won’t be able to completely define your Content Architecture.  Similarly, as you work through your Content DevOps checklists, you may need to add pieces to the architecture.  In some cases, it may be data that needs to be included that you had forgotten about, but allow and expect significant back and forth with your different teams. Also beware of the trap of allowing the needs of the lower items on the Content Stack determine too much of how the structure works.  The shape of the foundation needs to accommodate the rest of the building but must have its own integrity to support the whole structure.

First, we’ll take a look at the components of an Agility Content Architecture. In the diagram below, we see 2 distinct layers of components – Shared Content and Pages.

 

Shared Content

The Shared Content section of Agility acts much like a Content Database: it provides Content Lists and single Content Items that can be referenced by name and reused anywhere you like. Consider the previous example with 3 Agility Instances, the first of which was the Main Instance including Corporate Content and Branding. Here’s how we might use that Main Agility Instance.

We’ve determined that we want to have Executive Team Bios, Terms & Conditions, and Job Posting under the Corporate Content umbrella.  Those will likely be a List (bios), an Item (terms and conditions document/copy), and a List (job openings) respectively.  Similarly, we’ve determined the kinds of Content that we feel should live under Branding.   You can easily brainstorm this kind of Content with your teams internally and come up with all sort of Content that is important to you, then organize effectively.

Next, it will be time to decide what data in each of those content types you need to capture, what those data types are, and how they might relate to each other. We won’t look into that level of planning in this document since it is a whole topic on its own and different in every organization.

Channels, Sitemaps, Pages and Modules

Agility Content Architecture really shines through the clouds by allowing you to create multiple ad-hoc hierarchical structures.  That’s a fancy way of describing a “Sitemap,” which we use to define and manage Pages within a specific Digital Channel on a Website.  Sure, we want to be able to use our Content we need to, but often the primary output is a website.  Giving your team an easy way to find, edit, approve, and publish pages on your website is often a top-level priority for marketing teams, so getting this portion of the Architecture right is imperative.

The important elements of the sitemap structure are:

• Digital Channels
  • These are the top-level grouping that a sitemap can live under. You can use it to delineate anything that needs its own hierarchy.
• Sitemaps
  • Each Channel can have 1 sitemap, but a sitemap can have as many _pages _as you need, and each page can have as many nested pages underneath it as you determine.
  • This provides an amazing amount of flexibility for your Content Team to create the overall structure of your website.
• Page Templates
  • A Page Template in Agility allows us to delineate the named areas where content can be dropped into on a given page. This might be a Top Section / Bottom Section, Left / Right Section, or maybe Column 1 / Column 2. 
  • This gives the Editor much more control over the presentation of the content without having access to any code, or indeed any development experience at all.
• Module Definitions
  • A Module Definition is very similar to a Content Definition that you’d use for a Shared Content Item, except that it’s specifically designed for use on a page.
  • When an Editor is building a page using a page template, they will have the ability to choose from any of the Module Definitions we set up.
• Pages
  • This is it! This is where all your hard work in the setup and configuration of your data model starts to really pay off.
  • Adding a Page to the Sitemap allows your Content Editor to define the navigation structure and hierarchy of content on your website.  Choose a Template, drop some Modules in the available Zones, and you are off and running.

Content Workflow

The most valuable element of the Content Stack is people.  Your Content Team will be who you lean on to solve problems and get results as your organization evolves.  The best way to keep them happy?  Listen to them.  Take their feedback and make sure that they have the tools they need to be successful. Look at the things they do every day, the roles and functions that they fill and make sure you have all your bases covered. 

Make no mistake about it–this part of your Content Stack represents a journey that, hopefully, will never end.  Most Content Management System implementations are considered _failures _because the team that actually works with that solution on a day-to-day basis doesn’t feel empowered to do their best work. 

You have the opportunity to avoid those pitfalls right now.

Use Cases

All aspects of creating great Content Workflow experiences should start with the identification of Use Cases.  Use Cases are the sample projects/actions that outline how the members of your teams will actually get things done.  

There are a few ways that you can come up with a great set of Use Cases, including:

• Meet with your team and brainstorm
  • This should probably be your first option and will bring you a wealth of ideas and knowledge about what will empower your team.
  • Make sure these meetings don’t focus too much on the airing of past grievances with existing tools. This is a chance to move forward with new processes – let the emphasis be on that.
• Watch your team at work and gather metrics
  • Take a look at how your team works right now. What are their actions, how long does it take to do a task?  How many steps does each task have?
  • These metrics will help you define ways to measure the improvements you wish to make with your Content Workflow.
• Create empty Use Cases based on the Content Architecture
  • To ensure you have all aspects of your Content Architecture covered by Use Cases, go through every type of Shared Content, Page and Module Definition making sure your team will be able to work with each situation effectively.

You may be wondering why we didn’t create these Use Cases as part of the Content Workflow _before _we created our Content Architecture.  That’s a good question, and in many cases when starting projects, you should consider the needs of your team first and foremost before you start defining the structures.  However, in the case of Content Architecture, we want to keep a birds-eye view of what we are trying to accomplish with our Content Strategy. 

Once you start brainstorming Content Workflow Use Cases you may find yourself somewhat mired in the nitty-gritty details and even a few grievances with your team.  Our experiences prove that having a draft Architectural Structure in place for your Content–based on what you reasonably predict about the system needs to accomplish–greatly helps keep your team focused on the future rather than getting stuck in the past.

Definitely take advantage of the Use Case creation as an opportunity to _validate _your Content Architecture. Any changes that you make to that structure now is relatively easy, at least compared to making changes after developing DevOps processes.

User Guides

The natural progress of a Use Case once it is validated with the Content Architecture is to generate a User Guide based on each particular task.  These Guides are usually Role specific and can outline every task that the users in your organization will need to know in order to work with your Content.

User Guides often are compiled into a document, but you also populate a Wiki system with them.  Think of each Guide as a step-by-step recipe for success.  A great User Guide can help new users get onboarded to the system quickly, saving you significant time and resources when you need to get things done.

Moving forward, it’s important to keep the User Guides top of mind as your system evolves. Often, we see Content Architectures that have been built upon for many years – I can say with almost guaranteed certainly that the same tasks that folks started off with will have changed since the original set of Use Cases and Guides were created.  Keeping these tools updated and comprehensive over time will pay dividends.

Content DevOps

DevOps brings the Development and Operations process together in a cycle used to deploy and update the artifacts powering our online properties. This is illustrated by a continuous repeating pathway through the stages of Plan > Create > Verify > Package > Release > Configure > Monitor > Plan. This process has redefined how we deploy and maintain our code online because it allows us to iterate quickly and continuously with new features and bug fixes.

The Rise of DevOps

The concept of DevOps is one that has gained traction in recent years by offering several benefits.

• Centrally managed Source Control repository services
  • Tools such as GitHub and other hosted code repository services have made it easy for teams to take advantage of sophisticated code tooling and team functions without a lot of overhead time or costs.
  • These services enabled internal and external/outsourced teams to work together with little IT overhead.
• Online Package Managers
  • Node Package Manager (npm.org), nuget.org and other package manager have emerged to democratize reusable code modules.
  • This allows development teams to quickly integrate industry standard packages of functionality into their code.
• Centrally managed and hosted DevOps Service “Pipelines”
  • Tools such as GitHub Pipelines, Azure DevOps and AWS CodeDeploy have become immensely popular, and are easily accessible.
  • Any dev team can easily automate their code deployment mechanisms such that as soon as code is checked into the Source Control repository, a build > test > verify process can be kicked off, and then a Release Management team can approve the release of that code to a Production deployment.
• Containerized hosting using PaaS technologies
  • It’s all well and good to make it easier to build and deploy our code, but without a flexible and scalable hosting model for it, all the effort is for naught.

The ability to deploy and orchestrate “containerized” application such as with Docker/Kubernetes, as well as PaaS offerings from Azure and AWS, allow your DevOps team to quickly spin up deployment endpoints for all of your needs in a scalable and cost-effective way.

Your DevOps Strategy

There are several questions you need to ask in order to shape out your DevOps Strategy. Here are a few to get you started:

• Who will develop the software artifacts needed for online properties?
• Who will own the code artifacts over time?
• Where will the code be stored (on-premise or managed service)?
• What will the process of building/testing/approving/releasing code require?
• Who will be accountable for the process at each level of responsibility?
• What packages and/or frameworks will you rely upon, and what are the risks involved?

Cloud vs On-Premise Hosting

One of the biggest choices facing each organization in terms of DevOps is to determine where things live.  Will things be hosted in the Cloud or on-premise? This is a big question that will affect subsequent strategic and tactical decisions.  If you do choose to host in the cloud, which provider makes the most sense?  Is there a serverless option that can save you money? 

Versioning and Releases

We always recommend a phased approach to every Content Stack, and that methodology includes DevOps.  The systems need to be architected such that a regular release schedule makes sense, both for new features and bug fixes as necessary.

The most flexible DevOps Strategy will include the notions of Continuous Integration and Continuous Delivery. 

Speed, Reliability, Disaster Recovery and Business Continuity

We work from the notion that everything should be fast.  Speed is a top priority and something that should not be compromised in a production scenario and making sure that the response time on anything you build is sub-second should be called out early and often. 

Reliability and Uptime are also a top priority – you need to have confidence that your online services and properties are available at all times, and you need to be able to show that as a metric if necessary.  Modern DevOps Strategies will include concepts like Load Balancing and Geographic Failover as tools for raising the level of uptime and reliability.

A Content Delivery Network (CDN) can also be used to accelerate things and provide Web Application Firewall (WAF) protection to your online services, helping to guard against both attacks such as Distributed Denial of Service (DDoS). A CDN can also help keep things fast during traffic spikes. 

Conclusion

We live in a world that needs us to move quickly.  We need to rapidly prototype and translate our ideas from first-concept into a finished output.  We must stay well informed about how and why our processes work or fall short.  We also need to have an effective rhythm to our efforts.  As humans and as organizations, we move within an innate tempo that pulses daily, weekly, monthly and so on. 

Your Content Stack is a tool that can help you harness the rhythm of your organization into the outputs that you need in order to be successful.  We’ve walked through the concepts of Content Strategy, Content Architecture, Content Workflow and Content DevOps.  Unpacking how these concepts relate to the ideas you have for your organization is an exciting and challenging proposition.

We hope you’ll allow us to join on your journey.