Distributed Development

A scalable framework for harnessing citizen innovation

“When you create the ship, you create the shipwreck… Every technology carries its own negativity, which is invented at the same time as technical progress.”?— Paul Virilio

Executive Summary

The use of No Code / Low Code (NCLC) tools by citizen developers presents novel opportunities and challenges for the enterprise. Though vendors are quick to extol the benefits of their products, technology decision makers must balance the demands of the business with security, compliance, and sustainability. Instead of NCLC tools earning a permanent position in enterprise tech stacks, they languish in a state of incomplete adoption and ambiguous ownership.

Modern businesses need an operational framework that reconciles the hidden risks of unchecked citizen development with the benefits of increased participation in the development process.

This article aims to answer these questions:

• What are the risks and benefits of citizen development?
• How can organizations leverage NCLC platforms in a sustainable manner?
• What are the implications for the market?

The Paradox of Citizen Development

Software development is hard; building for the enterprise is even harder.

NCLC platforms make software development more approachable by abstracting traditional software components into familiar building blocks. These building blocks can be connected and combined, eventually composing robust business functionality. Leading platforms offer use-case-specific templates for “Project Management” or “Content Calendaring”, allowing any employee to test the waters of citizen development with a single click.

Citizen development is an alluring concept. Savvy employees can create the tools they need to do their work without learning to code. This act of creation can be a source of pride, which is magnified when the creator shares their work with colleagues.

Employees engaged in this work have one significant advantage over professional developers: domain expertise. The overhead of gathering requirements, generating user stories, or constructing reference models can be reduced or eliminated, because the person designing and building the solution is immersed in the domain — they are both the app builder and the app user.

When a solution is built this way, IT is spared a development project, the citizen developer receives credit for their contribution, and the business problem is ostensibly solved.

As much as vendors would have you believe that any employee can drag and drop their way to no code nirvana, the same traps, challenges, and tradeoffs found in professional application development apply to citizen development.

What could go?wrong?

In complex systems, architecture dictates performance, scalability, maintainability, and all the other “ilities”. The professor who first applied the notion of architecture to a systems context was Eberhardt Rechtin, who stated: “The essence of architecting is structuring. Structuring can mean bringing form to function, bringing order out of chaos, or converting the partially formed ideas of a client into a workable conceptual model. The key techniques are balancing the needs, fitting the interfaces, and compromising among the extremes.”

For the citizen developer spinning up a simple workflow, defining an architecture sounds like overkill. “It’s a simple project management app” they say, “it doesn’t need architecture, it works right now.” This perspective is rational, but naive.

Solutions built without an upfront investment in architecture are susceptible to both subtle and catastrophic forms of failure. Symptoms include trouble integrating with external systems, diminishing performance as additional users are onboarded, or data loss and duplication.

The cure is refactoring — a process daunting enough to cause even seasoned developers to recoil. More commonly, these solutions are abandoned or rebuilt.

The value provided by a citizen-developed solution depends on an array of factors, including the size and composition of the user base, the criticality of the workflows addressed by the solution, and the ease with which the solution can be extended or enhanced to address adjacent use cases.

Citizen developers who build valuable applications for a large number of users discover the reality of solution ownership: trouble tickets, feature requests, user onboarding, and enablement. The dream of citizen development quickly becomes a nightmare as the citizen developer attempts to balance these new responsibilities with the job they were hired to do.

Here lies the paradox: Citizen developers who succeed in building something of value either relinquish core responsibilities to free up bandwidth for development work (developer > citizen), are overwhelmed by the overhead of solution ownership, resulting in solution failure (citizen > developer), or in anticipation of either outcome, abandon the solution and settle for being a regular citizen again.

This paradox of citizen development is the reason CIOs and other technology leaders relegate NCLC platforms to a tier reserved for shiny toys and trendy apps.

But what if citizen developers could pursue their ideas with the confidence that qualified assistance is readily available?

What if CIOs could empower employees to innovate and experiment without sacrificing security or stability?

What if vendors could shape their platforms to make that future possible?

A New Delivery?Paradigm

Imagine solution ownership on a spectrum: at one extreme lies full democratization, and at the other, complete centralization. Full democratization fails because of a diffusion of responsibility, challenges with integration, and lack of quality control. Complete centralization is equally doomed due to limited development resources, insurmountable backlogs, and the threat of shadow IT.

Between the two extremes lies Distributed Development, a delivery paradigm characterized by ubiquitous access to NCLC development platforms, layered solution control, and a hierarchical network of Citizen Innovators and Digital Operations Architects.

Citizen Innovators

Citizen Innovators are non-IT employees who actively engage in the software development lifecycle. Participation may be continuous and hands-on, as in the case of those who build databases, automations, interfaces, and other application components, or may be sporadic and indirect in the form of providing solution feedback, producing enablement materials, and curating data.

The more generic use of Citizen Innovator over Citizen Developer is constructive because its broadens participation to include those employees would not describe themselves as “technical”, for whom the word “developer” is unrelatable.

