Think about it.
Whether it’s a packaged application for sales, IT, HR, finance, or any other function, every “off the shelf” solution is really just an assembly of 20 (or so) common functions or components, which are the building blocks.
Recognizing this, an increasing number of enterprises are investing in low-code platforms that enable business users to build their own workflows, the way they want them to work, rather than simply buying more software.
There’s a base set of building blocks, which have system fundamentals built into them such as security, scalability, and visibility. In our (current) model, these common components of all business software include:
- Portals
- Forms
- Data management
- Rule enforcement
- Search
- Workflow
- Email/Text
- Tasking
- Approvals
- Alerting
- Chat
- Schedules
- Calendars
- Surveys
- Robots
- Auditing
- Analytics
- Knowledge
- Users and Teams
- Integrations
Amazon Web Services (AWS—which accounts for just 10% of Amazon’s total revenue but more than half of its operating income) has similarly made a claim that there are 150 or so core services in an IT infrastructure—computing, file storage, a relational database service, etc.. They let the customer assemble those core services into what’s right for them. The customer is happy. It’s priced reasonably. And Amazon isn’t telling the customer how to do their thing.
Build, Buy, or Assemble?
Enterprises seeking to solve problems or improve business processes using technology can take one of three paths:
- Buy packaged software: It’s expensive and limits flexibility, but enables companies to get an adequate (generally) solution in place quickly. (As long as you don’t rip it apart.)
- Build custom software: This was the default approach in the early days of business computing, and it allows organizations to build exactly what they need. But it requires deep software engineering talent and the systems become very costly and difficult to maintain over time.
- Assemble solutions using pre-built components in a low-code environment: This is a more recent strategy, and is built upon the fact that most business apps are similar and pre-built modules can exist. This approach empowers business users to create their own workflow solutions, without the need for deep IT involvement or coding skills, that are much simpler to maintain.
That’s not to say purchasing off-the-shelf applications is never the right approach. It still makes sense for enterprises to buy prepackaged software in those situations where the business:
- Wants to get up and running quickly with new software;
- Doesn’t have an established, unique, differentiating process already in place; and
- Will be able to use the software as is, without (at least any significant) customization.
When those conditions don’t hold, however—such as when a company operates differently from competitors or the industry norm—then software assembly, using a platform that provides the base building blocks, may be the best approach.
A good example of that is Tesla. They’ve built their own ERP system instead of using SAP, Oracle, or Infor. Tesla built their own ERP application because they don’t sell through dealers. They sell direct. They do lots of things differently from the norm.
Stating that “all business applications are the same” doesn’t mean they work the same way, of course; just that they are built from the same common components. It’s a bit like the difference between a cake and a croissant: they are mixed and baked differently, but both are made from the same ingredients (and both are delicious).
Not “Best Practices” — Your Practices
When companies purchase packaged software, they are paying for the convenience and for a proven application that solves a defined set of business problems using common practices.
Note that these aren’t necessarily “best practices,” however, as…who is to say what qualifies as a “best practice”? Businesses like Amazon, Tesla, Uber, Airbnb, and Netflix certainly weren’t built using any established ideas about “best practices” in their industries.
For enterprises that want to do things differently—better, faster, cheaper—to step back and re-think how to best serve their customers, packaged software can represent a significant roadblock rather than a business enabler.
If the software includes lots of features and functions the business doesn’t need and never uses (which is the case for most software inside most companies), then the organization is paying for unneeded complexity.
And if the software doesn’t quite fit the way a business works, the company has two roughly equally unappealing options: either adapt processes to fit the way the software works, or develop customizations that may “break” every time the vendor releases a new version.
It’s those enterprises, the ones that think differently, that can benefit most from using a low-code platform which provides the common components, incorporating the essential attributes. Those organizations can say “all business applications are the same—except ours. Because we built those. And we built them our way.”
Cassy Lueneburg