Jean Sini: web. scale. software.

Unsurprisingly, when trying to abstractly model behaviors, events and processes in a given domain or system, dissecting and studying actual, concrete scenarios plays a critical, dual role: experimentation with real-life material, that exhibits the exact behvior we are trying to model, not only proves a very helpful way to ground and strengthen the understanding we have of the phenomena we are describing (thus enabling us to model them), it is also a necessary step in validating such a model: real-life examples provide the required test-beds allowing us, iteratively, to refine, adjust, and ultimately design a model suitable for use beyond the examples actually studied. This methodology (draw an abstract model from concrete experiments, then validate the model with more real data-points) is very common (see Eliyahu Goldratt’s take on it in his Theory of Constraints).

This approach can obviously be applied to the domain I am covering here: building and maintaining structured knowledge. What are good models for such knowledge building systems? And what is a good, real-life scenario where such a system would be useful, so I can dissect and study it, build a suitable system, and eventually use it to generalize a model of such systems.

One such scenario is the challenge to produce useful functional specifications for software products I am working on. Usefulness is a concept we could philosophize about for a while, however in this context it simply means that the document (in its evolving revisions) is a reliable and exhaustive source for reviewers (who came up, directly or not, with requirements from customers) to determine whether what we’re planning on building is up to their expectations, while it also is a precise enough source of information for developers to unequivocally build the said piece of software. This simple definition carries a lot of constraints, as it pushes onto the specification the responsibility of ensuring that the product eventually meets the requirements, but that’s what a specification is about, after all.

First, such specifications clearly constitute a valid scenario of structured knowledge: they are meant to convey to readers a massive amount of structured information about a product that is being built, they need iterative refining and evolving, and due to the nature of the contributors and consumers of these documents, they need co-authoriing and workflow processing support (to run through cycles of iterations). By nature, their content,and the implicit decisions it reflects, need to be justified to both the readers charged with validating the underlying requirements, and the readers tasked with implementing a suitable software component matching the same: thus, functional specifications (and their maintenance) exhibit the characteristics of a typical structured knowledge system.

Second, functional specifications are, in my view, an interesting problem to tackle, because while no-one will typically argue that anything larger than a small development project should do away with them, instantiations of such documents that truly meet the usefulness criteria above are very rare. Building useful specifications, therefore, can’t be simple, and frequires solving a number of complexities that we’re bound to face with any structured knowledge base, so that solving these functional specifications issues will help solving the more generic issues of structured knowledge. On the need for evolving, useful functional specifications, read Joel Spolsky’s articles, Painless functional specifications.

I position the features of a support tool for such a task (building useful functional specifications) along two dimensions:

• Process Management This dimension groups all the features related to the process of co-authoring structured documents: workflow, notifications, inline editing and commenting, change management, fine-grained addressability and so on. These features are pretty much orthogonal to the type of structured documents the group is trying to author.
• Structure and Content Management This dimension is more specific to the domain or type of knowledge being accumulated. In the case of functional specifications, the structure of the document, once ready for review, must make it easy for readers to understand what product they are going to get if developers build according to the specification. This structure is very fine-grained, and I would say it needs to be adjusted to every type of software product being built. For instance, if we’re building packages where the user interface plays a big role (as opposed to, say, a faceless package that solves a particular type of math equations, or implements a given networking protocol), then the structure must place a lot of emphasis on the graphical interface, leave none of it to the reader’s or the developer’s imagination, otherwise the contract that the specification represents isn’t precise and fine-grained enough. For enterprise application software, for instance, 2 key elements of the specifications should be screen-shots of mock-ups and possibly performance indicators of response time to the end-user. Determining the right structure and format (possibly using templates) for the completed document is, thus, a fine-tuned exercise that will affect vastly the usefulness of the effort. The importance of structure and format relates back to the learning quality of a knowledge base: how well it allows readers to grasp the concepts it carries. I don’t believe there is a unique format, best suited to convey any message. Instead, just like professors will pick and adjust educational tools and methods to best explain concepts they are communicating their students, the nature of the knowledge to share should drive the format of the communication. Rich on pseudo-code snippets when algorithms are discussed, rich on video, screen-shots when graphical interface is key, etc.

