Gartner currently thinks of a citizen developer as “an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units.” Pega’s Low-code Factory Approach considers one kind of citizen developer, which we call a Pega Maker. What distinguishes a Pega Maker from a citizen developer more generally is that they use a platform that is sanctioned and supported by IT (rather than simply not being forbidden), and that they are users of the applications they create even if others might also benefit.
Obviously, not every use case is suitable for a Pega Maker. But where’s the line between what a Maker should take on, and what’s best left to the professionals?
By democratizing intelligent workflow and application development through access to low-code tools, organizations can expect to see a reduction in IT backlogs, a decrease in development costs, and productivity benefits associated with the automation of manual and routine tasks. Using templates in Pega App Factory ensures that Makers have the tools they need to succeed without also sacrificing security. The return on investment is clear, as Forrester observes, it is typical to see an 16% decrease in development costs combined with a 12% increase in productivity savings per user per app.
The value of citizen development comes from the ability to quickly automate many simple processes as a complement to professionally developed low-code apps that solve the most complex challenges. In this post, I’ll provide guidance for how to qualify an app along three axes: Maker readiness, app criticality, and app complexity.
Maker readiness
Most new Makers will never have used Pega before, and they are unlikely to consider themselves ‘citizen developers.’ Their top priority is to get work done within their department and they are looking to automate manual processes for themselves and those around them. Because the most important thing to a Maker is the ability to solve a problem quickly and easily, it’s incumbent upon Low-code Factory Practice Managers to verify that they are set up for success before they even get access to Pega App Studio for the first time. Practice Managers, therefore, should ask the following questions:
- Does the Maker have the skill necessary to be successful? Pega App Studio is easy to use, but you can decrease time to value and increase app quality if the Maker has completed high quality self-paced learning in advance. The most successful programs require at least the successful completion of the Low-Code App Builder Mission on Pega Academy.
- Does the Maker fully understand the business problem they are trying to solve? You should include a request for details about the business problem as part of the Maker intake form in Pega App Factory. If the business problem doesn’t seem well understood, the Practice Manager should coach the prospective Maker to clarify the process they are looking to automate. The Practice Manager will reject applications from Makers once they’ve clarified the problem if the business problem has already been solved by an existing solution within the enterprise IT landscape, or if the proposed app is either too critical or too complex to be considered for citizen development.
App Criticality
We can determine an app’s criticality based on the scope of its use (i.e., is it meant to serve a small number of users within a work group or department? Or is it an application that large numbers of users from multiple departments are likely to benefit from?), and the amount of risk and reward it represents.
A Maker is typically the product owner of the applications they create. Where they are serving themselves in addition to others working in the same department, bug fixes and feature requests are few and are likely to benefit the product owner as much as those around them. If, however, the application is likely to serve users across multiple departments, the number of requests may increase and the requests themselves may be unique to departments other than the Maker’s own. Where this is the case (either for a new app or an app that has broadened its user-base over time), an organization has a couple of options:
- The Maker’s manager agrees that the Maker’s work is sufficiently valuable to the organization overall and formally adds app management to their set of responsibilities.
- Co-production with Makers in other departments so that effort is distributed, and Makers can more effectively represent the needs of a diverse set of users.
- Full ownership by IT because rates of adoption are expected to continue to grow.
An app’s criticality is also a function of its potential value and risk associated with its use. A very simple app that delivers significant value and that would see major repercussions for the organization if it were to go down may not be a good fit for citizen development, even if a Maker had sufficient skills to build it on their own. Likewise, if the app could expose the company to certain kinds of risk (financial, legal, security, reputational), it might not be a good fit for citizen development. Important questions to ask that are related to app criticality include:
- Will the app be customer-facing?
- Does the app require access to sensitive data (e.g., personally identifiable information, financial records, etc.)?
- Does the app write back to a system of record?
- If the answer to any of these questions is ‘yes,’ then the use case might not be right for a Maker to own.
In the early days of a Low-code Factory, it may be best to be more restrictive when it comes to data access. The use of templates in Pega App Factory can ensure that Makers have access to the data they need without having access to the data that isn’t role appropriate.
As a Low-code Factory matures and Makers become more experienced, the use of templates also allows for different levels of access depending on the Maker’s skills and approved access to data. Where access to sensitive information and the ability to write back to systems of records is given to some Makers, we would recommend additional training requirements (successful completion of the Low-Code App Builder - Extended Mission on Pega Academy) in addition to approvals for access to sensitive data. Access to more advanced features in Pega App Studio is provisioned using templates in Pega App Factory, which can also manage and document your approval process.
App Complexity
The power of Pega App Factory to automate the enforcement of technical guardrails assumes that Makers only work in Pega App Studio. But what if the Maker wants to build an app for their workgroup that requires features not available to them in Pega App Studio?
When a Maker requests a feature that is not available in Pega App Studio (either natively or as part of the reuse layer) the Practice Manager should ask the Maker the following questions:
- Is the requested feature necessary for the application to solve the business problem? Especially as your Pega App Factory matures and your reuse layer is robust enough to include the most common integrations and shared components, it may be that the requested feature isn’t necessary. A ‘nice-to-have’ feature (like UX changes, for example,) may not have a sufficient impact to justify professional development effort.
- Is the requested feature something that would benefit other Makers? If the requested integration or component would provide value to other Makers, then the Practice Manager should add that feature to their Low-code Factory roadmap and work with their Pega Center of Excellence (CoE) to prioritize adding it to the reuse layer according to the value it is expected to deliver. If the request is for something that is unique to a particular project, then the CoE may decide to build it into the reuse layer anyway, or to co-produce the app in a way that would see IT take on ownership of the app but give the Maker access to make role-appropriate changes as an SME.
- Does the added complexity signal an increase in criticality? If the maker of an existing app requests a feature that is not currently available to them — like integration into a new system, for example — it may reflect a change in its scope or risk potential. Where more complexity does not signal an increase in criticality, the Practice Manager should work with the Maker to make sure that it is necessary. Where it does signal an increase in criticality, the Practice Manager should reassess the application to ensure that it is still fit for citizen development or if it belongs with IT.
In summary, the value of Pega’s Low-code Factory approach to citizen development comes from its ability to increase business productivity by empowering Makers to create intelligent workflows that automate hundreds and thousands of simple processes without exposing the organization to risk and without increasing IT burden through reliance on manual governance practices. Using Pega App Factory in support of Pega’s Low-code Factory approach to citizen development guides Makers and Practice Managers to ensure that apps are a good fit for citizen development, and leverages templates to ensure role-appropriate access to data and other more advanced features.
Recommended Resources:
To learn more about citizen development and how your organization can get started, check out our eBook: Building your Low-Code Factory: A Best Practices Kit for Success.
Don't Forget
-
JOIN THE CONVERSATION on Collaboration Center
-
FOLLOW @PegaDeveloper on Twitter
-
SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS