Low code during the Build phase

5 Topics
Release 1
Pega Express
English
In the Build phase of Pega Express™, you use Pega's low-code development platform to configure and test your application.
Pega Platform™ leverages Scrum along with out-of-the-box tools and best practices like DevOps' continuous delivery and
continuous integration paradigm to rapidly develop and iterate your build, gather feedback from your client, and ensure
alignment with business objectives.

After completing this module, you should be able to:

Describe how low-code development works for rapid delivery

Embrace the DevOps approach to ensure an efficient feedback cycle
Determine which Pega low-code workspace is better for your needs, App Studio or Dev Studio
Respond to project changes effectively and efficiently

Available in the following mission:

Pega Express Delivery

Topics

The Build phase

The Build phase
The Build phase is important in Pega Express™ because that is when you configure your solution. You start by building
solutions to the user stories prioritized for the first sprint. Use a Pega low-code platform such as App Studio or Dev Studio to
visually model and implement the user stories for each Microjourney™. For Customer Decision Hub you will use the Next
Best Action Designer to configure your solution.

At the same time, your team prepares and executes testing (for example, business testing and unit testing). Pega
Platform ™ supports the Build phase with automated testing tools for performance and functional testing of platform
components.

To keep the backlog filled with user stories that meet the definition of ready (DoR), the Product Owner and business architect
run Directly Capture Objectives (DCO) sessions engaging business team members and soliciting continuous feedback. The
output of these DCO sessions is the refined user stories for the Product Owner to prioritize into subsequent sprints.

In the following image, you see how the Build phase fits into the Pega Express delivery approach.
Build phase resources
For tools, templates, and resources to support the Build phase, go to thePega Express Delivery Resources page.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Low-code development
Definition of low-code
Low-code development has been described by Forrester as:

"Products and/or cloud services for application development that employ visual, declarative techniques instead of
programming…"

This is exactly what Pega has been doing for 30 years — creating Software That Writes Your Software™.

Benefit of low-code application development

As you manipulate and expand the visual model for your software, the low-code development tools create the code for you.
User interface capabilities such as drag-and-drop, process flows, and visual tools allow anyone, regardless of technical
ability, to create transformational software. This approach increases productivity, as everyday application development tasks
are streamlined, requiring less IT involvement. Low-code tools make application development simpler.

In the center of the following image, slide the vertical line to compare traditional coding with low-code tools available inApp
Studio.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Building with low-code tools

Many users think that a simple, easy to understand visual development tool is limited to creating very basic applications, on
par with something you could build in a spreadsheet. Pega's low-code platform can be used to create very robust
applications in a myriad of channels.
Here are some examples:

The marketing team replaced a shared spreadsheet used to capture and track requests with an email and web-based
request system
A multinational conglomerate built an enterprise-wide procurement management system in just six weeks
An international medical and care product company built a regulatory affairs submission management system in just
nine weeks

Pega's low-code technology lets you to build an application that captures data and initiates business processes. The
application can be a web page, a mobile application, or a chatbot that interacts with your client over Facebook Messenger.
You can build a solution that extracts data from an incoming email, or uses a robot to pull data from other software. Through
a visual interface, Pega empowers developers to build integrations to these systems to obtain the data necessary to drive
businesses process forward. It also provides a holistic view of the data landscape by creating a graphical mapping of the
data into the application, thereby empowering developers to build applications more easily and quickly.

Low-code and developers

While low-code enables the non-developer to create application code, it also helps experienced developers write code more
rapidly and effectively. Pega's application development studios enable developers to dive deeper into the Pega Platform™ to
craft a solution to the business problem, hiding the implementation, and visualizing the business logic for others to consume.
With patterns for reuse and extension built into the Pega studios, developers can build a solution once and leverage it many
times throughout the entire ecosystem.

Low-code authoring studios

A workspace is an environment that provides specific tools and features. By using different workspaces to develop and
manage an application, team members can focus on the tasks that align with their expertise. Pega Platform provides
four role-based, low-code, authoring workspaces, known as studios. They are:

App Studio
Dev Studio
Prediction Studio
Admin Studio

Each studio speeds application development and enhances productivity by providing users role-based functionality, as
shown in the following image.
 Tip: A Pega Express best practice is to use App Studio as much as possible for case-based applications as it helps
you build an application more quickly than Dev Studio, without touching a line of code and guarantees guardrail
compliance. Use Dev Studio only when building more complex and customized functionality that cannot be built in
App Studio.

App Studio versus Dev Studio

App Studio and Dev Studio Compared
Pega Express™ delivery promotes and supports speed to value with low-code options in the Pega Platform™. AppStudio
allows for a quick start with low-code features and visual designer capability to capture business objectives directly, enabling
quick prototyping. App Studio is an easier tool to use. However, with Dev Studio, developers can set up more
advanced application behavior. Information can be shared between both App Studio and Dev Studio.

The following image shows the differences between the features in the two Pega studios.

AppStudio
UI Authoring: Using the design templates provide easy UI configuration, such as cell level configuration, including labels,
headers and basic tables, formats and visibility​

Case Types: Application overview page summarizing Pega Express delivery assets: Microjourneys™, Personas & Channels,
Data & Systems

Data Objects/Integration:

Visual data modeler with ability to review, search, and extend application data model and relationships​
Integration landscape visualization of data types and source​
 Calculating and formatting email, phone, URL and simple data references

Channels and Personas:

Define and assign personas to available portals with user management of profiles​
Organization modeling, add and assign work queues, and management for landing page based on privileges​

Project Delivery Support Features:

Integrated traceability with your user stories and application features​

Generation of application documentation

DevStudio
UI Authoring:

Styling, formatting and editing in runtime​

Reporting with personalized dashboards and charts​
Mobile location services, native buttons, attachments etc.

Case Types:

Built-in feature map, Pulse messaging for development teams and team gadget to see who else is editing assets​
Publish to DevOps pipeline with comments, user and bug traceability​

Data Objects/Integration:

Data imports from external systems and email account management​

Simulated data and inheritance of complex data types and classes

Channels and Personas: Multi-channel dashboard with extensible channel types e.g. chatbots, voice assistants, NLP for
conversation channels and social media marketplace channel integrations​

Technical Quality:

Automated unit testing​ – Pega Unit

Automated scenario testing ​ – Pega Scenario

Studios and roles

Robust, enterprise-grade Pega Platform™ applications depend on cooperation between two key groups of application
developers.

They are:

Domain experts: Business Architects (BA), citizen developers, and front-end developers. These experts offer valuable
insight into business processes and user needs.
Implementation experts: System Architects (SA), full-stack developers, database administrators, and security
administrators. These experts (often certified) have the technical skills for critical use cases that require complex
configurations.

In App Studio, domain experts can use core application development features (case design, data management, and user
experience) and apply their business knowledge to improve development outcomes.
To learn more about App Studio, complete the Pega Academy topic,App Studio.

To support advanced rule configuration in applications, Pega Platform gives implementation experts a second development
environment, Dev Studio. In Dev Studio, technical team members can access rule forms directly to address complex or less-
common configuration requirements. In addition, Dev Studio provides features for configuring security permissions and
access control, managing rules to promote reuse, and addressing the performance limitations of an application.

To learn more about Dev Studio, complete the Pega Academy module,Dev Studio overview.

Note: If you have completed the Business Architect (BA) mission or System Architect (SA) mission, you can build
an app using the three pillars, and showcase the prototype for business feedback.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

DevOps approach
DevOps defined
DevOps is a set of practices that bridge application development (dev) and operational behavior (ops) to reduce time to
market without compromising quality and operational effectiveness. The goal of DevOps is to deploy into a production
environment faster, gathering feedback to enhance the product rapidly. It allows application developers and business owners
to quickly respond to customer needs, increase the feedback cycle, and ultimately achieve business value faster.

