OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: [Summary #2] Should Subject Matter Experts Dete rmine XML Data Implementations?

It seemed to me, from the beginning, that this thread was more about analysis and design technique than about XML. 

The example given has two different data models which encode two different sets of requirements (even though the number of requirements is small and one set is a superset of the other).  This looks less like "legitimate" or otherwise influence than a missed business requirement in the first iteration.  The issue in thise case is where should knowledge of which methods are preferred payment methods live and the example does not contain enough detail to know the answer, because there are more things to consider: information hiding (do we want to make that preferred status visible?), change management (how do you change the preferred status later?), and universal applicability of rules (is this true everywhere that the schema is visible?) are all considerations. 

Some business requirements as expressed by the users are about software implementation and some are about how the business works.  The example here might be more like the former than the latter and those are always problematic.  Absent a design objective to have the XML represent the mental model of the business users (something I think is often dangerously brittle in the face of business change), the old ANSI C committee's "as-if" rule is appropriate: if you can deliver on the core requirement you don't have to actually build the theorietical implementation model.


On Fri, Oct 17, 2008 at 2:05 AM, Len Bullard <len.bullard@uai.com> wrote:
I didn't say "blind", Mike.  I said, "Not their shot to call".   I also said
they should inform the business manager about performance and I consider
improvements to design a performance issue.  It is the data designers
obligation to inform.   It is not their right to determine.

Successful businesses coordinate and inform, but unless a data designer or
any other employee understands proper authority, no business remains in
business for very long.   So again, I quibble with the question as posed.
In essence, implementation serves the business, not vice versa.


From: Michael Kay [mailto:mike@saxonica.com]

> The data designer does not answer the question of when a
> business rule is *legitimate*.   It simply is not their shot to call.   It
> their job to determine how to meet the business requirement as determined
> by the business owner/manager as long as that requirement is within legal
> constraints.

Actually, I don't believe it's a good model that IT people blindly do what
the business tells them to do, and I don't believe successful businesses
work this way. If the IT people are good at implementing IT systems then
they also have the brainpower to design improved business processes (perhaps
to take advantage of IT potential, but perhaps just because they have the
right kind of thought pattern).

I remember when I was a student one of the computer science faculty members
(John Larmouth, I think) implementing a program to automate the complex
rules for University Senate elections, and ending up proposing an improved
set of rules which were duly incorporated into the University Statutes. I
think that's the way things should work.

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.


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS