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.
-Craighttp://craigrandall.net/
@craigsmusings
huh… I actually said almost exactly the opposite.
http://bexhuff.com/node/256
In previous posts on my blog, I said that a end-all-be-all ECM standard is impossible. ECM is a marketing term, not a techincal term, thus over 100 apps can claim to support “ECM”, but can deliver whatever the hell they want. Good luck creating a standard interface to a marketing buzzword.
If you want some modest ECM standards, fine. There are 4 such standard already, just pick a damn horse. Stellent/Oracle supports 3, and will probably support all 4 soon… just in time for the 5th to be finalized. Joy.
Not that it matters… nobody uses the ones that already exist, yet they keep asking for more. I understand why: every ECM standard is far far too simple to be useful. Why should somebody shell out thousands of dollars for an ECM system, and access it with a “standard API” that hides 90% of the features? At the same time, an enterprise can have several ECM systems at once… and it would be nice if a middleware layer could have a single API to access them all. Nice, but not nice enough that they will willingly sacrifice important features.
I feel a standard will happen, but not until Microsoft fixes SharePoint, more consolidation happens in the market, and the vendors who merely claim to have ECM either shut up or go away.
Thanks, Bex, for the clarification by way of referring to a post of yours older than the one I referenced.
Seeing straight just fine, thanks.
[…] I notice there have has been an upsurge in volume of posts discussing standards in ECM here, here and here and especially […]
[…] This conversation…enabled via standards […]