AW: PEPPOL's support for SMEs

[<Susanne.Wigard@it.nrw.de>]

Dear Kenneth,

 

Good to hear the e-CODEX presentation was useful, I felt somewhat insecure about what is interesting to this group and what isn't. What I'd like to do at some later point in time, maybe in a few weeks, is elaborate a bit more on the particulars of our discovery requirements.

Also if ever it fits, I would find it interesting to discuss the differences between uses cases that involve some human processing vs. direct EDI application integration.

 

The 4-corner-drawing I've not only seen but also quoted in our own e-Delivery document ;)

 

Thank you for your clarification on SME support - if that's basically about not assuming any specific capabilities on the 1st and 4th corner, that would in e-CODEX again map to subsidiarity - existing national systems remain untouched, whatever they may be (and whatever their technical maturity).  

However, there seems to be some small difference: where in PEPPOL SMEs can rely on a (commercial) service provider, e-CODEX gateways will be run by governments (ministries of justice), and so they will for their own country define minimum requirements to connect to that gateway.

In some countries as far as I know the national "Registered Email" solutions are in fact commercial, but these service providers don't run their own e-CODEX gateways, but will be connected to the one of their country.  

Somewhat confusingly, what we call "service providers" are the technical systems connected to the gateways, so these sit rather on the 1st and 4th corner.

The agreements between the entities running the gateways (that correspond to the PEPPOL agreements) are the basis of what we call the "Circle of Trust" (the legal details of which are still in the making).

Similar to PEPPOL, we also standardize only what's between the 2nd and 3rd corner; how end entities communicate with the gateways is up to the Member States. (We do have defined a backend interface for the "default" implementation we provide for our partners, however in principle countries can change / replace that backend interface or use an altogether different implementation, as long as it communicates with the other e-CODEX gateways via the standardized (ebMS) protocol.)

In fact, we can probably learn a lot from PEPPOL in terms of interoperability agreements.   

 

What corresponds to PEPPOL's service providers, catering for different needs of different user groups, are for e-CODEX the ministries, catering for the needs of their judicial IT infrastructures.

 

We're not so much concerned about demand and supply - it's governments that decide they have a demand for cross-border e-Justice, and who then decide to run an e-CODEX gateway (and by joining the project as a piloting country, they have already implicitly made that decision).

 

So in sum you are right that this requirement maps not so much to ours of avoiding proprietary infrastructures, but to the one already mentioned, that (where you have no requirements for SMEs) we have no requirements for the national systems (e.g. case management systems) nor to how they are connected to the e-CODEX gateways (e.g. .some secure national transport infrastructure, or, in the extreme case, gmail).

Thank you for pointing this out.

 

Regarding your last remark, that you "see that a similar structure can support your use case for connecting judicial authorities" let me just mention that we view the citizens’ communication via the European e-Justice portal just as a special case of this - in fact the e-Justice portal wants to connect to the e-CODEX infrastructure through e-Trustex, very much like e-Trustex is connected to PEPPOL.

 

Best regards

 

Susanne

 

 

---

Von: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] Im Auftrag von Kenneth Bengtsson
Gesendet: Donnerstag, 17. Mai 2012 02:07
An: bdxr@lists.oasis-open.org
Betreff: [bdxr] PEPPOL's support for SMEs

Dear Susanne

Thank you very much for your interesting presentation today. I actually learned something and now understands e-CODEX somewhat better (I think) :-)

I'm attaching the PEPPOL 4-corner drawing that I know you've already seen a million times, but just as a visual aid to help me elaborate on how PEPPOL supports SMEs:

The "private company" in the drawing can be any company who supplies to public sector in Europe. It may be a medium sized or a large company who already does EDI and is well-equipped to implement new standards and procedures, but it may also be a one-man company whose technical capabilities are limited to the use of Gmail. The last example may be a bit extreme, but the point is that PEPPOL cannot assume any capabilities or assign any technical responsibilities to the "1st and 4th corner" of the infrastructure.

Instead the responsibilities are placed on the shoulders of the "2nd and 3rd corners" - the service providers (acting as intermediaries):

First of all, service providers required to comply with a set of technical standards and specifications, assuring that every service provider connecting to PEPPOL is able to exchange documents with every other service provider connecting to PEPPOL.

Secondly, the service provider is required to sign an agreement with PEPPOL that obligates him to perform certain functions and to provide a certain level of service. This agreement covers (among other things) an obligation to receive messages to his end-users sent through any other service provider in the PEPPOL infrastructure, and to make sure these messages (if compliant with PEPPOL requirements) are delivered all the way to the end-user. The agreement also covers that the service provider must accept messages from his end-users intended for any other end-user of the infrastructure, and that he must deliver these message to the service provider of the recipient in a manner compliant with PEPPOL requirements and specifications. The PEPPOL service provider agreement does not cover how service providers must interact with their end-users, only that they must relay message to and from their end-users. In other words, it is only the message exchange between the 2nd and the 3rd corner that is standardized in PEPPOL.

The theory here is that where there is a demand there will also be a supply. Where there are companies who want to fully integrate their ERP systems there will also be service providers offering to connect them, and where there are companies who think that Gmail is already a mouthful there will also be service providers who can cater for their needs. Because service providers are obligated to always relay messages between their end-users and other providers in the PEPPOL infrastructure, then every SME (as well as every large organization) has the freedom to choose the service provider that best matches their needs and capabilities, completely independent from what service is used by their trading partner.

In a way you can say that for PEPPOL, the "technical requirement derived from SME support" is that there are no technical requirements for SMEs. Only for their service providers. My take is that this differs a bit from the e-CODEX requirement of avoiding "expensive and proprietary infrastructures" - at least to my understanding but please put me back in my place if I am wrong. I can also see that a similar structure can support your use case for connecting judicial authorities.

Best regards,

Kenneth

From: <Susanne.Wigard@it.nrw.de>
Date: Monday, May 14, 2012 5:11 AM
To: <bdxr@lists.oasis-open.org>
Cc: <giorgia.lodi@digitpa.gov.it>, <Raia@digitpa.gov.it>
Subject: [bdxr] e-CODEX use cases and requirements

Dear TC,

 

Please find attached a first impression of the use cases and requirements from the e-CODEX project (www.e-codex.eu). Since the requirements are, at this level, very similar to the ones from PEPPOL, I have referenced Kenneth's presentation and added the e-CODEX viewpoint for better comparability.

 

Best regards

 

Susanne

 

 

--------------------------------------------------------------------- To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdxr-help@lists.oasis-open.org