Business Architect Responsibilities

Question 1

Traditional vs Pega BA

Answer 1

Traditional:

1. making sure an application meets business objectives by…
   - Collecting and documenting application requirements around areas like work flows, reporting and correspondence.
   - Documenting workflows using a tool such as Visio, usually using a standard notation such as UML or Business Process Modeling Notation
   - wireframing the user interface using sketches or a visual prototyping tool
2. BA works as part of a design team that creates a set of application documents and pass those documents to the IT development team.
3. A traditional development project is application focused, and IT driven.

a business analyst is responsible for identifying business objectives, gathering requirements, and managing specifications, typically for workflows, UI design, reporting, and correspondence. This may involve documenting workflows in a tool such as Visio and developing UI wireframes with hand-drawn sketches or some sort of prototyping tool. They gather these documents – Visio diagrams, word-processing documents, and image files – and turn them over to the IT department.

Pega:

• A Pega development project is work focused and business driven.
• business architect role is a much bigger one
• BA is part of the development team, and works side by side with the system architect.
• The BA still collects requirements, drafts work flows and builds the UI wireframes, but does this directly in PRPC, and those assets become the foundation of the application.
• Pega also empowers the BA to automate business rules and policies, to create correspondence templates, and to design and build reports. (dev roles in traditional)
• The business architect is not a technical role.
• The BA is the development team member most familiar with this business’s priorities and can best identify opportunities for improving the business operation.
• The BA’s focus is on and benefits, business value assessment, and communications with project sponsors and stakeholders.
• Pega Business Architect in a development team working a specific release or application “sliver”.
• Because PRPC is model-based and doesn’t require coding, Pega enables business analysts and architects play a bigger role in application design and development than in traditional software projects.
• the traditional business analyst takes on a more active role throughout the entire development process, as a business architect
• instead of focusing to the existing system or process, a business architect is a true member of the development team, working alongside system architects to build the application.
• still performs traditional business analyst duties, such as identifying objectives, gathering requirements, and managing specifications. (but done in PRPC). As a result, these project assets are not just artifacts to be passed to system architects – they become the foundation for the application.
• can take on a more active role in application development.
• can actively contribute to developing portions of the application itself – designing workflows, creating UI wireframes, automating business policies, designing reports, and creating correspondence templates.
• a business architect can leverage their familiarity with the business’ priorities to identify opportunities to improve business processes and model improvements directly in PRPC, without having to rely on others to do the work for them.
• the role is not a technical one (even though they could do development)
• works alongside technical developers – system architects – to complete development of technical aspects of the application
• contributes their analytical skill and business expertise during the development effort to identify project risks and benefits, and communicate with project sponsors and stakeholders

Question 2

BAs tasks (can do) in Pega project?

Answer 2

• Create an application profile
• Participate in DCO sessions
• Model business processes
• Create user interface wireframes
• Define rules to automate business policies
• Facilitate DCO sessions (methodology black)
• Help establish a “Center of Excellence” or “Competency center” to govern the software development lifecycle policies and procedures for the organization (methodology black)
• And manage Pega application development methodology (methodology black)
• Oversee an entire project, spanning multiple releases or slivers (LBA)
• Work with Project Managers and System Architects on development planning (LBA)
• Mentor junior BAs (LBA)
• Organize DCO sessions and set expectations for all the participants (LBA)
• Architect complex relationships between multiple types of work (LBA)

Question 3

DCO?

Answer 3

• DCO empowers change and collaboration, and uses common business metaphors to define how we want business processes to work.
• DCO provides easy forms that empower business analysts to work directly on the system, safely and efficiently.
• we don’t start by writing reams of documentation, and creating massive specs that then get handed off to IT.
• we actually start by building a model, from which the system automatically writes the code. Anytime somebody changes the model, the system automatically changes.

DCO is a strategic approach, developed to facilitate Pega application development.

• DCO eliminates knowledge gaps between the business and the implementation team.
• everyone responsible for an application – SMEs, SA,BA,QA – interprets the business needs and proposed applications in the same manner.
• isn’t a substitute for an implementation methodology, nor is it part of any specific implementation methodology.
• is a flexible strategy that we can incorporate into any methodology.
• can be used throughout the development life cycle
• used to establish understanding between all parties
• helps to ensure that the end result satisfies business needs as much as possible.
• we capture all of the knowledge about an application – the objectives, requirements, and specifications – within PRPC itself
• provides everyone access to the same set of artifacts
• establish a consistent understanding between all involved parties: stakeholders, SMEs, business architects, system architects, QA, project managers, and anyone else involved with the implementation.
• increase the fidelity of their implementation
• business needs are always up-to-date and in-sync
• establishing a central repository for our objectives, requirements, and specifications
• provides traceability
• we start by identifying business objectives for our application, which helps us to establish the scope of our project.
• we can define the project requirements, which define what our application needs to do.
• we can write high-level specifications to establish how the application satisfies our requirements
• we can link the specification to the requirement or requirements it implements, and the business objective it satisfies.
• we can begin to estimate the effort required to implement a feature
• during DCO sessions, we refine the specification with more and more detail until all of the involved parties – SMEs, BAs, and SAs – are satisfied and consider it complete.
• we may create a draft of the implementation as we understand it. (help to visualize, often generate useful feedback, can narrow any knowledge gap)
• associating the specification with its implementation allows everyone to easily verify the specification against its implementation, and helps to ensure that the application addresses the business needs.
• address knowledge gaps between business and application developers
• converge on common understanding
• application development is more effective, faster, and better focused on the end result
• reduce or eliminate wasted effort du to misunderstandings

For a more-detailed discussion of the DCO features built into PRPC, how they support these best practices, and how we can use them to improve quality, reduce misunderstandings, and drive the application implementation, enroll in the DCO Essentials course.

