Faced with a long-running shortage of experienced professional developers, enterprise IT leaders have been exploring fresh ways of unlocking software development talent by training up non-IT staff and deploying tools that enable even business users to build or customize applications to suit their needs.

A broad spectrum of tools has arisen to facilitate software development in the enterprise, from no-code platforms like Bubble and low-code drag-and-drop tools, both stand-alone and integrated into enterprise applications, to intelligent tools that use machine learning to suggest lines of code to professional developers as they work.

Sales of all three of these categories of tools are growing. IDC forecasts that sales of no-code platforms will grow at an annual rate of 13.9% through 2026, with sales of low-code platforms growing at 14.1%, and those of intelligent developer technologies roaring ahead at 31.3%. This last category has received a boost as platform vendors explore the potential of generative AI models such as ChatGPT to create boilerplate application skeletons on which developers can hang their own business logic — or even turn human-readable requirements into machine-readable code.

The predictions about the future of software development are contained in IDC’s “Worldwide Low-Code, No-Code and Intelligent Developer Technologies Forecast, 2022-2026” report.

Its author, Michele Rosen, says the market for intelligent developer tools has become even more interesting since she finished writing it, now that some of those tools — such as Salesforce’s Einstein GPT or Microsoft’s GPT-based Copilot — have become public, although even before that, products such as OutSystems’ AI Mentor were offering similar functions.

Autocomplete on steroids

“Think of them as boilerplate writers, or autocomplete on steroids,” Rosen says. “They are tools used by someone who knows how to do this themselves, who may be using them to supplement their knowledge about a technology, library, or framework they haven’t worked with before, or to avoid looking up a few lines of code on Stack Overflow.”

Other uses for them might involve typing a few words as a prompt to generate the 20 lines of boilerplate needed to get a project started. “It’s really just a force multiplier, an accelerator,” she says.

Low-code and no-code platforms, on the other hand, typically adopt a drag-and-drop metaphor rather than a command-line interface, and that shows up in the way line-of-business developers think about the problems they’re solving too.

Users without a technical background will typically consider an app from the user interface inwards, she says: “That’s just the mentality that most people approach computing with.” If they are provided with UI components they can arrange to create the user interface, and then also components that can be assembled into business logic and even integrate with third party systems, then, in a sense, no-code and low-code development for the non-technical developer becomes a component based experience, she adds.

That componentization is key, says Andrew Peterson, CTO of executive search firm Riviera Partners, a longtime user of low-code development tools.

“One of the reasons I like low-code is because certain parts of your application are commoditized,” he says. “If I can get those things off-the-shelf, then I can focus on building the things that really add value, that are important to my particular business: the business logic, the innovation, the competitive advantages. Then I have a quicker time to market.”

But it’s not just about making life easier for the coders, whether they’re in the IT department or elsewhere. A good low-code or no-code platform will also help the CIO, says Rosen.

Governance guidelines

“If I had to tell someone looking to buy a no-code or a low-code tool what to look for to tell whether that vendor is serious about helping them build a culture of low-code/no-code development, it would be controls to help them set up governance around who can use the tools and what the tools can be used for,” says Rosen.

In some ways, governance around low-code tools is no different than for other software development tools, says Nick Mates, VP of operations and technology at Lendr, an online business-to-business loan platform. “We treat a low-code application as if it was a traditional code application,” he says. “It should follow the same governance lifecycles, from a business analyst’s desk to a developer’s desk to a QA desk to deployment.”

But with code-facilitating tools such as these, enterprises must also set up governance around which tools are best used for which use cases, Rosen says, noting that many organizations have multiple such tools in operation in house. Organizations with the most experience leveraging low-code and no-code tools have also set up centers of excellence (CoEs) to advise lines of business on which tool to use and when, she says. The CoEs also provide support by coding more complex interactions and integrations that low-code development tools or their users can’t handle, providing reusable components that line-of-business developers can access, and curating them in a marketplace or code repository.

One thing that plays into deciding the right tool for the job, and when a professional developer’s help is needed, is the level of interoperability that any given vendor has enabled in their platform, Rosen says. “Do they really just want you to bring all your data and logic to their platform, or are they allowing you to build apps that cross over multiple platforms?” she says. “That’s an important feature that customers can look for.”

The cost of keeping up

Should CIOs not yet all-in on the trend budget their software development tool spend to keep pace with IDC’s growth forecasts? “It’s not something where they need to make a major investment,” says Rosen. Setting up a CoE and making reusable software components available are affordable steps for most enterprises, she says. “Generally speaking, it’s not expensive to get started,” she adds. “What’s expensive is scale.”

Rather than worrying about whether their software spending is keeping pace with that of their competitors, Rosen advises CIOs to ask themselves, “What features are we not offering that we might be able to offer using low code, and that will be impactful for the business?” That approach could lead to cost savings since reusing componentized interfaces may mean a reduced need to hire expensive, expert programmers to build each application from scratch.

One key indicator on budgeting would be to weigh the cost per user for low-code platform licenses against the cost of hiring additional staff, Rosen says. For now, the difficulty of finding highly experienced professional developers is tilting that balance in favor of enabling line-of-business staff with low-code tools. Lower down the expertise scale, the decision whether to hire or to reskill existing staff is less clear, she says. At this level, CIOs need to take other advantages of deploying low-code platforms into account: not just develop a new digital business product, but perhaps also empower employees or improve retention.

“Once you know what you’re going for, you can look at the platforms with a different perspective,” Rosen says.

CIO, Developer, Development Tools, No Code and Low Code, Software Development

By Patrick McFadin, DataStax

When the gap between enterprise software development and IT operations was bridged 15 or so years ago, building enterprise apps underwent a radical change. DevOps blew away manual and slow processes, and adopted the idea of infrastructure as code. This was a change that upped the ability to scale quickly and deliver reliable applications and services into production.

Building services internally has been the status quo for a long time, but in a cloud-native world, the lines behind cloud and on-prem have blurred. Third-party, cloud-based services, built on powerful open source software, are making it easier for developers to move faster. Their mandate is to focus on building with innovation and speed to compete in hyper-fast markets. For all application stakeholders—from the CIO to development teams—the path to simplicity, speed, and risk reduction often involves cloud-based services that make data scalable and available instantly.

These points of view aren’t far apart, and they exist at many established organizations that we work with. Yet they can be at odds with one another. In fact, we’ve often seen them work in ways that are counterproductive, to the extent that they slow down application development.

There might be compelling reasons for taking everything in-house but the end users are voting with execution. Here, we’ll look at the point of view of each group, and try to understand each one’s motivations. It’s not a zero-sum game and the real answer might be the right combination of the two.

Building services

Infrastructure engineers build the machine. They are the ones who stay up late, tend to the ailing infrastructure, and keep the lights on in the company. Adam Jacob (the co-founder and former CTO of Chef Software) famously said, “It’s the job of ops people to keep the shit-tastic code of developers out of your beautiful production infrastructure.” If you want to bring your project or product into the sacred grounds of what they’ve built, it has to be worthy. Infrastructure engineers will evaluate, test, and bestow their blessing only after they believe it themselves.

Tenets of the infrastructure engineer include the following:

Every deployment is different and requires qualified infrastructure engineers to ensure success.Applications are built on requirements, and infrastructure engineers deliver the right product to fit the criteria.The most cost-effective way to use the cloud is to do it ourselves.

What infrastructure engineers care about

Documentation and training

Having a clear understanding of every aspect of infrastructure is key to making it work well, so thorough and clear documentation is a must. It also has to be up to date; as new versions of products are released, documentation should bring everyone up to speed on what’s changed.

Version numbers

Products need to be tested and validated before going into production, so infrastructure teams track which versions are blessed for production; updates must be tested too. A critical part of testing is security, and we are generally behind the latest cutting edge, so we have the most stability and security.

Performance

Performance is critical, too. Our teams have to understand how the system works in various environments to plan adequate capacity. Systems with highly variable performance characteristics – or those that don’t meet the minimum – will never get deployed. New products must prove themselves in a trial by combat before even being considered.

Using services

Installing and running infrastructure is friction when building applications. Nothing is more important than the speed of putting an application into production. Operational teams love the nuances of how things work and take pride in running a well-oiled machine, but developers don’t have months to wait for that to happen. Winning against competitors means renting what’s needed, when it’s needed. Give us an API and a key, and let us run.   .

When it comes to infrastructure, developer tenets include:

Infrastructure has to conform to the app and not the other way aroundDon’t invent new infrastructure—just combine what’s availableConsume compute, network and storage like any other utility

Things service consumers care about

Does it fit what I need, and can I verify that quickly?

The app is the center of the developer’s universe, and what it needs is the requirement. If the service being considered meets the criteria, this needs to be verified quickly. If a lot of time is spent bending and twisting an app to make a service work, developers will just look for a different service that works better.

Cost

Developers want the lowest cost for what they get. Nothing so complicated that a spreadsheet is required. With services, developers don’t necessarily believe in “you get what you pay for,” with more expensive being better. Instead, they expect the cost to decrease over time from a service provider finding efficiencies. 

Availability

Developers expect a service to always work, and when it doesn’t, they get annoyed (like when the electricity goes out). Even if there is an SLA, most probably won’t read it—and will expect 100% uptime. When building my app, I assume there will be no downtime.

In the end, the app matters most

From working with a lot of organizations for whom applications are mission-critical, we’ve often seen that these two groups don’t work particularly well together—at times, their respective approaches can even be counterproductive. This friction can slow application production significantly, and even hamper an organization’s journey to the cloud.

This friction can manifest itself in several ways. For instance, a reliance on home-grown infrastructure can limit the ways that developers access the data required to build applications. This can limit innovation and introduce complexity to the development process.

And sometimes balancing cloud services with purpose-built solutions can actually create complexities and increase costs by watering down expected savings from moving to the cloud.

