Low-code tools enable both professional software engineers and non-technical ‘citizen’ developers to build their own business applications with little or no need for coding by hand.
Departmental requirements often drive such efforts, as individuals within each department can collaborate with their IT departments to create customer and employee-focused apps in a lightweight, iterative manner.
In many cases, the focus of such applications is on simple automations – freeing people within the department (or in some cases, customers) from having to complete various tasks manually.
Scaling up such simple automations to cross-organizational processes, however, is more of a challenge. Organizations struggle to scale small-team departmental efforts to the cross-departmental and enterprise-wide levels.
Here are some tips for overcoming these challenges.
Are Scale and Agility at Cross Purposes?
It seems that scaling up departmental low-code efforts can take two paths, both of which lead to problems.
One approach is to spread the love – empowering many individual departments to leverage one or more low-code platforms to build their own applications.
All too often, spreading the love in this way leads to shadow IT – where departments build apps outside the purview of a common governance framework, leading to redundant efforts, uneven quality, and security vulnerabilities.
The other common approach to scaling up departmental low-code efforts is to bring in established, traditional enterprise software development and operations practices.
Such practices apply a ‘heavyweight,’ waterfall-centric mentality that extends the timeline of projects, adding to their cost and inflexibility.
While traditional management techniques can institute effective governance, such processes and procedures come with an expensive cost: the loss of agility.
Neither shadow IT nor heavyweight enterprise software practices lead to the desired outcome: flexible, customer and employee-focused software that responds nimbly to changes in business requirements while maintaining necessary governance and compliance strictures.
There’s got to be a better way.
Finding the Middle Path
What we’re experiencing in the enterprise software world today is no less than a generational shift in how organizations build and run software.
The old way is heavyweight, time-consuming, expensive, onerous, waterfall-centric, customer adverse, and management-led.
You can easily recognize such old-fashioned software efforts, as they tend to cost millions of dollars, take over a year to complete, and involve reams of requirements documentation that rarely aligns with what the users of the software actually want once the project is complete.
The new way to build software is stark in its contrast to the old way. This modern approach is lightweight, iterative, efficient, Agile-centric, customer-focused, and self-organizing.
The challenge we face, therefore, is scaling the new way without falling into either the trap of shadow IT nor the discredited patterns of the old way.
Governed Self-Organization is the Key
The solution depends on how we handle the self-organizing part of the modern approach to software creation.
Low-code tools, in fact, encourage and leverage self-organizing teams. People within each department decide how best to build applications, given the skills they have available and the goals of each application.
Self-organization, therefore, works well on this smaller organizational scale as it empowers the people involved in the creation process.
In order to scale this self-organization beyond individual teams and departments, we must move to a governed self-organization model.
The organization must implement governance ‘guardrails’ that keep individual departmental low-code efforts on track, assuring they coordinate their efforts while addressing compliance and security concerns – without slowing down the efforts or otherwise shifting to old-fashioned onerous software procedures.
The people who craft the guardrails, in turn, should belong to a low-code center of excellence (CoE) – as long as the CoE itself is self-organized, so it doesn’t become an isolated ‘ivory tower’ in the organization. In other words, CoE might also stand for center of empowerment.
A CoE works with individual departmental teams as well as the IT organization and management in order to hammer out any practices that will keep disparate low-code efforts on track. For example, a modern CoE might:
- Coordinate important regulatory constraints and work with IT Ops to ensure all low-code projects work within the constraints (hence the ‘guardrail’ metaphor)
- Work with the data team to hammer out common data standards across separate low-code efforts, perhaps even defining a common data model that supports those efforts
- Work with the integration team to establish common integration practices (for example, standard APIs and data formats) that all low-code projects can leverage as necessary.
- Work with enterprise process leaders to coordinate the cross-departmental automation needs of the organization with departmental, low-code enabled automation activities.
This list of priorities for a CoE, however, is only a starting point. Every organization is different, and thus has different priorities. One of the benefits of a self-organizational model is how well it can respond to such differences.
The Intellyx Take
What a particular organization calls its CoE isn’t important. What’s important is how the organization empowers this team to coordinate various departmental efforts, thus enabling the organization to scale its low-code automation efforts to the cross-departmental and enterprise-wide levels.
In addition, OSF formed a performance improvement team (sharing aspects of a CoE) that was responsible for building applications that improved cross-departmental collaboration while enhancing transparency and visibility across the organization.
OSF was also able to implement a central database that supported multiple low-code projects across the organization.
In other words, OSF extended the self-organizing, low-code approach that worked at the departmental level to solve cross-organizational challenges without falling into either the trap of shadow IT nor old-fashioned heavyweight software practices.
As a result, OSF achieved the scale and agility benefits that the middle path between lightweight and heavyweight software approaches promise: the ability to build patient-focused applications quickly while reducing costs and maintaining the governance guiderails that enabled them to scale their efforts while maintaining their standard of patient care.
Copyright © Intellyx LLC. Quickbase is an Intellyx customer. Intellyx retains final editorial control of this article.