Question 4

6 R

Answer 4

The final key differentiator is what we call Six R Case Automation – the ability to handle all aspects automating operations.

First, the system allows us to Receive work across the different channels, capturing whatever data we need into the system.

The next R is Route. With Pega we organize work using a rich case management infrastructure of parent and child cases, and then route cases and subcases using sophisticated logic based on priority, roles, skills and availability.

The third R is Report. This isn’t just Pega’s ability to create rich, live operational reports. It’s also the ability to communicate with interested parties and proactively notify managers of any problems.

The next R is Research. Pega systems are able to automatically to go out to get data when and as it is needed, across architectures, from the most modern SOA architectures to traditional MQ and other Systems of Record. Pega can also incorporate predictive and adaptive analytics to help us know what the next best action is to take for any given customer or situation.

The R of Respond is how we work with staff and customers in the way that they want. Pega generates tailored screens, forms and communications that are aligned to optimize each interaction.

And the final R is Resolve. Pega automates as much of the process as possible. And where human interactions are required, we can guide them, making sure we only ask questions related to valid outcomes. We won’t have things on screens that don’t make sense in the situation.

Question 5

DCO Tools
DCO processes
What is generated in DCO?
Benefits of DCO

Answer 5

The DCO Tools and Processes

DCO tools:
•The Application Express creates the foundation of new applications, frameworks, or extensions of existing implementations.
•The Application Documentation wizard automatically generates professional quality documentation related to a specific application’s assets.

There are three primary DCO processes:
•DCO Sessions are tightly moderate meetings whose sole purpose is the gathering and capturing of details related to a fixed set of Use Cases.
•Flow Drafting is done in the context of DCO sessions and involves the definition of Discovery Maps in the Application Profile, the creation of draft flow rules by the Application Accelerator, and the subsequent refinement of those flow rules in the Process Modeler.
•UI Drafting is also done in the context of DCO sessions and allows the rapid mockup of user interface screens using an integrated visual editing environment.

Let’s see how these DCO tools and processes are used together as we build an application.

Let’s say we’re building an application of moderate scope over a twelve week period.

DCO is methodology agnostic – it works with SmartBPM, waterfall, Scrum, or your own in-house methodologies.

At the beginning of our project, we need to document what we need to build. Instead of putting business objectives, requirements and use cases into documents outside of PRPC, business architects use the Application

Profiler to put them directly into PRPC. This gives us traceability: we can easily determine exactly which application requirements we’ve met and which ones we have left to do.

System architects then feed the Application Profile information into the Application Accelerator, which generates our application foundation for us, saving us costly manual configuration.

Business architects, system architects, other SMEs and stakeholders then hold multiple DCO sessions to nail down the details of the use cases. These meetings focus on efficiency, getting the right people in the room to focus on the implementation details of defined problems.

Now in BPM, CRM, decision management, and case management, process is king. By focusing on building out draft flows in our DCO sessions, business architects, system architects and subject matter experts agree up front on how our application will process our work, avoiding costly rework later.

Most end user subject matter experts think about the application they want delivered in terms of the screens they’ll see. By focusing on mocking up UI in DCO sessions, business and system architects get end-user validation up front and avoid nasty surprises down the road.

All throughout our development cycle, business architects run the Documentation Wizard, generating customized status documents for each group of stakeholders, showing them exactly what has been completed and what remains.

Question 6

The Role of the Business Architect?

Answer 6

• Successfully engage business users and experts.
• Quantify appropriate objectives and form requirements, based on those conversations.
• Guide the system architects who develop the functionality that meets our objectives and requirements.
• are advocates for business users
• works with subject-matter experts, or SMEs, and key project stakeholders to understand business needs and define objectives and requirements.
• works with SMEs and system architects to define the specifications for an application and communicate them to the system architects who build the application.
• works with system architects throughout an implementation to ensure that the application properly addresses the business needs.
• The work of a business architect begins long before anyone creates a single rule.
• first review the current state of a business process to identify inefficiencies.
• define application requirements and business objectives
• look for opportunities to improve the process, often by automating reproducible actions.
• business architects create specifications to satisfy requirements, meet objectives, and describe process improvements.
• system architects use these specifications to guide development of the application, creating rules that implement the functionality defined by the specification. - testers use these specifications to develop test scripts and test plans to verify that the application works as expected, and meets the expections of SMEs and business users.

Question 7

Application development

Answer 7

• often guided by an implementation methodology that helps to manage the project.
• each methodology organizes and manages the development lifecycle in a different way.
• all share three basic activities: scoping, implementation, and verification.
  • Scoping involves the collection of objectives and requirements. This information helps us to define our application and quantify the effort needed to create it.
  • Implementation involves creating the application. We use our objectives and requirements to develop specifications, which we refine with the help of SMEs. These elaborated specifications then guide system architects as they build the application, while also providing support and traceability to the original requirements and objectives.
  • Verification involves testing the application and measuring the results against our objectives and requirements. If testers identify any issues, the team investigates them and we addresss any defects.
• a successful application depends on the relationship between business architects and system architects.
• the quality of an application depends on how well system architects configure rules to meet business needs. And how well do system architects understand those needs? Well, that’s the responsibility of a business architect.

As we mentioned earlier, a business architect identifies business objectives for the application. These objectives help the business architect to define requirements for the application. These requirements, in turn, shape the specifications written by the business architect. And our specifications inform system architects as they create rules, guiding their choices in the design and implementation of rules.

To achieve a successful application:
- our specifications must accurately describe the application sought by business users.

To write effective specifications:
- we need requirements that clearly establish boundaries for application behavior.

To create quality requirements:
-we need appropriate, quantifiable objectives to base them upon.