I am back from a hectic round of travel: conferences, BPM Master Classes, client meetings, and vacation. I attended both the SharedInsights’ BPM conference in Ft. Lauderdale, FL, and the ISSSP conference in Scottsdale, AZ (yes, we evangelists live a tough life!)

At the SharedInsights’ conference, Roger Burlton, the conference chair, opened the proceedings with his keynote, “Business Process and Beyond.” One of his standard slides is his ROI graph. When I saw it a few years ago, I grew enamored with it. I think it is a really neat way to communicate the key drivers of ROI. The traditional MBA approach is to focus on the Y-axis, the money: reducing costs, improving productivity, increasing market channels, product innovation, and so on. For many companies, this is approaching the point of diminishing returns. Roger highlights the X-axis, the time. The competition is now in time-to-market, time-to-profit, and time-in-profit. This is nothing new, of course, expect for the increased focus that BPM brings to the X-axis. BPM’s role in improving the ROI from time, the “Return on Time (ROT)” if you will, is leading to ‘aha’ moments for people when presented this way.

At our BPM Master Classes, I introduce two other levers of profitability: the probability of delivery, and the probability of profit. The first highlights the very high failure rate of projects (60-70%), and the second highlights the challenge with delivering what the customer really wants (and is willing to pay for).

Just when I thought I had finally absorbed Roger’s ROI model, he comes up with another. This one is NICE (of course, it is nice, but that’s the acronym). Picture a 2 X 2 matrix. The X-axis represents ‘Understanding’ of the problem domain (values are: ‘little,’ and ‘lots’). The Y-axis represents ‘Detail’ of information about the problem domain (values are: ‘little,’ and ‘lots’).

When we have little detail and little understanding of the problem domain, our analysis of the problem is going to be ‘Naïve.’ The usual reaction to this is to acquire lots of data, i.e., a data warehouse or data mart project. However, lots of data with little understanding makes the whole problem domain incomprehensible (the 'I' of the model). This is congruent with my own experience, as I covered in my article ‘Re-Energizing BI with BPM’ in Data Management Review, April 2007.

It is possible to gain a understanding from an ocean of data, thus moving into the third cell of Roger’s NICE model. In this cell, the world is a complex (‘C’) entity, demanding tremendous amount of work trying to keep up with change. In my opinion, this is a terrible spot to be in, with data and information overload. More BI (as in the traditional approach) is guaranteed to take you here. The issue isn’t simply more understanding, but more understanding at a reasonable price.

The ROI for understanding comes in cell 4, ‘Elegant.’ Here, only the right information is delivered in a way that is intuitive, actionable, and relevant for solving critical business problems. This is the cell that is the result of applying Occam’s Razor diligently to a Complex model of the problem domain. Since it is impractical to insist that a company always reside in the ‘Elegant’ cell, ideally it should be able to quickly move through the first three steps (Naïve, Incomprehensible, and Complex) to come and rest in an elegant state. Those three phases should be no more than short-term perturbations in the system, while ‘Elegant’ should be the homeostatic condition that a company must aspire to.

The NICE model is the high bar that BPM must vault over to be truly useful.

Posted by kirankg in BPM | Permalink | Comments (0) | TrackBacks (0)

...especially given that I live in Milwaukee?

I just got back from a hectic tour in France and Germany. We held a BPM MasterClass in Frankfurt and Paris. This is the second time I have been in both cities; the first time I stayed at Sofitel within a stone’s throw from Versailles, and did not get a chance to visit it! This time, I did not get a chance to look around Frankfurt, but Paris offered a respite. We did a quick tour of Notre Dame (awesome!), swung by the Eiffel Tower (both during day and night), and plenty of walking through the streets. webMethods has an office next to the Arc de Triomphe. Paris in April – one cannot complain! Frankfurt ist auch eine schöne Stadt (Frankfurt is also a lovely city). 90 mph in a Mercedes Benz cab on the autobahn in Frankfurt is an experience!

There were a couple of interesting differences between audiences in Europe versus the US. For one, over 90% of those who registered showed up for the class; we had to scramble around to find extra chairs! Second, they all spoke at least two languages, more often three and even four. We English speakers were cautioned to stay away from idiomatic expressions and jokes based on the American context; apart from that, their fluency in English is astonishing. I wrongly assumed that the language barrier would prevent participation, but there was plenty of dialog; just as much as in a US class (and perhaps a tad more than the interaction we got at a couple of US locations).

The European attendees seemed less exposed to Six Sigma and Lean compared to their US counterparts; however, they showed greater appreciation for the concept of discipline. One favorite question I pose attendees is “Does their company have a Project Management Office, and if so, what is the attitude of the rest of the company towards the PMO?” I get the classic roll of the eyes: PMO is viewed as unnecessary bureaucracy (except by the PMO folks, of course). In an environment that demands agility and rapid execution, any hint of oversight, process, or tollgates is viewed negatively.

Not so in Europe. They seemed to appreciate the need for discipline. They do not make the mistake of confusing discipline for bureaucracy. Discipline means being responsible, having a plan, and sticking to it. Good financial traders know this. It turns out that the key to superior financial performance is to pick a decent trading strategy and stick to it without second-guessing it. Research shows that changing horses midstream is a sure way to get wet and miserable.

The best companies speak of “responsible growth,” meaning, how to grow shareholder value without compromising on ethics or taking on irresponsible risk. For public companies, governance has additional regulatory implications. But the concern remains, how do we take the concept of discipline and make it an enabler of agility and execution? How do we take out bureaucracy? One, by making discipline an integral part of what we do, so we make the time to do it. For example, no one complains about having to brush teeth every day. Two, by making space for it. Traditional project methodologies waste a lot of time discovering the current state of the business and by documenting requirements in different formats to suit different audiences.

When process governance is an integral part of BPM, it enforces this discipline. Governance becomes a seamless part of how projects are done and business operations are conducted. By eliminating the need for endless documentation and translation between various models of requirements, BPM also makes space for responsible behaviors in project execution and business operations.

Does lack of a formal Six Sigma or Lean methodology seriously hamper the quest for continuous process improvement? Hardly. While the formal methodologies are extremely useful, we are now seeing a move away from overly relying on the heavy frameworks towards a lighter approach. The caveat here is to adhere to the spirit of Six Sigma and Lean, and not to slide into bad techniques. Richard Douglass, webMethods’ VP of Global Industry Solutions, and an expert on Supply Chain, Manufacturing, and Six Sigma, spoke of continuous process improvement by using the principles of the formal methodologies even when not using the whole toolkit. The specific ‘get started’ strategy we advocate is to measure the state of your business first, and use real data and metrics to drive the discussion around process improvement.

These are some of the key messages that we will be delivering in Toronto next Tuesday. Joining us will be Yvon Berube, President of Logimethods, Inc., our systems integration partner in Canada. Neale Partington of SaskTel, our joint customer, will be sharing their experience implementing webMethods’ BPM. If you are in the general area of Toronto, we’d love to see you at this event.

Posted by kirankg in BPM | Permalink | Comments (0) | TrackBacks (0)

At Gartner’s BPM Summit last month in San Diego, everything went fine until the last Gartner analyst left a lasting impression at the last session of the last day. Simon Hayward, VP and Gartner Fellow, who helped kick off the BPM Summit, has the dubious honor of also sounding its death knell. His bombshell? The prediction that, to paraphrase, “By the year 2012, BPM will be subsumed into major applications.” I forget the exact probability he assigned to this scenario, but it was precisely between 0.7 and 0.8 (both inclusive).

Predictably (i.e., with probably 1.0), there was violent disagreement from the audience. Their cries of “No!” reverberated in the auditorium. There was applause for attendees who spoke in protest. I am sure there was concern among the participants about the discipline of BPM itself vanishing (and with it, boondoggles to sunny climes), and among the vendors on the implied demise of their own companies. If Simon’s intention was to end the conference on a vigorous and memorable note of controversy, he definitely succeeded.

Now, I can’t predict the future as accurately as Gartner. I don’t know if BPM functionality will indeed be subsumed under applications from the largest app vendors. What I do know is that if it does happen, it will happen only if one of the following conditions is met:

one, a major app vendor will take over all the applications and supply one huge ERP that covers all businesses end-to-end for all the companies (regardless of size) on the entire planet and the space station;

two, app vendors will package BPM-like functionality without truly understanding what it means, thereby fooling themselves and all of their customers all the time.

Your guess is as good as mine (or Gartner’s) on the likelihood of these scenarios happening.

Conceptually, though, suggesting that BPM functionality will reside in apps is like saying operating system algorithms will be subsumed by applications (i.e., that OS functionality like system resource management, job scheduling, load management, memory management, etc. will be built into each and every application). Talk to your app vendor and ask them if they’d be willing to develop OS functionality (as in Unix and Windows) directly into their apps. Also, ask them if they’d be willing to create their own database engine rather than connect to an existing, independent DB engine. How about their own reporting solution?

BPM is to business processes what the OS is to IT programs: BPM is a process operating system. Just as an OS provides a ‘system process space’ context for pieces of running code, BPM provides a ‘business process space’ context for applications. What are the elements of this business process space context? A comprehensive answer is too long for this post, but it should include process metrics, process design, business semantics, and process governance (the analogy to the OS should be clear: an OS collects and displays system metrics, such as memory utilization, resource handles, CPU utilization etc.; for the design of applications, it provides an API to applications for accessing system level resources; it defines the system semantics through such APIs and through the use of semaphores, threads, handles, sockets, pipes, devices, etc.; it ‘responsibly’ manages the use of system resources to eliminate contention, resolve deadlock, terminate hanging processes, implement prioritized scheduling, etc.) Imagine an app vendor having to build this entire infrastructure (whether OS or BPM) into each application!

BPM provides the abstraction layer that is common to all applications that must function as responsible citizens in the corporate world, just as an OS provides an abstraction layer to all applications that must reside and play nicely together on a computer.

People attend BPM conferences because they see problems that are not (and cannot) be solved by their current stack of applications (CRM, ERP, G/L, etc.) These apps are in a terrible mess in their own right today because they are not designed according to SOA principles (some would question if they were designed in any way at all). App vendors have their work cut out in trying to fix application level problems. Why would anyone egg them on to take on functionality that is an order of magnitude more sophisticated and more abstract?

Let us hope that this is one Gartner prediction that will never come to pass.

Posted by kirankg in BPM | Permalink | Comments (1) | TrackBacks (0)

"Understanding Business Process Management & the 'People' Factor of Process Change"

This is the first of three e-seminars on business process management sponsored by Talisen Technologies. I have been invited to join Howard Webb (Principal, the BPM Group) in this first e-seminar to discuss the “people aspect” of BPM and how change leaders are enabled by BPM adoption. The next two sessions will feature a discussion of process and technology aspects of BPM.

Change management and people issues are a neglected aspect of BPM adoption. In the BPM Master Classes that webMethods conducts, I frequently quiz the audience on their change management practices. Most technologists don't realize the importance of this. They assume that the cool technology of the day will win the hearts and minds of the business folks. In reality, business executives are besieged by change: from customers, competitors, and economic conditions. Many of them are barely coping with it. Asking them to deal with another change—a pretty radical one at that—is rather risky without employing some change management techniques.

While Howard will cover how to get support for BPM and link it with other process improvement efforts, I'll focus on the implications on an organization of implementing BPM.

Register here to attend this webinar on March 16, 2007, at 10:00 am CST.

Posted by kirankg in BPM | Permalink | Comments (0) | TrackBacks (0)

Recently I participated in a podcast with fellow ebizQ bloggers to make some fearless predictions for BPM in 2007. Making predictions, of course, is a dicey affair. There are only two ways to do it. Either you make a firm prediction and hang your hat on it, or you make a fairly general prediction that few can refute and fewer still will bother to do so.

One interesting example that actually achieved both objectives (unintentionally, of course) was this statement of Henry Ellsworth, Commissioner of the U.S. Patent Office, in his 1843 report to Congress: "The advancement of the arts, from year to year, taxes our credulity and seems to presage the arrival of that period when human improvement must end." This is apocryphally misquoted as: "Everything that can be invented has been invented."

