Pegasystems PRPC Discovery Maps

Since my blog post on Pegasystems DCO, several people have asked me to expand upon what I said about Discovery Maps.

The expansion is in the slide deck below. In summary, although Pega Discovery Maps are intended as a mechanism for Pega Business Architects to model business processes in business terms, they are too crude to do that effectively. My own experience is that a business should approach any software development project with their To Be processes already modelled (e.g., using BPMN 2.0). That would be sufficient to allow the appropriate person to built robust Flow Rules. Discovery Maps, in my experience, inadequately and inaccurately model processes and are, as such, an obstacle to success.

Pega Discovery Maps are liked by people who have no experience of, or training in, modelling business processes because they are very simple. But way too simple. Discovery Maps are just not capable of capturing the complexity of a process that has even one alternate flow.

However, while PRPC is an excellent process implementation tool, Discovery Maps just don’t cut it for me. They strike me as a tool designed for analysts by people who have never done analysis. Bear in mind that part of my job on a Pega project is to clearly define the business process in terms of needs and to communicate that to everyone as leanly and as clearly as possible. I have a scalpel that helps me do that job well and it is called BPMN. I don’t need to be lumbered with the blunt pocket-knife that is the Discovery Map.

There is a misconception that you must produce Discovery Maps on a Pega project, but that is not true. Discovery Maps serve only to A) model the business process and B) automatically generate Flow Rules, but as you will see in the slide show below, they don’t do either very well.

If you want to document business process within PRPC, my advice is to do the following:

  1. Model the process using BPMN before your Pega project starts
  2. Build your Flow Rules manually based on the process models (it only takes minutes if your models are robust)
  3. Attach the process model to the relevant Flow Rule (that is DCO too, you know)

What have your experiences of Discovery Maps been?

Related posts:

6 comments to Pegasystems PRPC Discovery Maps

  • George Haytov

    Dear Declan,

    Thank you for your detailed and interactive review. I couldn’t agree more with you about the discovery maps!

    This feature is really causing confusion but I was not sure if it was my understanding of it or the lack of experience using it.


  • Dear Declan,

    Great Post. I cannot agree with you that the tool causes more confusion than clarification for analysts. I have had my share of confusion and learnings with the tool. I slowly came to terms with the tool.

    How I see the tool is- each box is nothing but a use case. So the discovery map is nothing but use case diagram. The differences are
    1) Use cases are at higher level as Pega calls it business use cases
    2) It has a sequence ( so little better than use case diagram in that sense)

    So if i ask an analyst to define a process in terms of usecases diagram then what you get will not be drastically different from a discovery map. Infact discovery maps provides some sequence to use case diagram.

    I agree with you that the making a flow from discovery map is going to avoid all decision points, triggers etc. but if again thinking in terms of use cases, this criterion would be inside those use cases.

    So although i am not a great fan of discovery map, perhaps changing a way to look at those will help adapt to (if not appreciate) the tool.

    Please share your thoughts.

    best Regards,
    Sumit Talwar

    • Thanks for taking the time to comment, Sumit.

      The main problem I have with the Discovery Map is that it is supposed to be a notation for modelling business processes, yet it cannot model process flow outside the primary flow. Other notations already exist which do that better, including BPMN for business processes and UML Activity Diagrams (or even PRPC Flow Rules) for modelling Actor/System interactions.

      You should not have to come to terms with a bad tool when good tools already exist. Believe me, I have tried very hard to appreciate the Discovery Map and make it work, but it does not.

      As for process flow, while you can describe the flow textually inside a SUC, it is preferable to do so visually. This is a key tenet of iterative and agile development. Discovery Maps cannot do this. My point about Flow Rules is that in my experience, it is quicker to build them manually from a business process model or activity diagram prepared by the Business prior to project initiation than it is to try to figure out how to fix an incorrect Flow Diagram generated automatically from a Discovery Map.

      To address your two numbered points above:
      1. Business Use Cases model an entire process from start to finish, include any necessary manual steps (e.g., talking to a customer) and any steps using technology other than PRPC. In PRPC we should model only what PRPC is going to implement, so BUCs have no place inside PRPC.
      2. A Use Case Diagram is primarily for showing functional scope. Since Software Use Cases would be children of BUCs, the BUC will already show the sequence. once again, the Discovery Map does badly what an existing notation already does well.



  • Katherine

    Hi Declan,
    I am so relieved it is not just me that feels this way about Discovery Maps. I come away from every experience with them wondering what I am missing and if I am not getting something that someone else is. It is very hard when coming from a BPMN background to model at such a simplistic level without decision points and manual steps, and trying to explain it to someone else is a nightmare!

    We take a very detailed set of BPMN diagrams into our inception workshops and seem to take a backwards step in converting them into a map, regardless of the flow it may generate. I agree it would be easier to manually model these than go through the confusion and limitations associated with the tool. Many people seem to get lost on the way, and this is compounded by many differing modelling techniques by the System Architects.

    Stakeholders these days are generally clued up on process mapping and can easily cope with direct modelling so I would embrace your approach and lobby it in our organisation! Your slide pack is the first thing that has started to make sense of this whole puzzle in my head.

    Kind regards

    • Thanks for the feedback, Katherine. I know I’m right about Discovery Maps, because I went through a painful, six-month period of trying to prove myself wrong. Even so, it is reassuring to get confirmation from people such as you.

      If you can think of any way I can improve the slide deck to make the message clearer, do let me know.


Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>