Hi,
I am going to present something i known about PEGA PRPC (Pega Rule Process Commander).
The first good news to all NON-IT guys is: "This is the product for you all". To become a PEGA PRPC developer, you don't need to know any CSE stuff other than some OO concepts and little bit of java.
For all IT and Research guys, this is the area to consider as next gen programming paradigm.
The core concept of PEGA PRPC revolves around "Changes in software with time is inevitable". And PEGA PRPC's work is to cut down the costs involved during those changes.
Most of the products will spend 70% of their life time in maintenance adjusting themselves with the changing requirements of client / end user. To make this phase easier and cheap, we have to follow various software development methodologies like XP and follow industries best practices and coding conventions and Knowledge transfers ....... Blah Blah..........Blah.
PEGA products (www.pega.com) tag itself says how it fits in this scenario --- "BUILT FOR CHANGE". The products/services built using PEGA are resilient to changes. PEGA achieves this by separating the Business policies from application code. As the time changes, Business policies will change. Untill now, Change in policies require change in application code also. But here both the things are separated and changes in one module doesn't require to touch any part in another.
Let get into some technical jargon....
PEGASystems is the leader in Developing Business Process Management applications.
For starters, BPM (Business Process Management) software are usually tools that let business users directly interact with the system to set their own business rules and manage/change other aspects of the system dynamically when required. In short, a BPM tool tries to eliminate the need for developers and software coding so business users can directly make the changes they need like setting up business rules and policy execution flows once a platform has been built and adopted in the enterprise. Pega Systems delivers fast and immediate business benefits including improved revenue growth of 30% and more, cost reductions of 40% and more thanks to work automation, and 5 points increase in customer retention
To add strength to my arguments let me compare PEGA PRPC based development with Java.In the Java IDE Environment, adding a new process, changing an existing process, and discontinuing an existing process. require code changes, database changes, and re compilation. By contrast, we found modifications to be very easy with Process Commander. All that was needed was to make changes to Visio flow diagrams, which automatically drive changes to the rules in Process Commander. In fact, the ease of changing and updating the application makes it possible for Business Analysts/Users to make changes without directly involving IT resources. We find this capability to be a core strength of Process Commander. Process Commander protects developers from introducing new logic by adding a new property to an existing class; updating and discounting an existing logic flow, and measuring the time it took to complete these tasks. With the support of Visio-based flow diagrams and HTML forms. The appropriate rule form supports each step. Commander provides wizards for Web Services Development. It is possible to use a web service without any configuration or settings in a few easy steps. Using the Process Commander Web Services Generator, we pointed to the Web Service URL. Process Commander read and parsed the WSDL, and generated the appropriate class structures, methods, and properties needed to expose the Web Service. Developers can use SOAP to expose the Methods by building WSDL. An easy-to-use wizard performs the WSDL generation Process Commander also allows the developer to use other interfaces, such as EJB, SOAP and IBM’s MQSeries with minimal development effort
Personalization through Rules Resolution
o Interfaces to Crystal Reports, MS Word and Excel
o Customization of development environment
Deployment Features:
o Push or pull changes to production with advanced deployment support through rule set
management and versioning
o Distribution support for applications developed with Process Commander
Application Changes and Updates:
o Changes to business logic via changes to business rules in real time
o Changes to business process flows via changes to Visio flow diagrams in real time
o Built-in Version Management
o Robust enterprise versioning enabling scaling to 100,000 rules and processes
o No database schema changes required to add properties or objects
Web Services:
o Wizard-based Web Services set up; three times faster than Java IDE
o Support for SOAP, IBM’s MQ Series, COM and XML
• Security:
o Role-based security
Productivity will increase even more dramatically when Process Commander is used in an environment that requires frequent real-time changes to rules and process flows. This is often the case in complex BPM scenarios
Saying all this, no doubt getting the chance to work on PEGA products is a great opportunity. Here we are expecting most of the projects to move from Java & J2EE space to PEGA space. And this is the sector any Service oriented company can look into.
But as developer/programmer, i am a little bit biased towards cording work, which you find very minimal in PRPC based development work. I am personally feeling that without coding, we can't improve our analysis and problem solving skills. Ofcourse, its my personal opinion only.
Luckily, we have a devision here which will take part in PEGA product development itself which will work in tight integration with PEGA india team.
Lets hope i will get into that team, so that i will take responsibility of doing the magic behind scenes rather than again and again re-using the features developed by someone else. Why should i miss the fun........ :-)
As a developer i don't recommend to work as PEGA PRPC developer but from organizations and clients profits point of view it is highly recommended. If you want money, go and get trained on PRPC, there is a highly demanding skill. If you want coding satisfaction look into java/J2EE space.
Right now i don't have any choice... i have to work in accordance of my organizations goals. ;-)
The biggest hurdle infront of me is to master this Technology. I personally feel there are no resources available for it on the web and the PEGA's PDN is not that much sufficient. Until now i am finding it very difficult to learn it. The manuals and Online Help PEGA is providing is giving one procedure to achieve something. But in that procedure if any thing goes wrong we don't know what went wrong and how to fix it. Just because we don't know what is happening behind the scenes. Understanding the internals is not recommended for every PRPC developer and even if you desired for it, there is no way you can do it unless you worked in a PEGA Product development environment. Right now i am collecting bits and peaces to get out of the hurdles i am facing with the help of seniors and in tern i want to share it globally.
So i am decided to publish some of the "technical how-tos" in the way i understand them.
Keep watching this space.....
Saying all this, no doubt getting the chance to work on PEGA products is a great opportunity. Here we are expecting most of the projects to move from Java & J2EE space to PEGA space. And this is the sector any Service oriented company can look into.
But as developer/programmer, i am a little bit biased towards cording work, which you find very minimal in PRPC based development work. I am personally feeling that without coding, we can't improve our analysis and problem solving skills. Ofcourse, its my personal opinion only.
Luckily, we have a devision here which will take part in PEGA product development itself which will work in tight integration with PEGA india team.
Lets hope i will get into that team, so that i will take responsibility of doing the magic behind scenes rather than again and again re-using the features developed by someone else. Why should i miss the fun........ :-)
As a developer i don't recommend to work as PEGA PRPC developer but from organizations and clients profits point of view it is highly recommended. If you want money, go and get trained on PRPC, there is a highly demanding skill. If you want coding satisfaction look into java/J2EE space.
Right now i don't have any choice... i have to work in accordance of my organizations goals. ;-)
The biggest hurdle infront of me is to master this Technology. I personally feel there are no resources available for it on the web and the PEGA's PDN is not that much sufficient. Until now i am finding it very difficult to learn it. The manuals and Online Help PEGA is providing is giving one procedure to achieve something. But in that procedure if any thing goes wrong we don't know what went wrong and how to fix it. Just because we don't know what is happening behind the scenes. Understanding the internals is not recommended for every PRPC developer and even if you desired for it, there is no way you can do it unless you worked in a PEGA Product development environment. Right now i am collecting bits and peaces to get out of the hurdles i am facing with the help of seniors and in tern i want to share it globally.
So i am decided to publish some of the "technical how-tos" in the way i understand them.
Keep watching this space.....
Comments
Appreciate, if share more details - documents, architecture, how it works etc.
Babu