Author: David Guenette (Page 4 of 4)

With the advent of Kindle, from Amazon, a second dedicated ebook reader device has made the news, and there’s a lot to like about Kindle on the face of it. But the old hobgoblin of too many dedicated devices still reigns.

That’s what drives me crazy about Kindle. It has a built-in cell phone, but there’s no option to use it for anything else other than ordering a book. It has the ICs and jacks for playing MP3 files, but no playlist management, nor—absurdly enough, considering that Amazon is set up to sell things like music—any iTunes-like music downloading. The critical assessment of the Web browsing capability of Kindle is not fully formed, but there’s already plenty of complaint about the Kindle’s shortcomings there. Even one of the strong features of Kindle—E-ink—comes with its own drawback; while promotional copy claims that it is just like reading a page, that also means that you can’t read without a light, so better add a booklight to your pack, even as you’re carrying an electrically powered “book.” And with Kindle’s fundamental lack of support of PDF files—without question the single most widespread format for ebooks—you have to wonder, “What were they thinking?!”

A fuller discussion can be found in our Publishing Practices Blog, in Ebook Readers, Unite!

Bill Trippe’s post on January 04, 2005, “ECM and Business Process Management,” and the discussion emerging from Bill Zoellick’s post on January 08, 2005, “Sarbanes-Oxley: Too Narrow?” (especially comment by Glen Secor) make me think about the issue of DRM transactional infrastructure. Glen Secor’s comment, especially, while framing the compliance issue more usefully in regard to effective implementation strategies, also helps highlight the significant challenge ahead for DRM (or, in Glen’s usage, ERM, for enterprise rights/[business]rules management).

When the scope of integration becomes as wide as Glen argues it must, it seems to me that the DRM infrastructure requires ubiquity. After all, what we’re talking about is governing content not just between and among departments within an enterprise, but also among partners, suppliers, regulators, and a dozen other categories of participant that aren’t necessarily easily anticipated. The good news is that the DRM approach to security, compliance, and business process integration of content is theoretically flexible and applicable—arguably the best single strategy to show up to date. The bad news may be that theory will move to practice only when a sufficient DRM transactional infrastructure emerges.

But what is a sufficient DRM infrastructure? At best it would be one or a number of trusted environments that provide ubiquitous business rule transaction management common to all participants, so that enterprises could concentrate on defining and associating the business rules needed with all types of content. Since DRM platforms must not only accept and manage rules associated with content, but handle financial transactions and regulatory demands (among other things), and since the advantages of electronic commerce brings with it fast-changing relationships and conditions, the best solution is to use a DRM system in which all others can and will participate.

There are reasons for hope, albeit, perhaps, not in regard to a quick-to-emerge DRM ubiquitous infrastructure. XML-based common meta-data structures provide portability and platform independence to a large degree, and there have been some early efforts toward defining DRM meta-data with XML (ContentGuard’s XrML being the best known, but hardly the only effort). In short, the general industry trend toward abstracting meta-data above platforms means that DRM in the enterprise already has some applicable structure. However, apart from some limited examples—Authentica and Adobe come to mind—there’s still not much in the way of DRM “editorial interfaces” (i.e., rules definition and association) for content management. Fortunately, there’s little barrier to the creation and improvement of such interfaces, and preferably within CM platforms themselves.

But the question remains: is widespread compliance, security, and business processes associated with content likely without a general infrastructure such as the “Trusted Environment” on the Intertrust model? There are plenty of small- and mid-sized companies that won’t be able to afford particular DRM solutions that are not generally addressable. There is a great amount of work left to do to bring DRM into the enterprise, and while some pieces of the puzzle are in place or on their way, I wonder if the lack of working generalized trust environments remains the missing necessary piece for all sorts of “content governance” implementations.

Bill Trippe’s post on January 04, 2005, “ECM and Business Process Management,” and the discussion emerging from Bill Zoellick’s post on January 08, 2005, “Sarbanes-Oxley: Too Narrow?” (especially comment by Glen Secor) make me think about the issue of DRM transactional infrastructure. Glen Secor’s comment, especially, while framing the compliance issue more usefully in regard to effective implementation strategies, also helps highlight the significant challenge ahead for DRM (or, in Glen’s usage, ERM, for enterprise rights/[business]rules management).

When the scope of integration becomes as wide as Glen argues it must, it seems to me that the DRM infrastructure requires ubiquity. After all, what we’re talking about is governing content not just between and among departments within an enterprise, but also among partners, suppliers, regulators, and a dozen other categories of participant that aren’t necessarily easily anticipated. The good news is that the DRM approach to security, compliance, and business process integration of content is theoretically flexible and applicable—arguably the best single strategy to show up to date. The bad news may be that theory will move to practice only when a sufficient DRM transactional infrastructure emerges.

But what is a sufficient DRM infrastructure? At best it would be one or a number of trusted environments that provide ubiquitous business rule transaction management common to all participants, so that enterprises could concentrate on defining and associating the business rules needed with all types of content. Since DRM platforms must not only accept and manage rules associated with content, but handle financial transactions and regulatory demands (among other things), and since the advantages of electronic commerce brings with it fast-changing relationships and conditions, the best solution is to use a DRM system in which all others can and will participate.

There are reasons for hope, albeit, perhaps, not in regard to a quick-to-emerge DRM ubiquitous infrastructure. XML-based common meta-data structures provide portability and platform independence to a large degree, and there have been some early efforts toward defining DRM meta-data with XML (ContentGuard’s XrML being the best known, but hardly the only effort). In short, the general industry trend toward abstracting meta-data above platforms means that DRM in the enterprise already has some applicable structure.

However, apart from some limited examples—Authentica and Adobe come to mind—there’s still not much in the way of DRM “editorial interfaces” (i.e., rules definition and association) for content management. Fortunately, there’s little barrier to the creation and improvement of such interfaces, and preferably within CM platforms themselves.

But the question remains: is widespread compliance, security, and business processes associated with content likely without a general infrastructure such as the “Trusted Environment” on the Intertrust model? There are plenty of small- and mid-sized companies that won’t be able to afford particular DRM solutions that are not generally addressable. There is a great amount of work left to do to bring DRM into the enterprise, and while some pieces of the puzzle are in place or on their way, I wonder if the lack of working generalized trust environments remains the missing necessary piece for all sorts of “content governance” implementations.