Check out our fearless predictions on this podcast. Fellow intrepid gazers at the crystal ball are Keith Harrison-Broninski, James Taylor, Joe McKendrick, Sandy Kemsley, Michael Dortch, and David Kelly (whose article put the said crystal ball temptingly on our bloggers' table). Elizabeth Book, ebizQ's editor-in-chief, moderated the podcast.

Of course, if none of the predictions come true, then we'll borrow a leaf from Yogi Berra and claim that 'the future ain't what it used to be.'

But a large part of where the BPM market goes is really in our collective hands. One of the 'sooths' that I say is that there will be an increasing awareness and adoption of BPM within companies. It is up to us—bloggers and readers— to make sure this comes true, by actively evangelizing the benefits of BPM, educating our colleagues on the concepts of BPM, and boldly going where no ERP ever ventures.

I'll be in Chicago this Thursday, bravely spreading the word along with some of my colleagues through a BPM Master Class. Oh yes, the classes are free. Attendees get a free copy of my book ('The Power of Process'), and get to hear Bruce Williams, co-author of three 'For Dummies' books in Six Sigma and Lean. But most important, attendees get a ton of information and practical tips on BPM, plus a first-hand look at BPM in action through webMethods' Fabric 7.0 platform.

Posted by kirankg in BPM • SOA | Permalink | Comments (0) | TrackBacks (2)

Let me expand on the intersection of ECM and BPM from my earlier post.

Enterprise content is basically of two kinds: (a) content that denotes knowledge of the what and the how of business operations (or processes, if you will); and (b) content that denotes the outcome or product of those operations or processes. The former includes price lists, business rules, decisioning rules, policies, organization structures, roles, compliance rules, product categories, business entities, etc. I call these the ‘knowledge artifacts.’ The latter are the actual transactional documents (such as loan applications, orders, and service requests) and several kinds of non-transactional documents (such as website content, email, and presentations). The set of knowledge artifacts is relatively static in size and functions as a Book of Knowledge for the company. In contrast, transactional documents are generated in huge volumes. They must be stored, indexed, searched, imaged, retained, retrieved, destroyed, and reported; these specialized capabilities and associated technologies are the domain of ECM. However, the Book of Knowledge is better served under BPM, because knowledge artifacts must be dealt with in the context of business processes. To take artifacts of knowledge out of the context of business processes and to manage them outside a BPMS makes no sense.

As far as ECM is concerned, Bruce Silver observes that there is considerable investment in content repositories. True, but there is even more investment in paper than in ECM. That doesn't mean companies should continue to proliferate paper, or that BPM doesn't have anything to say about that. ECM looks at the huge mounds of paper and electronic documents, takes that as an immutable fact, and tries to offer a solution for dealing with it. It addresses the symptoms, not the disease. There is nothing wrong with that, since the symptoms need treatment. But, with all the advances in technology, BPM questions (or at least, I do) why there has to be paper in the first place. I do not claim that this problem can be solved right away, which is why ECM and Document Management will continue to exist. Hopefully, after another twenty years, much of this mountain of data will be past its retention period, and will be mercifully incinerated or consigned to be bit bucket.

In the meantime, companies should employ BPM and Continuous Process Improvement to avoid generating unstructured transactional documents (paper & electronic) in the first place, and to store artifacts of process knowledge within process models. I know this is not possible in some areas because paper documents are legally more acceptable than electronic ones, but at least consider the option. Like the fitness mantra says, stop the insanity.

Posted by kirankg in BPM | Permalink | Comments (0) | TrackBacks (0)

Most companies worry about what competitors are doing, how the economy is doing, what competitors are up to, and where interest rates are headed. (Which reminds me of the wag who said he knew exactly how interests would behave in the future. “Interest rates will rise, or they will fall, unless, of course, they stay flat!”)

But few companies worry about what they know and what they don’t know about their own business operations. They are woefully equipped to innovate, respond to competitive threats, or adapt to changing conditions. Consider that each of these situations begins with a mad scramble to figure out where the business stands. The managers are asking themselves, “What does my business process look like? Who performs in what roles? Where are the operations policies? Who is following them, and who isn’t? How do our business metrics look like?” I have never seen any exception to this, not one situation where the affected manager said, “Here is the latest and greatest repository of our corporate knowledge. It is completely up-to-date. Let us consult it before responding to the change.” It’s not that the managers don’t realize the importance of such self-knowledge, but that it comes with a huge price tag—in time, if not in money; but then, time is money.

Years ago, I helped a soap manufacturer analyze their business to see what their most profitable brands were. It turned out that rather than any specific soap line, a byproduct of the soap manufacturing process called oxalic acid (a key reagent in many industrial chemical reactions), was the most profitable one. So, this soap industrialist could have taken the process part way and stopped when oxalic acid was created, and turned completely profitable. (They didn’t choose that; instead, they found out that their company was sitting on prime real estate that could be more profitable as a shopping mall. Besides, shopping malls smell better than a soap factory, so that’s what they did).

The point of this story is that BPM has interesting byproducts that you wouldn’t think are worth much. You start off a BPM project to reduce cycle time for order processing, only to discover that linking ordering processing and shipping business rules to the process steps turned out to be the best thing since sliced bread. BPM, it turns out, is a perfect vehicle to capture and maintain process knowledge. Which reminds of the recent discussion about BPM, ECM, and security in posts by Ismael Ghalimi and James McGovern.

If BPM takes on management of process knowledge, as I think it should, what’s left for ECM? Will ECM morph into the middleware for management of transactional documents? After all, it seems pretty evident by now that we will never be a paperless society. Besides, a lot of enterprise content will be on PostIt notes (to the utter delight of 3M). So, if we leave transactional documents for ECM and Document Management, then Knowledge Management can be carved out for BPM. The interesting thing is, BPM doesn’t even break into a sweat while dealing with knowledge management. It is an effortless (almost, but not quite) byproduct of process modeling and process management.

Would that knowing oneself (in the spiritual sense) was similarly a byproduct of some fun activity (like watching Monday night football).

Posted by kirankg in BPM | Permalink | Comments (0) | TrackBacks (0)

At the beginning of the thirteenth century, the Tatars of the East were a ferocious people. They were very effective at raiding and plundering. Their most remarkable aspect was their speed of execution. They copied Caesar’s ‘Veni, vidi, vici’ mantra, but conveniently omitted the ‘vidi.’ Not for them the survey of their opponents or any attempt at understanding them. Instead, they came as a flood and departed, seemingly in one breath, leaving behind total destruction. They nipped at the edges of Genghis Khan’s empire so persistently that he was determined to either exterminate them or discipline them. Fortunately for both parties and unfortunately for his enemies, he managed to discipline them by the simple expedient of killing any Tatar who was taller than the axle of one of his desert carts (James Michener, Poland).

Every time I talk to both IT and business users, listening to their description of the mess of applications, I am reminded of the Tatars. Like each set of functional applications may be very effective, much like a small band of Tatars. But best of breed solutions do not make up a coherent enterprise architecture, just as the Tatars never won any major wars or leave any lasting legacy behind them. It took a Genghis Khan to control them, and orchestrate them into his campaigns. Before you start wondering if you should pull the plug on applications that don’t conform to the axle wheel of your architecture stack, consider how to achieve the same positive outcome—discipline—without resorting to catastrophic measures.

Firstly, realize that discipline need not be boring or bureaucratic. Secondly, discipline need not add overhead; in fact, properly cultivated, discipline can increase speed of execution. Thirdly, discipline can become part of corporate culture, a habit, a way of doing business. It means picking an investment strategy and sticking to it, without second-guessing it or letting your emotions upset it. It means growing your company in a responsible way (i.e., paying attention to risk). It means complying with the highest standards of business ethics. It means methodically ticking off the pre-flight checklist before takeoff without relying on memory, even though you have done it a thousand times before.

To institutionalize discipline, a governance process is essential. This is the umbrella process that ensures all other project methodologies, ways of doing business, operational mechanisms, etc. comply with best practices, ethical guidelines, and regulation. In the context of process management and its cousin, SOA, governance implies, among other things, the following:
• Processes & services are documented correctly and completely
• Documentation is maintained and kept current
• Projects reuse processes and services
• Implementations take into account the full end-to-end process, and not just the sub-process that is in scope for the project
• There are policies for submitting processes and services into the repository, and that these policies are followed
• Processes that are executing are monitored against key performance indicators, and that proper alerts and notifications are in place

This is not an exhaustive treatment of governance, of course. But the key is that companies cannot avoid the consequences of non-governance. They will end up paying the piper sometime. But companies do have option of making governance part of their corporate culture. To do so, top executives must be ready to lead the change in mindset. At some point, they must be prepared to pay for solutions that are comprehensive and address the various aspects of governance.

If you spot a copy of the Management Secrets of Genghis Khan floating about your CEO’s office, quietly substitute it with the Power of Process.

Posted by kirankg in BPM • SOA | Permalink | Comments (0) | TrackBacks (0)

I discovered Lawrence Sanders when I read his murder-mystery, First Deadly Sin, as an impressionable teenager. His writing is brilliant, the characterization is remarkable, and the plot is well orchestrated. The book was subsequently made into a unmemorable movie, with a completely mis-cast Frank Sinatra playing the detective Edward X. Delaney. Sanders went on to write more murder mysteries in the Deadly Sin series. He would have gone down in history as an excellent writer if he had stopped with this. But he was just getting started. He went on to write a chilling science fiction novel, The Tomorrow File. Then he started on his famous Commandment series. (Funnily enough, I found several books in this series displayed on the “Religion” table at a book fair; I warn you, don’t present any of Sanders’ books to minors!)

Sanders also wrote a psycho thriller (The Case of Lucy Bending), and in his final years, his McNally series. This is not all. I haven’t covered his Wolf Lannihan stories and a bunch of other writings. What is remarkable is that each of these genres has a different writing style; the mood is different (ranging from mystery-noir to light-hearted, flippant protagonists, to an orthogonally different dystopian sci fi); the vocabulary is different. It’s as if he had a multiple personality disorder, except in his case, it shouldn't be called a disorder.

BPM is a bit like that. It is imbued (as opposed to afflicted) with multiple facets. It’s a technology…no, it’s a form of enterprise architecture…no, it’s a set of practices…no, it’s a management philosophy…wait, it’s all of the above! BPM pervades the entire business. (Proof: The business of companies is business. Companies carry out business through business processes. Business processes are, by definition, the domain of Business Process Management. BPM, therefore, covers everything that a company does. Q.E.D.)

I do not believe that BPM is a piece of technology alone. I do not believe that BPM can be truly effective without technology. Like Sanders, BPM is versatile. Unlike Sander’s books, it is rated ‘G’ so that it is safe for ‘minors’ (i.e., those who are just dipping their feet into BPM and those who are not experts in leading-edge technologies).

I am thrilled to be blogging for ebizQ. Through this medium, I hope to share with the world at large my thoughts about this vast ocean. About the power of BPM.

Posted by kirankg in BPM | Permalink | Comments (1) | TrackBacks (0)

Guest post from Elizabeth Book, ebizQ's editor-in-chief:

This week, we bid farewell to David Ogren, the originator of BPM-Blog, and we welcome Kiran Garimella, who will be "BPM-blogging" in the same location.

David, a BPM thought leader who has hung his hat with several enterprise technology vendors; with Sun, with Fuego, and most recently with BEA after its acquisition of Fuego, has decided to take a break from blogging. We very much look forward to hearing more of him and from him in the future. For posterity, we want to leave David's blogging archives in place.

But starting today, we welcome Kiran Garimella, a VP of webMethods, as a new blogger on ebizQ. Kiran has a flair for the dramatic, having recently published a novel about BPM, called The Power of Process: Unleashing the Source of Competitive Advantage.

You will see what I mean about a flair for the dramatic when you read Kiran's first entry in BPM-Blog.

Happy reading!

Posted by elizabeth in BPM | Permalink | Comments (0) | TrackBacks (0)

I've been remiss in posting for a while; I'm still trying to get caught up from my Asia trip. More late this week but here's a quick post to get started.

Microsoft Visio has two formats it can use to store diagrams. A proprietary format (VSD) and a relatively new XML based format (VisioXML). Because VisioXML format is much more open it is the format required by many tools that can import from Visio. This includes many BPM tools (including BEA AquaLogicBPM) that can import from Visio. It also includes many other diagramming tools such as OmniGraffle Pro, a diagramming tool I use on my Mac.

Unfortunately, because the proprietary VSD format is still the default format in Visio, most people are still not using VisioXML. When I receive a Visio file attachment from a customer, it's almost always in the proprietary format. This usually means I have to track down a PC and a copy of Visio to convert the file.

However, I've found an online service that will convert from VSD to VisioXML. So if you are using AquaLogicBPM Studio and need to import a VSD, you can use this site to convert the VSD to the needed VisioXML format.

Posted by davidogren in BPM | Permalink | Comments (2) | TrackBacks (0)

Several of my colleagues and I have been discussing the IBM acquisition of FileNet this morning. Like Sandy I'm not sure what to think. Considering that IBM is already in the ECM and BPM spaces, what does FileNet give them other than a customer base? This, of course, will start a round of speculation about "which products will be killed?". But I don't think we'll find out the answer to that for a while.

Posted by davidogren in BPM | Permalink | Comments (2) | TrackBacks (0)

This is the third, and final part, of my blog posts regarding what we can learn from spreadsheets and non-traditional application development. The first part discussed how spreadsheets are a positive example of how line of business experts can develop their own applications. The second part discussed some of the challenges the BPM is in replicating the successes of the spreadsheet vendors, most notably the traditional enterprise software business model.

The essential point that I wanted to make with this series of posts is that, while BPM is unique in many ways, it does have some important parallels to other software categories. We, as the BPM community, should be doing a better job of learning from the successes and failures of the past. In this post I'd like to discuss several related technologies and the lessons that I think we, as BPM vendors, can learn from those technologies.

Spreadsheets

I'll start with spreadsheets, since that has been the example we've been discussing the most over the last few posts.

Things that spreadsheets did well that we should emulate:

• As I said in my first article, the model must be the implementation. Imagine if analysts had to send their spreadsheets over to IT where the spreadsheet is imported into a different tool, the cells "implemented", and an EXE generated. No one in their right mind would have used a spreadsheet if they had to go through all of that. I feel the same way about BPM tools that require a conversion step between an "analyst model" in BPMN and a "developer model" in BPEL. It's pure insanity.
• Quick iterations are important for business users. For non-technical users it is important to be able to get immediate feedback on changes. If a business analyst changes a process model they should be able to test the impact immediately. This immediate feedback both helps analysts learn the tool as well as prevents there from being a large integration and testing cycle.

Things that spreadsheets didn't do well, and we should just learn to accept:

• IT isn't going to be able to control everything. Most Excel spreadsheets are ugly hacks. But they work and they are "good enough" for the business users. Yes it would be nice if there was a re-usable library of spreadsheets with a sales forecast spreadsheet. It would be even better if every department used that same spreadsheet. But every department manager has their own way of doing things. (Which is why everyone is doing their sales forecasting in Excel instead of using the sales forecasting feature of the CRM package.) We need to treat processes as valuable assets but we also must accept that departments will make their own choices regarding their processes.

Business Rule Engines

What I consider a sister technology to BPM (and others consider a subset of BPM), Business Rule Engines have been moderately successful. While they haven't taken off outside of their key verticals (financial, manufacturing, heathcare & insurance mostly) they have generally been successful in delivering more control directly into the hands of line business. Like BPM Business Rules implementations also have multiple competing stakeholders and have to balance the needs of the business for flexibility against the scalability and manageability concerns of IT.

Things that Rule Engines do well that we should emulate:

• Rule Engines (in general) treat rules like enterprise assets: including tools for cataloging, managing, and searching existing rules.
• Rule Engines (in general) are good about managing the deployment lifecycle, coordinating the description of rules by the business, any additional development by IT, QA, and deployment.

Challenges that Rule Engines have that we should learn from:

• No matter how pretty an interface you have, line of business experts are not programmers. (More on this later in the week.)
• Standards (like JSR 94) aren't very interesting if the standards don't allow portability. (If you can't move your rules from one vendor to another the only benefit of the standard is to ISVs.) Rule Engine lock-in is very hard to avoid due to a lack of standards about rule portability.
• Standards (like JSR 94) aren't very interesting as a communication protocol if the standard doesn't include enough functionality to be comparable to proprietary alternatives.

Portals

A few years ago portals were the hottest technology on the market. Except that everyone had a different definition of what a portal was. Some vendors supplied complete out of the box systems while others vendors were essentially frameworks and toolkits from which portals could be built. Some vendors focused on security and integration, while others focused on knowledge management and publishing. Portals were really a conglomeration of multiple existing technologies where the integrated whole was greater than the many parts. Any of this sound familiar? It should, because all of these statements could equally apply to the BPM industry.

Things that the Portal vendors did well that we should emulate:

• Portals (in general) did a good job at selling the business value of their technology. Despite the fact that there were often multiple disparate stakeholders involved in portal decisions, portals have become a mainstay of enterprise technology.
• Portals, in general, did a good job at integrating with third party systems. Enterprise Portals, like BPM, typically require integration with third party systems in order to build meaningful systems. The leading portal vendors did a commendable job in making that integration possible.

Challenges that the Portal vendors have had that we should learn from:

• Standards aren't very interesting if the standards don't include enough functionality to be comparable to proprietary alternatives. JSR 168, while promising, has generally been a disappointment for real deployments due to its lack of support for intraportlet communication. And while more functional standards like WSRP are emerging they continue to lag significantly behind the proprietary APIs.
• Widely varying areas of strength. While this is really both a strength and a weakness, I believe that the reason that no dominant portal player has emerged is because there are so many different ideas about what is important in an enterprise portal.

There are lots of other examples out there, I'd be interested to hear some your own comparisons in the comments.

Posted by davidogren in BPM | Permalink | Comments (2) | TrackBacks (0)

So, in my last post, I was expressing optimism about how BPM tools could enable non-technical users to build their own applications. Just as the spreadsheet made departments capable of developing certain types of applications on their own, BPM would enable "the business" to develop their own process based applications. Today I'm going to to mix a little dose of reality and skepticism into the mix.

Let me start by referencing an old article by Tim Bray. Tim says that there are essentially two ways that technologies can get introduced into the market: the front door and the back door. "Front door" technologies are bought high up in the organization to solve a business problem or strategically reduce costs. Examples include ERP systems, CRM systems, and application servers. "Back door" technologies are snuck into the organization by sysadmins and programers to solve day problems or reduce tactical, day to day, costs. Examples include Linux, Perl, and and PCs. (Of course, technologies can cross from one category to the other: application servers used to be "front door" but open source J2EE servers have led to "back door" culture as well. PCs used to be "back door" but have become so commonplace that they are dominated by "front door" purchasing).

Spreadsheets were unquestionably a back door technology. A department manager expensed a copy of VisiCalc, 1-2-3, or Excel and wrote his own sales foreasting spreadsheet. Other managers found out about this spreadsheet and built or copied their own version. Management hates the spreadsheets because there is no way to "roll them up", because manager has their own one-off version, and because the data is vulnerable to loss and theft because it generally lives on the managers' laptops. So management tries to push a CRM based sales forecasting system. Success varies from organization to organization, but generally results in department manager's copying and pasteing from their spreadsheets into the CRM system on a weekly basis. :-)

One of the challenges of the BPM market, and the reason that I believe BPM has taken so long to bloom, is that it doesn't fit very cleanly into either category. On one hand, BPM delivers power directly to the business and is very "tactical" in delivering immediate solutions. On the other hand, BPM is sold in a traditional enterprise software model (high upfront license costs, enterprise salespeople) and requires the cooperation of IT because of the needed integration and maintainance. This requires a traditional "front door" approach full of RFPs and cross-functional teams conducting PoCs.

Hopefully you can see the conflict here. If BPM is going to be sold as enterprise software and integrated into IT systems it needs to have IT's blessing. A blessing which it isn't going to give if BPM will result in a rat's nest of processes that it has no control over. But if the business is going accept BPM (and give up the existing paper, email, or spreadsheet based processes) then BPM has to be a little bit subversive.

Now there are several ways to deal overcome this paradox. Some companies have tried the open source route. I believe this is fundamentally flawed as a strategy. The sysadmins aren't going to be able to sneak an open source BPM solution in the door the way they snuck Linux in the door. BPM requires too much enterprise integration and has too much end user visibility. Not to mention that open source has been traditionally weak at some of the key requirements of BPM such as documentation, end user appeal, and enterprise integration. (Please reserve your hate mail, I know that is a generalization and that there are exceptions. I am a generally a fan of open source.)

Other, generally low end, solutions have tried to appeal only the business, trying to fly under the radar of IT by staying departmentally focused and promising the business that they can operate BPM without IT. Others have attempted to give away their modeling tools, hoping to get the business bought in on the modeling tool before IT gets involved. I have to admit that I think this strategy is interesting. But it doesn't solve the fundamental problem, at least not by itself. To get to deployment, the business is going to need IT. 

Fundamentally, I think that the solution to making BPM successful is better cooperation between line of business and IT. I wish there was there was a technological "magic bullet", but I don't believe there is one. The business is going to have to realize that IT has value to add when it comes to writing business logic, organizing data, and working with enterprise systems. And IT is going to have to empower businesses to control their own departmental processes. Yes, that will mean that mistakes will be made. Departmental processes aren't going to look or act perfectly.

Which leads me to part three, which I'll hopefully post Wednesday night: what lessons we can learn from other technologies (including spreadsheets) regarding empowering business users. Including what to control and what to give up control over.

Posted by davidogren in BPM | Permalink | Comments (0) | TrackBacks (0)

I spent several hours stuck on the tarmac in Toronto today: the storms on the east coast kept us grounded. As such I didn't get a chance to finish the second part. Hopefully I'll post it tomorrow night.

Posted by davidogren in BPM | Permalink | Comments (0) | TrackBacks (0)

Several months ago, I started thinking about the parallels between spreadsheets and the BPM industry. Several of my customers had been asking me about which features of AquaLogic BPM that "non-technical business users" will be able to use and which features will require IT involvement. This is certainly a fair question because one of the core tenets of BPM is to give more independence to the business in defining their process applications. I had been hoping to finish that post this weekend. But, while researching, I found that another blogger had just made a post on the exact same topic. I guess there really are no original ideas. :-) :et me comment on the posts I found first and then follow that up with some of the post I've been working on.

