Tags:

Naming Topology Types and Site Types

Alvin Reyes

SDL Web 8 introduces a feature called Topology Manager, which connects Content Management (CM) and Content Delivery (CD) by:

  • Removing CD details from CM (i.e. Publication Targets)
  • Removing CM details from CD (i.e. the deployer configuration seen in one of Nuno's post)
  • Storing these former relationships in its own database, modifiable through scripts

This change makes managing the relationships between SDL Web Publications and their CD websites easier across DTAP (dev, test, acceptance, and production) and over time (upgrades, hardware changes, and cloud or hybrid cloud setups).

In this post I wanted to explore ways to name the Topology Types, Site Types, and Business Process Types that were introduced in SDL Web 8 along with Topology Manager. Think of these as preliminary options and musings rather than the best practice naming conventions, which you will create over your next several Web 8 projects. Let's take a step beyond just "Staging and Live."

Topology Type

Gathering a list of familiar purposes lets us discover appropriate Topology Types names. A purpose describes a Content Delivery environment. It's just a label or string, which you'll likely to match against the familiar Target Types that editors select to publish against.

Example Target Type names you might have seen include:

  • Staging
  • Review
  • Preview
  • Live
  • WIP (Work In Progress) 
  • Test

You might imagine even more creative Target Types such as "Generate PDF" or the occasional "Mobile." I suspect Mobile Target Types are less common now since the popularity of responsive web designs and some may opt for a mobile Publication rather than Target Type. Ideally you avoid server names and technical details in such Target Types. For example, if you use Staging for Experience Manager, you'll want Staging across all of DTAP (see my StackOverflow question on the full DTAP setup). 

Group up a set of these purposes to see how you might have different Topology Type names.

  • Staging and Live could be called StandardPublishing, Corporate, [CompanyName], or maybe even Default
  • WIP, Staging, and Live could be called Workflow
  • Test could be QuickAndDirty or simply Test as well

Though you might name a Topology Type, "StandardPublishing." Its actual Topology might set up as:

  • StandardPublishing for SDL's cloud
  • StandardPublishing for an on-premise setup
  • StandardPublishing for Azure or AWS
  • StandardPublishing for PartnerAcme's cloud

You use these Topology Types in Publication. Which brings us to Site Types.

Site Types

First described by Nuno Linhares in 2014, Site Types are a type of Publication used as a parent to sites created in the Site Wizard.

You might call these Publications something like (there are several BluePrint naming conventions):

  • Master [LogicalSiteName] Pages
  • Shared [CompanyName] Pages
  • Microsite Shared
  • Microsite Master
  • Pages [BrandName]
  • Campaign Site Parent

You'll likely have a prefix for these as well such as 400, 050, or 06 depending on the levels in your BluePrint. 

Business Process Type

Business Process Types include Target Types (logical selections to publish to) along with minimal approval status.

If a given system only has one way to Publish, it doesn't matter what you call the one Business Process Type. However, you might have different scenarios to match the above Topology Types such as:

  • StandardPublishing
  • Corporate
  • Default
  • Workflow
  • QuickAndDirty
  • Test

I've seen the 5 stages of Tridion grief in the four Bootcamps that SDL Education has run so far for Web 8. Topology Management doesn't benefit all-in-one boxes or demos any more (or less) than the legacy publishing setup (which is still available). Management is about creating, reading, updating, and deleting things.

Let me repeat that: management is about change. If you don't have CRUD (create, read, update, and delete) changes or DTAP, Topology Manager means managing formerly familiar settings differently. It's the same amount of mappings, just in different locations. 

It's telling that we got the most positive feedback from consultants in architect and infrastructure roles and we got nonplus ("meh") reactions from our solutions architects (presales). 

Read about the technical details in one of these posts:

See a technical Q&A on how to name your Content Management ID in Topology Manager.

I'd love to hear your examples and naming practices for topology management, leave a comment or link to your post(s) below!