Mark Masterson joins in the ECM standards conversation. I enjoyed his remark that the conversation to date has been entirely enabled via standards.

I agree with Mark that, unfortunately, a fair bit of discussion around standards–ECM-related or otherwise–tends to pit apples against oranges (e.g. approach vs. implementation, architecture vs. approach, orientation vs. …, etc.).

Concerning Atom/APP, RSS, WebDAV, et al, my focus is on their underlying intent. What I mean is this: technology X was created to solve problem set A. Later technology Y was created to solve problem set B. X and Y may overlap because A and B overlap. So, it’s critical to understand where the “sweet spot” lies between X and Y given my own problem space in relation to A and B. Sometimes, it’s a matter of supporting X or Y; however, sometimes it’s important to support both (e.g. de facto standard unclear, market adoption in transition, etc.).

Back to, for example, Atom/APP versus RSS, I think that Atom (format and protocol) is better positioned for publish/subscribe-based use cases in the ECM world. Other criteria I base that opinion upon include maturity of a standard and market adoption of a standard (i.e. industry pervasiveness).

There is also a purely pragmatic aspect to standards as demonstrated by this post itself. Setting aside whether XML-RPC is the end-all-be-all standard for distributed, XML-passing programming, the fact that Windows Live Writer and WordPress both support it makes me happy (satisfied). More importantly where the developers of this software are concerned, it causes me to use both products more regularly, further cementing their place in my personal content-oriented workflow.

WLW’s community grows from the variety of back-end systems its supports as a result of supporting XML-RPC, and WP’s community grows from the variety of front-end systems its supports via XML-RPC. One standard implementation versus N one-off integrations. More valuable development resources to apply to adding real, market-differentiating value!

Bex Huff left a comment on Mark’s post, which referenced his reply-via-post. Bex makes several good points, but at the same time what I perceive is that if an ECM standard isn’t reasonably or capably an end-all-be-all standard for the domain, then why bother. (Bex, if I misunderstood your post, please leave a comment to set me straight.) What I tried to convey in my last post on this distributed thread, is that I strongly believe that elements of ECM are ripe for further standardization. Clearly aspects of ECM have already been standardized. So, when Bex says “you lose functionality by standardizing, but you gain flexibility” I concur. However, that doesn’t mean that other options shouldn’t be provided by a particular ECM vendor or demanded by ECM customers. I see both/add rather than or here.

If you as the customer require flexibility (e.g. the ability to perform ECM functions across a range of content sources interoperably), you expect standardized APIs. For example you may need to export contract documents from all line of business repositories, file systems, etc. Once you have the quarter’s contracts in hand, you may then need to apply information analytics to visualize the business implications of these documents. In this case, you may choose a specific ECM vendor to execute this business process, allowing you to visualize hiring needs, market saturation, etc.

Even in the case of a BCS-like operation such as checkin, the same ECM vendor is perfectly free to provide a (LCD) standard version of checkin alongside a value-add, vendor-specific version of checkin. As the customer, you choose what version is appropriate to your use case and business requirements.