Stakeholder interactions

As a Pega BA, you collaborate with one or more of the following project stakeholders to ensure that there is constant alignment between the Business and IT project teams:

• Product Owner (PO): The Product Owner (PO) is one of the client's representatives on the project's Business team. The PO is primarily responsible for managing the scope of the project and prioritizing requirements throughout the software development process. Pega BAs collaborate closely with the PO to ensure that their Pega Platform™ application delivers the project's strategic outcomes in the expected time frame.

• Project Delivery Lead (PDL): The Pega Project Delivery Lead, sometimes known as the Project Manager, is primarily responsible for leading the Pega delivery team, maintaining the project governance, and liaising with the client’s leadership team. Pega BAs collaborate closely with the PDL to ensure that the project stays on time, on budget, and in scope, so that stakeholders from both the Business and IT teams are aligned in their expectations for the timing and cost of project deliverables.

• Scrum Master:  The Scrum Master is responsible for promoting and supporting Scrum, an Agile-based software delivery framework. The Scrum Master is responsible for organizing the Scrum team, facilitating Scrum ceremonies including Sprint Planning, Sizing, Backlog Refinement, and Retrospective meetings, and are accountable for the Scrum team's success. 

• System Architects (SAs): System Architects are the Pega developers on the project team who configure the Pega applications. The System Architect family includes System Architects (SAs), Senior System Architects (SSAs), and Lead System Architects (LSAs). System Architects collaborate with Pega BA’s and stakeholders from the business to develop the application using Pega GenAI Blueprint™. LSAs are responsible for importing the Blueprint file into the Pega Platform environment and will use the user stories created by both Blueprint and Pega BAs to configure both the functional and technical requirements of the application. Pega BAs translate technical information provided by System Architects for business stakeholders to ensure that they understand the application in development, and that it meets their requirements.

• Quality Analysts (QAs): Quality Analysts ensure that application functionality meets the documented business requirements. Using user stories written by Pega BAs as a baseline for their work, QAs build test scripts and scenario tests that confirm the application functions as expected. QAs also participate in Scrum rituals such as Refinement and Sizing sessions to ensure that the time and effort associated with application testing are sized appropriately.

• Subject Matter Experts (SMEs): Subject Matter Experts are representatives of the client organization on the project team who have deep first-hand knowledge of the steps required in the business process. SMEs provide the specific operational and functional requirements associated with these steps. Pega BAs collaborate with SMEs, typically in an operational walkthrough, to observe end users navigate the ‘as-is’ process and applications. Pega BAa works with SMEs to understand all the work (both in and out of the system) that end users need to perform in order to meet the customer’s needs and the desired strategic outcome. 

• Business Analysts: Business Analysts are representatives of the client organization on the project team. The Business Analyst is primarily responsible for documenting the current ‘as-is’ process, data requirements, and business requirements. Pega BAs collaborate with Business Analysts to gather and review this documentation to identify opportunities for improvement, including eliminating redundancies and bottlenecks, recommending workflow automations, determining resource needs, and defining technical details such as data and interface requirements.

• UX Designers: The UX Designer ensures that the design of the application meets the end-user’s needs, complies with accessibility standards, and delivers a consistent experience across all application delivery Channels. Pega BAs collaborate with the UX Designer to design the user interface to align with user experience requirements, maximize the use of Pega's out-of-the-box features, and meet strategic business objectives.

• Solutions Consultant: The Solutions Consultant works with the client during the initial phases of the sales process. In many cases, the Solutions Consultant designs the Blueprint in collaboration with Business stakeholders. If the client moves further in the sales process, the Solutions Consultant will transition the Blueprint to the Pega Business Architects and System Architects responsible for project delivery prior to the project start.

The following figure displays the project stakeholders that you interact with as a Pega BA:

The size and structure of a project team varies from project to project, and it is possible on smaller projects that some team members perform more than one role, for example, the Business Architect may have to act as the project's Product Owner.

Regardless of your project’s exact stakeholder mix, it is important for you, as a Pega BA, to ensure alignment between these areas of responsibility across your project team. This is the only way for you to ensure that the transformed business process meets its strategic objectives in the most efficient and cost-effective manner possible. You ensure alignment with the following stakeholders:

• Product Owner (PO): You, as a Pega BA, write user stories to address business needs for a mortgage loan application. You run regular user story review meetings with the Product Owner to finalize the user story acceptance criteria, and prioritize the user stories within the project backlog to ensure that the desired features are delivered within the project timeline. 
• Project Delivery Lead (PDL): You, as a Pega BA, identify that the solution for the fraud detection application is more complex than was originally understood. You work with the PDL and the PO to determine if the change in scope affects the delivery timeline and identify options to manage the additional scope. During regular program governance meetings, the PDL and the PO work with the project sponsors and management team to resolve the issue and agree on a revised plan for the project. 
• Scrum Master: You, as a Pega BA, participate along with the Scrum Master, in all the Scrum ceremonies as a member of the Scrum team. You provide input, feedback, and guidance to System Architects during the sizing and sprint planning meetings, and you work with the Scrum Master to remove any blockers preventing User Stories from being completed. 
• System Architects (SAs): You, as a Pega BA, document a business need for the home loan application in a user story.  You then run meetings with the System Architects to ensure that they understand the documented business need, and can estimate the effort required to design, build and unit test the need based on the user story.  
• Quality Analysts (QAs): You, as a Pega BA, provide input to the Quality Analyst so that they can create test scripts for the new mortgage application. When the Quality Analyst notifies you of a potential defect in the application, you meet with them to review and discuss the issue to determine whether it is a true defect in the current application design, or a new requirement that should be presented to the Product Owner to consider for inclusion in either current or future project scope. 
• Subject Matter Experts (SMEs): You, as a Pega BA, need to understand the specific steps that users go through when working on a fraud detection case. You schedule an operational walkthrough of the ‘as-is’ process with the SMEs to identify the mandatory steps, process requirements, and business rules that must be included within the new ‘to-be' fraud detection process. Once designed, you review the ‘to-be’ process with the SMEs to ensure that all business and user needs and requirement are met.
• Business Analysts: You, as a Pega BA, need to understand how, when, and from where, customer credit history data is retrieved in the current ‘as-is’ home loan process. You facilitate a meeting with the client’s Business Analyst to review database access in the current ‘as-is’ process to obtain the relevant details for inclusion in user stories associated with the 'to-be' process. 
• UX Designers: You, as a Pega BA, recognize that the client’s requirements do not offer clear guidance to users to complete their tasks. You work with the Pega UX Designer to establish guidelines for the workflow to ensure that the end-user experience is intuitive, engaging, and consistent throughout the entire application.  
• Solutions Consultant: The Solutions Consultant works with the client during the initial phases of the sales process to design a prototype of the Pega Platform application in Blueprint. The Solutions Consultant will transition the Blueprint to the Pega Business Architects and System Architects responsible for project delivery to validate the application design prior to the start of the project.

To support efficient and scalable application development, Pega Platform™ offers powerful tools for managing collaboration and configuration. Workspaces and Branching help teams organize their work, maintain version control, and streamline the development lifecycle.  Workspaces provide tailored environments for different roles and tasks within the project, while Branching enables developers to isolate changes before merging them into shared Ruleset. Together, these features ensure that development efforts remain aligned, secure, and adaptable to evolving project needs.

Workspaces

Workspaces in Pega Platform offer a secure, focused space for stakeholders involved with application development to build and manage application features independently. Each Workspace is tied to one specific operator with developer access, and is exclusively associated with one application.

Within an application, each operator has one Workspace created by default, but an operator can create multiple Workspaces within that application. Changes remain private within a single Workspace until shared to a Branch, helping avoid rule conflicts when multiple developers work on the same app.

Each Workspace belongs to one application and one operator. Developers can create and switch between multiple Workspaces, which show only their own changes. Some Rule types may require Dev Studio access based on permissions.

Workspaces are available in App Studio and Dev Studio, and can be enabled with the EnableWorkspace setting. 

The following topic contains information that is important for your understanding of Workspaces and for passing the Business Architect certification exam: Developing Applications in Workspaces.

Branches

Pega Platform™ uses Branches to help teams manage parallel development in distributed environments. A Branch is a container for Rulesets with records that undergo rapid change and development. 

Branches are beneficial for both large and small-scale development projects, where single or multiple teams work simultaneously on the Rules in an application. Branches also benefit feature development when the time to completion differs between features. A common strategy when creating a Pega Platform application is to create a Branch for each feature your team is developing. A Branch for each feature allows your team to independently develop a feature in an isolated space (the Branch) without affecting other teams. For example, your team creates one Branch to change properties in a form and one to change a UI Section. Changes do not affect other teams until the changes are stable, conflicts are resolved, and approval is granted to make the changes available to all development teams.

As a Pega Business Architect, you are a crucial link between project stakeholders, constantly working to ensure they are engaged, aligned, and communicating effectively.   

To meet the challenge of guiding the Business and IT teams to collaborate, create innovative solutions, and achieve business outcomes, you combine your experience with the following:

• Analytical and problem-solving skills to break down complex business processes and identify opportunities for improvement and simplification.

• Process design skills and knowledge of business processes design to innovate new processes and ways of working to achieve the business outcome. 

• Knowledge of systems design, Pega technology, and Blueprint to align the business requirements and end-user needs with Pega’s out-of-the-box features. 

• Active listening, communication, and facilitation skills to create a common language and understanding of both the business need and Pega’s capabilities between the project team and other stakeholders. 

• Knowledge of business change to help your Business team embrace the new Pega solution and become advocates of the new solution in their organization.