Craig’s Musings

For the past several months I’ve been focused on determining what web services specifications should be supported by forthcoming platform services in EMC’s ECM offerings (i.e. its Documentum brand software). Collectively these specs are often referred to as WS-* (or WS-DeathStar).

Earlier today David Chappell posted his latest Opinari piece, “SOA and the Reality of Reuse.” (David Ing added his thoughts here.)

Stating the obvious: Chasing reuse isn’t the same thing as reuse itself. Services are only as good as their consumption, and certainly service delivery existed long before SOAP arrived–Simple Object Access Protocol–and was subsequently buried under a mountain of next-generation specs (WS-*). What Roy Fielding described as Representational State Transfer (REST) has enabled this long-standing service consumption.

To be clear, I’m not against WS-* or necessarily for REST, but rather I’m concerned about consumption, reuse and business value. I expect for my customers to be closely involved in determining how services should be expressed for their consumption in enterprise applications. Sometimes I do question the agendas in play where service orientation is concerned. While WS-* focuses on truly complex distributed applications development and systems, I believe that a host of simpler solutions can avoid non-essential complexity by pursuing alternative means such as XML RPC, RSD, RSS, Atom, etc. When are uber-SOA platforms required and when are they overkill? (These are both questions to answer by a separate set of posts to be certain.)

Anyway, for whatever reason, a T-shirt idea popped into my head later this afternoon. Picture a simple red cotton T-shirt with an image of nameless pain reliever bottle on the front and the following text in white on the back: “WS-*? Stop. Think. REST.” (Yes, the play on certain Tylenol TV commercials is intentional.)

I guess my next move is to see how to work with a T-shirt shop like Threadless to get my idea realized. In the meantime, please consider this idea to be licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.

As the one year anniversary of hurricane Katrina’s devastation is remembered, it’s so important not only to recall the human tragedy but also to take action–personally do something about it.

Not too long ago my Dad had the opportunity to volunteer in the cleanup and rebuilding process. At that time he reported just how much was left to be done before the rebuilding could begin in earnest–lots of work was an understatement. 

Yesterday I heard from a gal who went to New Orleans to ”mud out” houses and to help home owners retrieve that one possession of priceless sentimental value. She already extended her time there as a volunteer and will be returning shortly through Christmas time, setting aside her planned return to college and master’s degree courses.

To my Dad and this women are great examples of what I wish were more the rule and not the exception when it comes to “servant leadership” in America. Church and other faith-based organizations have stepped up where government agencies have left or are dissolving. Rather than learn today about all of the speeches and appearances being made, I’d rather see more action and progress. Actions speak so much louder than words, and the lack of action seems deafening to me.

Even if only via TV, we’re all witnesses to the human suffering caused by natural disaster one year ago. As a witness, I find myself asking if I’ve thought enough, prayed enough, given enough, done enough about what I still know to be true…many of my fellow Americans are still suffering.

Update: The first guest on today’s broadcast of The Charlie Rose Show was Spike Lee who recently made the film “When the Levees Broke: A Requiem in Four Acts” for HBO. At points, Spike asked more questions than did his host, Charlie Rose. One of his questions stuck in my mind: How can the US [government] respond to Sri Lanka half-way around the world in only two days but take five days to reach out to its own states of Mississippi and Louisiana roughly eight months later?

The title of my previous post was inspired by Edward Tufte’s latest book of the same title, which I read shortly after its publication and before my daughter’s arrival into the world. Beautiful Evidence carries on in the high tradition of his previous work and I recommend it to anyone who produces or consumes information and wants to do so more effectively and concisely.

Two remarks by Tufte really stuck in my mind from reading his book as follows:

Making a presentation is a moral act as well as an intellectual activity. The use of corrupt manipulations and blatant rhetorical ploys in a report or presentation — outright lying, flagwaving, personal attacks, setting up phony alternatives, misdirection, jargon-mongering, evading key issues, feigning disinterested objectivity, willful misunderstanding of other points of view — suggests that the presenter lacks both credibility and evidence. To maintain standards of quality, relevance, and integrity for evidence, consumers of presentations should insist that presenters be held intellectually and ethically responsible for what they show and tell. Thus consuming a presentation is also an intellectual and moral activity.

