Re: [xml-dev] [Summary] Creating a single XML vocabulary that is appropr

["Fraser Goffin" <goffinf@googlemail.com>]

> On the other hand, look at how much work went into building UBL and how much
> it has cost so far, then do a traffic analysis of current usage.

Yes, the impression is that this ratio (especially from a ROI
perspective) would not be an attractive proposition. One the other
hand, once over the initial investment 'hump', the cost of entry
thereafter is much lower (there is enough UBL now for new users to get
benefit I would have thought - if it weren't so damned complex that is
;-).

Its a similar argument I face most days, shall 'Solution X' comply
with our [technical] architectural principles or shall we 'go
tactical' and worry about the impact that this may have later. Once
again its horses for courses with a bunch of influencing factors
(shelf life of the application, funding model, business benefit, 'run'
costs, delivery timescale, et al).

There's a lot of focus on 'agile' right now (something of which I
approve personally), but even here there are usually some 'sacred
cows' .... I heard someone say recently 'tactical is like - buy now
pay later (except no-one tells you about the 'pay later' bit), versus
pay now save later'. Simplistic I know, but with a grain of truth ;-).

Often, the initial funding model for enterprise architecture doesn't
fit with invidual project budgets, in which case should we send all of
the architects home and just do tactical everything ?

David Orchard et al have proposed a number of disciplines that *can*
be used to ease the impact (and thus speed and cost) of changing and
extending a vocabulary. These touched on the roles of the vocabulary
'owner' and the vocabulary 'users' and identified how both centralised
and decentralised control can occur without total anarchy.

Roger and others on this list have also in the recent past talked
about when to create new bespoke vocabularies and when there might be
advantage in reusing those that already exist. The arguments are not
dis-similar to those which you and I are making now.

In organisations its close to the 'reuse vs. buy vs. build' analogy.

Fraser.

2008/7/17 Len Bullard <len.bullard@uai.com>:
> It probably is unless you count the early work done for technical manuals.
> On the other hand, look at how much work went into building UBL and how much
> it has cost so far, then do a traffic analysis of current usage.   How is
> the rate of adoption comparing to the costs of implementation and
> maintenance (evolution costs or system change over fielding)?
>
> The example I posted doesn't factor in uses or users/consumers.  Sometimes
> we don't converge those down to one drillable dashboard.   The cost of
> another feed to yet another high res-display in a situation room is much
> cheaper than force feeding into a single display.    Real convergence comes
> in reports where data can be downtranslated into a displayable form.  Now it
> is the querying system that takes the hit, not the formats or vocabularies.
>
> IOW the single vocabulary approach might be deferred to a transformation or
> query approach.  That is why HTML trumped all other comers.  Humans do the
> thinking.
>
> len
>
>
> From: Fraser Goffin [mailto:goffinf@googlemail.com]
>
> What do you think of UBL ? This is the best example I can think of for
> cross sector usage of a common vocabulary ?
>
> Fraser.
>
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
>