Revealing* the German plan on the future “Industry 4.0” – part 1/3: terminology

Dear SIGSPL community and friends,

as you know, in our Special Interest Group we deal with the idea of how SPL – Software Production Lines – might look like in near future. From the business analysis point of view, we work on modeling the corresponding domain specific Value Chain.

We acknowledge findings by the classical mass production industry, like Lean Manufacturing (understood as Agile/Lean IT) or SCM, Supply Chain Management (being adopted as well). Learning from the industry is a very exciting and challenging process!

To address the challenges of this learning process in a more systematic way, we propose to become more conscious in utilizing the domain language and terminology from recent findings in industrial research to make interdisciplinary work and knowledge exchange easier.

In this article series, we start moving in this direction by undertaking the following steps, and warmly invite readers and influencers to discuss for better alignment between many experts and thoght leaders:

  • assess the term industrial revolution and look at it from the Software Engineering point of view (part 1);
  • review current plans and activities of the German government towards igniting the 4th industrial revolution (part 2);
  • identify and transfer useful core ideas of the Industry 4.0 domain to the domain of Software Engineering (part 3).

So what is the 4th industrial revolution?

The official known usage of this term originates from a high-tech strategy project by the German government back 2011, aimed to promote computerization of manufacturing. According Wikipedia, Industry 4.0 is a “collective term embracing a number of contemporary automation, data exchange and manufacturing technologies”.

Terms “computerization” and “data exchange” imply that chances are big that some software also plays a role behind the scenes. The most amazing thing about the modern (prior to the rising DevOps era) software engineering however is that at physical level it introduces many manual workflows, which are required to move and assemble all sorts of digital artefacts along the value chain towards the ready product. In the latest management speak, the business processes in software engineering teams introduce a very low level of digitalization – ironic as our Universe actually is!

Continue reading Revealing* the German plan on the future “Industry 4.0” – part 1/3: terminology

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)