Re: SGML/XML Justification - was replacement of Frame

[HALL Bill <bill -dot- hall -at- tenix -dot- com>]

I have to disagree with Chris Knight's excellent contribution in one area.

Chris wrote:

>As to how to justify all this with "hard numbers", this could be difficult.
>I was very impressed with the post from Bill Hall. One of the things that
>caught my eye was the ability to reduce the number of documents by
>managing and reusing document components.
>But I suspect his solution is affordable only if you're a navy supplier.
>Anyone got any more XML success stories? Horror stories?

At least in Australia, the days of cost plus contracts are long gone. Thanks
to the overall reduction in tensions internationally, the defence
contracting business world-wide has become fiercely competitive as
increasingly amalgamated organisations are fighting to win pieces of a much
smaller market for new projects. The ANZAC Ship Project and many other
defence contracts are now being negotiated under fixed pricing structures.
These days it is quite possible to make a loss on a multi-billion dollar
contract.

Believe me, the business case to implement our conversion to SGML/XML was
not easily won. We spent a year of R&D effort in 1998 (and mercilessly
exploited several cooperative suppliers in a situation where they were
competitively bidding against a "no promises" RFQ) to help us develop our
understanding of the technology and its capabilities, and then another 5
months checking and re-checking our assumptions and selling and reselling
the business case internally before the company was ready to commit to
implementing a system.

Where Tenix is concerned, the case was not easily made, because we are
already late in the documentation cycle for the project supporting the
initial implementation. Because our authoring of new routines is essentially
complete, even with spectacular reductions in documentation volume, we
probably will not even break even against the anticipated document
maintenance requirements for ANZAC Ship Project. However, if we had been
able to implement this kind of technology in 1993 when we began our major
authoring efforts, we would have paid for it ten or twenty times over. In
the present situation, we will only see a significant effect on our profit
margins as we deploy the now well understood technology into other
documentation intensive areas of the business (e.g., contracts and
subcontracts management) or in new projects.

I would argue that the business case for XML and DCMS technologies should be
much easier to make in the software industry, where new projects are
starting all the time and where the pace of documentation change is very
much higher than it is in the  10-20 year production cycle for a major
weapons system.

This kind of technology is easy to justify if your documentation meets
several of the following criteria:

o large number of (or a smaller number of very large) documents
corresponding to standard formats
o require maintenance of content elements over a long life-time (e.g., >2-3
years)
o significant duplication of or capability to reuse elements of content
across several to many documents
o requirements to validate elements of data against external sources
o requirements to deliver content electronically
o requirements to source several different deliverables from the same
content
o multiple authors contributing to the same documents
o audit (e.g., ISO 9000) or configuration management requirements
o benefits to be gained from semantically controlled retrieval of indexed
content
o electronic distribution of content (i.e., serve content to the Web)
o distributed authoring (i.e., use telecommuters)
etc.

My list is not exhaustive, but these are the kinds of questions which I
asked in building our internal business case. If you can put some dollar
values in terms of savings or sales against answering each of these (e.g.,
from reduced labour requirements, more competitive product, etc.) and they
stack up against the cost of the proposed solution, you are well on the way
to winning your business case.

A suggestion to the list members: it would be a good project for the whole
group to think of the kinds of issues in our present businesses that could
potentially be addressed by standard markup languages and the related data
management technologies. This is almost a necessary defensive exercise given
that we are in the midst of a technological revolution. If you don't think
of the process improvements and your competition does, and implements them,
whose business is likely to succeed?

Bill Hall
Documentation Systems Specialist
Integrated Logistic Support
Naval Projects and Support
Tenix Defence Systems Pty Ltd
Williamstown, Vic. 3016 AUSTRALIA
Email: bill -dot- hall -at- tenix -dot- com