Thank you for joining our first Pega Community event for Business Architects.

We heard from Pega Consulting Director Jo Warne @JoWarne, who explained what it really means to be a Pega business architect and how this unique role differs from the standard industry definition of a traditional business analyst or business architect. 

Curious what training and enablement you need to begin your BA trajectory? Jo detailed what professional skills are required to get started. 

We also heard from panelists Nadine (Nella) Erbeldinger, a Pega business architect at Greenfield Technology, and Oliver Field (OliverF7), a Pega service manager and business architect at the European Union Aviation Safety Agency (EASA).

Nella and Oliver discussed similarities and differences in their roles, shared how the BA role is evolving, and provided actionable advice for making a significant impact as a Pega business architect. 

So, what's next?

We hope you understand we couldn't get to every question during our Q&A session, but we wanted to provide you with answers. Check them out below: 

Q&A Session with Jo Warne @JoWarne  and Joan du Triou @JoanDuTriou 

Q: Do you think that it is compulsory for a SBA to get those technical certifications to be an LBA? Could the experience be the proof that the future LBA is capable of understanding all the technical issues without getting those certifications? 

Jo Warne: Historically, it wasn’t compulsory, and indeed, there were many Lead Business Architects (LBAs) who understood the technical aspects without having PCSSA & PCSA certifications. However, the application has evolved significantly over the years, as has the LBA role. Having the certifications guarantees a base level of understanding and a base level of technical ability that is evidenced, and ensures that the LBAs are able to have relevant and appropriate discussions, both from a business and technical perspective.

Q: How can we run Pega DCO these days when clients aren't in a position to sit with us for long hours as part of requirement gathering? 

Jo Warne: Our world has changed over the last year or so, in a way none of us could have imagined. This was a question we all asked ourselves initially when we went into lockdown. Internally we quickly identified tools and mechanisms that allowed us to continue working, albeit in a slightly different way. Here are my top tips for running DCO sessions remotely: 

- Use a collaboration tool (we use Mural at Pega), however whiteboard functionality in WebEx/Teams works – or anything that allows you to be interactive with people.  - Ensure you have documentation up front (process flows, etc.) so that you can plan sessions.  - Don't plan sessions for longer than 1.5 hours at any one time.  - Be organized. Know what you need to cover and keep your sessions specific.  - Have a little bit of fun – humor can really help to keep folks engaged when we are all remote.

Q: What are the Pega Express tools? 

Joan du Triou: We have a comprehensive toolkit on our Pega Express™ community page. We recommend that you access the toolkit and take some time to familiarize yourself with all that is available. Our toolkit identifies tools that are core to the Pega Express Delivery Approach with the label "essential" tagged to the tool. Whilst there is a succinct list of core tools, the toolkit includes a number of additional supporting documents, presentations. and guides that can help you on your projects.

Q: Why should a Business Architect also be a low-app code developer? (I refer here to the related Pega Academy courses). 

Joan du Triou: Pega’s low-code capabilities are evolving all the time. The functionality in App Studio helps the Pega Business Architect elaborate on the next sprints and user stories in a visual and creative way. There are many benefits to working in this way – not least of all is the engagement this approach drives with the business. Whilst the Business Architect training includes low-code training modules, we do not intend for the Business Architect to become a full time low-code developer. We include low-code in the BA training to ensure that the Pega Business Architect is proficient in App Studio and can support the delivery of Pega solutions that both maximize the out-of-the-box features in Pega and help create applications that are easy to build, maintain, and upgrade. All of this helps to accelerate the delivery of solutions for the business.

Q: Could you discuss the type of documentation you use in your agile environment? My team wants to track requirements only in DevOps, but as a Business Analyst I have preferred to have a separate document, as well as DevOps, to reflect a comprehensive set of requirements for a project containing all user stories.

Joan du Triou: If by DevOps you mean an agile project management tool – we would recommend that all user stories are captured in an accessible and flexible tool like Agile Studio or Jira. It’s important that all the users stories are held in one place to ensure that the product owner is able to review and prioritize the user stories with full visibility of the overall scope of the project, focus of the sprint, any dependencies on other stories, and the work that has been completed to date. These tools are very good at ensuring the entire team is focusing on what is important for your release and the next few sprints, thereby negating the need for heavy requirement documents that are difficult to maintain and keep current. There other benefits too. For example, tagging defects to user stories.