DevOps functionality
DevOps encourages a culture of collaboration between the development, quality, and operations teams bringing together
process and technology to reduce or eliminate barriers through the following fundamental practices:

Continuous integration
Continuous delivery
Continuous deployment

Adopting DevOps practices and using DevOps tools creates a standardized deployment process to deploy predictable, high-
quality releases.

In the image below, you see how DevOps supports the iterative nature of a project.
DevOps processes and pipeline
In a DevOps workflow, the first best practice for application developers to adopt iscontinuous integration. Continuous
integration is the process by which development changes to an application are integrated as frequently as possible, at least
once a day, and preferably multiple times a day, every time developers complete a meaningful work unit. With continuous
application integration, application developers frequently check-in their changes to the source environment and use an
automated build process to verify these changes. This continuous integration identifies issues and pinpoints them early in the
cycle.

Successful adoption of continuous integration enables the next best practice ofcontinuous delivery. With continuous
delivery, application changes run through rigorous automated regression testing. The changes are deployed to a staging
environment for further testing to ensure that there is high confidence the application is ready to deploy on the production
system.

Successful adoption of continuous integration opens the opportunity forcontinuous deployment. With continuous
deployment, application changes are deployed to the production environment frequently or on-demand.

Continuous Integration:

Continuously integrating to a shared repository everyday

Checking in/Merging changes frequently
Fast validation

Continuous Delivery:

Always ready to ship

Running all tests frequently in QA, UAT or Staging environments

Continuous Deployment:

Continuously Deploying/Shipping
Frequent deployments and validation in production (like) environments

DevOps pipeline
In the Pega Express™ delivery approach, these processes translate into a DevOps pipeline, defined in four stages:
In the Pega Express™ delivery approach, these processes translate into a DevOps pipeline, defined in four stages:

Stage 1 - Development
Stage 2 - Continuous integration
Stage 3 - Continous delivery
Stage 4 - Continuous deployment

Stages 1 and 2 are development developer-centric and seek to answer the following questions:

Are the changes good enough to share?

Do the changes work together with other developer changes?

Stages 3 and 4 are customer-centric and seek to answer the following questions:

Is the application with the new changes functioning as designed and as expected by customers?
Is the application ready to be used by customers?

In the following image, click the + icons to learn more about the DevOps pipeline.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

DevOps tools
The Pega Platform™ offers tools to support continuous integration, delivery, and deployment through Deployment
Manager. Deployment manager provides a low-code, model-driven experience to configure and run continuous integration
and continuous delivery workflows or deployment pipelines for your application.

You can fully automate deployment pipelines and start with automated integration of developer changes through:

Branch merging and validation

Application packaging
Artifact repository management
Deployments
Test execution
Guardrail compliance
Test coverage enforcement

Note: Pega Platform supports open DevOps integration using popular third-party tools (such as Jenkins and
Microsoft Azure DevOps) by providing an open platform, with all the necessary hooks and services. With open
DevOps integration, you can build a deployment pipeline using third-party tools to automate branch merging,
application packaging and deployment, test execution, and quality metric enforcement.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Change and adaptability

Change with Pega Express
Pega Express™ is based on Scrum, which means it is designed to accommodate change-requests throughout the project life
Pega Express™ is based on Scrum, which means it is designed to accommodate change-requests throughout the project life
cycle. Accommodating change on short notice provides an enormous advantage to the client who may need to adapt to
events in the market.

Guiding principles
While Pega Express can easily accommodate change, there are few aspects of your project that should never change to
avoid chaos and maintain a high level of quality. For example, your team can maintain consistency in how they organize and
manage their work.

Here are some aspects to avoid changing:

Sprint Length – The duration of your sprints should be consistent throughout the build phase.
Sprint Goals – The scale and level of work being targeted to each sprint should be consistent.
Definition of Ready (DoR) – The criteria that determine when a user story has met the required standard for estimation
should remain consistent.
Definition of Done (DoD) – The criteria that determine when a user story has been properly configured and tested
should remain consistent.
Team Composition – Where possible, keep the makeup of the team consistent to encourage familiarity and improve
velocity

