Re: Summary of findings of TA Spec. review. my 2c

[Jaideep Roy <jroyjroy@yahoo.com>]

Hi All,

I too agree that the document doesn't look like an architecture
document from a software point of view. It needs some re-work and
re-organization to be acceptable and to truely reflect all the hard
work put in. 

Regards,
Jaideep Roy


--- Krishna Sankar <ksankar@cisco.com> wrote:
> Hi all,
> 
> 	I agree with Duane in that the Architecture specification *is*
> important
> and is the foundation. So we do need one at Tokyo. We are software
> professionals - we live and die by architecture.
> 
> 	As there are a lot of e-mails and some concerns, I dedicated this
> Sunday to
> analyze this document (to the best I can). Here are some of my
> comments:
> 
> 1.	Nagwa & Tim are referring to the version 0.8.71. I do not think
> they are
> referring to an old document. Is this the current version ?
> 
> 2.	I do have to agree with Nagwa and Tim in the sense that this
> document
> does *not* read like an architecture document. But as I read thru the
> document, it has a lot of information. The team has done a lot of
> work and
> it shows. But the document needs reorganization and more
> material/diagrams
> for a lot of sections.
> 
> 3.	For example, the first detailed section should be the one which
> describes
> the ebXML architecture - what are the components at a high level, how
> do
> they fit in - some are layers like the business processes run on the
> transport and some are orthogonal like the regrep. Some are
> implementations,
> some are concepts like the BP/CC, .... you get the picture.
> 
> 	For e.g.: Line 210: Talks about seven components. We should define
> these
> and give a brief description in 3.0. Something like "the ebXML
> Architecture
> is based on seven components viz. ..."
> 
> 4.	We need a lot of diagrams explaining the ebXML Architecture - the
> systems
> overview diagram is over used; it is there everywhere. Even though a
> common
> diagram shows consistency, having only the common diagram does not
> explain
> much. The architecture diagram has to elaborate on this common vision
> with
> more text and diagrams.
> 
> 5.	Many sections do not have a theme or worst some have multiple
> themes.
> Each section should do only one thing and it should do it well. (I
> have
> heard this many times from my books' editors - sometimes in not so
> flattering words !)
> 
> 6.	The Section 5 road map should be an Appendix. As it stands now, we
> are
> describing a roadmap without even covering what the components are.
> 
> 7.	Yes, the document has a regrep-centric feel. It is because a lot
> of the
> sections talk only or talk much more about the regrep. We do need to
> take
> some stuff off and add more from other components point of view.
> 
> 8.	The use cases are good. But we need to add more. Things like the
> discovery, how to bootstrap a communication, etc are missing. I think
> if we
> look at each components and capture the most important use cases we
> should
> have them all.
> 
> 	Detailed and more elaborate use cases do belong to the respective
> specifications. I am not sure about your point in the case of regrep.
> 
> 9.	The use cases do need a taxonomy/categorization. Now it looks like
> a list
> of use cases without any relationship.
> 
> 	A diagram showing their relationships would help. The diagram can
> also have
> the 7 major components in the Y axis thus showing where each use case
> fits
> in. (I can draw a strawperson diagram)
> 
> 10.	The sample files section is good. It needs a new name - may be
> sample
> documents is better or something much more generic. Here we run the
> dichotomy problem. This document needs to be revised every time a new
> sub-document comes out else this section will be outdated.
> 
> 	On second thought, the examples would not make sense without the sub
> documents anyway.
> 
> 11.	We do need a lot of sequence diagrams explaining the various
> concepts,
> interactions et al. Many of them belong in the use case section.
> 
> 12.	That brings me to the use case section - do we need one ? It is
> good, in
> the sense that it describes what a minimum system should have. But it
> adds
> pages to the document and complexity.
> 
> 	I think if we judiciously select use cases which amplify the ebXML
> architecture and explain the end-to-end process, develop good
> sequence
> diagrams and elaborate the relationships among the use cases, this
> section
> would do justice.
> 
> 13.	We do need a section for various "shalls" and assumptions.
> 
> 	Now that I am an accessory ;-), I offer any help needed for all of
> us to
> get a good document out by Tokyo. As Duane said, with out an
> Architecture
> document, we cannot have the other documents.
> 
> 	cheers and have a nice weekend
> ----------------------------------------------------------
>        |          |             Krishna Sankar
>       :|:        :|:            Member of technical Staff
>      :|||:      :|||:           Internet Commerce
>  ..:|||||||:..:|||||||:..       (Ph) 408-853-8475
>     Cisco  Systems Inc          ksankar@cisco.com
> ----------------------------------------------------------
> "Failure is certain if we don't,
>            but Success is uncertain even when we do.
>                          So the choice is Ours, always..."
> ----------------------------------------------------------
> 


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/