[Fiware-wpl] Thoughts and proposed action points from Educational Session Week

[Juanjo Hierro]

Hi all,

  These are my first thoughts and proposed action points based on experience during this educational sessions week, as an input to our confcall tomorrow.

  First my impressions:

  *   UC projects exhibit different level of progress.   Regarding Architecture Design of their solutions, some of them are still in a very high-level.
  *   There are some cases where it is clear that the FI-WARE GEs nicely fit in the proposed Architecture.   This was rather clear in InstantMobility and Oustmart (though the described architecture was rather high-level).  Also in Finseny to some extend
  *   The educational session have been useful to improve the understanding by attendees from UC projects.   Now they realize that there is concrete stuff to analyze.
  *   There is a common agreement that the communication hasn't been very much productive so far because there was no real stuff to discuss about from neither of the two sides:
     *   FI-WARE hadn't produce the Architecture Description nor the Open Specifications so therefore UC projects could not refine very much their requests on features to be supported by FI-WARE GEs
     *   UC projects hadn't produce Architecture Deliverables we could inspect to point out areas where mapping between enablers identified by UC projects and FI-WARE GEs have to be investigated
     *   now, we have this stuff in both side so that is the time to push from both sides
  *   Some UC projects claimed that some sessions run parallel so they couldn't attend both.   Don't know whether we can find a solution for this.
  *   More attendance on those sessions linked to FI-WARE GEs that provide APIs that UC programmers have to use (Apps, IoT, Data/Context and Security chapters)

  Then, the actions I believe we have to carry out and propose:

  *   Action-1: We have to officially ask all UC projects to share any documentation they may have regarding their Architecture, and do it inmediately.
  *   Action-2: We have to document and be able to monitor progress of our communication, so using a tracker system is still the right thing to do.   However, we have to decide which one (or define a new one).   My proposal would be not to use the "FI-WARE Theme/Epic/Feature Requests" but the "FI-WARE General Support" tracker because it will more agile.   Use of the tracker would be bidirectional, so that we can open tickets on UC projects.
  *   Action-3: Each FI-WARE chapter should carefully study the Architecture documentation by UC projects (available after Action-1) to find the places where they believe there is an opportunity of using FI-WARE GEs that should be explored, then open the proper tickets on the UC projects to launch the discussion.   Note that discussion doesn't need then to be carried out always off-line.   Chapters should be ready to setup confcalls, f2f meetings, whatever when necessary.
  *   Action-4: We will re-inforce the role of the dedicated team (in this case, Carlos and Axel) that has to push Action-3 first, and then follow-up progress and push communication afterwards.    Creation of a dashboard that allows us to monitor progress will be key.
  *   Action-5: Communication between the UC projects and the FI-WARE chapters may lead to the need to support new features in existing FI-WARE GEs, define new FI-WARE GEs, etc.   These case should lead to creation of a ticket in the "FI-WARE Theme/Epic/Feature Requests" backlog but, this time, the description of what is required will be much more concrete and well understood from both sides

  Last but not least, some reflections regarding usage of the tracker:

  *   I don't know if you agree, but the presentation by people from InstantMobility was probably the best one from the UC projects, among other things because you could see this guy was a rather technical person.   After the meeting, I had the opportunity to talk with him and he told me that he though that a tracker was what programmers like to use and only people who deals with paperwork hate them.   I tend to agree.   It is not the tracker what may fail but the people who is around who has to commit in doing the work
  *   We need to document things for the reviews, like it or not.   The tracker will allow us to do this without problems.
  *   We need to be able to monitor progress in order to detect when things are malfunctioning and put remedy actions.   You need something like a tracker to do that as well.
  *   Even most important than the previous: we should not forget that FI-WARE will be extended so that may app developers will try to use it after year 2.   And there, on-line communication is not going to scale (despite we may organize events like the "Programmers' Days" and stuff like that).   We have to formalize a process and accompany them with toos, using phase 1 and first part of Phase 2 of the FI-PPP to test them (taking advantage there will be a limited number of projects then)

  Your own feedback/comment is welcome.


-- Juanjo

-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Chief Architect

You can follow FI-WARE at:
  website:  http://www.fi-ware.eu
  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
  twitter:  http://twitter.com/FIware
  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932


________________________________

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-wpl/attachments/20120524/9aedd090/attachment.html>