Comments on: My CMS does delivery too!

By: Tarun Kumar

Tarun Kumar — Mon, 25 Sep 2006 04:10:01 +0000

Hi,

I feel both approaches whether loosely coupled or tightly coupled try to address various challenges of ECM. I would like to look at it from the perspective of having generic and well defined interfaces for interaction between various pieces of ECM services like versioning, Workflow, search, categorization, publishing, collaboration and delivery. In that case it may become transparent whether ECM system is based on loosely coupled or tightly coupled architecture.It will provide benefits of both approaches and customers can choose any approach based on their requirements. JSR 170 is a step in this direction which is taking care of core repository services like create/modify/view/version/observe content.

By: Rika Ng

Rika Ng — Fri, 14 Jul 2006 15:04:14 +0000

Thanks, Apoorv – I learnt something new. That scenario never occured to me. This would be an interesting topic for another posting next time.

Methinks this can still be resolved through careful architectural planning: perhaps an intermediate server that pulls and does data cleansing, then fresh submission through the SIT-UAT-production cycle. But then, I’m a bit of a purist on this.

By: Apoorv

Apoorv — Fri, 14 Jul 2006 12:49:00 +0000

oh yes you would be surprised how many people want that ability
apart from that, there are genuine requirements also – for example, a site that accepts user generated content but before that content actually appears, it has to go thru CMS workflow.

By: Rika Ng

Rika Ng — Wed, 12 Jul 2006 16:50:53 +0000

Changes in production first? my gawd, I can’t think of many situations where that is warranted except for one: during disaster recovery. Even then, one should make it part of the procedure to re-sync the CMS to the production again.

By: Apoorv

Apoorv — Sun, 09 Jul 2006 06:00:53 +0000

Thanks – I ageee that *usually* it is the other way round: what has expired in the CMS should also be expired in the destination production web-site but there are cases when people have to directly make changes on production environment. Also, there are legal issues sometimes because of which content expires on production. In such cases, these changes have to reflect in CMS as well.

By: Rika Ng

Rika Ng — Sun, 09 Jul 2006 04:16:20 +0000

Shouldn’t it be the other way round: what has expired in the CMS should also be expired in the destination production web-site?

IMHO, it is usually the technical side who are more comfortable with loosely-coupled delivery because it fits in well with the usual apps development workflow i.e. develop-SIT-UAT-production, and it also fits in nicely with the existing defense-in-depth network and security architecture.

Usually, it is the end-users who prefer tightly-coupled delivery. They usually need to publish things in a hurry, and consider all the “testing” and publishing steps unnecessary bureaucracy.

So, the real question of which to choose is really: do you want to give your end-users enough rope to hang?

By: Apoorv

Apoorv — Thu, 29 Jun 2006 09:52:44 +0000

Thanks Alan. I’m updating the post with that. The reason i left it out was that the focus of this post was on different delivery architectures and how the Management and Delivery applications integrate. Content Archival is definitely an important aspect of the CM Lifecycle.

By: alan pelz-sharpe

alan pelz-sharpe — Thu, 29 Jun 2006 02:05:07 +0000

What about the fourth stage – archive/destruction?

You must have expected this comment from me ?

Alan