For Citizen Innovators to safely and sustainably contribute to Distributed Development, they must retain the right to relinquish ownership of the solutions they produce. In cases where solutions developed at the business edge gain traction and usage, relinquishing ownership to the Distributed Development network protects the Citizen Innovator from becoming trapped as a product manager, and allows scaled resources to support and scale their work.

Digital Operations Architects

The natural inheritor of an edge-developed solution is the Digital Operations Architect aligned to the Citizen Innovator’s business unit. These professionals are responsible for integrating the various solutions serving their functional area. It is the Digital Operations Architects who maintain product-agnostic domain models that serve as blueprints for their Citizen Innovators. As business processes evolve, Digital Operations Architects liaise between leadership, management, and Citizen Innovators to update the models accordingly.

Depending on the size of the organization, more than one tier of Digital Operations Architects may be needed to provide sufficient coverage. In the same way that Citizen Innovators can relinquish solution control up the chain, Digital Operations Architects can likewise transfer ownership of their systems to the next node in the hierarchy.

At the highest level of each functional hierarchy is that function’s distributed development lead, who represents their function in the Center of Excellence.

The Distributed Development Center of Excellence

Distributed Development is powered by a Center of Excellence (CoE) model, which provides the expertise, resources, and policies that enable and govern development activities. Centers of excellence are commonly used to coordinate cross-functional support for a focus area like workplace safety, environmental sustainability, or data analytics.

Where possible, executive sponsorship for the CoE should come from CIO, CISO, or CDO. In practice, the CoE is steered by a committee comprising the lead Digital Operations Architects from participating business units. Vendor personnel, including customer success managers and other field roles, are loosely aligned with the CoE as external resources and advisors. Agencies providing design or implementation services are likewise aligned to the CoE.

Data Governance

Security and compliance is a primary concern for the steering committee, which partners with the information security and compliance functions to define, implement, and maintain data classifications and access controls. Training and certification may be used to gate which datasets or endpoints a citizen innovator can access.

Standards and?Policies

The rules outlining when and how a solution is transferred from a Citizen Innovator to a Digital Operations Architect are likewise maintained by the steering committee. These policies seek to balance risk and control. Examples include:

• Reach of a given solution: “Edge-developed apps with users spanning more than one business unit must be passed up to the first Digital Operations Architect whose scope includes all users”
• Sensitivity of the data: “Apps with write permissions for Tier 1 and Tier 2 data must be managed by Digital Operations Architects”
• Integration surface area: “Apps that integrate with messaging and calendar platforms may be retained at the edge. Apps that integrate with backend systems, financial systems, and field-facing systems must be managed by Digital Operations Architects”

Support Activities

Systems work is an obvious focus for Distributed Development, but ancillary activities like user enablement, system documentation, change control, and feature prioritization are equally critical to sustaining the model. These support activities originate with the solution itself, and follow the solution as it moves inward toward the CoE.

The CoE provides training and tooling to help Citizen Innovators and Digital Operations Architects perform support activities in a consistent, efficient manner. When the burden of support activities for a given solution exceeds the solution owner’s capacity, this is a signal to either streamline the support activities or pass the solution up the hierarchy.

Implications for the NCLC?Market

The Solution Value?Chain

When an organization buys licenses to access a development platform, work must be done in order to receive business value from that platform. In this sense, platforms do not provide value “off the shelf” — customer value is derived from the applications developed on the platform.

Fundamentally, application development platforms provide elements that can be combined to create system structure and behavior. This includes data types, functions, triggers, endpoints, and anything else that might be used to build a solution. Let’s call these elements “Platform Primitives” — think of these as atomic units of development.

The use of design patterns in traditional software development dates back decades. Design patterns are named arrangements of simpler elements that can be applied in a variety of contexts to achieve the same effect. Here we will adopt “Design Patterns” to describe useful combinations of Platform Primitives. In this way, Design Patterns are like molecules.

To produce what we’ll call “Functional Solutions,” the builder selects and applies Design Patterns to achieve specific requirements. To strain the metaphor, Functional Solutions may be likened to polymers.

Once the Functional Solution is released to users and imbued with data, it becomes a “Production Implementation.” Solution value increases with each step along the chain, but customer value is realized exclusively in this final step.

This Solution Value Chain model offers vendors, customers, and partners a simple language to anchor conversations about feedback and to test new features.

Think about NCLC platforms like a cake shop. Production Implementations are the delicious cakes that customers buy. Those cakes come in a variety of shapes and sizes and flavors for different occasions, like Functional Solutions. They’re all made up of common components like frosting, filling, and cake. These are the Design Patterns. Each of these was created from the Primitive ingredients of flour, sugar, chocolate, and the like.

Bakers don’t offer customers a sample of the new flour they plan on using in their cakes, because the customer can’t reliably predict how the new flour will affect the quality of the final product. Instead, the baker swaps out the flour in a reliable cake recipe and offers customers a sample of the new cake — or better yet, a side by side taste test. NCLC platform vendors should do the same.

• When an end user finds something is broken, they are giving feedback about the Production Implementation. This can be called a bug report or trouble ticket.
• When an end user can’t perform a task they expect to be able to perform, they are giving feedback about the Functional Solution. This can be called a feature request to the solution builder, or a previously undiscovered functional requirement.
• When a solution builder combines platform features to do something useful across multiple contexts, it is a potential entry into the platform’s Design Pattern language.
• When a solution builder identifies gaps in the tools available to design a particular solution, that is feedback about Platform Primitives. This is true product feedback.

As NCLC platforms mature, product teams build new Platform Primitives. Prior to public release, Primitives are subjected to beta testing or dogfooding (the practice of allowing vendor employees early access to unreleased features). It is impossible to assess the potential business value of a Primitive in isolation, and yet product teams solicit generic feedback from customers and employees after flipping on the feature flag.

Instead, Primitives should be evaluated for their impact to the Solution Value Chain. First, identify any new Design Patterns made possible by the Primitive in question. Next, determine if any existing Design Patterns can be simplified or replaced by the new Primitive.

The new or improved Design Patterns can then be assessed in the context of a Functional Solution, the first link in the chain about which solution end users have strong opinions. Beyond this stage, new Primitives can be assessed in Production Implementations, where they can be traced back through the underlying Functional Solution and its Design Patterns.

The Platform Presales?Paradox

Another paradox arises when presales engineers demonstrate NCLC products to line of business buyers. Let’s say a solutions engineer presents a demo of a CRM prototype to an audience of sales leaders and sales ops professionals. Questions arise concerning functionality: “Can this integrate with Porcupine Payroll? How does it handle opportunity splits? Can we get that chart in our brand colors?” The solutions engineer can answer in two ways: either they show or explain how yes, that’s a feature of this solution, or they explain that this is a platform, and the feature in question must be built.

This is the paradox — the closer a presales prototype gets to the functional solution the customer needs, the less that customer realizes the value of the underlying platform. Because of this, NCLC platform vendors that target specific business functions (product, marketing) unwittingly imperil their deployments by failing to provide a sustainable model for solution ownership.

Vendors would do better to sell the advantages of the Distributed Delivery paradigm — empowerment of domain experts to shape the tools they use, increased feature velocity, and improved agility to respond to changing requirements — rather than competing directly with leading point solutions.

Messaging of this sort is more likely to land with an operations or IT audience, whose work is impacted by shifting the delivery paradigm.

Vendor-Facilitated Distributed Development

It is not enough for vendors to document features and provide basic templates. For vendors to claim differentiated value, product management teams should invest in platform features that support Distributed Development, and product marketing teams should prioritize the publication and maintenance of the assets that Citizen Innovators and Digital Operations Architects need.

Vendors that adopt the Solution Value Chain model have an opportunity to dramatically improve the stability and serviceability of their product in the field by cataloging Design Patterns, maintaining Canonical Solutions, and publishing reference architectures.

Design Patterns are catalogued by assigning each a name and describing how the Platform Primitives are combined to achieve the pattern. Examples should be provided to demonstrate when and how that Design Pattern may be applied.

A Functional Solution is deemed Canonical when the vendor takes a position on how best to serve a set of use cases with their platform. Vendors should document their assumptions about the business domain, identify tradeoffs made in the design, and welcome qualified feedback as to how it might be improved. Solution builders can then browse and select a Canonical Solution to confidently accelerate their initial design work. Critically, the Solution Builder then has the documentation to decompose any aspect of the solution into its Design Patterns, exchanging or modifying each in accordance with functional requirements. This is the cure for shallow templates.

Vendors can further improve enterprise outcomes by integrating multiple Canonical Solutions to produce a reference architecture. As with Canonical Solutions, the reference architecture becomes valuable when the vendor explicitly documents their assumptions about the business domain and identifies tradeoffs in the design. This tangible, testable model for scaled deployments can elevate the dialogue between NCLC vendors and their customers from one about solution value to one about platform value.

Service Partners

Agencies, systems integrators, and service partners can leverage the Distributed Development framework to provide value to their customers. For the enterprise customer taking its first steps towards Distributed Development, partners can provide interim coverage of the Digital Operations Architect role on a retained basis. As the customer’s Distributed Development CoE matures, these embedded contractors can provide training and coaching, eventually handing off their role in the network to a full time employee.

Service partners can likewise apply the Solution Value Chain model across multiple technologies to develop their own Design Patterns and Canonical Solutions, provided they continuously integrate feedback from their customers back through the chain.

Outlook

As the quote from Paul Virilio at the beginning of this article suggests, new technology must be carefully assessed if it is to be harnessed safely. The NCLC market has witnessed its share of shipwrecks, but the Distributed Development framework presented here is a map that warns of shoals and hazards, and promises an exciting land beyond the horizon.

For those who take this map and embark on the journey — I wish you fair winds and following seas.