A ‘SaaS’y Disruption: Printing Software

The ‘sorry state of Enterprise Innovation’ according to Urs Hölzle, Google is broadly a result of the fact that ‘each enterprise is a snowflake’. In the consumer world, developers can work against common standards. Hence to overcome this state, we should introduce new infrastructure layers of abstraction to develop against a common set of standards.

While standardization on the Infrastructure and Platform level will undoubtedly be fueling innovations, there are good reasons enterprises want to be snowflakes on the application level. For their core processes, enterprises often wish to be snowflakes - if they were just the same as everyone else, there is no reason for them to generate large margins or even be in the economy.

So-called ‘packaged Software’, where vendors sell ready-made packages for areas like Human Resources, Finance, Logistics, or Client Relationship Management, are suitable for processes where enterprises seek no differentiation. They have to be ‘good enough’ and get a job done.

But almost all valuable business models would say they have core processes where they differentiate themselves from others. For example, a service company and many software companies often depend on having the best people, i.o.w, on their hiring, retention, and promotion process. Even a discounter will differentiate itself on its operationally excellent processes.

In this blog, we want to suggest a solution, in the sense of a disruption hypothesis for the next decade(s), that will answer clients’ need to differentiate on the process and application level. From a technology standpoint, IaaS and PaaS providers offer such advanced Services & capabilities that the traditional argument that it is too expensive for companies to write their software will soon become obsolete.

The only argument that will still be valid is that it is tough to define a large enterprise solution. But there is hope there too to speed up this social process in virtual environments.

Twins & Printers

‘Construction 3D Printing’ refers to various technologies that use 3D printing as a core method to fabricate buildings or construction components. The level of automation and onsite production promises faster construction, lower costs, ease of construction, and enabling DIY construction.

Demonstrations of construction 3D printing technologies to date have included fabrication of housing, construction components, bridges, artificial reefs, and sculptures.

But why, if these techniques are so promising, has no one ever tried a similar ‘software printing’ approach? After all, if we can ‘print’ an entire house and large physical structures like bridges it should be ‘comparably easy’ to generate Infrastructure (by code) and code for all kinds of functions.

One reason why this was not attempted ‘at scale’ is likely that defining, what software should do, is no easy task. While it is comparatively straightforward to define how a house or a bridge should look and what requirements e.g. to stability it has to withstand, the software is a ‘complex beast’. It is sometimes a year-long process to define what software should do in enterprises. A software vendor for example designs & codes its product trying to research but sometimes really ‘feel out’ the client needs. It reacts to comments from Clients and the Developer Community, Sales statistics, competitive analysis, input from employees.

The software really is the result of a complex social interaction - a house is defined by its owner, a bridge designed by an engineer.

Software definition is not only a complex process, it is typically also a not ending process of changes and improvements. Over the years, with so many layers of requirements and changes coming together, a System might ‘get messy’.

Imagine you add to and renovate and extend to a house - the initial structure will be less clear and different parts of the house will require different maintenance and offer different levels of comfort. For a house, that might be charming. For software, this process is feared and often referred to as ‘Technical Debt’. Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

Unaddressed technical debt slows down the agility of changes and keeps companies from innovating fast. At some point, it might become easier to throw away and redo a System rather than trying to innovate or an existing codebase.

Overcoming the obstacle of getting large groups aligned on what a System should offer requires a new approach. Instead of working in documents, meetings, emails and sprint demos we should entirely virtualise the process and similar to manufacturing work in a digital twin environment. For our SaaS Disruption hypothesis we need the following two elements:

• A virtual gaming environment, where we gather, discuss, explicate and iterate overall requirements. This environment will be a 1:1 reflection of the reality, that is all users, user interfaces, processes will be defined here. We will refer to this as RGE the ‘Requirement Gaming Engine’

• An engine that can take the requirements and generate Software from it. This Software generation will as automatic as possible and will recreate the entire System upon small adjustments. We will refer to this as SGE the ‘Software Generation Engine’

RGE and SGE best work in combination but the Requirement Gaming Engine does not need the Software Generation to Engine to disrupt the way we currently define and create Software.

The RGE vs Agile Methods

Processes like ‘waterfall’ or these days' agile’ are after all just a - often clunky - method to organize large groups of humans to come to an agreement on what functionality a software should deliver. It is easy to ‘finger point’ and list how slow, expensive, and often ineffective in delivering what the client ‘really needs’ they are. After all, they are the best we have and agile processes are certainly an improvement over waterfall delivery methods. Their main tools to come to an agreement are documents (for waterfall) and product, so-called ‘sprint demos’ (for agile) which are meant to explicate to anyone involved in the process, what the software we are working on will eventually look like. Nevertheless, all such processes are a ‘representation’ of what will be delivered and as such mere crutches for testing the end product.

But hold on, haven’t we become much better at simulating real worlds in recent years? Haven’t we seen amazing movie special effects, virtual environments, and gaming engines that simulate environments? Why would it not be possible simulating and visualize the environment in which software should function and the software itself instead of describing it with documents or demonstrating it in demo environments?

