Review of a Single Point of Truth based Deployment Week for FIWARE

Dear colleagues, dear Phase3 teams,

in the following I would like to share some background insights and collaborative successes of a recent 2 weeks time frame where I aligned on, scheduled and hold seven online communication slots for group deployment work.

The setup of this delivery business process model inherits some concepts from the model used by the Release Steering Committee Board to which I daily reported 2012 during my time at VHA, where the release responsible team sat day by day many hours in same room. They had a big dashboard with open critical issues and many 15 min slots for delegated dev team managers to come in, stand there and explain what is the status of their deliverables. I was one of these poor fellows sweating in front of them! Well, this was a very complex rollout of a vast enterprise telecom-IT landscape, consisting of many interlinked products. Hard and stressful, but in my opinion a necessary and unavoidable routine in large distributed teams carrying out a business-critical mission, I would say.

Back to present, namely in our FIWARE case, we have got series of components which are of course interdependent but in many cases can be run in a stand-alone environment, which makes our lives much simpler.

So, during these seven communication slots mentioned above I presented the FIC2Lab’s quality pipeline to our Accelerator’s Phase3 teams and instructed them where to start and what to do in order to make their first experiences with FIWARE software. (Preliminary information, tech support contacts information and manuals had been distributed already during Welcome Days as a „CTO Welcome Sheet“). Teams got homework to assess the maturity status of the deployment-helping artefacts available along the Enablers, and where needed, implement a Dockerfile and/or a basic smoke test.

The results were as expected – some teams were fast enough to make their contributions creating a quite disruptive competition feeling for other teams, because those other teams got on one hand an easier access to components already improved by their peers, but on the other hand they faced the challenge to step up in the task complexity to tackle on more advanced excellence improvements.

Well – we all stand on shoulders of some disruptive giants – don’t we?

So let’s step up and make more software of this world having a measurable shiny and green A+++ (A triple plus) level of technical excellence!

(contributed by Peter)

Leave a Reply

Your email address will not be published. Required fields are marked *