Round-trip content engineering

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…