Hi all, One of the points that has been raised during the first interactions of the FI-PPP Architecture Board (AB) has to do with trying to find a precise definition of what would fall in and out of the scope of the discussions that should take place within that body. Please review the attached mail sent by Andreas Metzger as an example. During our last AB meeting, it was agreed that functional and non-functional features required on platform enablers will be compiled in a "FI-PPP AB backlog" to be reviewed by the AB. Required features will come from FI-WARE (we have to start compiling these features per chapter once we finish with our High-level Description deliverable) and from UC projects. While the former will be focused on Generic Enablers and therefore will be translated into features of the "FI-WARE backlog", inputs from the UC projects will require an analysis to distinguish between features on Generic Enablers (which would then go to the FI-WARE backlog) and features on enablers that would be categorized as "Specific Enablers" after the analysis (therefore, not going to the FI-WARE backlog). This is the reason why we distinguish between the FI-PPP AB backlog comprising all evaluated features on enablers and the FI-WARE backlog, comprising those features relevant to the FI-WARE project (a subset of the FI-PPP AB backlog). This is not an issue so far. However, the potential conflict may arise when discussing about priotization of features in the FI-WARE backlog since this prioritization would affect the development of our project. Note that there are three types of sources for requested features in the FI-WARE backlog: * UC projects * FI-WARE partners (based on what they believe or have certainty they can sell to their respective Business Units). * third parties I would like to come with a proposal I can share with members of the AB in the July 11-12 meeting, regarding how prioritization of feature requests in the FI-WARE backlog can be handled. Possibilities are (in theory): 1. the AB can only decide on relative prioritization of features in the FI-WARE backlog requested by UC projects. 2. the AB can only decide on relative prioritization of features in the FI-WARE backlog requested by UC projects and third parties. 3. State that the AB decides on prioritization of all features, including those setup by FI-WARE partners. In my honest opinion, we should go for 1, or even 2 because this is what is more realistic. FI-WARE GEs rely on several assets on which our respective companies are investing already and I guess they won't like to see their priorities ignored in favor of what UC projects may dictate. One thing we may say is 1, then explain that FI-WARE would assign a final prioritization when merging features identified by UC projects with features identified by FI-WARE on its own. We may explain that we would provide the rationale why those features identified by FI-WARE owners are assigned a higher priority in case this occurs. I guess we should also explain what we are going to do if no consensus about prioritization of features requested by UC projects is reached at the AB. I guess then that FI-WARE should arbitrate since it doesn't make sense that a given feature is not implemented if it can actually be done but just a few UC projects believe other features are more relevant. We may state that FI-WARE would take a decision taking into account the different inputs and sentiment of the majority of members of the AB. Your feedback is welcome. As I have explained, I would like to bring an agreed proposal to the July 11-12 meeting of the FI-PPP AB. Cheers, -- Juanjo -------- Original Message -------- Subject: RE: Minutes of Future Internet PPP Architecture Board in Budapest Date: Wed, 1 Jun 2011 11:12:11 +0200 From: Metzger, Andreas <Andreas.Metzger at sse.uni-due.de><mailto:Andreas.Metzger at sse.uni-due.de> To: Havlik Denis <Denis.Havlik at ait.ac.at><mailto:Denis.Havlik at ait.ac.at>, JUAN JOSE HIERRO SUREDA <jhierro at tid.es><mailto:jhierro at tid.es>, "Thierry.nagellen at orange-ftgroup.com"<mailto:Thierry.nagellen at orange-ftgroup.com> <Thierry.nagellen at orange-ftgroup.com><mailto:Thierry.nagellen at orange-ftgroup.com>, "kolja.eger at siemens.com"<mailto:kolja.eger at siemens.com> <kolja.eger at siemens.com><mailto:kolja.eger at siemens.com>, "werner.mohr at nsn.com"<mailto:werner.mohr at nsn.com> <werner.mohr at nsn.com><mailto:werner.mohr at nsn.com>, "denis.mischler at technicolor.com"<mailto:denis.mischler at technicolor.com> <denis.mischler at technicolor.com><mailto:denis.mischler at technicolor.com>, "slusallek at cs.uni-saarland.de"<mailto:slusallek at cs.uni-saarland.de> <slusallek at cs.uni-saarland.de><mailto:slusallek at cs.uni-saarland.de>, "Berre, Arne" <Arne.J.Berre at sintef.no><mailto:Arne.J.Berre at sintef.no>, "alonm at athenaiss.com"<mailto:alonm at athenaiss.com> <alonm at athenaiss.com><mailto:alonm at athenaiss.com>, "roberto.gavazzi at telecomitalia.it"<mailto:roberto.gavazzi at telecomitalia.it> <roberto.gavazzi at telecomitalia.it><mailto:roberto.gavazzi at telecomitalia.it>, "benoit.miscopein at orange-ftgroup.com"<mailto:benoit.miscopein at orange-ftgroup.com> <benoit.miscopein at orange-ftgroup.com><mailto:benoit.miscopein at orange-ftgroup.com>, "Adrie.Beulens at wur.nl"<mailto:Adrie.Beulens at wur.nl> <Adrie.Beulens at wur.nl><mailto:Adrie.Beulens at wur.nl>, "luigi.telesca at create-net.org"<mailto:luigi.telesca at create-net.org> <luigi.telesca at create-net.org><mailto:luigi.telesca at create-net.org>, "Bohnert, Thomas Michael" <thomas.michael.bohnert at sap.com><mailto:thomas.michael.bohnert at sap.com> CC: Susanna Avessta <susanna.avessta at tivit.fi><mailto:susanna.avessta at tivit.fi>, "pauli.kuosmanen at tivit.fi"<mailto:pauli.kuosmanen at tivit.fi> <pauli.kuosmanen at tivit.fi><mailto:pauli.kuosmanen at tivit.fi>, Jose Lorenzo Mon <jose.lorenzo at atosresearch.eu><mailto:jose.lorenzo at atosresearch.eu> Dear Juanjo and all, A follow-up / related question: Assuming that feature requests will also come from sources beyond the UC projects, would it be the responsibility of the ARB to also decide about those "external" feature requests or only about the ones from the UC projects? Thanks and best regards, Andreas -- Dr. Andreas Metzger Research group leader 'Software and Service Quality' Paluno (The Ruhr Institute for Software Technology) * University of Duisburg-Essen Gerlingstraße 16 * 45127 Essen * Germany * callto:+49-201-183-4650 * fax:+49-201-183-4699 mailto:andreas.metzger at paluno.uni-due.de * http://www.paluno.eu * VAT-Nr. DE811272995 -- > -----Original Message----- > From: Havlik Denis [mailto:Denis.Havlik at ait.ac.at] > Sent: Tuesday, May 31, 2011 6:50 PM > To: Juanjo Hierro; Metzger, Andreas; Thierry.nagellen at orange-ftgroup.com<mailto:Thierry.nagellen at orange-ftgroup.com>; > kolja.eger at siemens.com<mailto:kolja.eger at siemens.com>; werner.mohr at nsn.com<mailto:werner.mohr at nsn.com>; > denis.mischler at technicolor.com<mailto:denis.mischler at technicolor.com>; slusallek at cs.uni-saarland.de<mailto:slusallek at cs.uni-saarland.de>; Berre, Arne; > alonm at athenaiss.com<mailto:alonm at athenaiss.com>; roberto.gavazzi at telecomitalia.it<mailto:roberto.gavazzi at telecomitalia.it>; > benoit.miscopein at orange-ftgroup.com<mailto:benoit.miscopein at orange-ftgroup.com>; Adrie.Beulens at wur.nl<mailto:Adrie.Beulens at wur.nl>; > luigi.telesca at create-net.org<mailto:luigi.telesca at create-net.org>; Bohnert, Thomas Michael > Cc: Susanna Avessta; pauli.kuosmanen at tivit.fi<mailto:pauli.kuosmanen at tivit.fi>; Jose Lorenzo Mon > Subject: AW: Minutes of Future Internet PPP Architecture Board in Budapest > > Dear Juanjo, > > The notes reminded me on the discussion we had on relation between the > requirements coming from UC projects and the "open calls". The notes say: > > - Open calls to address definition and development of reference > implementations of GEs not covered by existing partners > - Request for features to be supported by GE will not only come from UC > projects > > I would like to have a clarification on the procedure that will be used to decide > which topics will go in open calls, and where are these additional requests "not > form UC projects" will be coming from. My understanding was that the open > calls were intended to assure the feature requests by UC projects not covered > by current FI-ware project plan get a chance for realization, but it seems that > this understanding is not shared by everyone. > > Kindest regards > Denis > > -----Ursprüngliche Nachricht----- > Von: Juanjo Hierro [mailto:jhierro at tid.es] > Gesendet: Montag, 30. Mai 2011 17:15 > An: Andreas.Metzger at sse.uni-due.de<mailto:Andreas.Metzger at sse.uni-due.de>; Thierry.nagellen at orange-ftgroup.com<mailto:Thierry.nagellen at orange-ftgroup.com>; > kolja.eger at siemens.com<mailto:kolja.eger at siemens.com>; werner.mohr at nsn.com<mailto:werner.mohr at nsn.com>; > denis.mischler at technicolor.com<mailto:denis.mischler at technicolor.com>; slusallek at cs.uni-saarland.de<mailto:slusallek at cs.uni-saarland.de>; Havlik Denis; > Arne.J.Berre at sintef.no<mailto:Arne.J.Berre at sintef.no>; alonm at athenaiss.com<mailto:alonm at athenaiss.com>; > roberto.gavazzi at telecomitalia.it<mailto:roberto.gavazzi at telecomitalia.it>; benoit.miscopein at orange-ftgroup.com<mailto:benoit.miscopein at orange-ftgroup.com>; > Adrie.Beulens at wur.nl<mailto:Adrie.Beulens at wur.nl>; luigi.telesca at create-net.org<mailto:luigi.telesca at create-net.org>; Bohnert, Thomas Michael > Cc: Susanna Avessta; pauli.kuosmanen at tivit.fi<mailto:pauli.kuosmanen at tivit.fi>; jhierro >> "Juan J. Hierro" > Betreff: Minutes of Future Internet PPP Architecture Board in Budapest > > Dear colleagues, > > Please find enclosed the minutes of our AB (Architecture Board) meeting in > Budapest. > > Don't hesitate to provide any comment/feedback or raise any point we didn't > capture in the minutes. > > Following this email, I will send you the excerpt from the FI-WARE DoW which > provides an accurate definition of very basic terms and concepts related to FI- > WARE. > > Also following this email, I will send to you the two presentations I > made. One of them containing the very initial proposal on fields to be > considered for entries in the FI-WARE product backlog. > > Hopefully, we will soon decide on the collaborative tools that we > will use for further exchange of information. This was an action point > on CONCORD and FI-WARE. > > Best regards, > > Juanjo Hierro > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra > política de envío y recepción de correo electrónico en el enlace situado más > abajo. > This message is intended exclusively for its addressee. We only send and receive > email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx . ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-pcc/attachments/20110628/fdf267d9/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-pcc/attachments/20110628/fdf267d9/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy