Archive for the ‘AJAX’ Tag
After reading numerous articles, blog posts and definitions of Web 2.0, and separate hype from reality, I have concluded that there are three essential ingredients of a Web 2.0 application:
i. A rich user experience in an Internet browser.
ii. “Mashups”, or the ability to pull together information from various sources that is relevant to collaboration.
iii. Strong emphasis on collaboration, or sharing information and ideas.
When I look at Web 2.0 and BPM, and the underlying objectives and challenges of each, I find a perfect match that can greatly boost the acceptance and usefulness of BPM.
First, let’s look at rich user experience for Internet applications, also called Rich Internet Applications (RIAs). RIAs are developed using new technologies such as Asynchronous Java Script (AJAX), Adobe Flex or Microsoft SilverLight. Every BPM product in the market today does not use these technologies. Only a few do. However, there is no doubt in my mind that BPM vendors, like other software vendors, will all rollout new versions of their products that use these technologies. I can safely predict that in the next 2 years or so, most vendors will have their user interfaces as RIAs, some moving faster than others. Indeed, the sheer benefits of an RIA from a usability and customer satisfaction perspective will make it a competitive advantage, compelling BPM vendors to accelerate their development efforts so as not to be left behind. As I pointed out in another blog “What it will take to deliver BPM SaaS?” (https://leadershipbpm.wordpress.com/2008/10/06/bpm_saas/), if BPM SaaS is to be widely adopted some key components of BPM have to be exposed in browsers so that users with rights can not only participate in processes but also configure and adapt them to their changing needs. Converting these components of BPM into an RIA will go a long way towards BPM SaaS.
Second, with respect to mashups, I would strongly argue that BPM is one of the first application categories to offer mashups even before Web 2.0 was popularized. Think of the modern BPM “client”, or the application that users use to participate in a business process and do their work. The BPM client is a classical example of a mashup. It pulls information from a number of sources such as databases, Web Services, EDMS (for document attachments), the BPM server (for status information), and often from other enterprise applications such as ERP and CRM. This information is collected in real-time and then presented to the user in a manner that is conducive to quick decision making and getting the job done. Of course, the ease and flexibility with which BPM applications allow these mashups to be created depends on the capabilities of the underlying BPM software that is used. However, the point is that the BPM client is a mashup used by all the participants in a process. Likewise, other BPM suite components such as BAM/reporting and administration have attributes of a mashup.
Finally, with respect to collaboration, I think it is clear to everyone that BPM for system-centric processes, also called straight-through processes, is optimized for speed and has little human involvement. By their very nature, these system-centric solutions are not collaborative and they do not need to be. They are automated production lines which are fully robotized. Then there is another class of BPM solutions, called “production workflow” in the 1990’s, that do involve humans but are for high volume, fairly rigid processes for claims processing and call centers, etc. Again there is not much need for collaboration in such applications, and the focus is on structure, compliance and speed. So neither of these two types of BPM solutions need Web 2.0 characteristics.
On the other hand, there are a large number of business processes that involve humans, and especially knowledge workers. In the early days of BPM/workflow, these processes were classified as “administrative/ad hoc”. The word “ad hoc” tried to capture the collaborative nature of these processes, even though technology at that time did not provide much opportunity for collaboration and ad hoc flow of processes. These human centric processes is where BPM truly has the potential for becoming a stellar Web 2.0 application for the simple reason that humans work in extremely complex ways, and the way they interact can often not be anticipated and programmed in advance. Here are some uniquely human things that people do when they work together:
i. Confer: Knowledge workers often want to discuss an issue with others before they make a decision
ii. Inform: Knowledge workers want to let others know why they made a specific decision.
iii. Assign: Knowledge worker often wants to assign tasks to others in the case of work overload or absence.
iv. Reject: Knowledge workers often reject a task they are assigned because it has incorrect of incomplete information.
v. Validate: Knowledge workers want to review other information in order to validate and support the decision they are making.
vi. Share and Assimilate: Knowledge workers want to share the decisions they are making or the information they have gathered, not only with the participants of the process but with a larger community or co-workers. This sharing and assimilation fosters organizational learning.
All these actions, and you can probably think of others, are ad hoc and collaborative in nature. Many BPM clients offer some of these capabilities. However if BPM is to truly address the needs of knowledge workers, the BPM client will have to offer all these capabilities in the future. The rapidly growing popularity of Web 2.0 applications such as blogs, wikis, instant messaging, forums, Internet document sharing etc., means that BPM solutions can leverage these technologies to provide similar capabilities to BPM users.
So my bottom line is that Web 2.0 is a perfect match for human-centric BPM. By the very nature of their core purpose of enabling people to work together, human-centric BPM solutions must become even better in collaboration, mashups and RIA technologies. Vendors who are nimble and deliver BPM as a Web 2.0 solution will have a significant competitive advantage, and will have the best opportunity for transforming their end customers and creating sustainable value.
NOTE: This post is an adaptation of my October 2008 column in BP Trends (www.bptrends.com )
An increasing number of BPM vendors are starting to talk about offering BPM software-as-a-service (BPM SaaS). These include Appian, Lombardi, Savvion and Ultimus. Given the buzz around SaaS, this is understandable as these vendors are trying to position themselves for a growing opportunity despite the fact that the SaaS model has serious challenges from a business perspective. So the question for users of BPM is what does it really means to have BPM SaaS?
Let us first make clear what BPM SaaS is not. First, the ability to run a hosted version of one aspect of BPM is not BPM SaaS. BPM is a combination of applications used by different stakeholders. Offering only one of these in a hosted, subscription-based model is not SaaS. For example, offering process modeling tools in a subscription-based hosted model is “process modeling software-as-a-service”; it is not “BPM software-as-a-service.” However this would be a very good first step towards BPM SaaS which can offer customers as well as vendors not only the benefits of SaaS but also the experience necessary to move towards full-fledged BPM SaaS. Second, creating customer-specific automated processes and then enabling the end-users of the customer to participate in the process using a browser/Internet is also not BPM SaaS. There is nothing new about this and customers and vendors have been doing this ever since the early days of the Internet.
In my judgment BPM SaaS has to have the following characteristics as a minimum. First, it must have the ability to model and modify executable processes in a hosted application. The ability to design executable processes, in contrast to simple flow diagram, is pretty challenging. Many vendors will start by offering pre-designed process templates and then allowing users to modify them in a hosted model. This is a good way to start and over time an increasing number of parameters (rules, flows, user interfaces and integrations) can be exposed to modification by users. Second, BPM SaaS must have the ability to allow customers to integrate with their inside-the-firewall data and other applications. This is crucial because BPM deals with company’s data and interacts with other applications. Without effective integration only the very simplistic BPM processes are candidates for SaaS, and CxOs are reluctant to invest money or mindshare on simplistic processes. Integration is the Achille’s heel of BPM SaaS and solutions for this will evolve only gradually. Perhaps the best approach for BPM vendors is the emerging class of “application appliances” that leverage virtualization technology to deliver inside-the-firewall solutions on a SaaS basis. This has the potential of solving the integration problem. I will discuss it in another blog as this is a topic on its own. Third, and easiest, is the ability for end-users to participate in business processes using a browser. This is easily accomplished by most vendors and the growing using of AJAX and Rich Internet Application (RIA) technologies will make it even easier and richer for end-users. Fourth, BPM SaaS must provide a means for customers to monitor and administer their processes over the Internet. Again, with the emergence of AJAX and RIAs, this is not a challenging obstacle. And fifth, BPM SaaS must provide some web-based reporting, BI and BAM capabilities.
With these five capabilities, BPM SaaS can empower customers to design, integrate, deploy, use, administer, monitor and measure their business processes. It provides the full value-proposition of BPM in a SaaS model. Vendors will move towards this in small steps and the more agile ones, who adopt SaaS and new technologies such as RIAs and application appliances, will have the competitive and time-to-market advantage. The key challenges are modeling/design of executable processes and integration. I will use other blog posts to elaborate on likely approaches to tackle these challenges.