Some of you who were following the threads Introduction to Drawing Workflows and Process Exercise were wondering how the modelling techniques I use relate to Pegasystems’ Direct Capture of Objectives approach, so here is a brief introduction.
Pegasystems says that “Direct Capture of Objectives (DCO) is a suite of features that enable project team members to directly capture, organize and manage business specifications inside of Process Commander and associate them with the specific parts of the application that are implementing them.”
I applaud this intent, as I am dead against old approaches that result in analysis paralysis. So what does DCO give us?
Limitations
The first thing you should know is when to use DCO and when not to. One of the key things to recognise is that DCO hinges around the use of the Application Profile wizard (which Pega describes as “a guided DCO development tool that supports an iterative approach to capturing high level processing details for the application or implementation you are planning to build”).
The AP wizard in turn hinges on the use of Work Types, which are integral to workflows. This means that the DCO approach is suitable for workflow implementations.
However, forcing your requirements into a Work Type model when there is no workflow in your business processes can cause you design problems later on. Moreover, if your project is more about implementing a Business Rules Engine (BRE), then there will be little business process involved at all.
It can even be more complicated than that, when a project is part workflow, part BRE and part non-workflow process.
So you might find the DCO approach does not work as smoothly as you expected if you apply it to your project with a broad brush.
Traceability
Since version 5.4 service pack 2 of PRPC, we have been able to document the high level requirements directly into PRPC using the AP wizard. This ability is very definitely a step in the right direction because it gives us traceability right from the project scope through to the implementation. However, there are two important caveats:
- Some project requirements might not apply to the PRPC solution at all, as they might need to be implemented in another technology, so what would be the point of capturing them within the AP?
- Requirements traceability needs to go all the way to system testing and perhaps even user acceptance testing, so there would still need to be a Requirements Traceability Matrix external to PRPC. In fact, I would argue that traceability between requirements and system testing is more important than traceability between requirements and construction.
You will remember from our process exercise that we drew a workflow model based on the high level requirements. Our work in producing that workflow model gave us the opportunity to drive out many of the key elements that will form the inputs to the Application Profile in PRPC. So a considerable amount of analysis has to be done before we whip out the AP wizard. Our overall workflow model can be expressed using DCO as a series of Flow Rules (a main Flow supported by several Sub Flows). But even before we get to the stage of creating Flow Rules, we now have enough information to run the Application Profile wizard in PRPC.
Business Objectives
In the AP wizard, we have the opportunity to document an overview of the target solution and add Business Objectives. Here I would record each of the HLSRs that we identified in Process Exercise: 5/6 as a Business Objective. Bear in mind that unless your project is being implemented entirely within PRPC, this will not be the project’s definitive catalogue of business objectives.
Actors
The AP also allows us to capture details of the Actors. These equate to the roles identified in our workflow. This only records details of Primary Actors of SUCs which are to be implemented within PRPC. If you are used to modelling other systems as Secondary Actors, you can add them to the AP as “Interfaces” (see below).
Work Types
We also define our work types within the AP. In fact, the AP is built around work types. In the case of our Change Request workflow, the work type is a Change Request. The Work Type is a fundamental aspect of how PRPC implements business processes, but it is a concept from workflows. If your processes are not workflows, you still have to identify a work type. Discipline in naming your SUCs will help you identify candidate work types. For example, if your SUC is called “Amend Address”, then your work type is likely to be an “Address Amendment”.
Atomic Use Cases
In the AP we document any AUCs that relate to that work type. I have never been very happy with AUCs and this morning it dawned on me why. PRPC has always implemented business processes using Flow Rules. On the Pega Developers’ Network it says that AUCs “correspond to one particular step or series of steps within a screen flow or a single flow action in the processing of a work type”. It becomes clear, therefore, that each AUC identified actually corresponds to a shape on a Flow Rule. In other words, rather than a tool that helps the analyst to think in the problem domain, the AUC is a design tool that forces the analyst to think in terms of the solution, which is not analysis at all. What’s more, there are sound reasons why you should ignore screens when modelling the logical flows of use cases.
While I am a great advocate of analysts and designers collaborating to get design off the ground as quickly as possible (see Lean Use Cases), it is important to understand the logic of each Software Use Case in our workflow before deciding what the implementation is going to look like. To that end, I would encourage you to model your SUCs as Activity Diagrams outside of PRPC, while a designer builds the corresponding Flow Rules inside the tool.
One thing for analysts to understand as that the Atomic Use Case can be used not just for documenting the business need, but also for documenting the technical solution to that specific need. Unfortunately, the AUC Rule does not have any fields that imply or cater for the distinction, so I have seen some quite messy AUCs where business need and solution are mixed up.
Discovery Maps
I like Discovery Maps even less than AUCs. The PDN tells us that “A Discovery Map is a flexible process mapping tool that captures a project’s high level processing steps in business terms.” There is already a very powerful tool for doing that and it is called Business Process Modeling Notation. Discovery Maps are part of an early attempt to enable DCO to become an analysis suite, but they are far from the mark yet. When you take a closer look at Discovery Maps, you come to realise that each step equates to an Atomic Use Case and, more specifically, to a shape on a Flow Rule. Rather than an analysis tool, therefore, the Discovery Map is just a colourful way to force the analyst to do design.
What a Discovery Map does not model:
- Alternative paths – a DM allows you to lump all alternative steps together, but does not model the flow logic of the alternative paths
- Branch points – a DM has no idea where alternative paths can split off from any other path
- Merge points – a DM has no idea where paths merge again
When you run the Application Accelerator, the DM generates a draft Flow Rule, but you have to manipulate the Flow to connect up the alternate paths. In fact, my own feeling is that it would be quicker to build a Flow Rule in the first place, than a DM and then manipulate the resulting Flow.
Through Discovery Maps and Atomic Use Cases, DCO attempts to jump straight to the solution without properly understanding the business need. While it is true that a premature solution can be quickly demonstrated and corrected in PRPC, I feel it is better to take steps to understand the business need in an agile way that facilitates the early elaboration of a solution.
I also have an issue with attempting to discover your high level business processes only after you have bought an expensive tool like PRPC. When a company issues a Request for Proposal before understanding its own business processes, it risks accepting a proposal that does not actually fit the need. The cost of a mistake like that can sometimes be measured in the millions.
Discovery Maps can be useful, though, not in exploring the business need, but in providing a bridge between a visual model of that business need and the solution provided by the corresponding Flow Rule.
In brief I would say:
- Use Discovery Maps if you have already modelled your SUCs as Activity Diagrams and you want to get a head start on design.
- Do not use Discovery Maps to “discover” your processes because they are a design artefact, not an analysis artefact.
Discovery Maps appear in version 6.1 of PRPC, so if you are using an earlier version, then discussion is moot. In 6.1 or later, you can run an earlier version of the Application Profiler if you want to avoid Discovery Maps.
Interfaces
The AP allows us to document any known interfaces to other systems and such important details as what protocols are used and how many interchanges are expected to take place, which is very useful.
Reports
We can also record in the AP some basic information about reports, but bear in mind that these would be reports on the use of the application itself, rather than MIS reports on business data.
Correspondence
We can record the details of any correspondence required in the AP, such as emails or letters that might need to be sent by the application.
Requirements
When documenting requirements, the tool allows us to document the following per requirement:
- ID
- Description
- Category
- Importance
- External ID
- Status (New, Open, Complete, Defer, Withdraw)
- Which PRPC Rules implement the requirement
You can also attach external files to supplement the requirement.
As for requirement category, the AP only offers us the following two:
- Business rule
- Non-functional requirement
I feel that list is too short, so I was pleased to see that you can type in your own category, such as:
- Common requirements (i.e., they apply across multiple functional areas)
- SLA logic
- Stakeholder requests
- Features
- Data validation rules
This does not update the list of available categories, so you have to type the category in each time.
However, when you go to add new requirements as Requirement Rules post Application Profiler, you are not able to type in your own requirement types. This inconsistency must be an oversight, as I cannot see a reason for it.
As for data requirements, we can create Property Rules, of course, but then we are creating physical Rules as implementation, not capturing the logical data model. This is a key gap in DCO for me, but we can make up for it with external documentation (see The Importance of Data Analysis).
My series of posts on Lean Use Cases will make it clearer how we can use Visio and Excel to supplement the DCO approach. Of course, I am looking forward to a future version of DCO which will allow me to model logical processes and the logical data directly into PRPC, rather than using their physical analogues directly.
At the end of the Application Profile wizard, we can generate a profile document. According to Pegasystems’ SmartBPM Methodology, the initial application profile should be generated during the Inception phase. In other words, the application profile is meant to be used to gain project approval before iterative development takes place, but I suspect most companies run the AP after the project has started.
Direct Capture of Objectives can be useful set of tools for the PRPC-aware analyst, but you have to be an experienced analyst in the first place. Passing Pega’s CBA exam will not turn you into an analyst overnight and neither will DCO. In fact, if your only experience of doing analysis is using DCO, then you are heading down the wrong path.
To become a good analyst on a PRPC project you need to do two things:
- Learn industry standard analysis approaches and techniques
- Do at least one project lifecycle as a junior developer on a PRPC project.
PRPC is a very good tool for implementing business processes and the idea of capturing the business needs in the tool itself is the right way forward. Some aspects of the DCO approach are very good, such as the ability to capture business objectives, work types, actors, interfaces. Some need further work, such as the ability to capture requirements. Unfortunately, DCO is wide of the mark when it comes to modeling processes and is totally lacking when it comes to logical data modeling.
Another important point is that the DCO approach hinges on the use of the Application Profiler and the AP hinges on Atomic Use Cases and Discovery Maps. However, not all of your requirements are going to need Work Types and Atomic Use Cases. In fact, if your requirements are for a Business Rules Engine project, then DCO might not be the way to go at all.
Kind regards,
Declan Chellar
