For the longest time, companies have been trapped by enterprise software vendors.

First by shrink-wrapped software packages.

Then by SaaS offerings.

Both situations led to what one even in a SaaS world can call shelfware – although these days the shelf is a virtual one instead of a physical one. Buyers still get enticed to purchase more capabilities than they need, which leads to them paying more than necessary while often using software packages that offer overlapping capabilities.

One of the promises that SaaS started with, was to end this. Sadly, it looks like this promise was not kept. And this is no wonder; after all vendors want to be sticky. And they need to have increasing revenues. This means that they need to offer an ever-increasing number of capabilities, aka features, to warrant their pricing and eventually regular price increases. Combined with the frequently used strategy of offering related capabilities, i.e., seats for an adjacent software that is not yet needed by a customer, this led to two things: bloat and shelfware. Both go at the expense of the enterprise buyer.

Since the dawn of packaged software, the argument to buy, i.e., to voluntarily step into this trap, is the same: Buying is cheaper than building.

Which probably was correct. Buying from a specialist was the logical choice. Engineering talent was, and still is, scarce. Building software includes a lengthy process of requirements engineering, years of development and ultimately never-ending maintenance.

Just that most of this is true for most implementations of purchased enterprise software, too.

And the buying process is arguably broken. Need identification is often done without the right stakeholders, the software selection becomes a procurement-heavy process that is more based on checking boxes than in fulfilling user needs and the implementation turns out to be a death march. Who has not read – or at least heard of – the statistics that show implementation failure rates of more than 60 percent?

But then, who got ever fired for buying IBM, or Salesforce or SAP, for that matter. Or Oracle? Take your pick.

The result?

As a consequence, we see processes that are not improved or that not necessarily differentiate the company, as they are either implemented to follow the “same ole” or along “best practices”, which often translates to “average”, i.e., mediocrity. Users are forced to adapt to the tool, and not the other way round. Their pain is not solved. This, combined with shelfware, contributed to low adoption and shadow IT which ultimately harms all efforts of a digital transformation.

And it is costly.

Entry low-code, no-code and GenAI

Low- and no-code environments are basically there since, well … forever. At least as measured in Internet time. I had my first experiences with one back in 1995 (yeah, I am that old).

Depending on who got its fingers on these environments, results have been good or not so. Anyone remember the infamous Lotus Notes app graveyards? It needs guardrails.

However!

The combination of low-code, no-code and generative AI has the potential to reduce the marginal cost of software development to almost zero. Instead of engaging into a multi person year software implementation project, it is now theoretically possible to “vibe-code” a bespoke application in a short time and at low cost. The scarcity of IT personnel is mitigated, and the procurement process is no hurdle anymore.

At least theoretically. Again, it needs guardrails and the right tools for the right people.

Still, and this is important, it is now possible to create what one could call a throwaway MVP, or a working prototype, that covers a requirement’s happy path at almost zero cost. To be clear, this is a capability that we didn’t or only barely have with all the traditional low-code and no-code environments. And this is a big deal.

With this prototype it is possible to quickly identify whether a real problem is solved or at least mitigated; and this before big money is spent for the customizing and deployment of a new SaaS solution. This flips the procurement process to something for which one could use the term prompt-to-product.

A new paradigm?

As said, the traditional software procurement lifecycle: requirements identification → software selection → implementation is flawed. It relies on abstract and static written requirements. Text is ambiguous whereas software is explicit. The gap between a fuzzy, written requirement (e.g., "The system must support flexible workflows") that we see all too often and the delivered reality is where millions of dollars in enterprise value can get tanked.

With the help of Generative AI, it is possible to establish a methodology that moves the build phase to the very beginning. It serves not as the delivery mechanism, but as an agile discovery tool in a three phased process.

Phase 1: Dynamic Discovery

Instead of collecting stakeholder needs in a static document, this process begins with live prototyping. Business stakeholders work with an AI engineer or directly with an LLM-enabled no-code environment to describe their problem in natural language, rapidly developing a working prototype that supports the happy path to the desired outcome. This is agile development on steroids. The prototype does not need to be secure or scalable; it only needs to fulfill the job and be interactive. As a result, it becomes very clear what the users actually want. Plus, some implicit requirements get surfaced early in the process instead of after the purchasing decision and project budget assignment.

Questions like “Does the user actually want a dashboard, or just a daily email summary?” or “Does the data structure actually fit the way the team works?”, and more, are answered before they require costly change requests.

Phase 2: Stress Test

After the prototype solves the business users’ pains, IT leadership is in a better position to decide whether to buy, build, or opt for composing a low-code solution. Based on the assumption that the existing software packages do not cover the requirements, this decision can be taken by answering three main questions based on the generated code.

• Does this tool need to read/write to business-critical system like the ERP, or does it live in isolation?
• Does the logic involve high-liability calculations (tax, payroll, health data)?
• Is the logic static, or will it require constant updates based on external factors (e.g., changing shipping tariffs)?

Phase 3: Strategic Fork

Based on the answers, the organization moves down one of three paths. Crucially, the outcome of phase 1 is valuable on all three paths.

Build

If the prototype is self-contained, low-liability, and specific to the company’s internal operations, the decision is to build.

The prototype code gets refined to cater for edge scenarios and for compliance and security, if the development environment of the prototype didn’t already take care of these. After that, it can get deployed.

Because the cost of generation stays at near zero, the resulting software is disposable. If the process changes over time, the application is not patched but simply discarded and regenerated.

As a result, the company has a solution with perfect process fit, low implementation cost and zero licensing fees.

Buy

If the prototype reveals that the requirements are more complex than anticipated, for example, if there are more regulations to consider, the decision is to buy. In contrast to the traditional process, this is now an informed decision.

The organization stops building but uses the functional prototype as a key part of the RFP that demonstrates the desired process. The conversation shifts from "Can you meet our requirements?" to "Here is exactly how our process works; demonstrate that your software can replicate this specific behavior."

The result is risk mitigation for both the company and the winning vendor. The prototype proves that building potentially creates unmanageable technical debt. It also prevents buying vaporware by forcing vendors to prove capability against a live model. For the vendors, it takes away considerable uncertainty in assessing the project size.

Compose

If the prototype requires the flexibility of custom logic but the governance of a standard platform (Microsoft, SAP, Oracle, Zoho, Salesforce, etc.), the decision is to compose it using a low-code environment.

The AI-generated logic gets transferred to an existing low-code/no-code platform. This platform handles identity management, UI standardization, and hosting, while the generated code still handles the unique business rules.

This enables speed of deployment with the safety net of IT governance.

What does this mean?

Executives should flip the purchasing process using three key actions.

• Provide an infrastructure that allows for rapid, AI-supported prototyping, aka vibe-code environments. Ideally, this environment already embraces security and compliance rules.
• Train users, business analysts or IT personnel to use this environment to bridge the gap between business and AI.
• Instead of asking for written requirements only, make it the creation of prototypes in this environment that serve as core elements of the demand mandatory.

This flipped process opens the build vs. buy question to no longer being binary. It creates a build-to-define process that ensures that the decision of how to deliver required functionality in a better informed, de-risked way that has a higher chance for success at lower cost. It isn't killing SaaS but stopping to buy hope. Low-code/no-code in combination with GenAI can help to know more exactly what gets delivered, regardless of whether you build or buy.

The News

On March 3, 2022 Zoho released the new version of its Creator no-code/low-code platform. It offers a unified development platform to empower both IT teams and business users. 

The new release is targeted at building end-to-end solutions in an easy way. It combines integration, process automation and analytics/business intelligence with the ability to build applications and offers application management capabilities needed to manage security, compliance and governance.

Along with the built-in collaboration features it allows for a tight collaboration between business- and IT users.

The bigger picture

About a year ago I wrote a first article on no-code and low-code platforms, based upon the realization that the ongoing digitalization and necessity for business agility in fast changing environments require more than traditional developer support. At that time I cautioned that business users should not just be allowed to do everything without governance in order to avoid another “Lotus Notes moment”.

Since then the world moved on. 

No-code and low-code have become an indispensable part of the business applications world. They are critical to the fast adaptation of business applications and process automation across business applications. This is a task that is traditionally handled by IT departments. These, however, are regularly understaffed to be able to fulfil all the operations and enhancements demands that are on their desks. 

To achieve this, no code and low code platforms need to support both, IT departments as well as the business departments. This means that they need to straddle a considerable gap.

Typically, no-code and low-code platforms concentrated on either business users or IT departments. The latter are not really useful for IT departments as they are too simplified, the former cannot be used in the business departments as necessary IT skills are lacking. This leaves a considerable space in between. 

The way forward is to make things as viable as possible for both parties by enabling 

