Content Staging and Virtual Staging

I was just reading over at Gadgetopia the post by Deane Barker about Content Staging and the merits of Virtual Staging of content. i was impressed by Dean of exposing the disadvantages of the Virtual Staging methodology especially when arises the need to change Menu structure.
When i come to think about an Architecture like this i think there is a balance point that is better then virtual or actual. Since we have to consider other parameters to the equation such as redundancy stability and productivity my take on the staging is a bit complex.
A Decoupled CMS/WCM is the term you might use for the architecture but the nature of the implementation does not mandate the software to directly support this.
I will start with a diagram of the architecture and then dive into the water.
Publishing CMS architecture
As you can see i have quite a strong opinion in regards to the content staging and publishing. 🙂
The process i see is a decoupled CMS that is a hybrid approach of a single server with multiple endpoints, the content generation is done in the internal facing content management server and staged through the application and web server so that it can be examined when a workflow is informing the editor of an upcoming change or new content and enables the creator to examine his work in context, i am a supporter of the in-context editing.
This is not the pure Decoupled system with many to many relationship as i have not seen a successful implementation of such a system yet.
But now that we have separated the content editing from the live content we have some ease of use and the ability to do any thing we want on the content editing site and later publish it to the website.
The publishing method can be any set of things, it could be DB replication and having to work on the same SAN/NAS or it could be file sync and DB injections, any method that has the stability and is well maintained is a good method.
The DR of the system has much more to offer as the environments are unconnected and can be replicated to a Hot Cold or Hot Hot scenarios, the ability to push the content in several data centre’s is also natural to a system like this.
As for the direction of content and code, or the Backward Forward dance “Code moves forward. Content moves backward.” blog post by Seth Gottlieb, in this scenario the whole server farm is our production and the content moves from here down the glide path.
The separation is based on the ability to separate the core from the content editors UI, letting the application interact with the API (core) of the product away from the content editors server, in some products this separation exists in a natural form and you will not need to manipulate the product, in some cases you will have to create that separation in a more complex way, but it is possible in most products.

Digiprove sealCopyright secured by Digiprove © 2011 Yuval Ararat

Comments

  1. Thanks for sharing. What a pelsuare to read!

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.