NPR’s Daniel Jacobson shares details on their CMS ecosystem

Programmable Web: COPE: Create Once, Publish Everywhere

Programmable Web: Content Modularity: More Than Just Data Normalization

What strikes me is the focus on data storage and the emphasis on normalizing it to a modular form that enables re-use.

I’ve seen CMSes over the years try and deny the value in this approach – they store content as blobs and force app developers to keep access knowledge and manipulation maintained in the app layer. The idea being that you can never know what content you will need to store down the line, so why attempt to build a normalized store where data is maintained and re-used long term?

In the end, many of these CMSes embrace the Anemic Domain Model anti-pattern that Martin Fowler wrote about. More and more behavior that is related to your domain is pushed in to your app-space or into a services layer.

NPR.org confirms my past experience – the investment in building a modular data store not only establishes a strong foundation – it is one that gains in value over time. It takes research – you need to dig deep into your business’s problem domain – you need to determine what is it that is the core product(s) of your business (note – I didn’t say CMS). For NPR it’s the Story. What is it for yours?

As Martin Fowler said, “In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you’ve robbed yourself blind.”

Invest the time.

BTW – this isn’t a NOSQL versus RDBMS issue – there are data management solutions among each that can satisfy this.

NPR’s development team has been sharing more regularly on their blog “Inside NPR.org”.

Related:

CJR: NPR Builds a Brain Trust: Thought leaders convene for a digital “Think In”

digitalthinkin.ning.com

On the future of CMS (is NPR actually there already?) – CMS Links for October 18th, 2009 –

Justin Cormack recently completed a three part series on the future of CMS that I think nails it. I might be biased because it’s what we’ve been building towards at CIM for the past few years. Go read: “CMS technology choices”, “Content Enabled Vertical Applications and taking the CMS apart”, and “Content enabled vertical applications (composite content applications) – executive briefing” – quote from the second link:

At the application layer, as Stéphane says, everything is a mashup, content from different systems, content from other APIs, this is the we application layer. It needs to be content aware, very much so, but it needs to be an application development environment. This is where most people will see the value added in the content management business, although in fact the value here is in implementation, design and integration services, not the technology itself. Application development environments no longer make a lot of money, and again they are dominated by open source (think Java, Eclipse, JBoss, Django).

Once you take out content infrastructure and application development, and the other tools like search, workflow, there is a core of tools for working with content, to support reuse, refactoring, cleaning, import and export, that one might call a Content Workbench. There is a lot of potential value if these types of tools are the value added end of the business, as they can differentiate vendors and add value. Interfaces for merging changes and so on would be part of this type of toolkit. This is the stuff where good UX means timesaving for content workers, but it is difficult to build on a customized per-project basis, so this still offers value from a particular vendor.

Overall then we see a picture where the monolithic CMS starts to break apart into infrastructure, application and toolkit layers, that can perhaps gradually be mixed and matched together to build content applications. We are just seeing the beginnings of this now.

Peter Monks had a reply to his pieces here: The Future of CMS Technologies.

Meanwhile, NPR is live with a CMS solution that resembles this. Read NPR’s Daniel Jacobson’s guest post on Programmable Web: “COPE: Create Once, Publish Everywhere”.

Content Here’s Seth Gottlieb explains how this approach might be too much for those who need less capability still, he concludes:

…at the very least, every publisher needs to start thinking on this level: creating and storing content in presentation neutral way to keep options open.

This conversation was kicked off by Julian Wraith. Check there for more.

I plan on doing my own round-up, as there are many, many interesting posts worthy of sharing. In addition, I think I’ll share some of my own thoughts as well. Would be great to contribute to the discussion Julian Wraith started instead of staying meta for once 🙂

Who said conversation doesn’t happen across bloggers anymore ?

And on another note, the CMS Myth just had its second anniversary: Two Years On: Still Puncturing Myths & Taking Names

CMS links for September 19th, 2009

I don’t agree entirely with the first first link from Sunlight Labs – blanket statements like ‘x is dead – use y’ – are poor generalizations – however it raises strong points about frameworks and CMSes.

I just wish organizations and individuals would realize that there is not an either/or choice here – as projects such as Alfresco-Django and Alfresco-Drupal show.

Sunlight Labs: Content Management Systems just don’t work.

fiercecontentmanagement: Rolling your own CMS just doesn’t make sense

CMS Myth: Is interest in content management declining?

Stop looking for golden hammers.

What is ECM-SOA?

EdLovesJava: ECM-SOA With Agile Attitude:

The first challenge is to think of our tooling as not a custom application, but more as a set of adaptable services, applications and integrations. This requires a change of thought.

Our previous efforts were to drop a monolithic application called a Content Manager into the middle of things, and then propose to change the business process around this application, ostensibly obsoleting the existing applications and ad-hoc processing to customizations within this new application.

During our previous attempt, we underwent a lengthy analysis phase and generated a 500 page requirements document detailing taxonomies, content types, work flows and templates that would solve our content management (web content management) needs. We then spent lots of time and treasure implementing these requirements. In the end, we built some of the requirements taking far longer and far more resources than anticipated, and we found that most the requirements and subsequently most of the customizations we built were wrong. The heroic content managers and brand managers made it work anyway, developing more ad-hoc, complicated and time consuming steps around yet another application that was supposed to help them. This story is not unique.

We must shift our processes as much as our technology. We are focusing on smaller efforts, more agility and more feedback and move away from 500 page requirements documents. To do this successfully, our architecture also needs to be agile and amenable to change. Our architecture must be a framework to grow on: to grow useful services, and to grow and integrate with useful applications. It must follow user demand that learns from using and refining our processes and tools.

The UNIX Way

Kas Thomas of CMS Watch riffs on “The UNIX Way”, principals summarized by Mike Gancarz:

1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter

Read the whole piece.

cURLing with Alfresco’s and Google’s Data APIs

Jeff Potts: Curl up with a good web script (interacting with Alfresco’s Document Manager via CMIS and Atom)

Google Data APIs: Using cURL to interact with Google Data services

Bonus: commandlinefu.com: Update twitter via curl as Function

Reading List: Getting Started with Alfresco SURF

Goal for today is to absorb the following:

AlfrescoWiki: Surf Platform

AlfrescoWiki: Deployment Configurations

benh: SURF Part 1 – Getting Started

benh: SURF Part 2 – Pages and Navigation

benh: SURF Part 3: Alfresco WCM Content

Back in February, there was a Code Camp run focussing on SURF that Jeff Potts has details of. Once you get the backing information, and can successfully build Alfresco from SVN, you follow along with exercises participants worked on.