Pegasystems’ DCO: an analyst’s perspective

I’m bumping this post because of some updates, as highlighted in green below. Note that this post relates to Pega 6.1 and was originally drafted in 2009.

Some of you Pega Business Architects 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.”

Many people think that DCO = Application Profile Wizard. This is not quite right, although I understand why people confuse the two, since Pegasystems encourage you to use the APW. DCO is an approach which means capturing your business needs directly into PRPC. As such, attaching a business process model drawn in Visio to a Use Case Rule or a Flow Rule is in keeping with DCO. You do not have to use the APW do be using DCO.

Moreover, some people even think the APW = Discovery Maps. This is an even bigger mistake. Discovery Maps only came in with version 6.1. The APW existed before that. I would argue (and I do) that Discovery Maps are a step backwards and that the APW works better without them.

I applaud the intent of DCO, as I am dead against old approaches that result in analysis paralysis.

One of the key things to recognise is that Pegasystems encourage you to use 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”). So what does the APW give us?

Limitations
The first thing you should know is when to use the APW and when not to.

The APW hinges on the use of Work Types, which are integral to workflows. This means that it 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. Indeed, some of your business process might not be implemented in Pega at all!

So you might find the APW 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:

1. 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?
2. 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.

Requirement Rules can only be linked to one of three other types of Rule:

• Application
• Use Case
• Flow

You can link a requirement to an Atomic Use Case Rule and link that AUC in turn  to, say, a Utility shape on a Flow Rule. This can be done manually or via a Discovery Map and it’s all fine and lovely. However, if the LSA later decides to redesign the Flow Rule in such a way that eliminates that Utility shape, unless he remembers to go tie the AUC to another Rule, you will have both a Requirement Rule and and AUC Rule hanging with nothing apparently implementing them and traceability is lost.

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. People often have difficulty distinguishing between Business Objectives and High Level Software Requirements. The former are strategic and might even strike you as vague (if they are not well-written), whereas the latter are specific to the software you are trying to build (although perhaps not detailed). One thing to note is that traceability in PRPC does not include business objectives. Bear in mind also that unless your project is being implemented entirely within PRPC, this will not be the project’s definitive catalogue of business objectives.

Actors
The APW 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 APW as “Interfaces” (see below).

Work Types
We also define our work types within the APW. In fact, the APW 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 APW 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 (or as sub-processes using BPMN) outside of PRPC, while a designer iteratively 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.

However, because Pegasystems emphasise Atomic Use Cases, it is not always clear to the inexperienced that the Use Case Rule is not just for AUCs, it is also for Software Use Cases. I would encourage anyone to first create a UC Rule for the overall SUC and link that SUC to the relevant Process (or Sub Process), and later to the relevant Flow Rule.

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 Model & Notation. Discovery Maps are part of an early attempt to enable the APW to be 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 just to build a Flow Rule in the first place.

Through Discovery Maps and Atomic Use Cases, the APW 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.

I am willing to concede that Discovery Maps might be useful, 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 when you have nobody on the team who knows how to model Flow Rules.

I have a more detailed presentation of my views on Discovery Maps, including concrete examples, here.

Discovery Maps appear in version 6.1 of PRPC, so if you are using an earlier version, then discussion is moot. However, you don’t have to build out a Discovery Map in order to use the APW.

Interfaces
The APW 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 APW 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 APW, 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, in version 6.1 the APW 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.

The better news is that in version 6.2, you get the following default requirement categories:

• Business Rule
• Change Control
• Enterprise Standard
• Functional
• Non Functional

Update: there is a way to add your own requirement categories, click here for details.

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 generate the AP after the project has started.

The APW 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 the APW, then you are heading down a very narrow path.

To become a good analyst on a PRPC project you need to do two things:

1. Learn industry standard analysis approaches and techniques
2. 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 APW 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, it 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 APW 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 the APW might not be the way to go at all.

Any thoughts or questions? I would particularly welcome challenges from Pega people because either I can defend my point of view or my point of view needs to change.

Declan Chellar

Related posts:

• Pegasystems PRPC Discovery Maps
• PRPC Work Types
• Software Use Cases in PRPC
• Adding new requirement types to PRPC