Take a small shop owner that orders newspapers, pencils, some food, and drinks to sell them between 7h and 23h every day. In a virtual environment - think some form of gaming engine - this owner would define himself, his wife, and his 1 employee as characters in the game. He would also define the 50 regular customers that stop by and always buy a specific newspaper or milkshake and he would define let’s say a 100 anonymous users that stop by and typically order a cappuccino, a sandwich, and buy a newspaper. Then, he would define characters for his suppliers: the bakery, the food truck, and the newspaper delivery van. He would paint and set up some user interfaces - just exactly as he likes it - for the order and purchasing process and some screens for automated and manual orders to stock up. After this is finished, he would be asked to go through a questionnaire: does he expect a lot of growth in the near future, does he need a mobile app, whom he wants to give access (himself, his wife, his employee), and so on. Then, with the press of the button, the software would be generated.

How would this extent to a large multi-national enterprise? Let’s say we want to introduce a call center to service clients in an enterprise spread across the globe. We would set up in our gaming engine all locations with all employees working there, we would define their shifts, skills and qualifications, and anything else that is relevant. We would also define their team structure, their team leads, system administrators, peers and so.

We would also define all stakeholders in that software, i.e. those financing the solution and defining their requirements, as well as those using or benefitting from the solution. Within such a context, we would allow zooming in to define screens that different user groups should be able to use. Additionally, we would also record the processes that users run through on screens. Eventually, there will also be a technical questionnaire, where Architects can define e.g. their Integration points with other Systems, certain Rules (like whenever you insert a new Client Contact coming from an online order pls also create an order for a welcome present) enter expected data amounts, expected performance peaks, and other non-functional requirements.

This virtual environment is designed to entirely replace documents and any artifacts used in traditional software engineering processes like agile or waterfall. We do not need documents, moreover, there is also no need for sprint demos anymore because the software - as it should be - can be visualized virtually at any moment in time.

Maybe these examples don’t even appear too ‘futuristic’. After all, gaming engines can create amazing visual worlds. Using those for refining something as virtual as software is some sense would be an obvious thing to do. But how would we come from that virtual world to the real Software? The traditional path is to start 'setting up and coding’ the entire system. More convenient, impressing and ‘futuristic’ would be, we generate the software automatically. We want to print the software like 3d printers print physical items based on their virtual counterpart.

The SGE vs Technical Debt

Now, with all the Data we found in the RGE, the SGE can start designing and ‘suggesting’ an Architecture. This would be similar to defining a house and deciding, which material and static construction one will choose - at this point, we are still able to make changes. For example, the engine might suggest using a SQL or NoSQL Database, a certain network topology, ex- and internal load balancers, a particular programming language and UI frameworks, AI capabilities like Bots for Self Service, and so on.

With the Construction plan entirely laid out, Clients can still analyze, why a certain topology was suggested and what requirements lead to that. And of course, we might adjust this. In the end, just as someone building a house, Clients can choose different materials, e.g. maybe they prefer a programming language they already master in-house or consider having more future innovation potential in a language, framework or stack the engine suggested.

After we did all that, we would simply generate the entire Software right to the point where users can log on to the System. ‘Complete and utter’ automation is more of an ideal to strive to rather than a reality that will happen with the ‘1st print’. In fact, even if you entirely print a house, you still will need to do your fine-tuning, like moving in furniture into the house and maybe you want to paint a wall differently.

The software won’t be any different, for example, you can define your Integration Points but you still have to manual connect your ESB, this is similar to building the road from the autobahn to your house: you created the door but you still need to connect from your house to the main road. Some areas like user training, change management in the organization will also never be automated.

In spite of all obstacles and a long path towards an (almost) entire automation, printing software has an immense advantage overprinting a house: Moving bits & bytes is really cheap, it is also really ‘no problem’ to make a mistake - you change some setting and run the SGE again. In fact, with any addition to the RGE, you could simply run the SGE and see, how the engine looks like now.

For example, if you add large user groups as to your prediction of how busy your website will be, or add functionality for users to upload pictures or movies, you would expect a change in the topology, code, and user interface. Here goes your agile sprint demo, your user story, instead you generate the software based on your specifications and have a look at it whenever you want.

The ‘secret sauce’ of the RGE is of course all those best practices Architects and Developers should follow, what databases and app servers they should choose for certain scenarios, how to best structure code, how a UI best looks like to make users productive and give them a pleasant experience, how to dissect your software into Services and so on. If there was a complicated project, where the RGE was not able to automate the generation of the Software entirely and manual intervention was necessary - let’s say for a complex rule and workflow engine to assess the risk a Client poses for not paying back a loan - then for the next iteration this invention would be incorporated the SGE.

The automation level would increase. If we find better ways to write rule engines, we would adjust the SGE and with the next generation of the Software, a client purchased this new engine would be in place. Note, there is no concept of technical Debt here that would hold us back. In the traditional packaged Software Model, if you once invented a Rule and Workflow engine, you would create copies for it every single client you have and this piece of code would take on a life on its own.

