Being the 'manager of the managers' - platform thinking revisited by OutSystems

An interesting suggestion proposed at a recent roundtable discussion hosted by OutSystems is that many businesses with an application or transformation project are going to have it fail on them.

It is going to run over budget or it's not going to hit its intended go-live date or, alternatively, there is some other application or transformation project that can’t be stopped and is consuming all available resources and budget.

As a provider of low code solutions OutSystems reckons it is ready for what it sees as the common user expectations of such technology, and how it sees the users being failed by it, as the company’s Head of Portfolio, Prakash Vyas, explained.

There are a lot of what I call 'weak level solutions’ locally. It's either low code technologies doing just the presentation layer, or a particular type of solution that a particular buying centre or team that's been built with low code. The problem is that customers get excited because they can see the benefits have a much wider context, but they hit a wall.

Often, the wall is that users have already invested in low code technology and they want to expand that same methodology into new areas, such as building new agile development teams. Delivering an agile, low code methodology is not possible without a local platform, which is where OutSystems comes into play as one of the few low code providers capable of meeting the changing market for application delivery.

Challenges

According to Vyas, many of the early and existing low/no-code tools were never designed to cope with an enterprise level application, even if they worked well when first introduced in a pre-enterprise level business. The result is a range of different, simple tools, even if they came from the same vendor.  So as the scope or quantity of the workload increases, users end up needing to take a significant step forward, which is where they hit the wall as there is no underlying platform that can carry the users forward to the next level.

Those tools can come from a range of different technology starting points, even when from the same vendor, yet they tend to end up at the same point - an inability to scale or be personalized, extended or otherwise modified. In addition, this makes change more difficult, and to be avoided if possible, because the user becomes increasingly locked in to the investment, trying to make it work and extend its life until that is simply no longer possible. It no longer fits with other important tools and services, such as cybersecurity capabilities, that met modern software design policies or externally regulated requirements for future business practice:

They need the options to rebuild, refactor without doing a heavy lift, and then finally to start automating processes. But so often attempts at automating processes break other parts of the business. Was it prompted by COVID? I'm not sure, but what I can say is that software now defines the business and the business is defined as the software. Progressive organizations are now bringing that to the heart of what they do, and they're building building IP around technology.

OutSystems, in terms of code, is industry standard .NET that works with the many software elements that are available on the generic low-code framework, Forge. In terms of business transformation, this opens up the the range of software engineering tools available on Forge. The company is also looking to create more reusable tools such as templates and code, all aimed at allowing developers a fast start on projects, said Vyas:

We are looking to democratise that advantage with our platform. That way we can make the average organization compete better against the likes of Netflix or indeed Amazon.

He observed that the driver here is the speed at which businesses now need to adapt and change in order to compete, while at the same time those that can compete can now do so with the biggest, on the same terms:

The days of multi-year IT projects are dwindling. People really want software delivered into the business in a matter of weeks or months, not months to years.

Road-blocks

Vyas identified three road-blocks that often get in the way of companies making the transition to an environment where they can meet those goals.

The first is the on-going increase in application complexity makes using traditional methods of applications building really difficult. In addition, there is no simple way, when using traditional resources, to break down some projects. Second is that talent is hard to get, and increasingly difficult to afford. As for the third:

The third is the application backlog. Those first two precipitate an application backlog which is completely stalled. In speaking to customers, what I find is, because they take shortcuts in the way in which they build software, what happens is the quality of the production releases tend to be fixes, which means that your frequent backlog very rarely gets bumped down. This is a vicious cycle many continue to have. So what they need is a way of building software that addresses the quantity of the people, the complexity, and the velocity that a business needs.

Platforms are now seen as essential basis for this and are becoming one of the next big areas of contest amongst vendors. Having a platform on which a wide range of business applications – and the processes built with them – can run in useful collaboration is going to be a major capability all businesses will be looking for. Owning that platform is an obvious vendor goal.

One of the interesting issues for users in this development is that platform contenders all seem to be approaching a common middle ground from a number of different start points. For example, ServiceNow is coming in from the operations management end, while Appian is coming 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 transformation programs.

Guidance

The guidance that Vyas typically gives to customers is that departmental point solutions can be built using low/no-code providers, and will work well so long as no further development is planned or expected. However, if change is part of the plan, and multiple changes part of the expectation or if those changes would typically be engineered using traditional code or if the goal is differentiation and significance in the market, those low/no code tools will not cut it.

To be fair, this is broadly similar to the advice that has come from the other platform-pitching vendors and it does raise an interesting side issue when it comes to future platform choices for users. Put simply, is the choice of platform likely to become the next ‘wall’ against which users come to a dead halt? The common statement now is that the new platforms can accommodate all traditional applications technologies and the low/no-code offerings of other vendors, which is good – backwards compatibility seems largely taken care of. But what of forwards compatibility if all are vying for the role of being the 'manager of the managers’?

The platform marketplace has to be one where commonality is more important than differentiation in the marketplace, otherwise those differentiations will be the snares into which users will unwarily wander and from which walls will be built. Vyas concluded:

What we're saying is, we've got the ability to extend the functionality of those tools in a way in which the customer wants to extend, not the way in which the vendor perceives that extension. We're saying that the customers have a choice - and we respect that and that they've made investments - but they can use our systems to extend the efficacy of those, because they're not working for them today. That's why we link into those systems in terms of ServiceNow and its ambition to be at the top. it's not just about integrating with the customers’ eco-system. It's about integrating with the wider world, or bringing a third-party services, party payment services, authentication, etcetera. So they're looking at which does integration.

My take

Interesting times. Not new, of course, but maybe more important than ever before. The appearance of new platforms all broadly pitching at the role of ‘managing the managers’ – the one primary overseer of all business activities both as individual operations and as a single business entities – is simultaneously both a good thing and a risky thing. They are, collectively and individually, good, if only because the increasingly complexity of business operations is now stretching human management capabilities to breaking point. The need to automate so much of it is now great.

It is also risky, for each of the contenders is coming at the issue from different angles, and with different views on what the really important issues are in getting over-arching business management to work effectively. This means that there is a real danger for early adopters to find themselves siloed down a dead-end of a solution that suited their early needs but has failed to pass the test of time.  Yes, this has always happened in the past, but this time, the scale of the impact of getting it wrong is likely to be several orders of magnitude greater – and more expensive.

Now, therefore, is the time to suggest that patience really will be a virtue in making vendor choices. In addition, add one important question to all the others you might ask of vendors - how will your platform work with any other of the platforms if your platform is no longer appropriate for our business future? Any answer along the lines of, `They will have to engineer the compatibility required’ should really cause you to run away with pen still in pocket.

Indeed, it is perhaps time to call for the development and acceptance of some level of common minimum standards of compatibility across all contenders so that users can be assured they will not find themselves boxed in and hobbled, regardless of the choices they may soon be taking, for those decisions will have far reaching consequences.