One on one production

Developing service oriented architectures (SOA) is pretty much how we develop software nowadays. With a firm believe that delivering small increments on software every two weeks and doing some daily stand up's is a goal, they stall in the improvement kata. A kata is a japaneese way of doing something. Think about a kata in martial arts, they are practised until perfection. Work can be seen as a kata too. Besides doing daily chores over and over again, there is also a possibility to use a behaviour kata for improving. By improving behaviour all the work will be improved. What this means is that we actually don't want to use a pattern to do things the same way all the time, we need a pattern to improve all the time and with that improve the work we do.

If we would stuck on the SOA implementation we can build a huge monolith application which we can release every two weeks. But what now if we have a target condition of delivering software throughout the day, up to perhaps ten times. A monolith would be very hard to push to production ten times a day. We should learn to improve each iteration with a goal of one on one production. If we would create one on one production it would be possible to release all day, any day. By creating small standalone services we would be able to release when we want, the only thing to keep in mind here is contract nagotiation. We should define an interface and stick to it, hence we need a versioning system (may I propose semver here?), a dedicated pipeline and knowledge of who our consumers are. By doing this we create owners of the service, a PO, a team and so on who really care about their product.

Creating one on one production might stand in the way we think about flexible processes. These are processen capable of doing more than one thing. Flexibility in processes might seem like a good idea. This makes it possible to work around problems that arise during processing and this will guarantee to meet the delivery dead line. There are many variables in the production pipeline to match all the demands any product needs to be produced. This sounds very flexible and therefor like an ulitmate solution. However, working around problems obfuscates the understanding of problems. Production is met with workarounds, but how are the core problems being identified and fixed? In a flexible system this is the hard part. Dedicating production pipelines and focussing on one on one production makes it possible to continuously improve the pipeline.

So for developing software from conception to deployment we should strive to one on one production, to continuously improve the way we work and practise a lot.