Saturday, June 03, 2006

Clearwater '06 - S1000D Business Rules

You will be getting 'fed up' with me talking about Business Rules but on the second day of Clearwater '06 the S1000D User Fest, a good part of the programme was about them.

The presentations and discussions indicated that there were several different views of what exactly the S1000D Business Rules should be. You should be aware that the S1000D people have, for the moment, combined the groups handling Business Rules and Implementation, not because they actually live together but more because the boundaries are not clear at present.

The Presentations

Several people gave presentations which were led off by one from John Lawless of the UK MoD Policy Organisation for Technical Documentation.

His message was crystal clear:

  • They are essential
  • They can take a long time to develop
  • Development of business rules in a multi-country collaborative environment can take even longer.

Not only were these points well made but his other very important point was that all Business Rules should take into account Legacy data. These projects could be in earlier versions of S1000D but also still in hard copy (should the pages be turned into electronic format). With the possibility of having S1000D projects containing different Issues of S1000D it is important that the output be capable of mixing these in a proper manner.

From a purely output point of view, five or so years ago I remember proving beyond any doubt to an MoD representative, that the mixing of DM issues was possible when I created an IETP using several different issues of DMs - they had been advised that it could not be done. I was interested that this point was mentioned in the presentation.

Vendors Presentations

There were several vendors giving presentations of their interpretation of S1000D Business Rules and how they could handle them. I feel that only one actually tackled the question and raised the questions of what are Business rules and mentioned and this covered things like

  • Missing issue of DM
  • Missing graphics
  • Are unverified DMs allowable in a transfer package
  • What happens when the business rules are tightened part the way through a project (e.g. do the existing DMs have to be re-checked)

Unfortunately there was one presentation which was purely a demonstration of the software and made no mention of the flavour of the session i.e. Business rules. It was pointed out to me that they presentations were marked as commercial but I did, and still do, feel that the vendor could have at least paid lip served to the topic.

The S1000D Business Rules Content

A number of the delegates that spoke indicated that they eagerly awaited the inclusion of Business Rules into S1000D and there was some dismay that it was going to take so long to achieve this.

As has already been indicated, version 2.3 of S1000D is not going to contain anything specifically about Business Rules. Of course business rules are alluded to throughout the spec. The current situation is reported as:

  • The group is visually scanning through the specification to identify all the places where a Business rule is indicated
  • These references are being built up to make up a list of cross references
  • The intention is to produce a checklist to help in the creation of the Business Rules i.e. what needs to be in (although it is clear there is going to be too much to allow simple tick box working)

How long does it take to create Business Rules for S1000D Projects?

Some questions came to the surface relating to how long it takes to create and finalise the business rules. A period of one to two years was quoted and this did not result in any objections from some delegates who had done some - so be warned - Business Rules generation is not a quick job and should include the idea that some parameters could be tightened during the life of the project.

Hopefully S1000D Issue 3 will contain what you are looking for a flow chart of the process in generating Business Rules and Implementation Information and further guidance.

2 comments:

Anonymous said...

Any brex file could define what configuration data was different from project to project. And this could be modeled around industry specific business cases, such as the Army and Navy could us these differently. The airlines industry may have their own which was specific to non-military requirements? The most important focus is the application logic layer from the software must get industry standard data models so this can be transformed into application functionalities. Like any rules file, hopefully we could use a rules processing engine in the future to build in automation and conditionality.

Anonymous said...

I find it surprising that nobody at that conference mentioned Schematron as a mechanism for describing, exchanging, and validating S1000D Business Rules. Efasoft has published an interesting white paper on the subject.