The one feature set that relates to both the tool and process used to build and share knowledge, and that knowledge itself, is the group of features exposed to allow editing of the document in the most convenient fashion. Whereas auditing, approving, tracking comments are all tasks pretty much orthogonal to the content they are processing, the tool(s) used to edit this content are inextricably dependent upon the structure of what is being edited. Text is the common denominator, but if you want the tool to be aware of the structure (in my example, if you want the tool to know about features, sub-features, dependencies, assigned resources, priorities, etc.) and facilite authoring along the natural structure of the product being specified, then you cannot be generic, instead you have to use a rich, specific editing tool. Fine-grained addressability actually falls in this category, since allowing reviewers or co-authors to edit video clips, or images, assumes they have the ability to make precise references to portions of such elements.

Now, what does this mean for my current challenge, building useful specifications? I will start by enhancing the XML Schema describing specifications tailored to my current project. While this enables me to embed images, even audio and video clips, addressability remains an issue. Then I will need to tackle the problem of how to render the document: I am thinking of a very dynamic, multiple views XSLT style-sheet that gives multiple perspectives to different readers, or enable one reader to successively focus on different aspects of the software being described – one important aspect is to keep conveying the context, regardless of the view, to allow readers to know where they are in the document. This set of issues are very specific to the domain of software functional specifications, and even constrained to the type of software I am specifying – I will tackle these first, in order to make sure I can at least come up with the right underlying and presentation models. Tools for process management, as described above, are more generic and I will tackle them when the structure and content management features are clearly defined.

An interesting set of communication systems recently gaining momentum with wider audiences are wikis. In essence, wikis, also categorized as social software, are web-based shared authoring environments. The concept of wikis was first invented by Ward Cunningham in 1995.

Aside from possible refinements to the features exposed by a wiki server (such as access control), all the content stored in the wiki is editable by all. Wikis use a simplified syntax to avoid requiring HTML authoring skills from their users, while allowing them to create links across pages on the same wiki, insert links to external documents or other wikis, or perform minimal formatting (typically bold or italic text, tables, lists).

The server or wiki container automatically exposes key shared authoring features: each page has a button to allow viewers to edit it (the full source is then shown in a text field and anyone can make changes to the entire page), another to display the history or the page (various wiki implementations either ship with their own diff tool or leverage the operating system’s tool). From anywhere in the wiki, a link is present to view the set of recent changes to the entire wiki, and thus allows the community to roll-back errors, to monitor the evolution of the content it shares.

This content is typically heavily linked, with a number of Starting points that are displayed as link on the top level page of the wiki. Not only can anyone edit each page, but anyone can also add new pages, restructure the organization of the pages and their linking, etc.

Most wikis I have played with are very bland in appearance. The simplicity of the syntax ensures a consistency in the look-and-feel of the knowledge base, but only at the cost of losing much of the formatting now expected by most readers. Even in the context of a wiki storing knowledge centered on technical documents, being stuck with a rather raw end-result is very constraining.

In addition, the co-authoring features are also very flat, with no inline mechanism where comments can be made, nor any mechanism allowing a review of the changes before they are promoted as the main version of the page.

But beyond these implementation limitations, the concept of almost-free-form, web-based co-authoring of a collection of pages constituting a shared knowledge base that keeps evolving with very little process constraints is very appealing.

For interesting examples of live, public wikis, take a look at the original wiki, or the wikipedia, a large-scale wiki-based encyclopedia.

I previously discussed the non-cumulative nature of email as a communication medium, and the short-comings implied by the associated semantics. One of the key paradigm shifts necessary to reach efficient team exchanges involves centering the whole communication system on a cumulative core, where relevant knowledge gets constantly and directly added, updated, and refined through a collaborative authoring mechanism.

In practice though, knowledge stored on shared file systems that do not integrate with the messaging tools used regularly by the team quickly becomes obsolete. At the very best, it is in an almost constant state of obsolescence between infrequent major updates: the effort involved in keeping it up-to-date, requiring synthesizing the substance of email exchanges and working out their effective impact on the stored knowledge, is very expensive. This is the case with any system where multiple modeling paradigms (here the cumulative vs. non-cumulative models) coexist and the task of bridging these models remains a manual activity: c.f. the effort and risks involved with manually translating from the design modeling semantics to the programming language semantics in Object Oriented software design, and the number of two-way tools that have emerged to close that gap. Obviously, avoiding such obsolescence should be a major design goal of any efficient communication and knowledge building system. This fact indicates that shared files systems alone are not the answer to the challenge of structured exchanges and knowledge systems.

Another crucial design point of structured knowledge systems revolves around their decision auditing and deconstructing capabilities. I think of this as their reflective capabilities: when we envision communication as a mechanism to reach and refine decisions, it is important to observe that those decisions will constantly need to be revisited: by the decision makers throughout the lifecycle of their project, by the managers or customers of the product, by new team members trying to educate themselves on the knowledge relevant to the project. It follows that the ability of the gathered knowledge to be parsed or apprehended in a way that illustrates the analytical process that led to all the embedded decisions is critical. Ultimately, the communication and knowledge building system must exhibit good didactic or educational properties, and offer multiple knowledge browsing perspectives, following either the hierarchical structure of the captured knowledge itself, or instead slicing through that structure along decision making perspectives.

Therefore, the self-describing, browsing and annotation capabilities of the knowledge system are of critical importance. This relates tightly to the communication concepts exposed in Barbara Minto’s The Pyramid Principle, in which she exposes a set of practical guidelines to be used when presenting one’s analysis to an audience, by resisting the urge to build up suspense or recount the trial-and-error-driven discovery process following the sequence in which it occurred, but by offering, instead, the conclusion up-front, and letting the audience guide the presenter through the subset of points they challenge, in order to maximize efficiency and concision, while minimizing the amount of redundant or well-known information that needs to be exchanged.

Most of the communication occurring among members of a project team is aimed, or should be aimed, at making decisions and enforcing them. Managing a project through its entire lifecycle involves a bewildering number of critical decisions of all sorts, distributed along many dimensions: vision and strategy, technology choices, architecture and detail-level design, requirements from customers, derived from competitive analysis, constraints such as cost, timeline, and so on.

A lot of these decisions, provided that the project’s execution is to be successful, must be made in a tightly interwoven fashion: there are, for instance, complex implications between the availability of a given technology in the market at a given time, the level of expertise in the team for this technology, and the overall strategy and direction adopted by a software or hardware product. And these decisions should be based on the confrontation of as much relevant facts and cross-fact connections as available with the analytical ability of the team as a whole.

How, then, do the communication systems we use affect our ability to reach the right decisions, enforce them, revisit them? More precisely, how do they assist us in gathering, organizing, linking and analyzing the facts, the knowledge so essential to our decisions and ultimately our success? Just as critically, given the scarcity of solid knowledge during the early phases of a project, how do they help in iterating through the on-going process of integrating new facts, additional knowledge in order to confirm or refine those decisions?

Indeed, communication systems and their associated semantics, far from being neutral, transparent bearers of the information they convey, have a major impact on the structure of the exchanges taking place among the parties involved. Therefore, they affect the process of elaborating knowledge, and ultimately the richness, accuracy, and relevance of the facts we gather, categorize, and derive our decisions from.

Consequently, deconstructing team communication patterns is essential in understanding how structured knowledge is elaborated, and used to reach decisions. Such communication patterns are also important in understanding how such knowledge and decisions are then described and shared within and outside the team, as well as kept track of and evolved over the course of the project’s lifecycle.

Given its ubiquity in software development teams, let’s start by looking at the way email, as a communication medium, shapes the decision making and tracking process.

Email-based exchanges, that are message-oriented, carry “differential” semantics: like all conversational systems, they involve the exchange of messages among the parties involved that do not typically contain the entire knowledge shared among those parties. Instead, these entities communicating are responsible both for maintaining the mental image of the knowledge they are sharing, and for amending it continuously as they process the implications on this knowledge of the messages exchanged, containing only additions and changes proposed by one entity to the others.