When a precise, narrowly focused technical idea becomes metaphor and sprawls globally, its credibility must be earned afresh locally by means of specific evidence demonstrating the relevance and explanatory power of the idea in its new application. It is not enough for presenters to make ever-bolder puns, as meaning drifts into duplicity. Something has to be explained.

Tufte’s second remark refers to his contention that puns enable overreaching–previously bright ideas sprawl, grow mushy, and collapse into vague metaphors when extended outside their original domain.

Speaking of evidence-based, not theory-driven, conclusions, Beautiful Evidence captures Tufte’s evidence invention, Sparklines–”intense, simple, wordlike graphics.” More on sparklines later…

Update 8/29/2006: Via the 37signals feed comes another Tufte quote of note: “If your words aren’t truthful, the finest optically letter-spaced typography won’t help. And if your images aren’t on point, making them dance in color in three dimensions won’t help…If you look after truth and goodness, beauty looks after herself.” -Edward Tufte

Only three hours in the world (when this picture was taken by my Dad), and my new daughter is so alert. I think she looks like her Mommy.

Although I alluded to the term “round-trip content engineering” back in April, it wasn’t until an email-based discussion at work this morning that the light bulb went off. Not that the term is earth-shattering–it’s not.

It’s all about a dynamic canvas for content at the center (e.g. a wiki). Select a subset of this canvas (or the whole), associate a template, and produce a snapshot document (e.g. .docx, .pdf, etc.)–a process similar to taking a collection of UML models and generating code from them. The content remains alive and you can birth snapshot documents for external processes at will. Or select an existing document, associate a template, and decompose the document into a new canvas–a process similar to taking a body of source code and producing a collection of UML models. The UML world understands this end-to-end lifecycle as round-trip software engineering (or just round-trip engineering). Hence… round-trip content engineering …

Content is dynamic. Collaborative content spaces like eRoom and wikis, not Word or PDF documents, intrinsically reflect this reality. So what are the implications where, for example, content-centric engineering processes are concerned?

Consider the specification writing process. What does your Product Development Process (PDP) or related Standard Operation Procedure (SOP) current dictate where specs are concerned? I’d venture to guess that most PDPs prescribe and require discrete documents, and there is nothing inherently wrong with doing so. How current are your functional and design specifications? Do they still represent as-built and as-deployed behavior and capability?

It’s easy for what are really point-in-time snapshots to become crutches when it comes to maintaining what increasingly needs to be non-technical visibility into one’s product portfolio. Meaningful (deployed and maintained) software and collective understanding of particular versions of software is dynamic and not served by mere snapshots in the long-run.

Architects specify vision as functionality; developers interpret vision as design; …; publications documents software; …; field engages with customer in applying software; … If you’re already promoting explicit traceability amongst the documents your PDP requires why not migrate even further toward implicit traceability.

Some team members may all have access to source code–and the code never lies (just obfuscates ). However, even if the code is well-written (i.e. intuitive, self-documenting, appropriately commented), it’s not available to everyone who can shed light upon the software (e.g. behavior in the field, most used features by customers, typical deployment topologies) and draw insight from the shared knowledge (e.g. what needs to be refactored, what needs to be promoted visually, what is coming next).

Requiring cross-functional team members at-large to digest documents written to service a particular function at a point in time can become taxing. If the tax is high enough (e.g. without code…), it’s unfortunately not uncommon to see relevant, valuable context passed over or lost in translation. There must be a better way, and I believe the answer lies in the use of collaborative content spaces.

As an architect I more effectively engage my technical leads and engineering staff by breaking apart what would otherwise be a monolithic document into folder and note-sized modules. I increase the parallelism within the team as well as the potential for feedback (via notifications). Overall team agility is improved.

While I’m on the analogy track, perhaps this concept should be called “continous content integration” given that the software engineering profession seems to acknowledge the benefits CI brings to code-driven projects…