[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Should standards address integration issues directly?



While I think we can put an infrastructure in place which is designed to
help reduce integration problems I'm not so sure that we can ever hope to
eliminate them by design.  There are simply too many permutations and
combinations of the integration issue compounded by an ever-changing IT
environment.

Steve :-)


> -----Original Message-----
> From:	Smith, Ron (GEM) [SMTP:Ron.Smith2@compaq.com]
> Sent:	Monday, October 19, 1998 12:04 PM
> To:	Multiple recipients of list
> Subject:	RE: EITAAC - Families Subcommittee
> 
> Comment to Bill Paul etc: Rigid standardization is not the answer. I know
> of
> only one real-world example of this...a big-name company with rampant
> integration problems that standardized on Windows (pre-95) and Office 3.0.
> All of their integration problems were solved by mid-1996. They are still
> fully integrated today...and totally isolated, since they can't decipher
> any
> messages received from the outside world. As a practical matter, Systems
> Integration is a critical and permanent technical function in the
> marketplace. Wouldn't we be best served if the standards addressed
> integration issues directly so that accessibility was built into the
> Systems
> Engineering design solution?
> 
> > -----Original Message-----
> > From:	Chuck Letourneau [SMTP:cpl@starlingweb.com]
> > Sent:	Monday, October 19, 1998 12:39 PM
> > To:	Multiple recipients of list
> > Subject:	RE: EITAAC - Families Subcommittee
> > 
> > Response to Bill Paul and question for Dave Bolnick:
> > 
> > To Bill: As an integrator of computer assistive technology from 1990
> > through 1996 I heartily concur with your comments about the systemic
> > incompatibility of both off-the-shelf and assistive software and
> > peripherals.  Even more frustrating is when two or more "identical"
> > systems
> > behave in oddly different ways.  The sad fact  is that no one, not even
> > the
> > esteemed National Software Testing Laboratories (NSTL), could test every
> > component with every other component on the market.  They probably
> > wouldn't
> > even accept the contract to try.  What's the solution?  Is it
> > industry-wide
> > adoption of and strict adherence to one set of technical standards?
> > Maybe... but I suspect the Washington Redskins will win a football game
> > before that ever happens.
> > 
> > For Dave:  By "proof-of-concept" verbiage, do you mean statements to the
> > effect that: "Tendered equipment must work with such-and-such installed
> > base of equipment or we can demand replacement or other fixes."?
> > 
> > Regards,
> > Chuck Letourneau
> > 
> > At 19/10/98 11:51 AM , you wrote:
> > >This is important for the entire EITAAC to understand and supports
> > >proof-of-concept verbiage in government contracts (I believe the SSA
> > >contract included one). Whether this can be a 508 requirement is beyond
> > me.
> > >Maybe the DOJ representative (Mary Lou Mobley) can comment here. 
> > >
> > 
> > ----
> > Starling Access Services
> >  "Access A World Of Possibility"
> >   e-mail: info@starlingweb.com
> >    URL: http://www.starlingweb.com
> >     Phone: 613-820-2272  FAX: 613-820-6983