Process as code

1 minute read

Over the past year, my team has been developing a process to link dozens of different business functions together. The goal is to see that every group is invoked as and when they’re needed, supplied with all of the right inputs, and allowed time to make their value contribution before handing off to the next step in the process.

Once built and stabilized, this systematic ‘machine’ will stamp out instances with increasing consistency and quality, and the business will have ample control and insight to tune the performance of the overall system. It’s a massive act of choreography, but there is a lot of invention required too - we need documents, templates, control gates, governance systems, prioritization schemes, resource management etc - all of the elements that bring a process to life, and make it tangible and concrete.

It strikes me that this sounds a lot like software development. Good software design brings not only a certain order to things, but it manages information as it flows through the system, calls subroutines or system functions with the right parameters to invoke some required operation, and uses the results for the next logical operation - all in service to some greater end-user goal. Each function may operate in isolation while contributing to the larger system. The programmer can instrument the code to provide useful performance and tuning data, which can help improve the performance of future iterations of the software.

So, what can we draw from this insight? In the DevOps space, I wonder if the process-heavy Ops folks could get some “cred” with the coders by describing their processes in software design terms. For process design, I wonder if the principles and techniques of software design could help us build more robust, reusable and efficient processes?

In any case, my mental map of this big process we’re building is improved when I think about it in code. I’m not sure why, but I’m going to work with it for a bit and see what happens.

Comments