The post I found was from Keith Swenson of Fujitsu responding to Tom Baeyens of jBPM. In short, Tom was arguing that analysis and implementation cannot be unified. That a "non-technical business user" may visually map the process, but that there will always be an implementation of the process activities under that process model. Tom says that "most often, there will have to be some custom code tied to the process either as node behaviour or as actions which are hidden from the graphical diagram." He also asserts that an a process model designed in an executable language (specifically BPEL) is less flexible for analysis purposes, asserting that BPEL has a level of specificity that the business analyst will not care about. I don't want to put words in Tom's mouth, but he was generally being skeptical of the mainstream BPM vendors and their claims of having business users develop their own applications

Keith responds by using the spreadsheet analogy as a counterexample. Specifically that when spreadsheets were invented they allowed business users to develop their own "applications" that previously required the intervention of IT. That even though Excel isn't a typical 3GL development language, it has been a critical tool for business in developing applications. (Keith specifically cites Sarbanes Oxley compliance and report generation as examples of applications which have been largely supplanted by Excel spreadsheets.) Keith says that BPM is similar. For a specific kind of application, specifically process centric applications, the spreadsheet enabled business users to be self-sufficient.

Obviously, since I had already been thinking of the metaphor, I agree with Keith'about the similarities between BPM and spreadsheets. And I generally frown on Tom's idea of creating artificial separations between analysis and implementation in BPM. The process model is the implementation.