• Fast and efficient development and integration done by IT departments
• Business users to easily find enhancements/processes/apps that solve their challenges
• Business users to implement own, consistent applications on their own if missing apps/functionalities are encountered
• A collaboration framework that ensures good cooperation between IT and business departments
• A governance framework that makes sure that developed applications maintain and support the consistency and integrity of data as well as necessary data privacy

On top of this, no-code/low-code platforms need to strongly support the interoperability of different application stacks. Nearly no company builds around one single vendor or application stack.

The trajectory is quite clear. Development becomes more and more what we used to name declaratory. Low-code is the consequence of no-code not yet being strong enough to avoid coding altogether. The ongoing adaptation of business applications to changing needs will require less and less low-code and move more and more into the no-code direction.

My Analysis and PoV

Zoho Creator is aiming squarely at the gap that no-code/low-code platforms need to straddle. It, on one hand makes it very easy to create applications, extensions, and integrations for business users and on the other hand allows for the implementation of complex business applications, which is normally done by IT departments. Bridging this gap is quite hard to achieve and Zoho has done a pretty good job at it.

Although tightly integrated into the Zoho software stack, the platform is also independent of this stack, which means that it does not need to run Zoho applications to use Zoho Creator. It offers around 600 prebuilt integrations. In fact, a considerable number of Creator customers does not (yet?) run Zoho applications.

Creator addresses the points I mentioned above and enables IT departments and business users to build apps, integrate processes and create relevant analyses that help driving decision making based upon data.

All this is the result of more than 15 years of evolution of Creator. 

Is it already perfect? Like any other solution, not yet. Is it a solution that businesses should have a very close look at when it comes to selecting a no-code/low-code platform? Clearly yes. If you want to learn more, refer to my complimentary report on the Zoho Creator platform.

I for my part am really keen to see the next steps that this platform takes to integrate different teams even more and to integrate the available tools even better.

It is the end of 2021 and I do not have anything better in mind than writing a last post for the year. So let's do it.

There have been some terms that were used more than others with some of them actually being quite hyped. Some of them for the right reasons, some of them for the wrong ones.

My favorites of these terms include in no particular order:

• Metaverse
• NFT (non-fungible token)
• RPA or robotic process automation
• Hyper personalization
• Hyper automation
• Customer Journey Orchestration
• Low code / No code
• Artificial intelligence / machine learning

Hyper personalization

I already did a short video that expresses my thoughts on hyperpersonalization. You cannot really avoid the term when browsing the web with anything related to CX in mind. Back in the day, what is now called hyper personalization was called one-to-one marketing. This was in the eighties. The problem was that we didn’t have the technology nor the computing power to technically implement a contextually relevant 1:1 approach at scale and in real time. That’s why we worked with segments. 

Now we have the technology and computing power to address individuals contextually relevant in real time, nearly regardless of the size of the audience. Technologically, this is quite amazing, and if used consciously is of great benefit for customers and prospects. 

But there is nothing “hyper” about it. It is still personalization, maybe individualization. 

My wish for 2022: Let’s do away with the hyperbole before we start to desperately look for the next hyperlative – or should I call it ultralative?

Robotic process automation

No doubt, RPA is an important technology. It provides a fast and easy – maybe too fast and too easy – entry into digitalization of processes.

Its origins lie in automated UI based testing, applied to the automation of workflows.

Using RPA or its derivative intelligent RPA helps companies to increase the efficiency of their processes, especially if they stretch across various applications that have poor or no interfaces or that haven’t been integrated.

This works very well for processes that rely on structured data and in the case of intelligent RPA increasingly also with unstructured data.

Why too fast and easy then?

The problem is that it is hard to improve processes with RPA. Instead, existing processes get entrenched even more. This is also why it helps in digitalizing processes and not in a company’s digital transformation, which involves the creation of new, different processes. Still, it is an important technology as it helps reducing friction in existing processes, helping in reducing manual work and speeding processes up considerably. As a consequence, both employee experience and customer experience can get improved considerably.

My wish for 2022: Let’s merge RPA into workflow automation because this is what it is.

Low code / no code

We have seen low- and no code for a few years now but it really popped into people’s minds in 2021. Related terms are “citizen developer” and “democratization of development”. 

Again, another important technology that improved a lot over the decades. 

Yes, it is available for decades. Look at all the abilities to customize that enterprise systems offer for a long time. Admittedly, it often looked ugly and was not that easy to understand, but still, it was there.

Low code and now code have a tremendous value in workflow automation and systems configuration. 

My wish for 2022: May there be sufficient governance to avoid the database hell that we experienced in the good ole Lotus Notes times (or have these been the bad ole days?).