Backlog maintenance and refinement

Maintaining a deep backlog, preferably with Agile Studio, is the key to embracing and responding to change effectively.
Backlog maintenance enables you and the Product Owner to reprioritize and move backlog items in and out of scope based
on your solution needs.

In the following example, at the top of the backlog, the user stories in scope for the current Minimum Lovable Product (MLP)
are prioritized, with an effort estimate of 35 days. User stories for future releases are listed below this threshold, awaiting
Product Owner prioritization. At the bottom of the list, you will see two change requests pending a decision by the Product
Owner.

In this example, these change requests are deemed important and high priority by the Product Owner. In the following image,
you can see that the Product Owner has prioritized these two changes, so they are now part of the current MLP. However,
because the release's capacity is set at 35 days effort, it impacts item BR_012, which must be removed from the current MLP
and reprioritized in the future by the Product Owner.

Note: The Product Owner plays a critical role in approving backlog changes.

Change log versus change control process

The change log is a way of recording any changes, whether they be small changes approved by the Product Owner or larger
decisions made by a steering board. The change control process is an agreed-upon part of Governance, which allows more
complex decisions to be effectively managed through the governance layers for a decision. All projects should have a
change control process, and these must be shared at the Project Kickoff meeting.

Here are the differences between the two:

Change log – The change log is a written document describing what has changed on a project with a brief description
of why. Pega Express recommends that all changes in project scope, resources, schedule, or cost be documented in a
change log. Logging can be invaluable to help understand project impacts or justify a particular change.

Change control process – The change control process is a mechanism that supports the initiation, recording,
assessment, approval, and resolution of project changes. Pega recommends that a change control process be part of
the governance plan developed at the beginning of a project. The change process ensures that changes
are documented by the Project Delivery Leader (using the agreed-on change log) and then added to the agenda for the
steering board meeting to review and choose.

Change request use cases

Not every change needs a change request. Some changes can bypass a change control approval process. Those can be
logged on the change log and simply approved by the Product Owner. Here are some guiding principles around when you
need to follow a more formal change control process.

Use a change control process when:

Stakeholders want to swap new work for work already completed
Stakeholders want to swap something big for something small
 The proposed change adversely affects another team. It might notbe a case of causing the team additional work. For
example, when implementing a proposed change would delay the development of a capability on which that other team
depends, it is appropriate to use the change control process.

Note: Swapping something small for something big does not require using the change control process, but record
the change on your project’s change log.

You may not need to use a formal change control process when:
Your Product Owner approves the change
Your team has not yet started the change
The change only affects your team

In either case, you document these changes on the change log.

1. Document the change in the project’s change log.
2. Add backlog items to describe the change.
3. Allow the Product Owner to prioritize them.

Types of change request

Anytime a request requires a change to thecontractual agreement, Pega Express best practices recommend you create a
formal change request. That is true even if the change is small and does not impact anyone outside of your scrum team.
The following table highlights when to use the formal change control process, and create a change request, or work with your
Product Owner and merely document the change in the change log.

Type A commercial/contract Impact No commercial impact but the No commercial impact, no

impact is high-value approval needed

Description Any change that affects the These types of high-value A change that the Product
contract or Statement of Work changes Owner can approve

Examples / Client changes project Change of branding The Product Owner

Criteria timelines or milestone dates Impact to another project approves the change
Client swaps out Impact to another Scrum The Scrum team has not
functionality required by the team started working on it yet
SOW The change affects only
Client increases scope that Scrum team
or functionality
Client delays delivery of
dependencies

Action Formal change control required Formal change control Document in change log only
recommended

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.
 Module Quiz
This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.
Quiz duration
5 mins

Low code during the Build phase -- Thu, 01/06/2022 - 02:02

To get the full experience of this content, please visit Low code during the Build phase