I would take this metaphor one step further, however. Think about the way that enterprises use spreadsheets. There are many different ways spreadsheets are used. "Non technical users" have no problems using a spreadsheet. According to Joel Spolsky, a former program manager of Microsoft Excel, most Excel users were just keeping track of lists. One of the nice features of a spreadsheet is that simple things are simple.

But, of course, spreadsheets are actually quite complicated pieces of software. In addition to the simple "take the value from this cell and add it to this cell" basic usage there are all kinds of functions for gathering information from databases and web services, parsing text, validation, complex math, lookup tables, and conditional logic. Not to mention all of the features related to slicing and dicing the spreadsheet data including pivot tables, goal seeking, analysis, and reporting.

My experience is that a lot of departments have a few complicated spreadsheets that they have developed that solve specific problems related to that department: forecasting sales, calculating bonuses, reporting on field offices, etc. Most of the spreadsheets are pretty complicated. They were created by some "power user" that figured out how to use all of those conditional logic functions and hacked together a solution bit by bit over the years. I've also seen many enterprises leverage spreadsheets for core business processes, with spreadsheets developed by professional programmers using a combination of Excel's built in functions and Excel's macro language: Visual Basic for Applications.

So, which functions of Excel can a non-technical business user use? It depends on the user. The majority of users can't really use anything other than basic cell operations. But there are certain business users will learn the skills needed to access more functionality. But even for the "power user" some features (like database integration and Visual Basic) will require IT involvement. It's also notable that even though the average department can create their own spreadsheet, creating something that is easy to use, styled appropriately, and "customer ready" will often require user interface specialists.

It's the same with BPM. Some users are never going to care about anything other than the high level model and the key performance indicators. Others will learn how to create their own forms and business rules. And integration and complex rules will probably require IT. And it's also important to note that some BPM applications will require IT (or user interface specialists) just because of testing and QA. No one wants a compliance spreadsheet that works most of the the time or a order tracking BPM process that works most of the time.

More on this on Wednesday, when I'll discuss how well the BPM industry is addressing the needs of business users and Friday when I'll discuss what lessons (good and bad) we can learn from the spreadsheet industry.

Posted by davidogren in BPM | Permalink | Comments (3) | TrackBacks (0)

I see that Sandy already beat me to posting about the (long overdue) 2006 Magic Quadrant for BPMS. I'm hoping that BEA gets republishing rights to this report so that I can give you a link. But in the meantime, I'll summarize in the same way that Sandy did.

As Sandy points out, we did enter the leader's quadrant with this report. In fact, BEA/Fuego leads the entire quadrant in "ability to execute". The other vendors in the leader's quadrant are Savvion, Pegasystems, and Lombardi.

Gartner basically missed a year in publishing the quadrant. So this report is extremely welcome. The BPM market changes quickly and the two year old data in the old quadrant was dangerously out of date. However, it's important to understand that the BPMS is still a poorly defined market. Each of the four leaders has a very different product with very different strengths and weaknesses. I hope to write more about that later this week, because I recently had a very harsh reminder of how different the focus of various BPM products are.

Magic quadrants are only high level summaries, of course, but we're celebrating at BEA this week. Being named a BPM quadrant leader and ESB Forrester wave leader in the same week is a good way to kick off the summer.

Posted by davidogren in BPM | Permalink | Comments (0) | TrackBacks (0)

Sorry to be missing from the blog scene for so long. I spent a couple of weeks spreading the BPM vision within BEA and then a couple of weeks off. Luckily this means that I've had some time to do "deep thinking" and have some ideas for blog posts. Unluckily this means that I also have an inbox stacked with work to catch up on and therefore little time to get the ideas into words.

So, while I find the time to get the original posts typed up, here is some quick commentary on things I bookmarked while out.

• Joe McKendrick has an post on ZDNet blogs about BPEL4People. Somewhat apropos, since I had a customer ask me if we supported BPEL4People. Which I found very odd, because as Bruce Silver points out, BPEL4People is nowhere near being even a draft yet. It's like being asked if your application supports Java 7.0, when Java 6.0 hasn't even shipped yet. I think all of the hype around BPEL4People just highlights the huge gaps that remain in BPEL. Unfortunately, after glancing at some of the initial concepts of BPEL4People it's clear that even BPEL4People doesn't consider human activities to be first class citizens of a business process. [Link received from my boss, Steve Carlson.]


• Speaking of Joe McKendrick, he also had a post in the whole SOA vs. BPM meme started by Chrisopher Koch. I think Christopher's article is right on. As I've said before, BPM and SOA are really the flip sides of the agility coin. Christopher just highlights that it's usually the line of business driving the BPM top-down approach and IT driving the SOA bottom-up approach. (Not to mention using the opportunity to make some pointed digs regarding failed BPR projects that just generated really expensive binders of unused information). Unfortunately the title of his post highlighted the conflicts between the line of business and IT and it's caused a little firestorm in the BPM blogosphere. Most of the responses seemed to ignore the fact that he hopes that the SOA/BPM convergence can resolve the business vs IT conflict. More on this in a later (and longer) post.


• While I'm sure that most readers of my blog are also readers of Sandy Kemsley's Column 2, I can't help but link to her multi-part series on the history of BPM. It's a great summary of how we got such a muddled story about what BPM really means and such a glut of vendors claiming to offer BPM.

Posted by davidogren in BPM | Permalink | Comments (1) | TrackBacks (0)

Bruce Silver has an interesting post on the convergence of BPM and SOA. As I've said before, I do think that the two technologies are interlinked. Spending the last two months at BEA has only solidified this idea in my mind. I've started to see more and more customers blurring the line between SOA, ESBs, and BPM in their technology purchases. I've found myself discussing the entire BEA AquaLogic stack as much as find myself discussing "pure" BPM.

One of Bruce's interesting points is that BPEL centric tools are following the lead of the BPM tools in having an a unified view of the business process that is shared between business and IT. Which is quite a coincidence, because I was just having the exact same discussion with a client last week. The client was expecting a tool that let the business analysts model a "logical diagram" which was then converted into a "physical diagram" by IT. They felt that the process that got deployed might be significantly different than that process which was modeled by the business. I explained to the customer that one of the core values of BPM is that there is one shared view of the process between business and IT.

This is one of my issues with the BPEL tools that require converting back and forth to BPEL. Trying to convert back and forth between formats means that business isn't really collaborating with IT efficiently. Having two separate modeling formats for business and IT just rebuilds the wall that BPM is trying to tear down.

Posted by davidogren in BPM | Permalink | Comments (1) | TrackBacks (0)

The BEA/Fuego merger is still keeping me very busy. BEA has great relationships with their customers and, as a result, a lot of BEA's customers are interested in hearing about AquaLogic BPM. That, combined with the usual end of the BEA quarter rush, as been making me a deliquent blogger. But all of the activity has certainly got be thinking about things to blog, so as soon as I get caught up I'll have several things I want to post.

In the meantime, here are some short and sweet comments that I'll roll up into a single post.

• Phil Gilbert has another post on the ongoing BPEL discussion. Looks like his blog is having some technical problems, but the gist is that BPEL is just an implementation language and therefore not really that important anyway. I couldn't agree more.
• Also on the BPEL front, I wanted to mention Ronan Bradley's post about ESBs. He notes that only 3 of the 8 products reviewed by Network Computing included BPEL support. It seems that even in the system to system world of ESB products, BPEL is struggling for acceptance.
• The Red Hat and JBoss merger deserves its own post, but I'll make a few short comments here. Those who know me from my J2EE days know that I've never been a fan of JBoss. I like open source, but I've found the leadership of JBoss to be very unprofessional. Both to customers and to their developers. (And this behavior is not limited to just its infamous CEO, Marc Fleury.) So maybe I'm not the most objective on the merger, but I predict that there will be culture issues between Red Hat and JBoss. Red Hat is a very practical company, whereas JBoss is very idealistic. I wonder how well Red Hat will accept someone who thinks that Red Hat is an "open source" pretender and wraps Linux in s**t. I also wonder how this will affect the non-core JBoss projects. I can see Red Hat wanting the JBoss server, but a lot of other JBoss projects are pretty experimental.

Posted by davidogren in BPM | Permalink | Comments (0) | TrackBacks (0)

Bruce Silver, well known BPM analyst, has a new blog. Right now, it's mostly some entries that he originally posted on IT Redux, but I missed some of them the first time around, so it was good reading. Of note, he posts a followup to his post about the BEA/Fuego merger in which he responds to my rebuttal. In quick response to a technical question he raises: yes, AquaLogicBPM is a native BPEL engine. It can execute BPEL natively without requiring any conversation back and forth to any other format.