The activity of constructing and maintaining the mental image of the shared knowledge is work-intensive. Worse, it is a risky task, in that the knowledge elaborated is not really shared directly, but instead maintained in mental images that are actually private to each party.

Therefore, I describe email as a non-cumulative knowledge building system. Not because each message that is exchanged only carries additions or changes to be made to that shared or pseudo-shared mental image, but because the work of processing the meaning of newly received messages is ultimately done by their human recipients.

How does the non-cumulative nature of a system impact the ability of the team to build knowledge?

A non-cumulative medium has many drawbacks, not the least of which is being prone to uncontrolled divergence between the private images of the shared set of facts and cross-fact connections held by the parties involved. Of course, the more parties are involved, the greater the risk of catastrophic divergence.

And the only way such divergences actually get noticed and possibly corrected in such a system is when one of the parties sends a message describing their contributions or additions to the shared knowledge and these additions suddenly fail to fit into the mental representation of the knowledge held by the receiving parties.

The sudden inconsistency prompts for clarifications, retransmissions, and not uncommonly, the rewinding of most of the conversation up to the point where all parties feel, again, confident enough that their private images are describing the same knowledge that they decide proceed forward again.

Such a phenomenon, obviously also found in verbal conversations, is the source of major inefficiencies in the communication, and it stems from the lack of a knowledge base that’s actually shared, and that all communicating parties are observing simultaneously as they evolve it.

Of course, cumulative systems, by contrast, rely on the existence and building of shared knowledge in the system itself, not in the minds of its users. Examples of cumulative systems are databases, shared file systems.

But what’s missing from a database of shared file system is the ability to exchange contributions and observations about the facts being shared, and thus augment, modify, refine the knowledge set of the group, within the boundaries of the system itself. Hence the appearance of out-of-band communications, typically taking the form of email exchanges, where additional knowledge is therefore appearing, outside of the shared system, at least until someone decides to feed their private cumulative image of the exchange back into the shared system. Quite a daunting effort!

The underlying challenge, thus, becomes: how can we integrate a cumulative shared system with a non-cumulative messaging system to support the on-going elaboration and refinement of structured knowledge, in a continuous, inline fashion, from a unified interface avoiding disruptions and rifts in the communication semantics?

I just checked out Kubi Software’s collaborative email product. They identified some of the inherent short-comings of email driven collaboration: all your messages are received there, unsorted, and even if you were to painfully move them around into organized folders, this would only benefit you. Client-side rules aimed at automating some of that are only addressing a fraction of the issue. So you end up spending your time sifting through relevant and not so relevant messages, expending vast amounts of energy just fighting the clutter. They propose a solution that plugs into the team members’ existing email clients (Outlook 2000, 2002 and Lotus Notes), and also leverages the servers already deployed.

Users of Kubi’s plug-in get to create Kubi spaces around projects or focus areas. The spaces are by-invitation only, and structured in the sense that they expose project-related tasks, contacts, documents, email discussions. Users publish documents, messages and track project events right from within their familiar email client interface. Removing the adoption critical mass barrier is thus one of the most immediately obvious qualities that Kubi brings its users.

One of the obvious features I still see as missing (at least from the demo): there is no sign of a workflow or generic event model that would allow users to subscribe to events on a particular project deliverable (say, a design specification document) and therefore get notified of changes automatically. Kubi does expose in its spaces a most recent activity pane, where I assume changes about document get automatically exposed based on the underlying shared document server, but there are no notifications that alert you it’s time to check out those updates.

Similarly, I didn’t see any mechanism to tie a particular document to a task and automate reminders, nor to enroll a set of users in reviewing documents at particular milestone points in the life-cycle of a deliverable. Finally, it doesn’t seem that Kubi spaces support sub-spaces, so you can’t create sub-projects to which a certain subset of your tasks gets delegated.

Incidentally, Kubi Software plans to launch their product next quarter, and VentureWire reports they will start raising a $10-million round of funding later this year.