Sizing process complexity

A lot of people think the complexity of a process is about the number of stages and steps it has but it’s not.

I have often seen BAs do an initial analysis of a business process by producing a diagram like this:

This is fine, as long as you have already established the scope of the process (see the end of this post for a link to a tutorial on that) and you are planning to elaborate the process beyond this simplistic diagram. Unfortunately, I have been on projects where the BA thought that was enough. A poor way to understand the complexity is simply to count up the number of stages and steps. However, a process is more than a count of its steps. The real complexity from a software implementation point of view lies in two things:

  • The decision points throughout the process
  • The points where any software you are going to build will need to interface with other software systems

Any other steps are going to be about gathering data either to make decisions during the process you are modelling or to send to other processes or display data to the user.

I won’t go into interfaces because they are for the technical solutions architect to explore (although the BA may be involved in identifying those interface points). In any case, if your process model is technology-agnostic, then interfaces will not be relevant yet.

The significance of decision points is often overlooked, however, largely due to a lack of awareness of the power of decision modelling. Most BAs I’ve met still think in terms of business rules, instead of decision logic. Moreover, they often start thinking about business rules too late. As soon as you have defined the scope of the business process, you should ask the business what key decisions need to be made within each process stage. At this point, the order of them is not important. It’s unlikely the business will be able to remember every step that needs to be performed in the process but it is quite likely they will remember the important decisions that need to be made.

You need to understand two things about a business decision at this stage in your analysis:

  • Roughly how many outcomes it can have
  • Roughly how many data items are needed as inputs

This information is enough to be able to ‘t-shirt size’ those decisions. I don’t have a formula for calculating the complexity of a business decision based on those two pieces of information but I’m sure you can see that a decision that can produce two possible outputs based on three inputs will be a lot simpler to analyse, model, test and implement that one that can produce five possible outputs based on 300 separate input data.

The technical solutions architect will size any interface points and you can produce something like this:

In this example, the zeroes represent steps that just gather or present data, while the ambers and blues represent decision points and interface points.

When asking the business to identify the decisions they have to make, help them identify hidden decisions, i.e., ones that they are so used to making that they don’t give them much thought. Examples could be: duplicate checks, whether to send an email, how to determine what data to put in that email, data validation logic, etc. In a loan application process, don’t assume that the only decision being made is whether to approve the loan.

Taking a decision-focused view of the business process will reveal the true sophistication of the process.

Kind regards.

Declan Chellar

Related posts:

Follow by Email

Pega Case Life Cycle Model – Part 2

In Part 1, we went through some of the key terms Pega terms in Case Life Cycle modelling. Here, in Part 2, we’ll compare modelling a Case life cycle using Pega 7’s modelling tool with BPMN 2.0.

The life cycle view of a Case in Pega 7 is similar to the Discovery Map in Pega 6.

Case lifecycle example in Pega 7

However, other than the sequence of the three primary stages, it is not possible to show the flow of the life cycle in Pega 7. If you are using it as a high-level technical solution design tool, that’s fine, but if you’re using it to gain an initial understanding of the business process, it is not necessarily appropriate, as we’ll explore further in Part 3. As an analysis tool, it has the same weaknesses as its predecessor, the Discovery Map. In this model, it’s not explicit that ‘Review Claim (2)’ is actually an alternate path. Moreover, while you can see that ‘Approval Rejection’ is an alternate stage, you cannot see where it branches from the primary.

Using BPMN, however, you can see at a glance the high-level view of the entire life cycle, what the key stages are, what the primary path is (in blue below), what roles are involved, what the alternate activities are (in grey) and what the business exceptions are (in pink) and then drill down into the sub-process according to your audience.

The high level view of the 'Manage Expense Claim' process in BPMN.

Even with this high-level overview of the business process, you can start to build test scenarios to make sure the process works at a business level before implementing anything in Pega. I’m a big fan of testing the business logic before you implement, so that when you test the software, you are testing only that the software works and not that the business logic makes sense.

Notice that I have re-used the sub-process “Review Expense claim”. Any differences can be handled by alternate paths in the child diagram or in the logic of any decision points in the child diagram. In the Case Life Cycle Model, such re-use is not obvious, nor even suggested. The fact that “Review Claim (1)” and “Review Claim (2)” means they are different processes in Pega.

In Pega 7, you can model the flow of a particular path through a particular Stage (remember, this is what Pega calls a ‘process’). Take the ‘Review Claim (1)’ process from the Pega life cycle model above, for example:

Pega Flow Rule

Here is the corresponding diagram for the ‘Review Expense Claim’ sub-process in BPMN:

Review Expense Claim sub-process in BPMN.

I’m sure you can see that if you gave that diagram to Pega developers instead of a textual use case, they would find it much easier to understand what flow to build.

Note: in Pega flows, the diamond shape represents a Decision Rule that holds the implementation of the decision logic. In BPMN, the diamond shape (called a ‘gateway’) simply interrogates the outcome of the decision logic, while a model of the logic itself sits in a Decision Model behind the corresponding ‘business rule’ task (in this case, ‘Determine Further Review Required’).

Here’s an important point for traceability: I would add a Specification in Pega of type User Story to represent any atomic tasks in the BPMN model. In the case of ‘Determine Further Review Required’ the actual business logic I would model and test in a Decision Model of the same name. The logic (business rules) in the Decision Model would essentially be the requirements. Neither a Process Model nor a Pega Specification is an appropriate mechanism for modelling business logic. Any Decision Rules in Pega could be traced back to the Decision Model via the relevant Specification and the ‘Determine Further Review Required’ activity in the Process Model.

I hope you have found this post useful. Thanks for taking the time to read it. For bonus points, have another look at the second BPMN diagram above (click here if you don’t want to scroll back up) and tell me:

  • Why I assigned the Business Rule type to the task ‘Determine Further Review Required’
  • Why I assigned the Service type instead of the Send type to the ‘Notify Employee’ tasks

In Part 3, we’ll consider when you should and should not use Pega’s Case Life Cycle Design tool to model the business process.

Kind regards.

Declan Chellar

Related posts:

Follow by Email

What is a Business Architect?

Some years ago, I was asked: ‘What is the difference between a Business Analyst and a Business Architect?’

My reply was that a Business Architect was someone who can apply the techniques of business analysis to an architectural framework in a technology-agnostic way. There are other differences but that was what occurred to me at the time.

However, that led me to ask myself: ‘What is a Business Architect?’ I think there are two types, broadly speaking. One would be someone who can truly shape a business and decide, or at least advise, what its business model should be, what strategies it should put in place and what it needs to do to implement those strategies. I am not that type of business architect. That kind of strategic advisory role requires deep knowledge and insight into a particular business and a particular industry. However, the people with that knowledge often lack the formal language/framework to model their ideas. As the poet John Ciardi said: “The language of experience is not the language of classification” (which is why, on software development projects, simply writing requirements in business language so often leads to business people saying during UAT: “Yeah, but that’s not what we meant”).

My area of expertise is the language of classification, or, rather, languages because each modelling technique is a language of sorts with its own vocabulary, grammar and syntax. Modelling techniques also allow variations in method and style, which are effectively dialects. In other words, I am a technician, not a strategist. I am a ghost writer. I cannot tell you what your strategic goals should be but I can help you put structure on them to make them clear and unambiguous. I cannot tell you what your business model should be but I can help you describe it formally in the language of the Business Model Canvas. In asking you the kind of questions the rigour of the canvas demands, I can help you articulate things that are so normal to you that you wouldn’t otherwise have thought they needed to be articulated, or help you think of things you wouldn’t otherwise have thought of at all.

Business Architecture is typically defined as:

‘A blueprint of the enterprise that provides a common understanding of the
organization and is used to align strategic objectives and tactical demands.’

With that in mind, I would say the strategist provides the content of that blueprint, while the technician provides the form. Ideally, an organisation would have a Business Architect who is a combination of strategist and technician but a strategist would likely not have the time to gain experience in the detail of technical models of the 2nd row of the Zachman Framework. On the other hand, a technician would not likely have the time to gain the business experience. However, their experience and skill sets are complementary. In fact, my view is that the 1st row of the Zachman Framework is where the two types of Business Architect mostly collaborate.

If I were to be precise, and those who have worked with me know that is one of my strengths, I would label myself a “Business Architecture Analyst” in that I analyse the architecture of a business, rather than the business itself.

Well, I’m glad I cleared that up.

What are your thoughts?

Kind regards.

Declan Chellar

Follow by Email

There should be no legislation against ‘hate’ crime

I hope that got your attention. However, this post is about defining terms well so that your business architecture and how your business operates does not get bloated simply because people conflate different concepts.

I’m using the concept of ‘hate’ crime because I happen to be discussing the topic with someone on Twitter and it illustrates an important point about modelling business taxonomy.

Having seen a tweet decrying the fact that the Republic of Ireland does not have any legislation against hate crime, I tweeted: ‘I don’t understand ‘hate crime’ laws. If someone [intentionally] stabs me, should it matter whether they hated me or not? Feel free to educate me.’

Moreover, if someone stabbed me, I would not want them to receive a different punishment based on whether their motivation was my skin colour, or the fact that I’m bald, or robbery, or anything else. I would certainly want the motivation to be recorded, however. By the way, I was assaulted once, by someone who made it clear with their words that the motivation was my skin-colour.

In response, I was sent the following argument:

Yes, it does matter. Obviously, any crime impacts on a victim. Hate crime has further impact as hate crime victims imply assert that their experience was an unlucky occurrence (wrong place, wrong time), they are forced to accept that their identity was targeted and they remain at risk of repeat victimisation. Fear of being targeted impacts on the way people live their lives, with victims changing the way they live, limiting their use of public space, etc. Hate crime’s ripple effect is also significant. As well as impacting on the victim, it sends a message to that community.

It would seem, therefore, that the intent is to acknowledge the motivation for the crime and to use that knowledge to educate victims and society at large and to enable us to tackle the root causes of such motivations and therefore the crimes themselves.

However, to achieve that, you don’t need separate legislation against attempted murder and attempted murder because the perpetrator hates, say, people with brown skin. You simply need to be able to record the motivation for the crime against the crime itself. One crime on the statute books, many possible motivations for that crime. That would be sufficient to provide the data needed for education and prevention programmes.

Having separate legislation for each motivation has several disadvantages without improving data for education and prevention:

  • Increased statutes and the corresponding time and effort involved in debating and adding such statutes
  • Operational overhead in having to add a new statute each time a new motivation is uncovered (as opposed to simply adding a new motivation to an existing statute)
  • Risk of allowing different levels of sanction against the same crime for different motivations

For those who want particular hate crimes, or hate crimes in general, to be addressed, it would be quicker, more effective and cheaper to campaign to have a new motivation added to crime reporting than to have a new statute added.

Actions and the reasons for those actions are related but distinct. Modelling them as the same thing makes for inefficient and ineffective operations, whether in terms of criminal statutes or business operations.

Is there a flaw in my reasoning? Let me know. If you can sell me your argument, I’ll spin on a sixpence.

Kind regards.

Declan Chellar

Follow by Email

Review of the PegaBPM Methodology

In this blog post I aim to provide an appraisal of the Pega Developer Network articles “What is the SmartBPM Methodology?” and “Using Pega BPM with PRPC“, based on my experiences working on Pega projects in the field.

I am a Certified Pega Business Architect (7.2) and Pega Methodology Black Belt, and here I provide an alternative to SmartBPM (now known as PegaBPM), which I hope addresses what I perceive to be the shortcomings of the methodology. This post addresses the SmartBPM methodology only and not the Pega Scrum methodology. Moreover, it does not address techniques specific to any discipline (e.g., use case modelling).

Note that Pega clearly states that the SmartBPM methodology “is not a concrete prescriptive process”, that it is adaptable and that the phase information is an outline only. Therefore some of my suggestions are nothing more than an adaption of the methodology and others merely add detail to what is currently in outline form. However, other suggestions are the result of the problems I see with the original PDN article or with the methodology itself. You can download the full appraisal in PDF form from the link below, but here are what I consider to be the critical flaws in SmartBPM.

Continue reading Review of the PegaBPM Methodology

Follow by Email

Pega 7.2: business objectives, requirements and specifications

If you are a Pega Business Architect, you will be familiar with Pega’s feature that lets you connect Business Objectives, Requirements and Specifications.

This feature is excellent for traceability but it may surprise you to know that I don’t use it exactly the way Pega tells you to.

Business Objectives

‘Business objectives illustrate how the Pega application delivers value to the business’1

It’s important that everyone on a Pega development understands what value they are trying to deliver to their customer because software delivery is not an end in itself, it is merely a means to the true end, which is realisation of the desired business benefit (which should be stated in the business case and encapsulated in the Business Objectives). Yet you’d be surprised at how few projects (in my experience) actually document Business Objectives in Pega. I’ve even worked on projects where no one on the team could tell me what they were or where they were documented. Not only do I document them, I also like to print them out and stick them on the wall so everyone keeps sight of them. Pega encourages you to keep Business Objectives SMART, which is absolutely correct, and provides you with the means to capture them:

However, I have some reservations. Firstly, any Pega project I’ve been on has had a wider scope than the Pega solution, usually involving other technologies as well as non-technological business changes, so there will be Business Objectives which are important to the success of the change initiative but which are not relevant to the Pega solution. Thus it makes no sense to make Pega the golden repository of Business Objectives, rather, I would document the Business Objectives in the business architecture repository and put a reference in Pega to the ones relevant to the Pega solution.

Moreover, while you can write a SMART one-liner, I like to put a lot more meat on strategic business goals. Click here to see what I mean.


‘One or more requirements define the criteria for the successful implementation of a specification.’2

Pega allows you to capture Requirements via the following form:

This form has hardly changed at all since Pega first introduced DCO in 2008. That’s not a bad thing in itself because many organisations still develop software the way they did in 2008 and the tool caters for that. In any case, if you don’t think it’s broken, why fix it?

My preference these days is to work with User Stories rather than Use Cases. The Pega Specification (see below) allows you to document either User Stories or Use Cases. The statement above, talks about Requirements as if they were User Story Acceptance Criteria, which they are, in my opinion, if you are taking a User Story approach.

The main problem I have always had with the Requirement form in Pega is that there is no way to indicate which Business Objective the Requirement is supposed to support. If you are following Pega’s methodology, you first document Business Objectives and then an initial set of Requirements. However, since you cannot link the two directly, the opportunity for scope creep is there. I suspect this lack of linking is also part of the reason people often ignore Business Objectives.


‘Specifications use business language to describe the steps needed to meet a requirement.’3

That’s what Pega says Specifications are for but it’s not what I recommend. Pega allows you to document Specifications as either Use Cases or User Stories and since my preference is for the latter, let’s stick with that. I prefer Mike Cohn’s definition of a User Story:

‘User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.’ – Mike Cohn4

I also like the description of User Stories as ‘placeholders for a conversation’; that being the case, a Specification in Pega is effectively a useful placeholder for anything you care to document about that conversation (business background, diagrams, acceptance criteria, technical solution designs, risks, assumptions, links to further useful information, etc.). Remember, Agile principles promote conversation over documentation, not instead of documentation.

Notice that it is a Pega Specification that you link back to a Business Objective (unfortunately, only one), so although the sequence of creation is supposed to be: Business Objective –> Requirement –> Specification, the mechanism of traceability is, in fact: Business Objective –> Specification <– Requirement.

 Notice that you can document both Acceptance Criteria and Requirements against a Pega Specification of type User Story:

 As I said, I consider the Acceptance Criteria of a User Story to be Requirements and judging by Pega’s definition of the purpose of Requirements (‘requirements define the criteria for the successful implementation of a specification’), perhaps they would agree. Therefore, I would not add both Acceptance Criteria and Requirements to my Pega application. Instead I would:

  1. Document Business Objectives
  2. Add User Stories from the customer’s Product Back Log in the form of Specifications
  3. Document Requirements or Acceptance Criteria against those Specifications

Note that if you document Requirements as Acceptance Criteria, you only get to add a single line of text. However, if you document Acceptance Criteria as Requirements, you get the richness of the Requirements form (see above).

Although my approach is not how Pega’s training says to do it, it does give you traceability from the outset: Business Objective –> Specification –> Requirement / Acceptance Criterion

Full credit to Pega for not enforcing their way of doing it. That’s the right approach to methodology: adapt it to your needs.

What have your experiences been?

Kind regards.

Declan Chellar

Follow by Email

Deriving Business (User) Stories from your Business Architecture

For any kind of enterprise-wide change initiative, if you derive your backlog of Business Stories only from interviews with users, you may to end up with a patchwork of individual needs that don’t necessarily hang together, some of which will conflict with each other and which won’t give you the enterprise picture.

If you don’t already know why I say “Business Stories” instead of “User Stories”, click here for some pre-reading.

Some time ago I worked on a programme that was already in sprint 8 of its software development by the time I joined. Two large walls were plastered with index cards representing Epics and User Stories. Considerable time was spent daily on re-arranging those cards, involving at least two senior business analysts and the Product Owner. After a week, I asked what they were doing and I was told that they were trying to organise the cards so that they represented the relevant business processes. My response was something along the lines of: ‘Surely the business architecture that drove out these stories already shows the relevant business processes.’

I admit, I knew there was no business architecture and that I would get blank looks but I wanted to make an important point, which is that you should derive your initial Product Backlog from your business architecture, not try to reverse-engineer your business architecture from a bunch of User Stories.

That conversation led to another one with the Product Owner and not long afterwards I was asked to work in parallel with the software development project to help the business define its technology-agnostic architecture and use that to verify whether the Product Backlog contained the right stories.

It turned out that many of the stories were wrong, or duplicated other stories, or conflicted with other stories and that no amount of re-arranging the index cards was going to tell the over-arching story: “What is the very nature of this business for which we are spending millions on software development?”

One of the key things missing was a common understanding of the strategic objectives of the programme. I eventually managed to trace down a list of them in a slide deck attached to an email (that’s right, not in a repository where anyone could find them easily). They were poorly worded, with no indication of who owned each goal, what time frame was needed or what the business value was. In fact, a set of well-structured business goals should be the starting point of your Product Backlog.

Also missing was an understanding of the business taxonomy. The organisation involved had thousands of employees, all of whom originally came from other parts of the enterprise. To use fruit as an analogy, some said ‘mandarin’, while others said ‘clementine’, when they both meant ‘orange’, so there was some duplication of user stories that was not obvious either to the Product owner or the senior business analysts. In other scenarios, multiple groups said ‘apple’, when one really meant specifically ‘granny smith’, others meant ‘royal gala’ and yet others ‘bramley’, so in some cases there was only one user story when several were needed and, again, that was not obvious either to the Product owner or the senior business analysts. In some areas of the business it was even worse: they didn’t know whether the concepts they were talking about were apples or oranges or even whether they were fruit at all.

By the way, this lack of consistency when it comes to naming and defining important concepts is common in organisations where ‘dialects’ develop over time as the enterprise grows, especially if that growth is due to acquisition of other companies. A well-formed enterprise-wide business taxonomy is an essential lingua franca.

A robust (by which I mean mature, tested but open to change) business taxonomy will suggest many candidate Business Stories. All you have to do is look at each thing defined in the taxonomy and ask whether key roles need to be able to CRUD it and you end up with candidate Business Stories along the lines of ‘So that [business value], as a [role] I need to be able to [create/read/update/delete] a [business concept]’.

Another problem on that programme of work was a total absence of business process models, which is why the senior BAs were trying to reverse-engineer processes from the Product Backlog. In fact, robust process models suggest candidate epics and stories. You could argue that a whole process can be represented by an epic. You could also argue that a particular path through a process can be represented by an epic. Either way, once you get down to atomic activities in your process model, you have candidate stories. The role represented by the relevant swimlane suggests the actor in the story (caveat: but not always), while the label on the activity itself suggests the narrative. The only thing missing from the diagram, although it should still be accessible as part of the meta-information of the model, is the business value of performing that activity.

These are the main examples of how your business architecture can be used to drive out a candidate backlog of epics and stories. Sometimes further analysis will reveal stories that aren’t covered by anything in the business architecture, in which case you update the models of the architecture to reflect the new understanding.

How do you derive your initial enterprise-wide Product Backlog?

Kind regards.

Declan Chellar

Follow by Email

Pega Case Life Cycle Model – Part 1

Pega 7’s case life cycle modelling tools enable you to quickly model and demonstrate a high-level process design within Pega in front of your customer.

The tools I’m talking about are the life cycle view of a case type and the flow view of a process within a case type. While these are useful tools for the high-level technical solution design and, importantly, getting your customer on-board with that design, I do not see them, strictly speaking, as business analysis tools.

Here, in Part 1, I explain some terms for BAs who may be new to Pega.

Case Type
You may think this is analogous to a business entity, especially when you see examples of Case Type names as noun structures, e.g.: Expense Claim, Vacation Request, Loan Application, Customer Order, etc.. The reason we use noun structures in data models and business glossaries is to emphasise the static nature of the model and to allow us to fully understand what something is separately from how we process it. However, the Pega glossary definition of a Case Type uses the language of process: ‘A case type represents work in your application that follows a life cycle, or path, to completion (the bold type is my emphasis).

If you’ve taken the Pega BA training course, you may remember the training material says: ‘A case type is a type of artifact in Pega used to define the tasks and decisions needed to resolve a case’ and ‘Case types model how and when work gets done‘ (the bold type is my emphasis). Pega also says a Case ‘delivers a meaningful business outcome to a customer, partner, or internal stakeholder’.

If you’re a business analyst new to Pega, these statements might strike you as more akin to definitions of a business process (hover here to see my definition), whereas you might understandably think of a ‘Case’ as a business entity. Indeed, the Case Designer in Pega is essentially a tool for designing the high-level implementation of a process. So when you are discussing Case Types with your team, be aware that it has a data model aspect (the What) and a life cycle aspect (the How). That Pega wraps the what and the how together in the Case Type has an impact on how you choose to model the business, as I shall explain in Part 3.

In Pega terms, a Stage ‘is the first level of organizing work in your case type’. You may by now have studied my slide deck on defining process scope, in which case you will know that my first iteration of a process model only addresses the Key Stages of the process. This is the highest level view of how a process breaks down into activities. This is similar to what Pega calls a ‘Stage’. One main difference is in the naming convention. Pega uses a noun phrase, whereas I use the BPMN convention of modelling key stages as sub-processes, thus I name them with verb phrases.

Another important aspect of a Stage in Pega is that each stage typically represents tasks performed by a different role. For example, an expense claim can go through submission, review and payment stages, with the Case assigned to a different role at each stage. At the very least, a Stage is one or more Processes (see below) that must be completed before then next stage can begin, even if only one role is involved.

This concept of a Stage in Pega is inseparable from the concept of a Case. This also has an impact on how you choose to model the business.

In Pega terms, ‘processes are organized within [my emphasis] stages and define one or more paths the case must follow’. In other words, in Pega, each possible path through a Stage is a separate process. Here is an important difference in language between a business analyst trained in process modelling using BPMN and a Pega business analyst.

In BPMN a Stage is a sub-set of a Process. In Pega 7, a Process is a sub-set of a Stage.

In Pega 7. the terms ‘alternate’ and ‘exception’ are synonymous. ‘Use alternate stages to organize the process steps used to manage exceptions from the primary path’. To my mind the word ‘alternate’ refers to a different way to achieve your original objective; it’s a deviation from the normal path but you still end up where you wanted to go. An ‘exception’, on the other hand, deviates from the normal path but does not lead you to your desired outcome. Be aware that many software developers only use ‘exception’ to mean technical exceptions (e.g., what to do when a particular system doesn’t respond to a request), rather than business exceptions.

In Pega 7, a Participant is an actor who performs activities. The term for this in BPMN is Performer. A Participant in BPMN is an entity (external to your process) or another process, that interacts with the process you are modelling.

I’m not pointing out these differences as a criticism of Pega but to make you aware of them, so that when you hear Pega Systems Architects using them, you don’t get confused.

In Part 2, I’ll compare Pega’s Case Lifecycle Model with BPMN 2.0.

Kind regards.

Declan Chellar

Related posts:

Follow by Email

Complexity versus Difficulty

On software development projects people have to estimate the effort involved. In doing so, one of the things analysts are asked to consider is the complexity of a process, but it surprises me how often analysts confuse complexity with difficulty.

The two concepts are mutually exclusive.  A process can be simple, but difficult to implement. Another process could be complex, but simple to implement. Yet another, simple and easy or complex and difficult.

Complexity is a measure of how many possible paths there are through a process. The terms of reference will be specific to each organisation, but the least complex process is one that has a single path (regardless of the number of steps along that path). The measure of complexity increases with the number of possible paths and possible outcomes. Based on whatever measurement applies within their organisation, it is the Business Analyst who evaluates the complexity of a process.

Difficulty, on the other hand, is a measure of how hard it is to implement a process. Difficulty often arises because one or more steps in a process require one system to interface with another. As such, difficulty is for the Technical Architect to measure, not the Business Analyst.

However, if you are a Pega Business Architect documenting specifications for Pega implementations, you should note that the Specification template has an attribute of ‘Complexity’ which is used to mean ‘estimated level of effort’. The Business Architect Essentials Student Guide for Pega 7.2 says on page 155:

‘Select the estimated level of effort ( high, medium, or low) to implement the specification. This helps you plan your project where you can focus on high complexity tasks earlier on in development since they will likely take more time to create.’


Since there isn’t a field in the Specification template for ‘level of effort’, the implication here is that ‘Complexity’ in Pega means level of effort (i.e., difficulty). Any Pega Lead Systems Architect I have discussed this with has confirmed the ‘Complexity’ field in the Pega Specification template is used to indicate technical difficulty, rather than complexity.

Kind regards.

Declan Chellar

Follow by Email

Introduction to the BPMN 2.0 Level 1 Palette

The slide deck below is an introduction for process modelers to the Level 1 Palette of shapes for Business Process Modelling Notation 2.0.

When I was new to the BPMN palette years ago, I used it as I had used any other process flowcharting palette previously, i.e., I used the shapes as I saw fit. I did not realise that each shape has a specific semantic and that there is a specification behind the notation that is managed by the Object Management Group. Once I realised that I couldn’t just make it up as I went along, I sought out training and certification, which I achieved with Bruce Silver, BPMN Yoda and author of “BPMN Method and Style“.

If you are new to BPMN, I hope this slide deck will be useful as an introduction to how to use the shapes of the Level 1 Palette.

Note that I have updated the slide deck (it’s now version 1.3), so if you’ve seen it before, you might like to have another look.

Kind regards.

Declan Chellar

Related posts:

Follow by Email