-Matt

What I think you’re saying is that you don’t see anything compelling enough about this particular database model for it to become broadly adopted in non-web-centric companies. It seems to me that there are plenty of applications in the non-web world that NOSQL would be particularly better-suited for than relational databases. I’m not saying relational databases will be replaced completely by NOSQL alternatives. I’m saying that not having a “relational default” is a good thing and that developers are going to use the tool that is easiest to work with and is a best fit for the requirements at hand.

Bringing it back to ECM, I think there is a good chance that vendors will take advantage of this technology because it may allow them to achieve better scale, replication, and model flexibility than they can currently achieve with a relational back-end.

From an ECM customer’s perspective, how much longer will customers actually care what’s going on in the back-end as long as the product delivers on all of the “-ilities” needed for their solution? A customer cares about the back-end to the extent that (1) they have to pay licensing and support costs for the server and (2) they have someone that knows how to take care of it, as you mentioned. As costs continue to trend toward zero the first item becomes less of a concern in the long-term. Relational? Graph? Document-oriented? Who cares. Just pay your “data persistence” bill when Amazon or Google sends it to you.

I agree that, depending on what you’re doing, someone in your organization has to learn the technology to some extent in order to utilize it effectively. But I wonder if, in the ECM case, vendors will take on some of the burden. This already happens today with products like Alfresco where the DBA is rarely involved. Yes, they take care of the database server care and feeding, and they may do some performance tuning, but the DBA is completely uninvolved in the database details. Alfresco and iBATIS/Hibernate take care of that. Or look at Day Software. Their products don’t require a relational database at all. CRX and CQ install with the Tar Persistence Manager by default. I doubt that Day’s customers see Day’s choice of persistence as exposing them to any more risk than is already present in a CMS purchase decision.

I’ll go back to the Lotus Notes example. Notes didn’t use a relational back-end. It used a document-oriented store called NSF. When a company rolled out Notes, they didn’t have to hire NSF experts. Companies with large rollouts did hire Notes Administrators, but those folks were primarily server people, not database people. They watched the server logs, made sure replication was happening when it was supposed to, kept the software up-to-date, managed users, groups, and permissions, and maybe did some troubleshooting or support for the apps that ran on the server. Extremely small businesses or big companies with departments running servers under their desks weren’t likely to hire dedicated administrators at all. I think we’re headed in this direction with ECM, eventually even for extremely large, clustered implementations.

So, I disagree that this is technology for “enthusiasts” only. I think we will see enterprise adoption. The question is how long will it take and what kinds of cool apps will we see to take advantage of it.

Jeff

I therefore expect that we will see a new generation of ECM architectures with much more decoupled and highly dedicated components, who communicate via standards.

As you write it nicely: “The challenge for Alfresco and other ECM players is whether or not they can achieve the kind of scale … for a world in which content is everywhere, user and data volumes are huge and unpredictable”. I think they could, but they must shift away from silo- and “we can do everything”-thinking.

-Juerg

#1 has been commented on ad nauseam since JCR first saw the light of day. One thing to keep in mind is that I consider myself a Java guy and I consider it a huge mistake – I can’t even begin to imagine how ridiculous this looks to non-Java CMS folks (who comprise the majority of the CMS community!).

Regarding #2, you’re mistaken that “every CMS is hierarchical” – to pick one example off the top of my head: OTEX VCM is not hierarchical at its core (though it layers in some hierarchies at higher layers for implementer convenience).

The real issue is that there are perfectly valid content models that don’t map to the simplistic “one size fits all” hierarchy mandated by JCR. They might be “flat” (document db-like) or perhaps require more sophisticated data structures (multi-hierarchies, digraphs, …) in order to support some complex navigational scheme on the end site.

Having to shoehorn such a model into a simplistic pre-baked hierarchy is an unnecessary hassle for the implementer. It would be much better if the content modeling facilities provided by the CMS supported hierarchies (and multi-hierarchies, and digraphs, and free-form graphs, and …), perhaps even shipped with samples showing how they are done, but did NOT mandate them.

I should mention that item #2 applies to CMIS almost as much as JCR, although at least CMIS has a reasonable notion of “Unfiled Content”. Now I realise that JCR “supports” that too… …but it does so by filing “unfiled” content in a special system hierarchy! If that isn’t sidestepping the issue I don’t know what is!

Now it doesn’t have to be JCR per say, but a universal, developer centric API that allows you to abstract the physical persistence is a great thing. There are also a few libraries being worked on that allow you to abstract your NOSQL implementation. That is pretty neat too.

If you remove JCR, what do you have? SQL? That is simply not going to scale. You could go with something proprietary, but what do you do when you want to change your persistence? Like right now, how much work do you think it would take Alfresco to rewrite their persistence to say a distributed file system or data grid? Well, if they used Jackrabbit all they would have to do is substitute the persistent manager for one that supports a distributed file system such as Hadoop. It they used ModeShape they would just have to switch the connector out for the Infinispan connector.

Also, every CMS is hierarchical so you need something “like” JCR rather than SQL or a simple key/value API that has no notion of a hierarchy. This is why Jackrabbit is nice. It can persist to a database or a key/value store but still provide the developer with a hierarchical view.

Rather than say confidence, I’d say preference. Though considering the number of JCR based repositories out there (and those currently migrating to it), I’d say it has been successful. I have been able to work on several different JCR based repositories equally as well since they all used the same API. I didn’t have to learn a new proprietary API, and that’s what I prefer

Let’s put it this way. Why don’t you want to use JCR?