The economic sense of off-the-shelf Puppet modules

The economic sense of Puppet In 2013, Simon Wardley started his writings about mapping. This technique allows us to discuss and predict to a certain sense what will be happening in the marketplace. In this blog post, we are going to use Wardley Mapping to look at some of the developments that are taking place within the Puppet ecosystem.

Short description of Wardley Mapping

A Wardley map always starts with the users needs. This is the thing that represents the actual value for the user. We put this at the top. But before the user can deliver this, there are certain requirements that need to be met. We place these below the users needs and get a chain of elements that are required before we can deliver the requested value. Here is a simplified value chain for an application.

Simplified Value chain

In this example, the application is the thing the user really needs. You can debate that the application is also a means to an end, but for this example, we can use the application on top of the value chain.

Before the application can produce value for the user, It needs to be developed. To run the application, we need an ICT infrastructure (e.g., the hardware) to run the applications on. The platform is the OS, database and middleware software that is required to run the specific application. To keep the system up and running, we need an operations department.

Evolution

Wardley noticed that components seemed to evolve in time.

Simon Wardley: Patterns of evolution

Evolution shows how we start with the genesis of an activity (e.g. the first battery, the first phone, the first television, the first computer) and then how custom built examples are made, followed by a stage of product development (constantly improving generators, phones, televisions, computers), the introduction of rental models for the activity, commodity provision and finally (where appropriate) utility services for provision. We commonly use the term commoditization to describe this path of evolution.

All the components in our simplified value chain can be in different phases of evolution. If we put the evolutionary phases on the x-axis, we get the following picture.

Evolutionary Phases

The most of the components are custom build for the user. Only the ICT infrastructure is bought. Nowadays it is very uncommon to build your own computers.

Supply and demand competition

Wardley also noticed something else. Due to the supply and demand competition, all components in the map are evolving to the right. If you want to build a product that will distinguish itself from the competition, you had better try to be on the left side of the graph.

Supply and demand competitionn

In essence, only the application delivers value, and the components lower in the value chain are mere costs that need to be minimized.

Current situation.

If we look at the current state of this kind of value chain in large enterprises, we see the following graph.

Current situation

Most of the enterprise customers perform operations and platform construction themselves. For the development of software (not in the simplified graph), they decided, long ago, that using off-the-shelf products like Oracle databases and WebLogic middleware is beneficial, but for the infrastructure as code, they mostly still custom-build everything.

The shift to commodity through products

A shift to commodity starts to be possible when standardizations occur. A well-known example of this is electricity. When the plug and the voltages were standardized, electricity became a utility.

If we look at building platforms, in the last couple of years, many things have happened that slowly but surely lead to standardization.

  • Tools like Puppet, Chef, and Ansible have become widely accepted and used.
  • Libraries of common components, such as the Puppet Forge and the Chef Supermarket, have been filled with common infrastructure components.

Standard building blocks

The Puppet Ecosystem

In the Puppet ecosystem, we see this change happening. In the beginning, the Puppet language was just a neat language to describe your ICT platform. Everybody wrote the same code to get their platform up and running. The introduction of the Puppet forge has made reuse and standardization possible. Nowadays, it is almost silly to build your own module to manage NTP or DNS and not use one that is available on the forge.

Our Goal

We noticed that a lot of the components that were used in the large enterprises were not (yet) available as standardized modules. We built upon the changes that were already happening and decided to create high-quality modules to install and configure Oracle and WebLogic. We are also looking to expand our modules to include IBM DB2, IBM WebSphere, IBM MQ series, and Tibco. If you are interested in joining us as a launching customer for one of those modules, please contact us. We think that, with this portfolio, a large enterprise can make the shift and start to enjoy the advantages of Puppet.

What is next?

In a future blog post, we are going to use the Wardley map to discuss the options and challenges of enterprises that are moving into the cloud.

Comments