W3C home > Mailing lists > Public > xmlschema-dev@w3.org > February 2008

RE: Impact of XML on Data Modeling

From: Tsao, Scott <scott.tsao@boeing.com>
Date: Mon, 4 Feb 2008 20:59:46 -0800
Message-ID: <C7A7D8EA54C20744BFF861613617222C06218EE0@XCH-NW-3V1.nw.nos.boeing.com>
To: <abcoatesecure-w3c@yahoo.co.uk>, <xmlschema-dev@w3.org>
The scenario described below seems to be quite REAL in large
organizations, where the Central Team is more interested in developing a
"common data model" reflecting the overall business of the enterprise,
but the Distributed Teams are more interested in developing the
"localized XML schemas" to facilitate interfaces between applications
(or with data warehouse).

I wonder in the case that the Central Team's modeling effort is lagging
behind the localized schema development, would it be advisable to
reverse engineer the XML schemas for the sake of maintaining a data
model that reflects the actual implementation?  Have you experienced
that in your practices?
 
Thanks,
 
Scott

-----Original Message-----
From: Anthony B. Coates (W3C Lists)
[mailto:abcoatesecure-w3c@yahoo.co.uk]
Sent: Thursday, January 31, 2008 3:13 AM
To: xmlschema-dev@w3.org
Subject: Re: Impact of XML on Data Modeling

...

At this scale, though, it's not just about the technology, there are
also important project management issues which can contribute just as
much to success and failure.  For example, if all of the Schema
creation/editing/generation (depending on your process) is done by a
central team, then during periods of heavy development that central team
will find itself on the critical path of a lot of work, and that can
have a negative impact on the way the central team is perceived.

The problem is one that transcends XML, it applies to many other things
too - how to you manage distributed design and development of shared
assets?  Central teams are good as pools of technical expertise, and as
custodians who can check work against design rules and policies, provide
guidance, manage formal releases, etc.  Distributed teams sometimes have
more of the business knowledge, plus they have their own resources which
they would often prefer to use rather than waiting for their work to get
to the top of the queue of work for the central team (central teams are
forced to prioritise work from different teams, and that can be hard to
do - why is one team's work more important than another? - and that's no
way to win friends and influence people).

...

Cheers, Tony.
Received on Tuesday, 5 February 2008 05:00:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:15:02 GMT