Co-code - solving for IT shortages, no-code governance and a composable future

Demand for automation across the enterprise is outstripping supply, with business users constantly begging overworked IT teams to help them implement more streamlined digital processes. No wonder that many business teams are turning to no-code and low-code tools and workarounds to bypass the IT logjam. But that merely sets up problems for the future, when the perils of making changes to undocumented automations built using long-forgotten tools will suddenly become plain.

Instead of running at cross-purposes, business and IT teams need to unite in a shared strategy that maximizes the pace and impact of automation, while minimizing wasted effort and unintended disruption. The core principles of how to make this strategy work are now beginning to emerge, based on two enabling trends. The first of these is the adoption of a more componentized approach to IT, which makes it possible for low-code and no-code tools to be built on the same building blocks used in IT by professional developers. The second is a more collaborative approach to automation and data projects in which pro coders work alongside business users of no-code and low-code tools — we call this co-code.

The 'co' in co-code stands for both of these ingredients — 'co' as in collaboration, and 'co' as in composable. The nature of the collaboration and the composability varies widely. In some cases, professional developers continue to take the lead, collaborating with business users throughout the design, development and testing of a project. In other cases, they take more of a back seat, providing the enabling components and guiderails but giving business users free rein to go on to create their own automations or data insights, while remaining available to offer advice and guidance when called upon. Let's look at some examples.

Automating around ERP

One of the most pressing arenas for improved automation and data insight surround core enterprise applications such as ERP. We're seeing vendors acknowledge this demand by introducing no- and low-code application builders. For example, midmarket ERP vendor Unit4 is introducing a visual tool for building workflow automations and independent services that connect into its core platform. Any apps created in the AI-augmented, drag-and-drop tool run as independent microservices on the Unit4 multi-tenant cloud, which simplifies governance, as Claus Jepsen, Unit4's CTO, explains:

If you go out and acquire a toolset from an external vendor, that's a huge risk. However, if our customer uses our toolset, it's all on our platform. So you control it through the platform, you can see in a repository, so we have full visibility, what actually runs against the ERP.

But what if your business runs on an older ERP platform that doesn't have a microservices architecture? Earlier this year, Neptune Software unveiled a no-code app builder that extends its existing Neptune DXP product, which is a web-native and mobile app platform with deep integrations into core SAP systems and other enterprise application stacks. This underlying platform adds an API layer that effectively transforms the core SAP system into a set of APIs that can be composed into new applications.

The no-code app can be created from scratch or from a library of customizable templates and components, and AI helps users by suggesting possible next steps as well as automatically tagging newly created functions and screens to facilitate later discovery and reuse. The vendor believes its tool will appeal to pro coders as well as business users, and sees it being used collaboratively, with pro coders maintaining oversight while leaving business process owners free to build prototypes or try out modifications themselves. Helder Gonçalves, Chief Product Owner, says:

The App Builder has as a goal the technical requirement of being able to bring everyone together — business people, IT people, collaboration. The goal is to enable anyone to build applications, but without shortfalls.

Automation across teams

In many organizations, the biggest headache is automating processes that span multiple teams and applications. Here, digital teamwork applications are increasingly coming to the fore as a platform for this type of workflow automation. API connections to enterprise applications and data sources are brought in either via third-party tools such as Workato, Jitterbit, Boomi and others, or in some cases with native tools such as Power Automate in Microsoft Teams. Salesforce subsidiary Slack just announced the open beta of its own drag-and-drop Workflow Builder, designed for no-code use by non-technical users, but which also allows pro coders to create custom reusable building blocks such as functions and third-party integrations.

Another Salesforce product that's just entered open beta brings no-code application creation into the same development pipelines as professional DevOps teams. This brings us back to the issue of IT governance, ensuring that the democratization of application development through these no-code tools doesn't introduce anarchy across the enterprise IT estate. DevOps Center makes it possible to bring Salesforce administrators and business application builders into the same processes that professional developers use to manage version control across the DevOps pipeline.

It says something that all of the examples I've cited above are still currently in beta rather than generally available in production. This is clearly still an emerging trend, where vendors are mostly playing catch-up to what the market desires. At the same time, it makes sense for enterprises to do the work now to start preparing for delivery of these capabilities. Here are three core principles to bear in mind.

1. Avoid fragmentation, embrace composability

Enterprises need to avoid a proliferation of no-code tools with no IT oversight. While there's no way to stop business colleagues going off and using their own workarounds — and I would defend their use for initial prototyping — a total lack of standardization inevitably leads to duplicated and wasted effort, as well as storing up problems for the future, as noted earlier.

At the same time, it's going to be unrealistic for most organizations to standardize on a single platform that will suit all of its business needs. At the very least, there will be some kind of digital teamwork backbone that connects people, processes and data across the enterprise, as set out in our Collaborative Canvas framework. It's likely that there will be separate tooling around key enterprise applications, such as the examples given earlier. What's important now is to map out the likely key features in this landscape and start to sketch out a roadmap towards that future state.

The landscape needs to be able to support the API-driven, building block approach that these toolsets support. A fundamental part of this planning therefore is to understand the future evolution of the IT landscape towards a composable, Tierless Architecture that will accommodate the various functions, resources and touchpoints as the enterprise continues to respond to changing demands and circumstances.

2. Change mindsets, nurture collaboration

Forgive me while I go off on a short rant here, but it's essential to break out of the compartmentalized mentality of traditional enterprise functions. Today's IT logjam and the consequent pursuit of backdoor 'shadow IT' by business teams have arisen largely because of the legacy of a disconnected, siloed organizational structure, rooted in a pre-digital era. This saw the IT function as akin to an assembly line that churns out fixed projects to order, while business teams are seen as having no IT capabilities of their own. This strict demarcation of functions made sense at a time when paper was the primary medium for recording instructions and specialist knowledge was laboriously acquired. In the digitally connected era of Frictionless Enterprise, those constraints no longer apply, but they remain baked into organizational processes. A completely new set of processes have to be put in place, along with a fresh mindset and culture focused on open collaboration.

That change of mindset is emerging as DevOps evolves, expanding its initial combination of software developers and IT operations to now include product managers and designers, as well as the trend towards what industry analyst firm Gartner calls fusion teams, which "blend technology and business domain expertise to work on a digital product." Digital connection is enabling this cross-functional working in atomic, focused teams and I believe it also gives specialist functions such as IT the ability to remain continuously engaged with their business counterparts, acting as a constant guide and mentor, rather than the old model of a remote back-office function focused solely on completing job orders and projects with minimal or no engagement. Forward-looking IT teams need to embrace this more engaged role, becoming centers of enablement rather than hoarding their expertise.

3. IT becomes tech

In conversations with IT leaders who are already adopting these emerging trends, I increasingly hear people talking about themselves as business technologists rather than IT specialists. Digital technology has now become so important across every aspect of business that it can no longer be portrayed as a back-office function that operates in its own silo. Technology expertise has to become available as efficiently as possible to every part of the organization, so that automation and data analysis can be something that every business person can manage and control. We're not there yet, but the direction of travel is becoming clear.