Friday, November 21, 2014

IBPMS: Updated Vendors Positioning

Few days ago I published a post titled: BPM - Agility is a Must. In that post I explained why Agility is important in BPM Programs and Projects. I quoted two analysts firms: Aberdeen Group (ten years ago) and Forrester Research (2013).

I did not quote the largest analysts firm: Gartner. I did not quote Gartner, not because their analysts' opinion is different. The reason was no quickly available source to quote.

Today I read Gartner's Magic Quadrant for Intelligent Business Process Management Suites dated 17 March 2014. This Research Note was written by: Teresa Jones, Roy Schulte and Michelle Cantara. 

Now I have an handy quote supporting my opinion: "IBPMS addresses the increasing need for Business managers to react quickly to event that impact their business and to gain better insights into business operations so that they can take the right corrective actions. Business change is inevitable, and leading organizations will require the ability to dynamically make changes to business processes to maintain competitive advantage."

IBPMS Vendors Positioning
It is interesting to compare the new Magic Quadrant to the 2012 Quadrant, I discussed in a post: BPMS Next Generation: IBPMS.

No vendor was added to the Leaders Quadrant so there are still only three Leaders: Pegasystems, Apian and IBM.

All vendors in the Visionary quadrant remained in the quadrant. However, the Ability to Execute of most vendors improved. No new vendor was added to this Quadrant. 

The Challengers Quadrant remained empty, as it was two years ago.

Two vendors were added to the Niche Quadrant and Cordys was removed.

I already read a Case Study of Newgen Software Technologies, but I new nothing about Kofax.

Newgen Software Technologies is a Document Processes company evolved recently to IBPMS.

Kofax is a Microsoft centric vendor. It acquired Singularity in 2011 (now I know something about Kofax because Singularity is a company I read about). Their Total Agility IBPMS suite based on two other acquisitions, in addition to Singularity: Altosoft a Business Intelligence vendor and Kapow Software. Kapow is an Automatic Information integration company, especially Web Information. Its product capabilities also include Legacy Information Integration. Legacy Integration is Kofax and Singualrity weakness.

The Buttom Line
Do not extrapulate the minimal changes in IBPMS Vendors Positioning. The market is still immature. Expect changes in vendors positioning in Mid Term future.



  

Tuesday, November 18, 2014

BPM: Agility is a Must



Agile Methodologies are used frequently in modern systems development. Readers of this blog, as well as many people who do not read it, know that the rate of Business changes was accelerated and Information Technology systems should be flexible in order to adapt quickly to the Business changes.

Agile Methodologies focus on high priority requirements. If you would use classic Waterfall methodologies, probably the requirements will change before you complete the Analysis.

According to an old Aberdeen Group's survey, published a decade ago, the time for implementing BPM is more important than the implementation's costs. The results of the Aberdeen Group's survey implies that Agility was required in implementing BPM. Those days, it is required more than it was required ten years ago.

Forrester's analysts Clay Richardson and John R. Rymer wrote in 2013: "The Mantra for BPM has always been "start small, think big, move fast!" However, most teams hit a brick wall when it comes to the "moving fast" of the equation"  (The Forrester WaveTM: BPM Suites Q1 2013).
This citation is actually a call for Agile Methodologies implementation in BPM Projects and Programs.

In the following section I will explain why BPM Agility is required now more than it was required 10 years ago. 

BPM's Evolution
In previous posts I described BPM's evolution until 2012.
In the post titled: BPM Market Growing Rapidly but still Maturing and Changing I discussed the relationships between BPM and Case Management and Software as a Service (SaaS). I also discussed the leading BPMS vendors. 

In the post titled: BPMS Next Generation: IBPMS I discussed a new BPM Use Case, Intelligent Business Operations(IBO) and the immaturity of the BPMS market.

Ten years ago most BPM implementations addressed Automatic or SOA Processes. The Processes were composed of Systems and/or Services executed one after another. Process Flow depended upon conditions. 

The next evolutionary step was Human Processes
Human Processes include Automatic sub-processes, however the human steps or human sub-processes are more complex. Addressing them requires more complex development than addressing the Automatic sub-processes.

The development required for addressing the next evolutionary step, Case Management, is a lot more complex and consuming a lot more resources. The next step addresses less structured Human Processes handled by Knowledge workers. The illustration at the beginning of this post depict the structure of a process of that type. 

Intelligent Business Operations(IBO) emerged afterwards. This new Use Case changed vendors position and only three vendors remained in the Leaders part of Gartner Magic Quadrant. Some of the former Leaders such as Software AG acquired smaller vendors of technologies they missed in order to improve their position. 

BPM and SOA alone are not sufficient: Other technologies such as Content Management, Knowledge Management, Complex Event Processing and Business Intelligence supplement them.

BPM for Case Management and IBO could turn into a large development project. Use of Agile Methodologies could help.

The consequences of BPM's Evolution are more Use Cases, higher number of Processes and more complex Processes handled by Human Processes, Intelligent Operation Processes and Case Management. Agility is necessary in order to cope with such complex environment.

Recently I read few articles and Research Notes on BPM trends.
The problem of Moving Target requirements, I mentioned in the context of systems development, was cited in some of the articles, but not in the context of developing systems. It was cited in the context of Processes development.

The next sections will focus on some of the Technological issues complementing Agile BPM Development usage, by shortening BPM development time. 

Low coding or Zero Code Processes
Less code means shorter delivery time. According to Forrester Research's Research Note written by Clay Richardson and John R. Rymer, titled: "New Development Platforms Emerge for Customers Facing Applications" (June, 2014): "Firms often Adopt Fast Delivery Practices with Low-Cost Platforms". 
The need for dynamic processes reflecting rapid changing Business is a must. 

The trend of Low Code Platforms is  especially relevant for Customers Facing Apps.

I recommend reading this excellent Research Note about  a paradigm change in Customer Facing Applications including: the Demand for new App Delivery Thinking, new Culture, Practices and Design approach. 

Unified Development and Execution Environment for all BPM Use Cases
a Unified environment eliminates the need to manage different environments for Automated Processes, Human Processes and Case Management Processes. It also eliminates the need to learn multiple environments, multiple tools and deciding which environment should be used. Unified environment also saves the time and effort of switching environments.

Seem less Integration with completing Technologies
Processes Development requires other technologies completing BPM. More complex Use Cases require more technologies than the simpler Use Cases. The BPM suite should provide easy integration or common operation between tools of those technologies.

If easy integration is not guaranteed, forget Agile Development. You will spend a lot of time and efforts in developing APIs and other integration mechanisms. 

Multi-Channel
a decade ago Multi-Channel  was crucial for successfully implementing CRM (read: The Marriage of Customer-Centric and Multi-Channel).

It was also a good practice to include adequate Multi-Channel Architecture as part of SOA Architecture.

Today Multi-Channel is required for BPM , Case Management and IBO, as well. Human Task performance should be independent of Channel. The implementation should enable usage of any Channel. No coding or minimal coding for addressing multiple Channels and variety of channels is a key for quick Development and rapid Deployment.

The term Multi-Channel denotes something slightly different from the same term ten years ago: It includes Mobile devices and Social Networks Channels.

Vertical Industry Specific Applications and Processes
Russell Keizere, a Senior Director in Pega Systems argues in a presentation: "The Platform should come with pre-built applications for your industry that you can quickly and easily extend and customize" The words quickly and easily were not highlighted by me. They were highlighted by Mr. Keizere. 
The principle of Agile and short time Development is presented again. 

his approach is not a new approach. More than ten years ago I was responsible of BPM Vendor selection in a Telco company. IBM, Tibco and Web Methods presented pre-built Industry specific processes.

The principle is not new but the solutions are more mature than they were ten years ago.

BPM in the Cloud  
Ovum believed on 2012 that Cloud Computing will not be BPM's dominant delivery model.
According to Ovum, BPM implementations invoke Systems and/or Services and the amount of code and data in them is minimal. 

Forrester's survey results on 2012 are different: The title of a the results graph is "Many BPM Programs Either Plan to Use Software as a Service or Already Do So". 
The results:
15% - "Already replaced most/all with SaaS" or "Plan to do so in two years".
33% - "Plan to Complement with some SaaS within two years or "Using some SaaS to complement" 
46% - No plans to use SaaS

The difference between Ovum's opinion and Forrester's survey results is probably because of the amount of code and data in BPM systems is no longer minimal. The more sophisticated Use Cases may require more coding and a lot of data. 

It should be noted that Servers and Software Infrastructure Installation and Customization takes a lot more time and human resources in the Data Center than in SaaS based Public Cloud implementations.

Summary
As BPM matures and addresses more complex Use Cases, usage of Agile Methodologies is a must. The long implementation time is a major barrier. 
I discussed some of the issues and some of the approaches and technologies enabling shorter development time. 
Short delivery time was important in BPM projects ten years ago. It is a must today and probably will not be less important in 2024.   




Public Cloud Core Banking: Hype or Reality? - Revisited

  More than 4 years ago I was asked if Public Cloud Core Banking is a Hype or a Short Term Reality? If you had read the post, you would prob...