Q: Will Pega be in the focus of this talk? 

Jo Warne: The aim of the session was to talk about the Pega Business Architect role, to ensure that everyone in the community had the same understanding. We get a lot of questions about what the Pega Business Architect role is, from both customers, partners and the community. As discussed throughout the presentation, it’s not “just” Pega knowledge that is required to be able to perform the role. We felt that this was an ideal kick-off session, covering what skills and training are required to be performant in the role. A Pega Business Architect must have a broad range of experiences and skills to complement their Pega knowledge and make them effective in their role, which is why this event was called “What is a Pega Business Architect.” In future webinars, we will be delving into specific areas relating to our methodology, the application, and more.

Q: How does the Pega Business Architect role play out for Pega CDH projects? What are some essentials when a traditional Pega BA works on Pega CDH projects? 

Jo Warne: Internally at Pega, we don’t use the Business Architect role on CDH projects. The Lead Decisioning Architect (LDH) roles cover all business aspects. If this is an area of interest, I would recommend signing up for our event series for decisioning!

Q: As a Business Architect, are you using Agile Studio to help organize and run your Agile teams? 

Jo Warne: This depends on the project and our clients’ tools – but where possible yes, we do.

Q: What all activities does an LBA do in the project discovery phase? And how can a Pega BA add value to get business outcomes? Do you have any fixed questionnaire, or any videos on that? Especially when a BA is part of sales team. 

Joan du Triou: Our Pega Express Delivery course on Pega Academy covers the activities and expectations for the completion of a successful Discover Phase. Depending on your organization and if you are working for a client or for a partner, the role the Pega Business Architect plays during the Discover phase can vary quite considerably. We would suggest that you review the Academy module covering Discover and align your skills to the activities and outputs we expect from the Discover phase. Speaking from a general standpoint, the Pega Business Architect should be proficient in DCO skills and collaborative sessions in order to work closely with the business to identify the business outcomes and customer journey. 

Q: In a small project organization, when talking about agile and education, is it the role of the BA to "educate" on the agile methodology?

Jo Warne: In an ideal world, no. We would expect organizations to have dedicated trainers/coaches and/or the Scrum Master perform the education to the wider project team. However, we do see this as something the BA does have to do in some situations. It is important that if you are educating others, you are ideally PSM certified and that you ensure you have time set aside to do this activity. 

Q: Can I become a Pega Business Architect without any IT experience, by cracking the PCBA exam? Can I shift from a non-IT background to IT background by getting a PCBA certification?

Jo Warne: Unfortunately, this isn’t a straightforward answer. We certainly see a lot of Pega Business Architects with non-IT backgrounds. However, whilst they don’t have an IT background, they DO have technical aptitude. The technical aptitude aspect is critical, as you need to understand Pega and what it can and can’t do. Simply passing the PCBA will not initially make you a Pega Business Architect. As discussed during the webinar, there are many skills and suggested trainings that we would expect a Pega Business Architect to complete in order to be successful in the role.

Q: When getting started on a new project, what would be a great way to get familiar with that type of industry and its processes? 

Jo Warne: Whilst we at Pega largely work within our industry expertise, there are times when we have to work on projects outside of industries we are familiar with. We are fortunate that we can usually speak to colleagues who have worked in the industry and ask them questions. However, we also do a lot of research online too. There is a wealth of material online like white papers and industry ezines that will help you to understand the industry. In respect of processes, you can sometimes find information about those online too, but I have found in invaluable to talk to the sales team and leverage material they may have gathered during the sales process. When looking at a new process, always put yourself in either the customer’s or end user’s shoes (persona). This helps me navigate through what I need to ask. The vast majority of processes will include one of those two personas, and at some point you will have had personal experiences as a customer, so you probably know more about the process than you think!