Hyper automation

This term is worth a rant. Gartner defines hyper automation as “a business-driven, disciplined approach that organizations use to rapidly identify, vet and automate as many business and IT processes as possible. Hyperautomation involves the orchestrated use of multiple technologies, tools or platforms, including

• Artificial Intelligence (A)
• Machine Learning
• Event-driven software architecture
• Robotic process automation (RPA)
• Business process management (BPM and intelligent business process management suites (iBPMS)
• Integration platform as a service (iPaaS)
• Low-code/no-code tools
• Packaged software
• Other types of decision, process and task automation tools”

There are many more definitions like this, published by many pundits. 

Automation exists like, forever. It is one of the very reasons for the existence of software. And it always included the use of multiple technologies, tools and platforms. Just adding a bunch of shiny category names that can be used to the definition, doesn’t add any hyper to automation.  

My wish for 2022: Let’s cut the crap and name it as what it is: automation or process automation. Sorry for these sharp words but here we are inventing a term just for the sake of inventing a term. This doesn’t add any value besides making some pundits appear important and/or visionary (with the emphasis on appear).

Artificial intelligence (AI) and machine learning (ML)

There is no doubt that these two terms describe a set of technologies that are immensely powerful, given the availability of enough computing power. Machine learning is a subset of what artificial intelligence is. The technologies have entered a trajectory away from technology for technology’s sake towards being embedded into business process and outcome oriented. The technology itself is mutating from a kind of silver bullet to a mere helper. Of course, this is not always the case. There are still areas where AI is overrated, sometimes even dangerous. We are also seeing ethical problems and biased AI come up. Still, with the ongoing change the acceptance of AI and ML have increased a lot. 

My wish for 2022: May we see a continuation on this path along with an increasing focus on explainability and ethics. May we also continue to see “human augmented by machine” instead of “human replaced by machine”.

Metaverse

I have kept my three favorite ones till the end, the metaverse and, related to it, web 3.0, that is currently in everybody’s mouth being one of them. The preliminary peak of the hype was Facebook changing its corporate name to meta in October 2021.

Right now, nobody can credibly say what the metaverse will be, except that it will be a significant development towards communication and collaboration. But what is obvious is that metaverse will be another evolution of the platform play. It will be seen as a significant source of new business. The players are already lining up to achieve “dominance”. With the likely consequence that the “metaverse” will be broken down into a couple of walled gardens that are intended to further the garden owners’ agenda and lack interaction/integration. This breaks at least the first four of Tony Parisi’s seven rules of the metaverse.

So far, the metaverse reminds me of the gold rush at the Klondyke river. Many people rush there, most will return disillusioned (if at all) and a few (platform) players got incredibly rich.

My wish for 2022: Call me a dreamer but may there be a strong focus on above mentioned four rules, in particular openness and that no individual entity controlling it.

Non-fungible tokens

A non-fungible token (NFT) is a unique and non-interchangeable unit of data that is linked to a blockchain. It cannot be copied, substituted or subdivided. NFTs gained notoriety for being electronic identifiers that confirm the ownership of digital collectibles.

NFTs are closely related to the topics of blockchain, which is still trying to find a compelling use case, digital twins, and metaverse, which drives its hype. 

Given that, NFTs are yet another example of a solution in search of its problem. Or the other way round, it creates a totally new market for the exchange of digital assets.

The crux seems to be that everything seems to be around virtual, as opposed to physical assets. This means that, as long as no metaverse emerges, NFTs are actually not creating value but destroy it. Looking at sites like Decentraland where companies recently bought chunks of “real estate” for millions of dollars reminds me strangely of Second Life. But then, maybe I am just not creative enough to understand.

My wish for 2022: May we find a compelling use case for NFTs that creates a solution for an unsolved problem or provides a solution for a solved problem that is better than the existing ones.

Customer Journey Orchestration

I want to end this post on a positive note, that’s why I left customer journey orchestration to the end.

Customer journey orchestration is a technology that actually exists and that has some benefits. It helps businesses to think outside-in and to come to a mindset that their success is the consequence of making their customers successful. Implemented properly, it enables the identification of customers intents in real-time and to offer them touch points of their choice on their journey towards the solution to their challenge at hand (or job-to-be-done, if you will). It helps businesses to identify unnecessary friction in customer journeys and to remove it.

My wish for 2022: May we increase our understanding that automated processes like automated marketing campaigns are not customer journeys.