I also found his response to Edwin Khodabakchian, from Oracle, interesting. (By the way, as an example of how small the world is, I knew Edwin back when he was the manager for Netscape's Process Manager product.) I think it's another example of how far the BPEL standard has to go before it's really a good standard for business process. As I said before, I have great hopes for BPEL. It's the best hope we have for a portable standard for service orchestration. But right now, I worry that people have unrealistic expectations.

Just this week I had a line of business analyst asking me about about AquaLogicBPM's BPEL support. After I demo'ed AquaLogic Studio's BPEL functionality they started asking me "what about roles", "what about global activities", "what about people" and I had to explain to the the big long story about BPEL4WS 1.1, WS-BPEL 2.0, and BPEL4People. Their response was basically, "I can't believe that IT told us that BPEL was the solution we were looking for. We're primarily interested in human to human modeling." It was a classic example of using the wrong tool for the wrong job because of "management by magazine".

Posted by davidogren in BPM | Permalink | Comments (1) | TrackBacks (0)

A question that I've been answering frequently recently is, "What is the relationship between BPM and SOA?". Of course, there is no single answer to this question because no two people can agree on an exact definition of either BPM or SOA.

But fundamentally, I believe that BPM and SOA are two sides of the same coin. From a business perspective, both are about providing more flexibility and control to the business, increasing agility and time to market, and allowing different business units within the enterprise to work together. From IT perspective, both are about building and orchestrating composite applications, enabling re-use of existing services and systems, and using open standards.

The difference, fundamentally, is the direction at which SOA and BPM approach the problem. BPM starts with a business process and develops a solution from top down. SOA starts of an existing catalog of services and builds up. As a result, BPM projects tends to be tactical and SOA projects tends to be strategic.

A BPM project will typically start with a process that needs to be implemented or optimized. After modeling and simulation, integration will be put in place to meet the particular needs of that process and the process deployed as a composite application that orchestrates all of the needed pieces. In other words, integration will be done on an "as needed" basis where only the functions needed for that process will be integrated. A SOA project, in contrast, will take a more forward looking approach. The services developed in a SOA project are designed for long term re-use and may not have an immediate short term need. Integration to back end systems will be designed not based on the needs of a specific project, but for long-term re-usability.

There are exceptions, of course. There certainly are companies with long-term strategic visions for BPM, with a well organized catalog of re-usable business processes that are leveraged across the enterprise. (I am seeing this scerario much more frequently as BPM matures.) Similarly, many companies use a short-term tactical project as a way to test the waters of SOA and order to get a more concrete return of their investment in SOA. But the more strategic a BPM project, the more it will be intertwined with a company's SOA strategy.

Posted by davidogren in BPM | Permalink | Comments (2) | TrackBacks (0)

In a recent article, Bruce Silver asserts that "The world of BPMS is divided into BPEL-lovers and BPEL-haters". I certainly understand what he means. It seems that the BPM community is splitting on whether BPEL can be saved. On one side, the purists know that BPEL is the best chance for a standard that will be portable across vendors. On the other side, the vendors know that there will be a huge chasm to cross between BPEL4WS 1.1 and WS-BPEL 2.0, and that even WS-BPEL 2.0 is only a tiny subset of what a BPM vendor needs to include in their product. Frankly, I believe that it's largely a moot issue. BPEL support is a technical implementation detail in an technology solution that is supposed to be aimed at business users.

As such, I guess you'd have to classify me as a BPEL-hater. BPEL is woefully inadequate for modeling real life BPM applications. This has been validated by both the marketplace, with rampant vendor extensions, as well as the standards body, who have shaped BPEL 2.0 to be very different and very incompatible with BPEL 1.1. Meanwhile the specification is so loose that real portability between vendors isn't possible anyway. Bruce himself has written about the huge problems that remain for the standard in his article about BPEL4People.

But I hate to characterize myself this way. BPEL is our best hope as an industry for standards based solutions. I really want to love BPEL. But BPEL doesn't even have the concept of roles or human activities. Until BPEL vastly improves, BPEL is only one tiny, tiny piece of BPM.

Since Bruce clearly understands the good, bad, and ugly about BPEL, I was very surprised to read his comments about the the Fuego/BEA merger. In part, he writes:

"FuegoBPM appears to have already morphed lock, stock, and barrel into BEA’s AquaLogic BPMS. Not that FuegoBPM isn’t a fine BPMS, but it’s not based on BPEL wasn’t BEA a “founder” of that standard? ... For example, process activities in Fuego are not SOAP calls to remote services, but user-defined “methods” of the activity implementation written using Fuego’s VB-like FBL script. Architecturally, that puts it closer to a workflow engine than to a BPEL engine. . .

Companies like IBM, Oracle, and Intalio have shown that you can build a complete BPMS with human workflow, business rules, BAM, and the rest on top of a unified service orchestration stack, so why would BEA want to go back to the old dual architecture approach workflow for the end-to-end process and BPEL just for system-to-system integration? That makes sense for a pureplay like Fuego, but not for a core platform provider like BEA.

First, let me straighten out a couple of technical inaccuracies. A process activity in FuegoBPM can have any number of implementations. In might be a FBL script, as Bruce describes. Or it might be a form. Or a series of forms organized into a screenflow. Or a web service. Or a call into an external system. Or an Business Activity Monitoring Dashboard. Or any number of other things. A BPM tool that only could only implement process steps as web services would be a very poor tool indeed.

Second, FuegoBPM does support BPEL. You can define a BPEL process, implementing all of the activities as SOAP calls to remote services, if you like. I'd assert that architectually FuegoBPM includes both a workflow engine and a BPEL engine, as well as a lot of other other things. BPM is the convergence of a lot of technologies and BPEL is only one extremely tiny part of what makes a BPM product.

The companies the Bruce lists as good examples of BPEL based servers is very telling. None are considered, at least by Forrester, as strong players in human focused BPM. They are all classified as "integration focused BPM" players. (Interestingly, Forrester says that FuegoBPM uniquely can work as both a human focused BPM solution or an integration focused BPM solution. Perhaps because of FuegoBPM's dual support of XPDL and BPEL.) I'd assert that the BPEL focus of the vendors Bruce mentions is is holding them back. That if FuegoBPM had been a BPEL-only solution that it wouldn't have been nearly as capable of fulfilling the AquaLogic stack.

Posted by davidogren in BPM | Permalink | Comments (2) | TrackBacks (1)