It is exactly five years ago in June that I started working for BPM Company: A new company focusing on implementing Pegasystems software for a growing group of customers. It was in 2011, when Gartner positioned PegaRules Process Commander (PRPC) as a BPM Suite. Previously, I always assumed that the abbreviation, BPM, stood for Business Process Management but maybe I was wrong all along. In the last 5 years I have considered 5 different meanings.

Read more: 5 years employed, 5 alternative meanings for BPM

Having experienced test automation and also having done it myself for various BPM solutions, I have come across some repeating issues.

Read more: Common Troubles With Test Automation

In the first decades of software development all programs were mainly written in traditional programming languages, such as Cobol, Visual Basic, C (++) and Java. The main disadvantage of a traditional programming language is that it can only be understood by technical experts and it is far from the language that is spoken in business. Therefore, in the past decades, various Model-Driven Development (MDD) platforms have come up. In this blog entry, I will share some thoughts on model driven application development.

Read more: Do Model-Driven Development (MDD) platforms make good on their promises?

Many employees are complaining about their jobs. They have to spend too much time on tasks they hate and cannot spend enough time on tasks they love to do. So to increase employee satisfaction it is very important to get rid of those tasks that are making employees unhappy.

In most modern offices employees have to deal with tasks they perceive as bureaucratic, mind numbing or inefficient. Instead of helping customers or creating new products they are wasting their talents on pushing paperwork, endless email chains, scraping information from numerous old systems, waiting for approvals and waiting for answers to questions asked a long time ago.

Read more: Improving Employee Satisfaction with Business Process Management Systems

Pega offers an interesting set of methods and tooling for directly capturing requirements and specifications into the system, called Directly Capture Objectives or DCO. The core of DCO is having DCO sessions where business and IT delegates work out the process flows and draft UI together. From practice I’ve seen that it's not always easy to make it work on the short run. Expectations of the results can be unrealistic and it takes some time for people to get used to the DCO way of working. But don't lose hope because when it starts working, it really gives a good vibe to your BPM project. This blog explains three do's and don'ts for working with DCO.

Read more: Six Do's and Don'ts for Directly Capturing Objectives

Page 6 of 7