It is very hard to change such architectures, often impossible, and as a result Software stacks that build on such a model get slower and harder to Innovate over the years. The key to overcome this is to entirely regenerate Software, even for small changes, and constantly incorporate the latest & greatest into the Software Generation Engine.

Now, that might sound futuristic to some: entirely generating Software instead of what now is tedious and intellectual work for highly paid Developers. High degrees of automation is no utopia, the technology can be invented - some large language models already demonstrate to us that coding can be automated as a response to natural language commands. In reality, progress is a question of channeling investments into the space and that depends on understanding the enormous technological and economical advantages such technologies will provide.

The Strategy

RGE & SGE are a possibility created by the technical progress in IaaS/PaaS platforms and virtual environments like e.g. Gaming Engines. They respond however to client needs to have entirely customized software for differentiating use cases. Additionally, have technology that carries no technical debt and can easily get upgraded to the ‘latest & greatest’ technology stacks.

Software vendors run a risk of being eliminated by Iaas/Paas platforms and their usage of virtual environments for designing the specification process in a much more efficient way. When that happens clients will also gain back part of their autonomy for producing software ‘just as they like it’.

They will have more choices and can choose to execute writing software themselves, thereby eliminating an entire link from the supply chain. This will also allow addressing entirely new markets of small and medium enterprises that so far could not afford ‘their own’ customized software catering exactly for their needs. A small business typically needs much less functionality than large enterprises require and can be overwhelmed by the complexities and costs coming with traditional Enterprise Software.

Coming from the consumer world they prefer simplicity & ease of use over features and they will have the opportunity to define what they need in a simple and pleasant virtual environment engine and then with ‘the press of the button’ get ‘their’ software delivered.

In short, the ‘SaaSy disruption’ will work as follows:

• Someone will build a virtual environment, the SGE, where clients can gather all their requirements in a virtual world. This will replace all documents, sprint demos and eradicate any ambiguities and unclarities as to what Clients request. This in itself will be a viable business, that can be offered standalone over the internet and in marketplaces for all major IaaS/PaaS providers competing with traditional Enterprise Agility Platforms

• Clients that purchase an RGE via an Iaas/PaaS Marketplace will receive a freemium version to generate the Software they defined with the help of an SGE. A generated software skeleton can be tested but will cost when purchasing and will require additional work. The earlier we are in the process the more manual work one will have for the final delivery of the software. Over time there will be a higher degree of automation

• Technological Innovations like new languages, frameworks, AI capabilities like both will be constantly incorporated into our SGE capabilities. This will give vendors a competitive advantage as they can improve their engine with every new client

The RGE will target Clients of any complexity and will be useful especially for large complex environments. The SGE will target small, less complex environments and over time mature into the enterprise market.

Two disrupted by this model are the Enterprise Resource Planning market for packaged software for large enterprises and the Enterprise Agility Planning Market for tools & methods to produce and deliver Software. One can find different sizes and projections depending on the source but both are in the billions with the EAP market representing a smaller market typically also supporting the creation and implementation of ERP packages. They grow with double-digits and illustrious names like Oracle, SAP, Microsoft, Salesforce, Atlassian, and many others compete in them.

Agility Planning Software would offer a subscription-based Revenue. The ‘Real Money’ however will be generated allowing clients access to the Software Generation Engine. The more advanced your capabilities are and the less manual intervention you have the cheaper we will be able to produce for the Clients wishes. Clients will not only get exactly what they want, fast - but also they will be regenerating their entire Software entirely devoid of any Technical debt and garnished with the latest and greatest technology, frameworks, and innovations.

Outlook

A disruption hypothesis concerns the future and predictions and hence are uncertain.

Having said that, we can extrapolate from the trends. 3d Printing automates the building of large and complex physical objects. If we can achieve this for the physical world, it will be much easier to automatically generate ‘Bits & Bytes’, i.e. an Infrastructure topology and code running on top of it. The evolution of cloud computing and Infrastructure and Platform as a Service over the Internet, on-demand will allow a similar degree of automation as soon as the economic incentives are accordingly.

One important reason we do not already do that is that software functionality results from an often very complex social process between many individuals and groups, usually over a long span of time. Again, digital twin environments in manufacturing lead our way, how we can design this process much more efficiently in the future.

Such twin environments offer far more efficiency gains beyond what processes like a waterfall or agile provide in the ‘real world’. Producing software in a virtual environment and using sophisticated Automations will just be part of a larger trend to build virtual worlds, like the Metaverse, where we can handle certain aspects of real-life easier and more fluently lifting restrictions of physical space. If anything, the software is one of the most obvious candidates for a transformation, which we already see in manufacturing.

Software is not a winner takes it all market. For example, there can always be areas where companies can live with mostly standardized packaged solutions, and no sophisticated customizations are required. None of the incumbents in the SaaS market must just disappear -  in fact; they might be in the best position to take advantage of the trend and disrupt themselves and their Industry.