Monthly Archives: July 2007

This conversation…enabled via standards

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.

Diving in San Ramon

Techset audience on Tuesday

Yesterday and today I had the privilege of supporting my colleague Charlotte Townsley as the subject matter expert during her EMC Documentum Foundation Services (DFS) sessions as part of the D6-focused Techset event. (For those not familiar with Techset, it’s an event Documentum ran and continues to run as part of the larger EMC Content Management & Archiving (CMA) business, providing timely valuable details concerning an upcoming platform release.)

I’m guessing that roughly 200 attendees–EMC field personnel, including consultants, plus EMC partners–participated in one of the two day-long sessions that featured instructor-led presentation plus lab work. Each day’s audience was definitely into the material based on the level of interaction and depth of questions asked.

I’m really looking forward to receiving feedback from these individuals as they “take to the streets” armed with DFS.

For those who attended Tuesday’s DFS session, I threw together the following graphic for today’s attendees:

Underlying DFS architecture

It’s purpose is to help clarify where the DFS runtime is involved, among other things. The top two flows represent remote consumer interactions, and the bottom/third flow represents a local consumer-provider interaction.

By the way, if you’re interested in learning more about DFS and how to use it to build custom services and service-consuming applications, please consider the upcoming DFS Fundamentals course from our Educational Services team. (The Techset sessions on DFS represent just a portion of that class.)

Cheers!

Standards and ECM (cont’d)

Laurence oversimplifies and confuses matters where ECM standardization is concerned. However, it’s perfectly valid to leverage a blog as a learning medium and to “think out loud” therein. So, I’ll respond here both to clarify what EMC is doing in this space and perhaps to offer some guidance to those thinking about ECM standards.

Let’s proceed, point-by-point:

  • To repeat myself, customers (i.e. the end users, developer and administrators they represent) require standardization. They expect ECM leaders like EMC to support industry standard–drive them, too!
  • As an “ECM person” I can confidently say that the “ECM world” is definitely ready for standardization. (I don’t know who Laurence is otherwise referring to.)
  • I like to think about ECM standardization in light of ECM commoditization. Gartner coined the term “Basic Content Services” (BCS) to describe this reality–that actions like checkin, checkout, version, etc. are fundamental, not differentiating, operations. BCS simply confirms that LCD is a fact of life–something to embrace, not avoid.
  • Remember: there is “enterprise software,” and there is “software that runs the enterprise.” Software running a typical enterprise must interoperate. (It likely also differentiates itself well where feature/function, value, performance, scalability, adaptability, etc. are concerned.)
  • Read RESTful Web Services. Understand the true comparison between approaches lies between REST and RPC, not REST vs. SOAP. Also I don’t see this as a one-or-the-other decision–I’m not alone here, either. And, yes, this debate can become “religious” in nature.
  • I do, indeed, expect there to be an emphasis on SOA with the launch and release of EMC Documentum 6.0 (D6). I encourage you, whether you’re a developer, partner, customer project lead or CIO to kick the tires of this major platform release and put DFS through its paces. Ultimately the judgment on “truth versus fiction” where SOA enablement in D6 is concerned rests with you. That being said, DFS represents a substantial engineering investment–one that I’m proud to represent.

It’s great to see an increase in attention paid to standardization, service-orientation and resource-orientation in ECM. If you have feedback to offer, in terms of standard services/resources, operations/methods, use cases, etc. herein, I’d love to hear from you. Leave a comment on my blog or post me an email. Cheers! :-)

Update 7/11/2007 (via DonR): The REST vs. WS-* war analogy deepens, thanks to Elliotte. WS-* is North Korea, and REST is South Korea.

Update 7/12/2007: Richard Monson-Haefel, glad to witness the trend now toward REST, says: WS* is intelligent. REST is wise.

Update 7/15/2007 (via my feed reader): Ted Neward chimes in on the Chappell…Elliotte… analogies thread.

Update 7/25/2007 (via my feed reader): David Chappell updates us with responses to his original remarks.

Another MVP

While I’m on the subject of MVP’s, I have to mention my brother. Brent is the epitome of community service to me–always generous with his time and talents.

Over the years, my brother has made it a priority to give back globally when it comes to the application of his licensed architectural skills. (There’s a running joke between the two of us about who is really an architect, since he builds buildings and I build…well, I built this.) Case in point is one of the featured projects on the eMI home page: a training center and dormitory in Camaragibe, Brazil.

In the spirit of “think globally, act locally,” Brent hosted my son at his place yesterday for an afternoon of building and swimming.

The 'Alaska' Airplane Building Crew

Not a bad result, especially when you consider that it went from a paper sketch to an assembled, painted result in only two and a half hours.

Kudos to you, bro! :-)

Another year as an MVP

This morning I received official word from Microsoft that I will continue for another year (7/1-6/30) as a “Visual Developer – Solutions Architect” MVP. I am grateful to receive this community involvement-based recognition, and I look forward to the coming year’s worth of interactions (e.g. Acropolis, Visual Studio 2008, .NET 3.5 with WCF, WF, etc., Windows Server 2008, and so on). As I said before, this award is about community service; so, please let me know how I can help you, my reader. Cheers!