This week I've been on a course to learn how to use Pega, a business process management (BPM) tool. My company wants to use this BPM tool for several goals. The main one being to wrap 'legacy' (everything that is not our goal architecture) software and use that for business process automation. Pega is really a good tool for this. An other goal is to minimize the time to market of our company.

The last one is tricky I guess. Other development environmentswe currently have are .Net, Oracle, Java, etc. One of the main problems the business side of our company has is the time it takes to design, implement, test and release new software products. The goal is to have a greater focus on standard software, which only has to be configured. Custom made software has it's advantages, but it takes time to develop. Configuring is a good idea. Pega is seen to be such a standard application, which only has to be configured. I think this is only partly true. Pega is able to handle a lot of different types of applications, always seen from a process perspective, of course. This makes the configuration complicated. Integration with other application, services or otherwise, will take technical knowledge.
To deploy software, Pega generates Java code and compiles this. The complex configuration and the generation of a third generation language makes Pega a fourth generation programming language, like Cool:Plex or Oracle designer. Where these products are data-focused, Pega is process focused.

The question is if Pega will shorten the time to market. I believe that it is possible with any modern development environment to have a short time to market. But there are choices to be made. Developer produce code (not software). This is why they want the best code quality there is. But a high quality of code and the prevention of bugs and functionality that doesn't do what it was ment to do, take a lot of time. The quality of designing, testing and maintaining determine the length of the time to market. Say, if we let developers make the designs and the software, we skip unit testing, we accept less quality and a higher production speed. Of course this doesn't really mean less quality, but less guarantee on quality.

Pega can become really complex if not maintained properly. This means that the choice is the same: the line needs to be drawn between quality guarantee and development speed. Please understand me correctly: I'm not judging Pega. I like the view Pega has on processes and it sure has it's applications. But Pega is a development environment and the software has to be designed, maintained and tested. There has to be some form of quality guarantee and this will take time.