Whoever split Development and Operations, probably put the wall between Business and IT as well.

Living in an isolated SAP world for the last 15 years I became oblivious to the typical problems of custom software development and largely missed DevOps movement. Re-listening to “Phoenix Project” I reminded myself again how much time in the past we were spending on non-value add tasks such as: source code management, code deployment, releasing, etc. Most SAP projects still miss on embedded automated testing, but this is probably one of the last barriers to DevOps practice that is left within SAP world. The other six: coding, building, packaging, releasing, configuring, and monitoring, were part of SAP platform from the earliest days of SAP and substantially improved through the years. In cloud SAP deployment enables us today to scale up or down the system pretty much indefinitely. Some companies, being so engraved on separating Development from Operations, did not even understand the beauty of SAP continuous delivery model and outsourced SAP Operations right after the deployment. In this article I will not talk about a mistake of splitting Development and Operations of SAP into two separate functions. There are plenty of information out there that summarizes the benefits of constant fine-tuning of any deployed software and SAP specifically. I am a vivid proponent of keeping SAP support in-house and using it as a strong competitive advantage. In this article I will focus on a much bigger mistake we are keep doing – building the wall between the Business and IT.

The learning or improvement zone lies between the easy zone of things that you are comfortable doing today, and the impossible zone of things that you cannot do no matter how much you will keep trying. Good teacher first finds and then keeps constantly moving the learning zone based on the progress of the student and therefore we all need, and should look for, a good teacher all our lives. Most famous speeches and actions of good leaders from Kennedy’s audacious speech about the landing on the moon within a decade to Jobs fantastic device inventions, while looked far-fetched to an uneducated eye, were based on well-understood and pragmatically calculated facts and mostly fell into the possible zone. Most of us cannot keep thinking for 40+ years and then keep working for 7 years non-stop like Andrew Wiles did to achieve a goal. I would argue that outside of academic world, 12-18 months is probably a sweet spot for the most of the practical solutions if not to be completely designed and deployed, then at least to be able to see some kind of progress in order to keep people working on it motivated.

With all the complexities of the last theorem of Fermat lingering around without a proof for 350 years, Andrew had one advantage today’s business leaders do not have – the result was well known. The business model of today is built around tries and errors and, in most cases, we execute a dozen different activities hoping than one or two of them will stick and bring an improvement we are looking for. It means that at the core of today’s business model, as well as at the core of Agile movements like SCRUM, lies the value to cost proposition that must be constantly evaluated. It means that Business “owning” the requirements and IT “executing” them will not work. There is no “business lead and IT enabled” or whatever other similar slogan we came up with trying to keep both partners engaged. In the future both partners will work side-by-side as two equal partners both shaping requirements and, what is really important, constantly shifting the learning zone to the vanguard of the recent business and technology developments. Who owns “it” will probably depend on the industry, company, and the individuals involved. But one thing is certain – similarly to the insanity of the idea of separating Development and Operations in the past, we will look at the separation of Business and IT in a similar way very soon in the future. Should we start a BuIT (pronounced “beauty”) movement now?