A KIX use case: Agile Distributed Integration

KIX seems to be the first tool, which aims to directly support Agile Distributed Integration.


Open source Plone, Microsoft Sharepoint and Google Wave are in that respect all potential contenders to KIX. However, none of them are aiming at directly supporting agile distributed integration.

KIX has one unique feature which makes it stand out - it supports the activities and work flows associated with distributed live documents with dependencies between them.

The KIX support for distributed integration across dependencies covers cases when stakeholders

• are geographically distributed,
• are distributed in time,
• or operate under distributed authority, i.e. belong to different organisations even when there are no formal arrangements.

The crucial question, when trying to achieve critical mass for KIX, is whether this special use case is common enough to support a break through for KIX. In principle the problem of distributed integration should be pervasive. However, in the past it has never been feasible to integrate complex operations without considerable centralisation. Thus there is bound to be a huge cultural resistance against any attempts to achieve integration in a decentralised manner.

Growing interest in KIX

Last week a colleague of mine approached me on the subject of KIX - please describe KIX in 5 minutes. I tried along these lines:

• KIX is a web framework for distributed integration and agile engineering.
• KIX has a multiversion document repository - i.e. the document owners explicitly nominates one document version to be the current one. This is not the necessarily the last version.
• KIX is a little bit like a distributed make system. It can be used to maintain dependencies between documents. However, KIX may do this even if the different documents are maintained by different stakeholders and the documents reside on different KIX servers.
• Significant document events are notified to all dependent KIX documents - the KIX framework supports the configuration of plugins, which may take automatic actions when such events arrive. For example a new version of a dependency document may result in the automatic creation of a new version of the dependent document. Thus changes to one document may ripple through a web of distributed KIX documents much like a spreadsheet, where each document taking part corresponds to a spreadsheet cell.
• KIX also has a plugin point for bespoke document display; any KIX document can be viewed by any number of viewing plugins - one after the other - thus providing multiple specialised views of the same document (see e.g. this wiki view followed by a document review view).
• KIX may also deploy the documents to the outside world; when for example a KIX document version is nominated as the new current version it may simultanously be exported as a file - with or without conversion. This is happening in the above example where the 'Exported page' link has been written as a static HTML file.
• Moreover, KIX provide a document version comparison tool and a generic KIX site map navigational tool.
• In order to support agile engineering KIX implements fast notified feedback from stakeholders in the form of threaded web conferences. A KIX display plugins may split a document in any number of document subject nodes, each available for individual threaded discussions.

Admittedly this interactive presentation took a little bit longer than five minutes. Despite the daunting scope of the presentation my colleague ended by asking how we could use KIX to improve integration and engineering at JET. In my view there are many potential possibilities, but a prime candidate is probably the JET Operating Instructions, which are used by Engineers-in-Charge when operating the JET machine. This is because of their formal nature and the many stakeholders involved in the review process and finally the latest approved version is used as requirements for JET operating support software, i.e. there are dependent documents.

New versions of the Document Review plugin and the KixFw framework

Version 1.13 of the KixFw framework has now been released. The main upgrade is to allow 'open browsing' of KIX documents, i.e. web users may view KIX folders, documents and comments without having to login to KIX. The open browsing mode is a configuration option when you install an instance of KIX.

Version 1.6 of the Document Review plugin has also been released. It also supports 'open browsing' when this is configured. Otherwise the plugin has been reimplemented for much better performance.

After these releases it is easy to demonstrate some basic aspects of KIX and the related Document Review plugin:

• The KIX document map for the SourceForge KixFw site can be seen here.
• A document review with a comment example (at line 70) can be seen here. (The KIX document is a Server Side Include HTML fragment).
• A KIX comparison between version 12 and 9 of this document can be seen here.
  

KIX may finally take off - or at least hover

The last two weeks I have been involved in many different activities related to Kix and KixFw:

• I have started a collaboration with an American, who would like to install and try out KIX. We will start by creating and refining an installation instruction at the KixFw website at SourceForge.
  
• I have presented KIX to a wider group of software developers at EFDA-JET.
  
• As a result a colleague suggested the DocReview plugin would be of benefit when reviewing new and existing JET Operating Instructions (machine safety critical instructions to the Engineer-in-Charge when operating the JET plant).
• Similarly, another colleague would like to use the DocReview plugin for his source code reviews. However, he would like the DocReview plugin to be configured with a syntax highlighter for the programming language he is using. This can be accommodated with a small enhancement.
• I have demonstrated KIX relatively comprehensively to another control engineer at JET. He would like to use KIX for collaborations around JET enhancement projects and major JET maintenance modifications. However, he would like to wait until KixFw handles unknown binary files gracefully i.e. Windows Office files and similar proprietary formats.
• I have used KIX to create a JET intranet website to manage the JET Spectrometer Room Project. Many pages are still missing in particular the pages which will hold formal representations of the detailed requirements for each of the 18 subprojects.
  

High precision feedback from stake-holders

When discussing kixfw with other professionals there is one feature of the kixfw collaboration tool which seems to attract more interest than anything else:

High precision feedback.

This strictly not a property of kixfw itself, but the mainly of the plugins which are used to view different types of documents. For example the DocReview plugin enables one threaded web conference per document line.



My experience with this detailed level of feedback is that the quality of the documents are raised dramatically. Review comments are firmly connected to the relevent context and kept for as long as the documents remains on-line. This provides excellent organisational memory.

The above screen shoot is an extract from the preparation of The Kix White Paper.

Much activity but no break through

Today I proposed KixFw as an internal collaboration tool to define the formal requirements for the interface software in the Spectrometer Room Project at EFDA-JET. The main idea is to define the various software requirements as formal documents expressed in CCL - the CODAS Configuration Language (a serialisation of RDF). A KIX plugin will be developed such that the software requirements can be viewed as hierarchical tables. The tables will have numerous HTML links, which will allow detailed threaded web conferences on any interface specification issue.

The same requirements documents can also be used to automatically generate software interface implementations following the principles of MDA (Model Driven Architecture).

As a similar example I demonstrated the operation of the KIX document review plugin and got positive feedback from the meeting. Someone suggested this should be announced to a wider audience.

Last Wednesday during a startup investment meeting I discussed the role of KIX in document reviews for the Semantic Web. In the semantic web context there is a pressing need to develop many different domain vocabolaries. This is an ideal application for KIX.

KixFw seems to be a very hard sell...

Yesterday I visited an IT consultancy seminar in London. The subject for the evening was

The Next Revolution in Productivity - The Plug-and-Play Business

The focus was on SOA and business modelling. There were three high power speakers:

• Ian Graham, Principle Consultant at trireme.com
• Brett McCall, Business Process Management Systems, Ford European Region
• Ian Dalby, Enterprise Strategy Consultant, Microsoft

Afterwards I approached each of them. None of them appeared in any way convinced of the benefits of using a collaborative modelling tool like KixFw.

One seminar participant was, however, relatively enthusiastic when I described KixFw and its present state. He promised to check out KixFw on the web.

Today I demonstrated KixFw to a colleague at work. He was very impressed. He suggested several names in our research organisation who might be very interested. This included the director.

To be continued...