- From: Tsao, Scott <scott.tsao@boeing.com>
- Date: Mon, 4 Feb 2008 20:59:46 -0800
- To: <abcoatesecure-w3c@yahoo.co.uk>, <xmlschema-dev@w3.org>
- Message-ID: <C7A7D8EA54C20744BFF861613617222C06218EE0@XCH-NW-3V1.nw.nos.boeing.com>
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 UTC