Thanks for joining us at our second Pega Community event for business architects!

About this event: 

Pega business architects champion design thinking and agile throughout the delivery process. This webinar will provide tips and tools for ensuring successful Pega projects from preparation to adoption.

So, what's next? 

We hope you understand we couldn't get to every question during our Q&A session, but we'd like to answer as many as we can.

Check them out below: 

Q&A

What is the difference between a Microjourney™ and a case type? 

Microjourneys capture the end-to-end experience the end customer will go through. The case type represents the Microjourney by breaking it down into stages and steps. Microjourneys may require more than one case type to ensure all the features of the Microjourney are addressed appropriately – an example of this could be where work can be more efficiently initiated if conducted in parallel. Alternatively, there may be specific security requirements that are best managed by using a separate case type for a part of the Microjourney. We have a great example showing the relationship between Microjourneys and case types in our Pega Express Delivery course on Pega Academy.

What would you recommend we do to improve design thinking capabilities? I completed the courses provided in Pega Academy but still struggle to think of interesting Microjourneys. 

Design thinking is a great technique for identifying Microjourneys. I recommend the PegaWorld breakout video from Motors Insurers' Bureau in the UK (MIB). This company has some excellent examples that might inspire you. You can access the video by visiting our Pega Events page.

What do you see as the role of the BA in a design thinking workshop? 

Great question. Design sprints are very collaborative affairs, led by a facilitator with participation from end users, subject matter experts, technical team members, experience designers, and the Pega business architect. The Pega business architect plays a role in all the exciting activities that happen during a design sprint, such as sketching and voting on ideas. However, the BA’s key purpose is to ensure the audience remains aligned around the business outcomes and focused on achieving this throughout the design sprint. BAs also play a key role in supporting the development of the prototype while making sure it takes advantage of Pega out-of-the-box capabilities (without stretching beyond the original intention of the MLP). After the design sprint the BA will have knowledge of the solution, which they can leverage to break down the work into manageable chunks and the user stories into the backlog. 

Does the Pega Express™ delivery approach differ based on delivery modal (Agile or Waterfall)? 

Pega Express™ is based on Agile and it uses scrum. During the Discover phase, the scope of the project should encourage releases of MLPs in 60 – 90 days with a road map of subsequent prioritized MLPs to ensure an incremental delivery of capability and business value. Adopting this agile approach ensures that there is more flexibility to change priorities, and will help you take account of more important, higher-value business requirements more easily and quickly. During the Build phase, we adopt the best practices of scrum to ensure that the business outcome and business value are constantly prioritized through the management of the backlog by the product owner. 

Where your organization is not able to adopt Agile, the Pega Express best practices, like defining the outcomes and linking them directly to the Microjourneys, design thinking, governance, and automated testing (using our low code platform and out-of-the-box features), can still be adopted to help mitigate the risks typically associated with Waterfall projects. 

Do you have any articles that speak to a day in the life of a business architect? 

We do not currently have a post that speaks to a day in the life of a BA. Is this something you'd like to see? We are happy to investigate if this is something that is of interest to the community. Let us know! 

In the meantime, take a look at this post on the Pega Community Blog, which addresses the differences between a business analyst and a Pega business architect.

Where can we find the toolkit you mentioned? 

The Pega Express™ toolkit is available on the Pega Express Community home page.   

Do you have thoughts on what a good DOR looks like? 

The purpose of the Definition of Ready (DOR) is to ensure that everybody on the team agrees on what is needed to build the user story so it can be pulled into the sprint during sprint planning. Therefore, the team needs to agree on what is needed to configure and test the user story. Typically, the team should ensure that the user stories adhere to industry and scrum standards. For example, the story should be well-formed and include clear acceptance criteria. You should also include information that will help the build team configure the story, which could include UX wireframes, process maps, etc. In our toolkit, we have a starter DOR, which you can tailor to fit your project needs. 

Does a Pega BA create the data model as well along with creating stages, processes, and steps? 

For those Pega business architects that are actively using Pega App Studio to create the baseline of the case type(s) during Prepare and extending the case type or prototyping business options during the Build phase, we recommend that the lead business architect and the lead system architect agree on the working practices upfront to ensure the maximum benefit to the business and to the technical team when data is included. Each project will be different and must account for the specifics of that situation. For example, the project may extend an existing application with an existing data model or include a new application with no pre-existing data model.  

For those teams that are not using Pega App Studio, the Pega business architect will be working to elicit the data details in collaboration with the business as they are producing their user stories for the Microjourney. For the best technical design, the lead system architect leads the conversion of that business expression of data into the data model held within Pega.    If you are keeping a data model document outside of Pega, we recommend that the lead business architect and lead system architect agree on how to manage, maintain, and update the document throughout the project lifecycle 

How should a BA propose Pega when there are multiple systems available for systems of record? Are they responsible for defining how Pega should interact with these systems? 

Integrating with multiple different systems during a project is not unusual. One of the first things you need to do is to identify and agree on what is the right system of record. For example, in a customer dispute application, Pega integrates with the financials and customer information system of records to obtain financial and customer information to supplement the Pega case. In that instance, Pega would only be the dispute case system of record. A Pega business architect would usually be supporting the lead system architect in those discussions.  

