SD TImes: Software Development Click for BZ Media
Search
NewsCurrent IssueBack IssuesColumnsOpinionsResource LinksSubscription services
About UsMedia KitSite MapContact UsHome

Advertisement







INDUSTRY WATCH: Welcome the Business Designer
By David Rubinstein

January 1, 2004 — One of last year’s hottest acronyms was BPM—business process management. In theory, BPM is a way to make sure that disparate applications are created that can work together to serve the needs of the business.

But as with every story, there are two sides. In this case, there is the marketing and sales effort of vendors with products ranging from application servers to CRM packages to rules engines, each trying to stake a claim in a market that research firm Aberdeen Group Inc. expects to grow to about US$4.5 billion this year.

On the other side is the technology, with vendors working together to create interoperability specifications and strengthen the symbiosis between IT and business.

These efforts, unfortunately, aren’t always in sync.

“BPM became a catch phrase that many people want to benefit from,” explained Ismael Ghalimi, one of the founders of BPMI.org and CEO of Intalio. “But they’re doing a disservice to the customer who’s lost now. App server vendors, true business process modeling companies…if there are too many, then BPM tends to mean nothing.”

Originally, BPM meant business process modeling. When BPMI.org, or the Business Process Management Initiative organization, formed in mid-2000, its goal was to create a uniform and universal way of presenting business processes. At the time, UML existed as a way to diagram some processes visually, but could be used only by very technical people. RosettaNet was developed as a way for companies to exchange common business documents, but it wasn’t visual. The Workflow Management Coalition has achieved only moderate success with its emphasis on interoperability between workflow engines.

So BPMI, Ghalimi recalled, created its Business Process Markup Language, which unified two mathematical modeling formats—Petri Net and Pi-Calculus. Meanwhile, IBM and Microsoft were working to solve the same problem for their customers. IBM was developing the Web Services Flow Language, which was based on Petri Net, and Microsoft was working on Xlang, based on Pi-Calculus. Those efforts came together in the Business Process Execution Language.

This put BPMI at a crossroads—continue down its own path, or work with IBM and Microsoft. As BPMI had neither the resources nor inclination to buck the two industry giants, it too rallied around BPEL as the common language.

Further, BPMI developed the Business Process Modeling Notation, or BPMN, a visual way for nontechnical people to create process diagrams. The organization is currently in discussions with Object Management Group Inc. to have BPMN become a part of UML, which would create a powerful tool for business process modeling and execution, Ghalimi believes. Business analysts can use the BPMN portion of the tool to create the process flows, then technical people can use the same tool to map those flows into UML diagrams that can be executed in the applications.

Ghalimi, who reminded us that IBM is very influential inside the OMG, expects something to be agreed upon early this year. “Now, there will be a consistent and complete stack of standards to create business processes,” he said.

Yet, even as BPMI, IBM, Microsoft and others try to advance a common standard, there are vendors coming at the problem from a myriad of different directions, all claiming they sell products for creating, implementing and managing business processes.

Ghalimi said that although the emerging standards are powerful and easy to use, they are quite difficult for vendors to implement. “If you look at the established vendors, the ones that will be here five or 10 years down the road, they all have plans for BPEL and BPMN, and they’re doing it from scratch. They are not re-engineering some existing piece of software, whether it’s an app server or a workflow engine. There are specific technical reasons for that. It tells us that if the big vendors are implementing from scratch, it will be hard for midlevel vendors to implement.”

Ghalimi said it’s important to understand who in an enterprise organization will be using these BPM tools of tomorrow. A business analyst on his own, for instance, won’t be generating processes that can execute, or integrate with CRM systems. A new class of IT worker, called a business designer, will emerge, Ghalimi said. This is a person, such as an analyst at a major consulting firm, or someone who has deployed SAP R/.3 systems, who has both knowledge of business processes and some level of understanding of what’s on the enterprise’s IT system. “Give them sophisticated tools and they will be very productive,” Ghalimi said.

The science of BPM, Ghalimi said, will change the traditional software life cycle, which is not in sync with the needs of the business. As for the vendor side, he added, “In 2004, the market will be clarified quite a bit.







David Rubinstein is executive editor of SD Times.

Columns
Alan Watch

And Another Thing...

First Look


INDUSTRY WATCH

Integration Watch

Java Watch

Windows & .NET Watch

E-mail your comments to Dave Rubinstein

Data Watch

Semiconductor Book-toBill


Click Here To See.



Advertisement


Click here for a complete listing of Industry Watch Columns

Click here to see a complete Column Archive.




 

 

 

 

 

 

 




Back to Top



news
| current issue | back issues | columns | opinions | resource links
about | site map | subscriptions | media kit | contact us

Copyright © 1999-2004 BZ Media, LLC, all rights reserved.
Phone: 516-922-2101 • E-mail: info@bzmedia.com