This story starts when I was in my early 20s. I had received my Master's degree the previous year. I was still conducting my PhD research in Enterprise Architecture at that time but decided that doing full-time scientific research wasn't for me. So, I decided to look for a management consulting job, and I got the opportunity to start as a junior consultant at the enterprise architecture practice of a large consulting firm. I had heard about the complexity and challenges of large enterprises and the inefficiencies that resulted from that. I was convinced I was going to change the corporate world and help enterprises become smooth-running machines that were super-efficient and effective.

Fast forward 10 years. After having seen numerous large organizations from the inside … after having seen how their business processes were quite chaotic, full of ambiguities, and misaligned across departments … after having seen many different complex IT landscapes of applications knotted together by spaghetti interfaces with data inconsistencies popping up everywhere, my naive dream of helping large enterprises become smooth-running machines had totally slipped away. I was at a cross-point in my career. Should I stop beating this dead horse altogether? Should I reeducate myself and make a career switch? But what about all the experience I had built up over the years? And what happened with all these ambitious ideas I had, just coming out of university? Can't we (the enterprise architecture community) do any better than this?

Around that time, I was head of Enterprise Architecture for Schiphol airport. That sounds like a full-time management job (which it actually was). But I had always said that I wanted to keep doing 'real' work, and I was guiding a long-running project where the airport had to integrate their operational flight information with that of the Dutch air traffic control and with KLM as the main airline.

This project had been running for almost 10 years, and they were still struggling to get the integration to work. However, what they were approaching as a technical integration felt for me much more like a business integration. The three (totally different) organizations had been working alongside each other for almost 100 years, but never got to the point where they operationally shared their flight information so that they could together manage flights efficiently as one smooth operation. For instance, they had multiple different interpretations and times for the quite tangible and observable event of the 'off-block' moment right before 'push-back'.

This is where my intuition started to tell me the solution for this project did not lie in technology but rather in people sitting together to create a clear business language.

Because I had nothing to lose, I started pushing for assembling a dedicated team of business experts from the three organizations. And I selected SBVR as the way to write down a shared business vocabulary. Not only that, we also wrote down all the business process steps of flight operations, along with how they are connected. We also wrote down the conditions under which certain actions need to take place. We even dissected the term 'flight' — under much protest of the experts. "We don't need to discuss what a flight means! We are handling flights for almost a hundred years now. We know what we are talking about."

But I stood firm and insisted everyone give their definition. So, the expert from air traffic control said: "A flight is an aircraft movement to (inbound) or from (outbound) the airport." Then suddenly the expert of KLM said: "No way! A flight is a route of an aircraft from a starting airport (say, Los Angeles) to the end station (say, London) consisting of multiple flight legs (say, Los Angeles to Atlanta and Atlanta to London)." At that point I knew we were on to something!

We delivered an entire set of business concepts and rules to the project. After that, we were suddenly able to pinpoint exactly where all the integration problems were coming from. They had no technical root-cause but rather arose from business issues.

While going through the entire business specification we created, I suddenly got the idea: Would it be possible that this specification set could be instantly executable? Why can't this be input for a software development platform to automatically run an application that processes these functionalities?

And moreover, it would have this benefit: This would mean instant ownership from the business. We had been struggling to get the business owners to take responsibility for the project we were running. Partly, this was to do with the low trust these business owners had — understandable because up till that point the system had produced wrong flight information that led to operational issues. And that was caused by the IT staff involved in building the solution lacking in-depth knowledge about the flight operations domain. So, not having to translate business knowledge into technical code via IT staff (where the translation was not 100% fault tolerant) would also help a lot in this case.

But would this be possible?

I started doing an extensive market search for development platforms that could produce executable software out of (controlled) natural language specifications. Sadly, after a long search I couldn't find what I was looking for. Yes, there are natural language specification tools, for instance, based on NIAM, fact-based modeling, or SBVR. And there are even tools that generate executable code out of these kinds of specifications. But they still have an intermediate, technical step where code is generated and deployed, and data needs to be migrated.

So, in practice, this makes it hard or even impossible to work on a piece of software in an agile way. Even though 'agile' is being adopted by most organizations nowadays, technical experts are still needed, and often custom scripting is also needed to get a new release live. This introduces additional risk of misalignment. I wanted a platform that could just run this business specification as if it were the code, without any technical steps whatsoever. Only then could businesspeople truly own their concepts and rules, without needing to involve a technical person, ever.

When I came to the conclusion there was just not such a platform available, I thought: I have a scientific background and I am convinced that it should be possible. So, why not try to figure out myself how this could be done? That gave me an enormous boost and renewed my energy to stay in the enterprise architecture business, but now with the aim to come up with an alternative approach — an approach that would drastically improve the chance of a digital project's success … and not only projects but actually entire enterprises.

After doing a lot of reading, I started writing a theory from the ground up. I took nothing as a given and tried to remove boundaries that existing data structures or programming techniques seemed to have. I combined elements from many different existing theories, techniques, and methodologies. In the meantime, I was still doing practical work as an enterprise architect and used my customers as case studies to empirically test my concepts. I started building my first prototype to test some core elements … and that didn't fail. I built a second, more complete prototype … and that didn't fail either. Then I came to the crossroads: Shall I write a book about this? Or shall I just build such a platform myself?

I chose the latter and started building a first MVP, which I just recently launched. (It is certainly not complete yet.) In short, it allows users to specify their data structure by creating a vocabulary of nouns and verbs, relating these with each other by writing short statements, for example:

Based on the data structure, users can write action rules that define what needs to be executed under which conditions, for example:

This is all combined into one integrated controlled natural language. As soon as a concept or attribute is added, it is instantly available in the application. As soon as you add a rule and make it active, it is instantly available in the application. No technical code is generated under the hood. No migration steps are required.

I am not saying it is perfect. We still need to do a lot of work on it. And it still needs to be tested extensively in complex and demanding environments. But I do think that this is the future for digitalization: to make it a more business-driven endeavor, where it is really about making organizations simple, efficient, and effective. So, yes, I think we can do better — much better than we have up till now. That is why I decided to stay a while longer in the enterprise IT business, to see how this journey will end….

# # #