Core Pega Express best practices for the Business Architect

Business outcomes are key, high-value business objectives that an application built with Pega Platform™ is designed to achieve. Business outcomes might include, for example:  

• a new sales objective
• a customer retention objective
• an efficiency objective

Identifying and setting key, strategic business outcomes for the Pega application provides the direction for your business process transformation program, and ensures that all increments contribute to achieving the needs of the client organization and their end customers. 

The Business value best practice is about ensuring that the organization achieves their strategic outcomes through the thorough preparation of a business justification and a supporting business case. 

For you, as a Pega BA, understanding the business case serves many purposes, including:

• Prioritizing scope to ensure that the proposed solution achieves the business outcome.
• Establishing target Key Performance Indicators (KPIs) that the Pega solution achieves.
• Calculating the return on investment (ROI) using the baseline and target models.

Establishing the business value for a project gives you, as the bridge between Business and IT, points of reference for discussions about prioritization with the Business team throughout the project.

Practical application of Business outcomes and Business value for the Pega Business Architect

As a Pega Business Architect, you work with the Product Owner to understand the project's key strategic business outcomes, which provides the direction for the business process transformation. As you progress through the project, understanding the business case for the project guides your discussions with Business team stakeholders about feature prioritization based on the business value each feature provides. 

Check your knowledge with the following interaction:

The concept of the Microjourney is fundamental to the Pega Express delivery approach and is our way of breaking down the complexity of the larger customer journeys into smaller journeys that can be delivered more quickly, increasing the speed to value from your business process redesign.

Identifying Microjourneys requires you to consider the end-to-end experience for an application's end users. This exercise identifies incremental pieces of functionality in the overall journey that your project teams can put quickly into production, adding immediate value for the client organization and their customer. 

For example, the following image illustrates an automotive service journey - a request for roadside assistance with a company called GoGoRoad - could be broken down into a Microjourney:

The Pega Express delivery approach advocates that you bundle application changes into a software release called a Minimum Lovable Product (MLP). A series of one or more MLP releases in a project then forms the transformational roadmap of your business process redesign.    

Each MLP delivers a solution that is not only viable but is also wanted and embraced by end users. As illustrated in the following image, an MLP is packaged to quickly deliver business outcomes in a way that delights customers and makes their lives easier, which achieves an accelerated time-to-value for the client organization:

Practical application of Microjourneys and MLP for the Pega Business Architect

Using the concept of the Microjourney and the MLP structure, as a Business Architect you break down the complexity of the development process into incremental deliveries that increase the certainty of achieving both application delivery and the associated value. This makes the application delivery process manageable and responsive to change. Stakeholders across Business and IT teams can then consider and apply learnings and insights gathered as each MLP on the roadmap is implemented.  

Check your knowledge with the following interaction:

Directly Capture Objectives (DCO) is the Pega discipline of continuous collaboration, iteration, and validation over the arc of a Pega project. DCO encourages alignment between stakeholders and drives high-quality engagement between Business and IT teams. As illustrated in the following image, DCO is a discipline that is driven by continuous collaboration, iteration, and validation:

DCO conversations focus on:

• Application design and development
• Achievement of business outcomes
• Human-centric design
• Iterations that realize business value faster

Using the visualization tools provided by Pega, DCO helps business stakeholders understand the application from a hands-on, experiential perspective.

As a Business Architect, incorporating DCO into your project is critical to reduce misunderstandings and minimize the risk of discovering business or functionality gaps too far along in the application development process. 

Reuse is the strategic best practice of designing and configuring applications with the longer-term roadmap, scale, and needs of the enterprise in mind.  

Reuse enables the rapid implementation of applications that can be quickly extended to address specific business needs and simultaneously encourage consistency of user experience.

Pega's approach to reuse, encapsulated in the idea of the Situational Layer Cake, consists of the following layers, from most specialized to least specialized:

• Innovation applications layer: Holds rules associated with applications built for specific business units or localized geographic regions
• Business applications layer: Holds rules associated with an organization's distinct business units
• Modular applications layer: Holds all of the rules available for reuse across the Business and Innovation applications
• Enterprise layer: Holds rules common to all applications across the enterprise
• Pega Platform layer: Consists of all the rule packages in Pega Platform

In the following image, click the + icons to learn more about Pega’s Situational Layer Cake approach to reuse:

Scrum is a fundamental part of the Pega Express delivery approach. Scrum ensures that stakeholders from the Business and IT teams work together collaboratively and transparently to achieve the right results for the client, guaranteeing that there are no unwanted surprises at the time of deployment. 

Scrum is a form of Agile development that defines specific roles, responsibilities, events, artifacts, and processes for your project. It involves leadership roles such as Product Owner (PO), Project Delivery Lead (PDL), and Scrum Master, divides projects into time-boxed development cycles called sprints, and requires a project backlog to be maintained that is divided into user stories.

Sprints and scrum events 

A sprint is a time-boxed cycle of work, lasting up to four weeks, in which the team builds a deliverable. Sprints are consistent in length throughout the project, and as a sprint ends, the next one starts, delivering a new increment. Multiple scrum events occur within each sprint. Each scrum event helps the team inspect and adapt to what is built. 

Scrum events include: 

• Story refinement and estimation: Provides time to review user stories for size and completeness.
• Sprint planning: Allows the Product Owner, Project Delivery Lead, and Scrum Master to prioritize user stories in the current sprint.
• Daily scrum: The Scrum Master leads this daily meeting so that specified members of the project team can meet and discuss their progress.
• Sprint review: Gives specified members of the project team a chance to review what has been built in the current sprint.
• Sprint retrospective: Gives the project team a chance to share feedback on what to change in the next sprint, based on what went well in the current sprint or what can be improved.

As a Business Architect, you actively participate in all of the scrum events, including, as far as possible, the daily scrums.

Story refinement and estimation 

Story refinement and estimation sessions are held frequently. During story refinement and estimation meetings, the team: 

• Confirms that the IT team understands the user stories that are ready for estimation and that the user stories meet the Definition of Ready (DoR), which is the criteria that determines whether a story is complete. 
• Allows the development team to size the effort that is required to configure and test the user story to meet the criteria set out in the Definition of Done (DoD), which is the criteria to determine whether a story is development complete. 
• Sizes the story by using story points (small = 1, very large = 13) so that the Scrum Master can consider the story at the next sprint planning session. 

Practical application of Scrum for the Pega Business Architect

Working at the intersection between Business and IT project teams, you actively participate in many Scrum events over the duration of your project. The information communicated during scrum events allows you to act, at various time, as an advocate for both the Business team and the IT team. For example, you actively participate in the story refinement and estimation scrum events to finalize the user stories you created as part of your DCO sessions. Once the user stories are finalized, you add them to the project backlog, making them available for development and testing by the IT team in upcoming sprints.  

Check your knowledge with the following interaction: