Re: Is "simplicity" a useful architectural constraint?

David Orchard wrote:
<SNIP>
> One approach that I like is to think about the customer of the specification
> and how many of them you expect to use the spec. 
...
> A final point is that sometimes you just can't make the spec simple as the
> task is just too complicated.
><SNIP>

To me these two points really emphasize the importance of collecting and
documenting the requirements before writing a specification.

ebXML did this and we ended up with a nightmare to write an
architectrure for.  The goal was to create an infrastructure that
"enabled globally interoperability and the formation of ad hoc business
relationships based on divergent XML vocabularies.  It also must be
capable of being fully automated".

The related architectural document was only 40 pages and tied together a
series of other specifications.  This modular approach enabled (or
should have enabled) a layperson to read each specification and
understand it as a component.  Each modular specification also made
normative references to other protocols, themselves governed by
specifications (examples: W3C schema, SOAP, HTTP, MIME).  

<sigh> It all seems so simple on paper ;-)

Duane Nickull

-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/

Received on Thursday, 3 January 2002 12:50:50 UTC