Q: What is your experience/role with respect to efforts estimation as a Pega BA? Any tips on how to estimate projects with realistic timelines? Joan du Triou: At Pega we make extensive use of the Case Type Backlog to create an initial estimate. For those projects that are starting out on Pega 8.5 and above, we use the Estimator Tool directly in App Studio to provide a real-time estimate based off the capture of the three pillars. The Estimator Tool provides a similar output to that produced using the Case Type Backlog. We have a great video on our Pega Express community webpage that provides guidance on how to use the App Studio Estimator.  

To refine your estimate further, you can use the Scrum Sizing Tool. This tool allows you to import your initial estimate and then model the final sprint and resource plan. This guides you through the process of creating a thorough view of the end-to-end plan. 

You can access the Case Type Backlog and the Scrum sizing tool, along with some additional guides, by navigating to our Pega Express Toolkit. For more information on sizing, we suggest you review the Pega Express Delivery course on Pega Academy.

Q: How does a Business Architect deal with integration discussions with legacy systems, especially in Insurance and banking domains where core systems may be very old and not conducive to digital transformation, but still need to be maintained along with new applications? Any experiences from the panelists would be very helpful.

Jo Warne: This depends on the Business Architect’s experience and skills. Usually, a Lead System Architect would be leading the integration discussions with the customer – the Business Architect would be supporting those discussions, as they would have visibility into the requirements. 

Joan du Triou: Irrespective of the industry - the Business Architect plays an important role in terms of helping to understand the business implication of integrations as part of the overall business solution. The relationship between the new system and the legacy systems should have been identified early during the Discover phase of the project and the scope and opportunities for change within the legacy system identified as part of that process. Where the new world solutions are integrating with old legacy systems, decisions need to be made by the business and the project team as to how much change can be supported by the legacy system. Based on these constraints, the digital transformation solutions will need to be designed to address the limitations and capabilities relating to those integrations. 

Q: What would be the basic expectation to fulfill the Principal Business Architect role? 

Jo Warne: Alongside all of the points we covered during the webinar, there are a few basic expectations for promotion into a Principal Architect role. We would usually expect a Principal Architect to have been in the Business Architect role for a minimum of eight years, have a broad range of project experiences. We would also expect them to be an evangelist and a thought leader who is able to navigate both business and technical challenges on a project (as well as having all of the training, enablement, and skills listed, at an expert level).

Q: Any tips for CDH requirements gathering and how it differs from a regular Express methodology? 

Joan du Triou: Great question! We have some excellent blogs on our community site that explain how CDH projects are delivered using the Pega Express Delivery Approach. You can find them on the Pega Community Blog.

Q: Could you name a few prototyping tools that you have found better to work with over other options?

Jo Warne: There are many prototyping tools available – usually our Innovation & Experience Design team would be involved in a project and would handle prototyping using specific tools. In scenarios where we don’t have their involvement, which is rare, as Business Architects we sometimes use Balsamiq.

Q: Do you advise that TOGAF is mandatory for a Business Architect and if so, why?

Jo Warne: As answered during the Q&A session – mandatory no, but strongly recommended. It all depends on the types of projects you’re working on, but I would say it’s more applicable to enterprise projects in larger companies. I think this statement from TOGAF, explains it really well; "the TOGAF standard plays an important role in standardizing and de-risks the architecture development process."

Q: There was a list of certifications at the start - varying levels of Pega Business Architect - Lead / Principal / etc. Are there separate certifications for these or are they based on experience / attaining a series of badges (e.g., PCBA and LSA)?

Jo Warne: At this moment in time, no there are no specific Business Architect certifications for the S/L/P levels – however, this is something that we are looking into with our Academy team. Currently, these are based on certifications/badges and experience.

Q: Would PCDC be a good certification to achieve as part of the BA path? 

Jo Warne: Currently we have a dedicated team that works on the CDH projects. Within Pega, this certification isn’t required for the vast majority of our Business Architects. However, if this is an area of interest, I would encourage you to complete the certification and perhaps sign up for the upcoming events series for our decisioning community.

If you have any follow up questions, we'd love to stay in touch. Please reply to this discussion and be sure to tag Jo Warne (warnj) and Joan du Triou (dutrj). You can also check back here to replay the event on-demand. We will be updating this post with the recording in the coming days.

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.