Rethink Industry 4.0: Lessons learned after 3 years of Industry 4.0 experience

Back in 2013 when I started at IBM and I first heard about the topic of Industry 4.0 I was enthusiastic about the vision of a new industrial revolution. I had not much background in production, but I believed that the manufacturing industry was 20 years behind what IT guys like me do. What are Daimler, VW and BMW compared to Google, Netflix and Amazon? The one push new versions of their products weekly, the others yearly. Internet companies are agile and pivot, while production companies are six sigma, process focused. The internet companies have a return on invest much higher than any production companies. So the first conclusion was simple let us take the IT technology that made the Googles, Netflix, Amazons and Facebooks (the GNAFs) so successful and push it into production companies. Did this work? It did not. But why, the assumptions of a young industry entry like me were wrong. Where were I wrong?

  • It is not about technology it is about processes.
  • The reason the GNAFs are so successful is not technology but culture, automation and agility.

There were many more things I was wrong about, like the level of technology maturity production companies have reached, they are by far NOT 20 years behind! But all those are details compared to the two main misunderstandings above.
Was I the only one that was wrong? No I still see us pushing for IT solutions that go for technology but not the key reasons why the role models in the internet age are so successful. How can we expect german production companies become the GNAFs or better Apple’s of the production industry if we offer them technologies that are not used by the GNAFs because they do not fit their culture and hinder innovation and agility. You don’t think we do offer this to companies?

Well look at every Industry 4.0 reference architecture, it is a heavy layered combination of systems, from with most of them are not agile, not open and have release cycles of years. Then they have propriartary APIs, the need for month and years of consultancy to implement, they are complex and they hinder by there licensing models the design of resilient/antifragile architecture. This list goes on!

The key to be innovative and efficient like the GNAFs is to have agile process and software. Don’t built systems that can not innovate daily! You say the internet is something else than you have, that was what Kodak and many companies said: And they are out of business today, because someone thought, it is not something else and made the effort to prove it and make it work. So I urge us to rethink how our Industry 4.0 architectures, strategies and products look. And go for the lean approach. But let’s start with the most important thing first, agile culture: Let us not go back to the drawing board and rethink and design for a year how our agile culture, products and industry 4.0 vision looks: let’s start now doing it.

Leave me a comment or discuss with me on twitter @smaterindustry. What is your opinion, where am I wrong? Let’s discuss and bring Industry 4.0 forward!

Future articles will continue this one in the following weeks:

  • API Industry 4.0: A hypothesis put to the test as a starting point to implement this kind of Industry 4.0. This is not something new or revolutionary, it just something to try. Let’s start failing fast, learn and improve.
  • Role models: Where Germany manufacturing companies should look to “borrow” for their Industry 4.0 strategy
  • The german tragedy: What happens if we can change our culture

Contribution to Blogparade: #Blogparade zum Thema „Industrie 4.0: Chancen, Risiken, Ideen und Umsetzungen – was hat Deutschland zu bieten?”

My tooling: Text Editor of choice for javascript and python

I normally use vi as my favorite text editor. This can be in terminal or in
MacVIM. But because I looked for a good editor with mutli OS support I tried
Atom. And I was suprised I really liked the workflow and sepecially the Markdown
Support. I know there is a vi on Windows but the compatibility of your setup is

So I looked in the internet for interesting article about transitioning from vi
to atom. And found the following:


And an intersting article why this is not a good idea:


I will continue to let your participate in my journey. I will still open my vi
especially if I am in Terminal. But for I hope to find a good replacement for my

To be continued …

Use Java 8 on Bluemix: How to use a custom buildpack

The default java runtime is the ibm provides liberty profile. Which has very good additional features that increase performance, but is currently (May, 2015) still on Java 7. So when you want to use Java 8 features in your application you just have to deploy a customer build pack which is not more then to a just the manifest.yml file in the root directory of your application. And there you have to change the line with the buildpack: to The result should look something like this.

buildpack bluemix java 8

Setting up your MEAN.js Develeoper Environment with Vagrant, Chef and Berkshelf

First you have to get started developing your Infrastructure Environment. An Up to Date Guide can be found at The following procedure will get your local workstation configured and ready to develop cookbooks with Test Kitchen, Vagrant and Chef-zero. Note that this is not a tutorial on how to write cookbooks.

This is just a short discription on the progress I made and not complete. Since I switch from the MEAN.js stack to the jHistper Stack (Java (Spring) in the Backend, AngularJS and Bootstrap in the Frontend, and a variety of databases) I won't continue this. Hope this still helps someone.

The Tools

Vagrant – We use Vagrant and Virtualbox to test our cookbook code and run our tests on our local workstations. The creator of Vagrant wrote the definitive guide for us all.

Test Kitchen – Test Kitchen is the tool we use to manage our Vagrant configurations, configure our environment to mirror Production in a meaningful way and run our tests.

Chef-Zero – Chef-Zero is a lightweight local Chef Server that our testing VMs use to mimic our live Chef environment.

ChefDK – The Chef Development Kit provided by Opscode bundles various Chef tools together. The beauty of ChefDK is that it comes with an embedded Ruby environment and the necessary Ruby Gems required by the tools. This is a great improvement if you’ve ever had to deal with pre-ChefDK local Ruby/RVM configurations, fluctuating gem dependancies and breaking changes between tools.

Getting Vagrant, ChefDK and Tools

ChefDK Installation

First, download and install ChefDK from ChefDK comes with chef-client, Berkshelf, Test Kitchen, ChefSpec, Foodcritic and more.

Vagrant Installation and Configuration

Next, install Vagrant. Head over to and download and install the appropriate package for your system.

Once you have Vagrant installed you’ll run the following commands in your (bash) shell to install the supporting plug-ins that we need to integrate Vagrant and Chef.

vagrant plugin install vagrant-berkshelf
vagrant plugin install vagrant-omnibus
vagrant plugin install vagrant-chef-zero
vagrant plugin install vagrant-vbguest

After installing these, you should logout of your shell and relaunch it to pickup the new environment variables.

Virtualbox Installation and Setup

Next, download and install VirtualBox from

Follow the directions for your platform but skip the VMWare portion and go to the Test Your Setup section below if you’ve opted to use Virtualbox.

Alternately, VMWare installation and Setup

(only do this if you use VMWare rather than Virtualbox)

Download and install VMWare from the web site and have your Vagrant VMWare license handy. You need to purchase the Vagrant VMWare integration license from HashiCorp (the company that makes Vagrant).

Copy your Vagrant VMWare license to ~/.vagrant.d/vmware-license.lic then follow the steps for your specific setup:

For VMWare Workstation, add the following to your ~/.bashrc file ( or ~/.bash_profile on OS X):

export VAGRANT_DEFAULT_PROVIDER=vmware_workstation

Then run:

vagrant plugin install vagrant-vmware-workstation
vagrant plugin license vagrant-vmware-workstation ~/.vagrant.d/vmware-license.lic

For VMWare Fusion, add the following to your ~/.bashrc file ( or ~/.bash_profile on OS X):

export VAGRANT_DEFAULT_PROVIDER=vmware_workstation

Then run:

vagrant plugin install vagrant-vmware-workstation
vagrant plugin license vagrant-vmware-workstation ~/.vagrant.d/vmware-license.lic

lly, everyone using VMWare should reboot their machine and launch VMWare for the first time, accepting the license agreement and allowing it to initialize itself once. Do this before running Vagrant. FYI: Vagrant has plans to consolidate Fusion and Workstation at some point in the near future.

Finally, everyone using VMWare should reboot their machine and launch VMWare for the first time, accepting the license agreement and allowing it to initialize itself once. Do this before running Vagrant. FYI: Vagrant has plans to consolidate Fusion and Workstation at some point in the near future.

Prepare Chef Tools

As you work more with Chef, you will eventually run into repositories that depend on Chef recipes that require your a broad range of tools to be available and configured on your workstation. Run through the following steps now so they are available when you need them.

Configure Knife

(do this only if you don’t have a knife configuration already)
Setup Knife and accept the defaults:

knife configure

You must place your validation key in the following location before generating instance data with Knife:


Create .pem File

Create a .pem for Chef Zero to use when faking Chef server for local configuration.

openssl genrsa 2048 > ~/.chef/<username from knife configure>.pem

Test Your New Setup

You should now create a temporary directory locally for Vagrant VMs and then test that you can create a new Vagrant project. There are many GitHub projects with Vagrant file templates. I recommend that you read up on Vagrant and create your own simple configuration file but if you want to test you can use the one in the next step.

Create an empty directory (~/vagrant_vm, say) for the configuration. This location will contain a Vagrantfile and will eventually contain the running VM as well.

you@workstation$ mkdir ~/vagrant_vm
you@workstation$ cd ~/vagrant_vm

Preparing your Vagrantfile

Copy a Vagrant file from a GitHub repo that suits you and put it in a new file called Vagrantfile in the ~/vagrant_vm directory. (You must name the file Vagrantfile. You cannot always leave it the same name as it is in GitHub.) You can find some generic Vagrantfile examples and the ssh key for the images here:

Or you can use the example one below:

#Quick vagrant file for testing
# do |config| = 'precise32'
  config.vm.box_url = ''

Using the Virtual Machine

Next, launch the VM from the ~/vagrant_vm directory using vagrant up:

you@workstation$ vagrant up

There will be lots of output and once the machine has booted you can ssh to it.

you@workstation$ vagrant ssh

Vagrant exports ~/vagrant_vm from your local your local machine to the VM. Check that you see the the Vagrantfile and .vagrant directories in the VM by running:

sbo@linux:~$ ls -la /vagrant
total 16drwxrwxr-x  1 sbo  sbo  4096 Oct 10 16:03 .
drwxr-xr-x 23 root root 4096 Oct 10 16:05 ..
drwxrwxr-x  1 sbo  sbo  4096 Oct 10 13:56 .vagrant
-rw-r--r--  1 sbo  sbo  1150 Oct 10 16:03 Vagrantfile

Exit from the VM

sbo@linux:~$ exit


Authoring a Cookbook

Each of the individual parts is now installed and shown to work. So lets configure a machine using chef. To do this we will:

  • Write a cookbook to install some of our favorite packages that should be on every machine
  • Run Foodcritic

Scaffolding a Cookbook with Berkshelf

Berkshelf is the “package manager” for Chef cookbooks. It is also the standard way to scaffold a cookbook with ChefDK.

Generate a Berksfile in a pre-existing cookbook
$ cd cookbooks
$ berks init .

New Place API by Google #APIEconomy

Google has launched its Places API for Android and opened a beta program for it on iOS today. It will allow developers to add better location pickers to their apps, so users can specify where they are with real place names instead of latitudes and longitudes.

In addition, it also allows users to add new places to Google’s database of more than 100 million locations.

Google’s Places API and associated JavaScript library has been available for Web apps for some time now, but the new APIs will help developers easily add their functionality into native mobile apps.

You can hop over to this Google Developers site to find documentation, code samples and demos for the Android API, or sign up for iOS public beta on this page.

Mobile Design for the Apple Smart Watch – A Todo App

Apple gave Developers the chance to and guidelines to have their app ready for the Apple Watch. This show how Apple wants their Smart Watch App to look like. In this case Todoist developed almost a complete version of their todo app witch follower the apple guidelines:

[blockquote author=”Apple” link=”” style=”” target=”_blank”]The apps themselves should not be very complicated or feature-heavy. Instead, they should focus on conveying the most, and most relevant information possible given the limited screen real estate, and for a to-do app, it makes sense that those limits would result in a lot of nested lists.[/blockquote]

I think this is a good advice and will consider this for my own smart watch apps either for iOS or Android.