Application development and delivery is cost sensitive, but it requires speed and efficiency. Anything that gets in the way can lead to a dulled competitive edge, and even lost revenue.

Yet we also know of organizations that have intelligently combined the efforts of infrastructure engineers, who run your mission-critical apps today, and those who use services to build them. When the perspective and skills of each group is put to good use, flexibility, cost-efficiency, and speed can result.

Many successful organizations today are implementing a hybrid of the two (for now): some bespoke infrastructure mixed with services rented from a provider. Several organizations are leveraging Kubernetes in this quest for the grand unified theory of infrastructure. When describing a deployment model, there are blocks that create pods and service endpoints, with  other blocks that describe endpoints on a pay-per-use method. If you are using any cloud with Kubernetes, think storage and network services.

There are other important elements to an organization’s universe of services — whether they’re built or bought. Standard APIs are the de facto method of serving data to applications — and reduce time to market by simplifying development. SLAs — customer and internal alike — also clearly delineate scale and other performance expectations — so developers don’t have to.

Finally, I should point out that this is an immediate challenge in the world of open source data where I live. I work with Apache Cassandra®—software you can download and deploy in your own datacenter for free; free as in beer and free as in freedom. I also work on the K8ssandra project, which helps builders provide Cassandra as a service for their customers using Kubernetes. And DataStax, the company I work for, offers Astra DB built on Cassandra, which is a simple service for developers with no operations needed. I understand the various points of view—and I’m glad there’s a choice.

Learn more about DataStax here.

About Patrick McFadin:

DataStax

Patrick is the co-author of the O’Reilly book “Managing Cloud Native Data on Kubernetes.” He works at DataStax in developer relations and as a contributor to the Apache Cassandra project. Previously he has worked as an engineering and architecture lead for various internet companies.

IT Leadership

Ease of implementation and return on investment (ROI), combined with ease of use, continue to dominate the business to business (B2B) software buying process, according to a report from software marketplace G2.

The report, which is based on a survey of 1,002 global decision-makers with responsibility for, or influence over, purchase decisions for departments, multiple departments, operating units, or entire businesses, showed that at least 93% of respondents indicate the quality of the implementation process is very important when deciding whether to renew a software product.

The respondents said they are looking for the least amount of friction while adding a new solution or software to their technology stack and that ease of implementation can add to the frictionless experience, according to the report.

In fact, 77% of respondents indicated they have either worked with a vendor’s implementation team or have worked with a third-party vendor for implementation, as opposed to 34% of respondents indicating that they handle implementation with their internal teams.

These implementation teams play a pivotal role as they shape an opinion about vendors and can help make contract renewals easier, the report noted.

Pricing no longer an effective sales tool

Pricing, according to the respondents, was the second-least favored factor in the buying process. The survey showed that sticker price is no longer a sales tool and has been replaced by proof of return in investment.

The decision makers ranked ease of implementation as the top important factor while ROI within six months and ease of use were the second and third most important factors among 12 other considerations, including price, as part of the buying process.

The survey data showed that these decision makers want to achieve ROI quickly and believe that an easy implementation process combined with an easy-to-use product may help them generate returns faster.

Lower switching costs affect renewal rates

At least 53% of respondents surveyed said they conduct research and consider alternatives when a product is up for renewal as opposed to 45% claiming they renew the software they already use without considering other options. This phenomenon can be attributed to increasing options and lower switching costs, the report showed.

However, the group of decision makers that renews a product without considering options is growing slowly. There has been a 3% increase year-on-year for the same category, according to the report.

Vendors must make information such as proof of ROI available in early stages of adoption in places where these decision makers frequent for researching new products, as a majority of decision makers are still looking for alternative products, the report said.

At least 76% of respondents said product and service review websites are trustworthy and transparency in the validation of the reviews is key. More than 33% of decision-makers surveyed said transparent validation of reviews is the most helpful feature when using online software or service review sites.

The report also shows that most enterprises have a six-month contract period, which leaves limited time for vendors to make an impression on the buyer. At least 57% of respondents said they have a six-month period compared to just 11% stating that they have two-year or multiyear contracts in place.

Buying directly from vendors is slowing down

Buyers are slowly shying away from buying directly from vendors, the report highlighted. Only 60% of respondents said they bought directly from vendors, a 9% decrease from the previous year.

Alternatively, buyers are increasingly purchasing software from third-party marketplaces and value-added resellers (VARs), according to the report.

At least 28% of respondents said they were buying software from third-party marketplaces, an increase of 6% from the previous year’s survey. Further, 11% of respondents said they were buying software from VARs, a 4% increase year-on-year.

Buying committee changes complicate purchase process

The B2B buying journey, according to the report, is becoming increasingly complex due to changes in buying committees. At least 80% of respondents said their enterprises or organizations have such committees in place.

More than 67% of respondents said buying-decision makers are changed frequently or nearly always during the software buying process, up by 15% from previous year’s survey.

Another challenge is that the buying committee is more likely to have changed at the time of renewal from when the product was originally purchased, the report showed.

IT Strategy, Software Licensing