Formal proposal submission: BPSS

[Karsten Riemer - Sun IR Development <Karsten.Riemer@Sun.COM>]

To the chair of eBTWG:

Attached, please find my formal proposal for a BPSS project.

I understand there may be a parallel proposal being forwarded to you.
But I wanted to list the reasons why this proposal is preferable:

1. Degree of specificity in deliverables.

Since this is for a project under a temporary WG, and since there are no other 
specific charters governing such projects, I feel that the project proposal 
needs to be quite specific as to deliverables for the next year. In essence, the 
project proposal is the contract between UN/CEFACT and the people investing 
their time on the project.

2. Agressiveness of schedule.

Since it is unclear to me how new minor and major versions may be sanctioned for 
release under eBTWG, I wanted to clearly specify each release and make it clear 
that these releases must hit the market at an aggressive schedule to have any 
impact. They cannot wait for an annual plenary approval.

3. UN standard status.

Since I have not seen any action to deliver on the UN/CEFACT promise to 
fasttrack ebXML specifications to UN standard status, I wanted to make that a 
deliverable for the BPSS project. Who else would best champion the 
standardization than the writers of the standard?

4. Focus on runtime XML interoperability, not on modeling.

Since BPSS is a XML based specification of the runtime aspects of eBusiness 
Collaboration, it needs to be very well positioned with everything else that 
goes on in XML based eBusiness, particularly web services and other XML based 
process definition languages. This alignment is in fact more important to the 
relevance of BPSS in the marketplace than its alignment with UMM. This is why 
the proposal spells out a specific web service aligned release.

5. Focus on XML not on UML.

Since BPSS is an XML dialect, it is important that the people working on this 
project have a strong background in XML standards. Knowledge of UML is not a 
requirement for being on the BPSS project. In fact, I would recommend that the 
UML diagrams be removed from the current specification. They only lead to 
duplicate maintenance and opportunity for ambiguity.

6. Focus on software executability, not on business modeling.

Since BPSS deals with the runtime aspects of the collaboration, not with the 
modeling and design of the collaboration, it is important that the people 
working on this project have a good understanding of the envisioned 
collaboration software stack. Knowledge of Open-EDI, UMM, or modeling 
methodology is not a requirement from being on the BPSS project.

Concluding note:

Criticism was made of how in 1.0 BPSS diverged from the UMM model. I personally 
take that not as criticism, but as acknowledgement. It is essential to the 
survival of BPSS in the marketplace that it be flexible enough to go where the 
prevailing XML interoperability trends go, even if it means that the mapping to 
UMM becomes more indirect.

With this, I hereby respectfully submit to the eBTWG chair the proposal that I 
believe best benefits BPSS as a competitive XML based eBusiness Collaboration 
standard.

-Karsten

---------------------------------------------------
Karsten Riemer,
b2b Architect
XML Technology Center
Sun Microsystems Inc.,
MailStop UBUR02-201
1 Network Drive,
Burlington, MA 01803-0903

ph. 781-442-2679
fax 781-442-1437
e-mail karsten.riemer@sun.com

BPSS-NextGen-Proposal-01.rtf