An interesting suggestion suggested in a recent roundtable discussion hosted by OutSystems is that many businesses that have an application or innovation project will fail them.
It will run over budget or it will not reach its intended go-live date or, alternatively, there is some other application or transformation project that cannot be stopped and consumes all available resources and budget.
As a provider of low code solutions, OutSystems expects it to be ready for what it sees as the typical user expectations of such technology, and how it sees users failing it, as explained by the Head of Company portfolio, Prakash Vyas.
There are many what I call ‘weak level solutions’ locally. It’s either low-code technologies that create only the presentation layer, or a specific type of solution that a specific buying center or team builds with low-code. The problem is that customers get excited because they see the benefits have a broader context, but they hit a wall.
Often, the wall is that users are already invested in low-code technology and want to expand the same methodology to new areas, such as building new agile development teams. Delivering an agile, low-code approach is not possible without a local platform, where OutSystems acts as one of the few low-code providers capable of meeting the changing market for application delivery.
Challenges
According to Vyas, many of the previous and current low/no-code tools were never designed to handle an enterprise level application, even if they worked well when first introduced to a pre-enterprise level business. The result is a set of different, simple tools, even if they come from the same vendor. So as the scope or volume of workload increases, users have to take a significant step forward, at which point they hit a wall because there is no underlying platform that can take users forward to the next level.
Those tools can come from a range of different technology starting points, even from the same vendor, but they tend to end up at the same point – an inability to scale or be- personalized, expanded or otherwise modified. In addition, it makes change more difficult, and avoided if possible, because the user becomes more locked into the investment, trying to make it work and extend its life until it is no longer possible. It no longer fits other important tools and services, such as cybersecurity capabilities, that meet modern software design rules or externally regulated requirements for future business practice:
They need the options to rebuild, refactor without doing the heavy lifting, and finally start automating processes. But often attempts to automate processes harm other parts of the business. Was it prompted by COVID? I’m not sure, but what I can say is that the software now defines the business and the business is defined as the software. Progressive organizations now take that to the heart of what they do, and build IP development around technology.
OutSystems, in terms of code, is an industry standard .NET that works with many software elements available in the generic low-code framework, Forge. In terms of business innovation, this opens up the range of software engineering tools available in Forge. The company is also looking to create more usable tools such as templates and code, all aimed at allowing developers to quickly start projects, Vyas said:
We are looking to democratize that advantage on our platform. That way, we will be able to better compete as an average organization against the likes of Netflix or indeed Amazon.
He notes that the driver here is the speed at which businesses today have to adapt and change to compete, while at the same time those who can compete can now do so to the greatest extent, in both terms:
The days of multi-year IT projects are dwindling. People really want business software delivered in weeks or months, not months to years.
Roadblocks
Vyas identifies three road-blocks that often stand in the way of companies making the transition to an environment where they can meet those goals.
The first is the ever-increasing application complexity that makes traditional application development methods difficult to use. In addition, there is no simple way, when using traditional resources, to break some projects. Second is that talent is hard to come by, and even harder to afford. For the third:
The third is the application backlog. Those first two cause an application backlog that is completely stuck. In talking to customers, what I’ve found is that, because they take shortcuts in the way they develop software, what happens is that the quality of production releases tend to be fixes, which means that the your frequent backlog is very rarely bumped. This is a vicious cycle that many continue to experience. So what they need is a way of building software that responds to the amount of people, the complexity, and the speed that a business needs.
Platforms are now seen as an important basis for this and are becoming one of the next big areas of competition among vendors. Having a platform on which a wide range of business applications – and the processes built with them – can run in useful collaboration will be a key capability that all businesses will be looking for. . Owning that platform is a clear goal of the vendor.
One of the interesting issues for users in this development is that all the platform contenders seem to be approaching a common middle ground from a number of different starting points. For example, ServiceNow will come in from the operations management end, while Appian will come in from the low-code and robotic process management end. The common goal is to provide the over-arching platform that provides the foundation for comprehensive change programs.
Guidance
The guidance that Vyas usually gives to customers is that departmental point solutions can be built using low/no code providers, and will work fine as long as no further development is planned or expected. However, if change is part of the plan, and many changes are part of the expectation or if those changes will usually be made using traditional code or if the goal is differentiation and market value, tools that are low/ without that code it just won’t cut it. .
To be fair, this is broadly similar to the advice coming from other platform-pitching vendors and it raises an interesting side issue when it comes to future platform choices for users. In other words, is platform selection likely to be the next ‘wall’ at which users stop? The common statement now is that new platforms can accommodate all traditional application technologies and the low/no-code offerings of other vendors, which is good – backward compatibility seems to be more taken care of. But what about compatibility going forward if everyone is vying for the role of being the ‘manager of managers’?
The platform marketplace must be one where commonality is more important than diversity in the marketplace, otherwise those differences will become pitfalls into which users will carelessly wander and if where the walls will be built. Vyas concludes:
What we’re saying is, we have the ability to extend the functionality of those tools the way the customer wants to extend, not the way the vendor sees that extension. We say that customers have a choice – and we respect that and that they have made investments – but they can use our systems to extend the validity of those, because they are not working for them now. That’s why we link those systems in terms of ServiceNow and its ambition to be at the forefront. it’s not just about integrating into the customers’ eco-system. It’s about integrating with the wider world, or bringing in third-party services, third-party payment services, authentication, etc. So they’re looking at which ones make the connection.
I take it
Interesting times. Not new, of course, but perhaps more important than ever. The emergence of new platforms that increasingly take on the role of ‘management managers’ – the primary overseer of all business activities as individual operations and as a single business entity – is both a good thing and a dangerous one. that thing. They are, collectively and individually, good, if only because the increasing complexity of business operations is now stretching human management capabilities to breaking point. There is now a great need to automate much of this.
It is also dangerous, for each of the contenders will come at the issue from different angles, and have different views on what are really important issues in getting over-arching business management to work effectively. This means there is a real risk for early adopters to find themselves stuck at a dead-end of a solution that suits their early needs but fails to pass the test of time. Yes, this has always happened in the past, but this time, the scale of the impact of its error is likely to be several orders of magnitude greater – and more expensive.
Now, therefore, is the time to suggest that patience will indeed be a virtue in making vendor choices. In addition, add an important question to all the others you can ask vendors – how will your platform work with any other platforms if your platform is no longer suitable for the future of our business? Any answer along the lines of, “They’ll have to engineer the compatibility requirements” should really make you run away with the pen still in your pocket.
In fact, perhaps it is time to call for the development and acceptance of some level of common minimum standards of compatibility across all adversaries to ensure that users do not find themselves boxed in and confused, regardless of the choice they can make soon. , because those decisions will have far-reaching consequences.
.