Having said this, we would expect that the Pega business architect understands the data that is available from each system within the scope of their project and be aware of any relevant business rules that affect the creation, maintenance, and deletion of that data. It would also be important that the Pega business architect understands whether the systems interact with each other in real-time or batch, and whether the interactions are synchronous or asynchronous.   

How long should a Prepare phase should typically last if two sprints’ worth of stories need to be added to the backlog? 

Typically, between two and three weeks, depending on the size of the project. Two weeks is the target, but achieving it takes a lot of focused work. 

In my current role as a BA, I am also defining UX, but I’m unable to find articles on UX. Can you suggest any articles please? 

There are some courses on our Pega Academy that may help you with this. I suggest you try the following courses for starters: 

• Pega User Experience (UX) Essentials
• User Experience (UX) Design
• Pega Cosmos Designer

You can also explore our design-focused articles on the Pega Community Blog. 

Can you speak more to the role of the BA in defect triaging? 

The Pega business architect plays a key role in addressing defects. The testing lead would manage and report on test execution and would run the defect triage meeting. The Pega business architect’s role during the client test phases is to support the product owner to help review the defects and decide whether the defect is indeed a defect, or a change (new requirement). BAs are the “project conscience” that helps the product owner understand the defect’s impact on the application, which helps the product owner prioritize effectively.  

Can we get an example of building stories in DCO? 

The stories produced from Directly Capturing Objective™ sessions are traditional user stories. Our Pega Academy mission includes a topic that walks through what good looks like. It also describes how DCO works to get you to those user stories! You can access Pega Academy using this link: https://academy.pega.com/mission/pega-express-delivery/v1  

I want to use Adobe, Google Maps, OCR, and visual analytics in my current process. Do you have any use cases covering these that will help me learn, explore, and grow? 

For the optimum integration with the above we would suggest that you engage with your lead system architect to understand the specifics of the features you wish to implement. 

What is the role of a Pega BA in Pega Customer Decision Hub projects? 

Pega Express™ is our approach for Pega Customer Decision Hub projects, and the Pega business architect can certainly play a role in helping to identify the actions and work to build out the backlog to support the strategies. At Pega, we have specific decisioning architects that handle Pega Customer Decision Hub deliveries alongside their technical colleagues. Having said this, if you are working on a Pega Customer Decision Hub project, our Pega Customer Decision Hub team has some great resources on implementing Pega Customer Decision Hub with Pega Express.  

Check out Tim Odeh's blog series available on the Pega Community Blog for a detailed break down of how to follow the Pega Express delivery approach when implementing a Pega Customer Decision Hub project.

Another great resource is the Pega Customer Decision Hub community page. The article on Organizational Architecture Overview may be just what you’re looking for. 

What is the impact of customization? 

At the outset, you must understand what's "in the box,” and this is very much dependent on your Pega product and the nature of your project. There are circumstances when it is justifiable to customize some features, but you must do this with extreme care and consideration. You’ll want to be sure that using “in the box” components and functionality can address the business needs before considering customizations. When customizing key features in our strategic applications, the implications can result in more costly and difficult upgrades. For other types of customizations, there will be an immediate impact on project effort, as it takes time to change and test the customization. It can also have an ongoing impact on the complexity of the application once you add increased capabilities. This can, of course, have an ongoing cumulative impact on testing timelines and maintenance efforts, including future upgrades. 

Should I refine the story in separate sessions and focus DCOs in the traditional sense (identifying the stories and writing them up), or have people used DCOs as a hybrid session to do both? 

Great question. You want to leave the Directly Capturing Objective™ session with a solid user story. Noting the scrum ceremonies of refinement, estimation, etc. will take place separately. It’s worth mentioning that during your refinement sessions, technical feedback from the system architects can result in revisions to your user stories, so refinement sessions must include the business teams as well and should be run as collaborative discussions.  

How does the BA help with business readiness? 

In our experience, traditional business analysts can help the training team create the training material and help the business team with any collateral to support process changes ahead of the application going live. Typically, the Pega business architect helps to support these activities, but wouldn’t play a significant role here, as the client owns the delivery of this activity. 

Is the BA responsible for defining the case type, or does this responsibility fall to the LSA? 

During the Prepare phase, the Pega business architect should be working in collaboration with their business teams and the Pega system architects to establish a baseline of the case type(s) that represent the Microjourneys prioritized for the first MLP.  

Where you are developing the application in Pega Platform 8.4 and above, we strongly recommend that this initial version of the case type(s) is created in Pega App Studio and discussed with the business as part of ensuring there is alignment and agreement before starting the project. Pega App Studio makes it easy for the Pega business architect to capture the case stages and steps directly into Pega. The initial version should be a skeleton of the case type(s) defined only as much as is necessary to confirm the high-level case lifecycle and key steps to ensure it: 

• Represents the boundaries of the scope. 
• Identifies the key decisions that must be resolved. 
• Allows the product owner to confirm that all the relevant business scenarios necessary to achieve the overall outcome are covered. 

In scenarios where the team is not working in Pega Platform 8.4 and above, we would expect the Pega business architect to represent the Microjourney in a visual tool to achieve key outcomes of the Prepare phase listed above. 

Thank you again for attending, and we hope to see you at our upcoming events. 

You can find the full schedule on our Pega Community Events page.

If you'd like to download this presentation in PDF format and are logged in to your Pega Collaboration Center account, you can access the attachment below.