Pega’s Low-code Factory Approach to citizen development is ideally suited when an organization wants to support the proliferation of hundreds of simple applications that are built and owned by the same person: the maker. For the simplest use-cases, makers can build workflows entirely in Pega’s App Studio, which means that training requirements can be basic, coaching can be light, and time to value is low (in part due to App Studio’s no-code visual interface, and in part due to the use of templates to accelerate workflow development). Used in conjunction with Pega App Factory, this approach also supports delivery at scale because the enforcement of many best practices and technical guardrails can be automated in ways that reduce the need for ongoing intervention from IT.
As an organization’s citizen development program matures and makers become more skilled, the program may expand in scope and become open to delivering applications that are slightly more complex. For moderately complex departmental use-cases, it is possible to extend access to some makers beyond App Studio and into Dev Studio. With increased access to Pega Platform capabilities, comes greater power but also greater exposure to risk and a lower ability to automate compliance with best practices.
When a citizen developer program expands to allow some makers to take on more complex use-cases, several additional steps should be added to the build and deployment process:
Training
To ensure success and to mitigate risk, makers should complete the right training prior to gaining access to more advanced features of Pega Platform. As part of the onboarding process, Practice Managers should assess maker skills against the complexity of the proposed build and recommend completion of appropriate training before provisioning an environment. (See below table).
|
Mission |
||||
|---|---|---|---|---|
| Role(s) | Makers | Coaches and Advanced Makers | Practice Managers | |
| Skills |
|
|
|
|
In addition to technical low-code training made available via Pega Academy, many programs will want to supplement with bespoke training that includes additional business-specific content including governance, policies, additional technologies, and general ways of working.
Testing
A Pega guardrail compliance score of 85% or higher should be achieved for any Pega application in production, regardless of its complexity. Guardrail scores may be viewed via the Application Quality Dashboard in Dev Studio
For makers only using App Studio, the use of templates and pre-built reusable components will largely automate compliance with technical guardrails, but guardrail score checking is still an important step in the deployment process. A security review is also recommended, but not required.
When power users are given access to Dev Studio, however, additional measures beyond checking the guardrail score are required. The deployment process for these moderately complex applications should include functional and scenario testing, unit testing, as well as a security review.
To ensure upgradability, the App Studio Compliance tool in Dev Studio makes it easy to test the user interface. A list of additional checks is also available via the Pega Wiki.
Documentation
Customized documentation is automatically generated by App Studio, but enterprise IT may have additional requirements that it wants to put in place for more complex apps. More robust documentation requirements are okay, but caution should be exercised by IT to strike a balance between the need for continuity, the complexity of the application, and the experience of the maker. If requirements are too onerous or complex relative to the criticality of maker-developed applications and are difficult to justify from the perspective of business users, then makers may be discouraged, give up, and/or look for alternative and unsanctioned paths to automation.
Support
Regardless of application complexity, it is important from the perspective of long-term growth and sustainability that makers themselves continue to own the applications they create. However, there should always be a contingency plan in case the maker changes their job function or leaves the organization.
Data Access
Standard guidance for maker-built apps is that they are limited to internal users within a single department, that they do not require access to sensitive data (such as Personally Identifiable Information), and that they do not write back to systems of record. Where a maker has a business case to justify access to sensitive data, necessary approvals should be obtained and documented, including approvals for system owners. At every step, stakeholders should be comfortable that the use-case is a fit for maker-led development and be prepared to ‘graduate’ the application to IT ownership with significant increases in criticality.
It is important to keep in mind that just because a maker is advanced enough to use Dev Studio doesn’t mean that they should use Dev Studio. The default guidance to any maker should be to use App Studio where possible. If the maker requires capabilities that are not immediately available in App Studio, they should be added as reusable components. When complex requirements are proposed, a conversation should be had about the extent to which that complexity is actually necessary to drive real value. And before granting Dev Studio access, practice managers should carefully consider whether the need for additional complexity signals an increase in business criticality. If so, then graduation to co-production or IT ownership may be the best approach.
Related Resources
- Pega App Factory: A Day in the Life
- Empowering citizen developers through Pega’s low-code factory approach
- How to qualify a citizen development use case using Pega’s Low-code Factory approach
- Automate workflows faster than ever before! Introducing Templates for Pega App Factory
Don’t Forget
- JOIN THE CONVERSATION on Collaboration Center
- FOLLOW @PegaDeveloper on Twitter
- SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS