E

The new version of PRPC v5.4 is just round the corner, and is loaded with exciting new features. Some of the new features are very impressive and immediately usable

• User Interface related
  • List to List Control
  • Copy items from one list to another (Whizza veterans, I know that this has been implemented in , however this is an OOB functionality provided now)
  • Auto complete is now an OOB functionality
  • SMART Info improvements now it can be placed on labels & fields without using HTML Paragraph
  • Error message customizations – you can now choose to
    • Display errors at the top and bottom of the harness
    • Display it in a floating DIV, or
    • Display it in a configurable section
  • Multi level Tabs is now a reality
  • Improvements to the form designer
  • Create mock ups without defining properties
  • Execute flows in DRAFT mode.
  • Branding / Skinning of applications – there a new wizard that enables one to customize fonts, colors and images of the application
• “This operator is using Application-based configuration; you may not specify secondary Access Groups.” This error is a thing of the past – you can now Assign one or more “Application Based” access groups to an Operator ID
• Cross browser code – finally one can use the generated application on Firefox. Preflight can check for cross browser compatibility issues.
• Reports
  • Joint List view and Summary view
  • you can use the wizard to modify existing reports
  • you can now use the wizard to create reports on any class within a class group
• Correspondence
  • send meeting requests!!
  • Inbound email now handles Auto Reply and delivery Status notifications
  • Handle inbound email attachments
• SOAP
  • Axis 2.0 in addition to Axis 1.2.1 support
  • Attachments support
  • Handle SOAP errors
• Circumstance rule improvements
• Class Structure! – finally a view to “see” the class structure right from the @baseclass
• Audit trail
  • Control which events trigger audit trail
• Obj-Browse, Obj-List-View,Obj-Filter, Text-Normalize - new Activities for common tasks
• Selective import of rules from zipped exports
• Rename classes and rulesets!
• Testing framework updates

SAP announced on Wednesday that it is acquiring privately-held Hyderabad, India based Yasu Technologies, which creates business rules management software. Yasu's flagship product is the QuickRules BRMS, launched in early 2000. The deal is designed to boost SAP's business process management (BPM) offerings and will be tucked into SAP NetWeaver, which channels the ebb and flow of data to software applications via SAP's back-end middleware. The India-based company was founded in 1999 and has just over a 100 employees. Started by 6 entrepreneurs, it boasts of some of the best talent in India’s IT industry, with over 70% of the product development team comprised of IIT alumni. The Yasu announcement comes just a little over a week after SAP announced that it will acquire Business Objects in a deal valued at more than $6.8 billion, its largest acquisition ever.

The question on Slashdot was actually "Do You Like Your Workflow or BPM Software?". The questioner was interested in "firsthand experiences with these kinds of products and in unbiased reviews" and requested information on following products:

• JBoss jBPM & Rules
• ILOG JViews & JRules
• webMethods & Blaze Advisor
• Oracle BPEL Process Manager
• COSA
• FLOWer
• Microsoft BizTalk
• Lotus Workflow
• Global360 BPM
• Bizflow
• WebSphere MQ Workflow
• Tibco BPM
• Fujitsu Interstage
• FileNet BPM
• Savvion
• Pegasystems
• BEA AquaLogic with Fuego

"The BPM industry is awash in hype" declares Kevin Spurway, warning that vendor hype has created market confusion about the proper role of IT with respect to BPM. I could not help but smile sadly and nod my head at this... IT unfortunately perceive BPM as a threat rather than the powerful tool that it is can be. What's beyond the hype, and how is the industry addressing this dangerous situation, and help clear the smoke? Kevin identifies 3 intersting developments - "Standards", "Free Modelers" & "Communities and Social Network-based Approaches". BPMN clearly stands out from amongst the various standards that mushroomed; however Kevin warns that "BPMN notation has to date gained little traction outside the relatively small BPM community" and observes that "Business users are highly unlikely to spontaneously adopt BPMN notation the way they spontaneously adopted the spreadsheet almost thirty years ago". Free modelers are a relatively new concept. this allows the organization to take Process Modeling for a test drive.. without shelling out the $$$$s. Lombardi and Savvion seem to have it.. whereas the others are playing a wait and watch. The developer in me is definitely excited at the prospect of a test spin... however the process modeler in me argues that I already have M$ Visio installed with BPMN stencils- do I need more? Communities and Social Network-based Approaches - again a new concept; Pega launched Pega Exchange recently to enable "customers and partners to create and exchange PegaRULES Process Commander (PRPC) content, from application frameworks, to plug-ins for common enterprise technologies, to utilities that make development easier", in order to "Leverage the community" and not "reinvent the wheel".ProcessXChange - however, according to Kevin was a "stillborn". Savvion has their What I would like to see is an open exchange market place where I could pick up a process modeled in one platform and use it with another seamlessly. Sort of like a sourceforge or a codehaus or component source for process models. For this to happen though, the standards such as XPDL or BPDM (the serialization standards in which you save the process models that you model in BPMN) must be widely adopted strictly adhered to (thanks for the correction Sandy).

Apache ODE, as in "Apache Orchestration Director Engine" (wow thats a mouthful), is a Top Level Project under the aegis of the Apache Software Foundation. The stated objective of the ODE is "to create a reliable, compact, and embeddable component capable of managing the execution of long-running business processes defined using the BPEL process description language", and the focus has been on "developing small modules with minimal dependencies that could be assembled (and easily reassembled) to construct a full featured BPMS". LEGO blocks of BPMS? The key components of the ODE architecture include the ODE BPEL Compiler, ODE BPEL Engine Runtime, ODE Data Access Objects (DAOs), ODE Integration Layers (ILs), and user tooling Based on the contribution from Intalio to the ASF in July 2006, (originally obtained by Intalio's acquisition of FiveSight Technologies) ODE left the incubator and took Top Level Project status on September 12 '07. Already 4 projects including the Intalio|Server are using the ODE :

• Apache ServiceMix: Agile open-source ESB (JBI Container)
• Coghead: online platform to create your web-based applications.
• Intalio BPMS: a full open source BPMS solution including a BPMN designer, runtime components and tooling.
• SUPER: Integrated EU research project, aiming to raise BPM to the business level, where it belongs, from the IT level where it mostly resides now.

"Intalio|Server is the fastest and most scalable process engine currently available on the market, capable of supporting hundreds of thousands of different process models deployed on the same server, and hundreds of millions of process instances running concurrently on a single CPU"

One of BPM's early pioneers, Dr. Setrag Khoshafian, Vice President of BPM Technology at Pegasystems (previously Senior Vice President of Technology with Savvion), surely knows a thing or two about BPMS. In this short and interesting white paper he diffuses what he identifies are Six Myths of Rules and Business Process Management.

The Six myths dispelled with insightful reality checks include:

1. We are focusing on BPM (automating processes) not rules [sigh… I hear you doc!]
2. We can handle the rules in Java or C# [my personal favorite]
3. "Best of Breed" is best of choice [but is’nt loose coupling a good thing?]
4. Let the BPMS handle 'simple' rules and the BRE handle 'complex' rules [grin grin]
5. Rules should be modeled separately from BPM modeling [yeah right!]
6. Rule-based BPM is a process engine written in a rule language that 'reduces' everything including processes to a rule [frankly, I didn’t get that myself at first]

Get the white paper (available as a PDF download) from pega.com

FACT #1: The Standish Group’s 1994 Chaos Report found that the top three project impairment factors across 352 companies and 8,000 projects were

1. Lack of user input (12.8% of respondents),
2. Incomplete requirements and specifications (12.3%), and
3. Changing requirements and specifications (11.8%)

• Development Process (the way we do it)
  • Waterfall
  • Iterative.
  • eXtreme Programming
  • RUP
• Tools (the hammer and tongs of it)
  • Word, Visio, Excel, Power Point (all are documents)
  • UML – Visual Paradigm, Rational
• Experience (hey cant dismiss that)
  • Business experience (Knowing the business is critical)
  • IT experience (What do we have, what do we need to build, the know how and prior experience with similar requirements)

• Recognize the responsibilities of each group
  • First, understand that requirements definition is a shared responsibility. Both the business and IT have equal stake in this process.
  • Business team
    • Describe business requirements in a simple language, preferably with ‘real world’ examples – and leave design and implementation to the IT.
    • Prioritize. What do you really, really, really need? What do you really, really need? What do you really need? What can wait until the next release? Do you need to system to perform that function for you? Consider the bang for the buck – IT cannot tell you what is critical to your business.
    • Signoff on all the documents, only after satisfying yourself that we have covered all that you need, accurately and appropriately. – RTFM
    • Inform IT in advance about changes to business needs / scenario – do not wait until ship date to start hmm and hawing
  • IT team
    • Spend time to understand the business, the business goals and the business context – it’s not all about code.
    • Identify functional and nonfunctional requirements – do not mix ‘em up.
    • Inform the business and all stakeholders regarding development progress and problems in a timely fashion – if you are going to miss a ship date, then the business needs to know, and who knows they might re-prioritize, and you could get to push that nasty little corner-case functionality to the next release. Hey not all change is bad ;-)
    • Get a good grip and over view of the entire system, so that you can effectively predict the downstream impact of changing requirements plus. You’ll know what can and can’t be done, and more importantly, what shouldn’t be done.
• Recognize the mode of expression
  • Word documents don’t always tell the story effectively
  • Not all requirements are describable in any one tool – mix ‘em up.
  • Some requirements may be lying in undocumented live applications – legacy code is not always bad.
  • Model Processes– work shops, walk-through’s, scripted role plays, Visio, flowcharts, UMLs
  • Mock ups – WYSIWYG, but don’t get carried away
• Recognize the role of the business analyst
  • At the crux of the business user and the IT staff lies this hybrid artificially created creature.
  • Many business analysts sadly and erroneously confuse themselves as to be the business users – they need to align themselves as the bridge, the go-between, the translator.
  • Other business analysts have their thinking clouded with prior application design knowledge, and try to ‘out think’ IT.
  • IT personnel playing the business analyst begin to dictate requirements based on personal design principles or beliefs.
• Recognize the appropriate software tool
  • There are several specialized tools out there in the market today that address specific needs
  • Requirements definition
    • Axure RP, Borland DefiniteIT, Compuware Optimal Trace, iRise, Ravenflow, Serena Composer, Sofea Profesy apart from modeling tools (such as Microsoft Visio) Microsoft Office, Graphics packages (e.g., Adobe Illustrator) HTML etc.
  • Requirements management
    • Borland CaliberRM, Compuware Optimal Trace, IBM Rational RequisitePro, Serena Dimensions RM, Telelogic DOORS, Test management tools, Change management tools and even and homegrown applications
  • Research these tools and ascertain the best-fit in terms of
    • Usability – are your business users, business analysts and developers all comfortable with the tool
    • Life-cycle worthiness – can you use the tool from start (project conceptualization and initiation) to finish (several iterative changes later unto the final release and maintenance phases) seamlessly
    • MS Project is not a tool for requirements management.

In a seemingly innocuous note softly tucked away in a comparative discussion on Human-Centric Business Process Management Suites, analyst Connie Moore makes a this poignant and quietly thought provoking observation: most buyers consider Pegasystems a high-end business rules vendor with BPMS aspirations.8 In reality, Pegasystems - a successful company with 2004 revenues reaching $96.5 million — has completely morphed into a BPMS vendor that uses its business rules/process engine to tackle and simplify complex processes. With SmartBPM Suite, the business rules engine (BRE) does more than codify and execute rules, which is how most other BPMS vendors use external BREs. SmartBPM Suite does that, but also uses business rules to empower rapid, iterative process design; to execute, monitor, and optimize dynamic processes; and automate processes in which changing conditions can drive each work item down a completely different path. However, business rules can make the product overly complex. People sometimes conclude it’s nothing but a BRE because rules are used for everything - not just for business logic, but for processes, access control, data modeling, and system integration] - Connie Moore February 24, 2006 The Forrester Wave™: Human-Centric Business Process Management Suites, Q1 2006 (all emphasis mine) On one hand Pegasystems does what is its purported to be (a BRE) much better than the other, and then delivers more than what the users think it can... however on the other hand, by handling all the tasks (access control, data modeling, system integration and the rest apart from business rules themselves) as rules.. causes users to dismiss it as 1. Either too complex or 2. Why do we need pega to do that? a classic case of being too good for its own good? or a case of a misunderstood genius?

Analyst Connie Moore devours 12 BPMS vendors across 215 criteria to understand the renewed trend towards Human-Centric business processes. She segregates Business processes today into 4 major groupings:

• Integration intensive
  • Order fulfillment, HIPAA transactions, Supply chain mgmt
• People intensive
  • Employee on-boarding, Claims processing, Handling exceptions
• Decision intensive
  • Mortgage loan origination, Underwriting, Retail inventory mgmt
• Document intensive
  • Accounts payable, Contract mgmt, Proposal mgmt, SOX and other compliance processes

• Human-centric processes
  • those that require people to get work done by relying on and interacting extensively with business applications, databases, collaboration tools, and documents
  • ex. claims processing, loan approvals, accounts payable, and customer service
• System-intensive processes.
  • manage interactions between packaged applications, custom applications, external applications
  • typically involve millions of transactions per day that are handled on a straight-through basis with no to minimal human involvement and few exceptions
  • ex. trade reconciliations, supply chain management, and line provisioning

• Make the individual or small team the design point; focus on people in the process, rather than removing them from the process.
• Identify people/information-intensive processes
• Focus on the processes that are broken
• Think about what percentage of the IT budget is dedicated to empowering people vs. automating rote processes