|
INDUSTRY WATCH:
With Process for All
By David Rubinstein
October 1, 2004 — There are business processes, and then there are business rules. A business process could define the way an organization works; for example, this developer reports to that manager, who signs off on all projects before they go to QA, which then must document all findings and send reports to four different department heads, who must sign off before the project advances into production.
A business rule can define the way an application behaves. A worker might try to change his 401(k) allotments over the Internet; the application will require a user name and password, then check to see that a three-fund limit is not exceeded, or that no more than 100 percent of the fund is allocated, otherwise the selection is invalidated.
Of course, not every company does things the same way, and not every application from every company performs the same way; that’s the competitive advantage. However, it is important that companies and applications do things the same way within their own organizations and trading partners.
Efforts are currently under way at the industry consortium Object Management Group to try to define standard ways of modeling an organization, to create common modeling concepts that tools using different business process notations can share, and to come up with standards around business rules.
“There’s a vision to bring together business rules and business processes,” said Fred Cummins of EDS, chairman of OMG’s Business Enterprise Integration task force. “The desire is to be able to change the process by changing the rule.”
This, of course, can be done now, but Cummins pointed out it can only be achieved on a small scale. “Rules are embedded in processes, which are buried in applications.”
Making a change in one or two applications isn’t a problem. It’s when a rule impacts multiple applications in disparate locations, and each has to be drilled into and changed, and then tested to make sure the new rule doesn’t adversely impact the process, that the shortcomings of the current method become transparent.
“What’s more ideal,” he said, “is to have the rules in a repository and then apply them when relevant. It’s idealistic, to invoke the functionality of an application where appropriate to the business process. This gets closer to having business people driving the business, to have their models tied into the applications that run the business.”
For all these things to come together, standards must be both created and accepted. Often, the first is easier than the second. “In business process modeling, standard models will open the door to new, more specific tools, such as process analysis tools. Otherwise, these things would have to be built by [process and rules engine vendors] as extensions to their specific tools.”
The vendors that currently control the markets, Cummins said, often join standards efforts to slow them down. But the realities of Web services and doing business over the Internet have driven vendors to adopt standards where they might not have otherwise, he pointed out.
OMG has three projects going to try to sort all of this out. One is the Business Process Definition Metamodel, which will allow companies using tools from multiple vendors supporting different specifications to map to a common metamodel.
Some people work in BPEL4WS, some are using the BPMN, while others use XPDL from the Workflow Management Coalition. OMG’s metamodel “is not a new notation, or how you see something on a screen,” Cummins explained. “It’s a way to exchange process definitions between tools for designing process, the analysis of process, and importing into runtime systems to execute the process.”
Another project is called Business Process Runtime Interfaces, which define ways to standardize interoperability between business process tools and workflow systems.
The third project, an RFP for an Organization Structure Metamodel, will define a consistent way of modeling organizations, with the goal of bringing together the various methods already in the market. Cummins said he hopes his task force has something concrete within a year.
These efforts should be supported, as should the work of those groups creating the standards under which these “metamodel” specifications are being built.
What this work does is twofold: It moves the development of software more in line with business goals, which creates economies and efficiencies of great value; and it moves the development of software closer to a true engineering profession.
This can only help software engineers earn more, as even more highly skilled workers, and help their companies profit more from having software that works well and actually implements the business plan.
David Rubinstein is editor of SD Times.
|
|
Advertisement
Click here for a complete listing of Industry Watch Columns
Click here to see a complete Column Archive. |
Back to Top
|