As soon as new business applications roll out, someone is waiting to change them. Most application developers are resigned to this reality because they understand that business conditions change, and the applications that support key business processes have to change with them.

If constantly rewriting application code kept pace with business needs, it would be worth all the accompanying hassles. However, rewriting application code never keeps pace with business change. Rewriting application code is inherently too slow and inefficient to keep up with the pace of business change. Markets and customer whims shift faster than the best engineer can work.

Web services make change more manageable by replacing application-level, data-gathering functionality. That means applications require less coding to link them with every back-room system that contains relevant data. In this role, Web services save programmers from recoding every time a company needs to make a relatively minor change to a process - for example, a health care company increasing the reimbursement percentage on a prescription drug.

Even with Web services doing the data collection, however, applications are still too unwieldy to support change at the pace of business. The problem is the limitations of Web services and the traditional software development model. The traditional software development model is data-centric. As long as that mindset holds sway, applications will always be too hard to change because they devote too much code to chasing data all around the enterprise. The key to more manageable applications that change with the pace of business is to stop building them around data and start building them around rules, using a combination of Web services and a rules-based business process management layer as the enablers.

Rules-based business process management systems on the market today contain functionality that enables business-level users, not programmers, to change business rules, processes, or workflows in response to market conditions. Paired with Web services to perform data collection functions, rules-based systems can reduce the typical 100,000-line application to about 10,000 lines. Although that's a dramatic drop, thinner applications are not the real benefit. The business objective behind them is systems that process transactions with little or no human intervention. To do that, they must be able to change. This ability hinges on the proper mix of Web services and a rules-based BPM "change" layer in the IT infrastructure.

Combining the How and the What
As a new technology with much-deserved credit for enormous potential, Web services appear at first blush to be the whole answer to rapid application change. However, their advantages go hand-in-hand with unavoidable limitations. Current Web services lack the intelligence needed to make agile processing decisions at the point of transaction. They can't make decisions based on the worth of the customer - such as whether to batch process an address change, which would delay a customer's order, or use a more expensive Web service to process a high-value customer's address change immediately.

Web services are an ideal mechanism for exposing processes to customers and partners. They aggregate information from various systems so applications don't have to. They do not, however, take the processing burden off the application, and as long as applications do most of the processing, they will resist change. Without intelligence and process automation ability, Web services are a limited solution. That's where "smart" business process management (BPM) comes in.

Smart BPM - BPM driven by business rules - can provide the missing intelligence needed to fully automate complex transactions. Smart BPM allows business people setting business priorities - not the programmers who implement them - to guide how rules influence the way work gets done. The ability to change business rules frequently without rocking the system is key to agility. They can add the intelligence and agility to Web services that companies need if they are to realize the full benefits of exposing key applications.

As Web services need BPM, so does BPM need Web services. Web services aggregate information - the "what" - and hand it up to the BPM layer. The BPM layer does the processing according to rules set by business users - the "how." When a business user needs to change a process, they make the change at the BPM layer in HTML. In the traditional software model, a programmer would have to make the change in the application code. That could take months, during which time transactions that should be routine have to be handled as exceptions.

A New Flavor of BPM
Traditional BPM alone is not enough to support mature and nuanced transactional automation. Smart BPM, built on sophisticated rules engines, joins process automation and best-practice rules to add fine-grained decision intelligence to Web services at the point of transaction.

Smart BPM automates work through business rules, workflow, and enterprise application integration (EAI) to automate the work that smart people used to have to do. On their own, workflow and EAI did little more than push around and assign work. Workflow applications ordered and streamlined processes, eliminating manual transfers and paperwork along the way. Rules-based BPM takes these concepts further by adding sophisticated rules engines to the mix to automate more complex business processes. With rules, smart BPM goes beyond workflow's limitation to documents or tasks on the one hand, or EAI's hard-coded, point-to-point rigidity on the other. Smart BPM automates both the decisions and the processes of how work gets done. Web services are in a good position to take advantage of the meeting of these technologies.

As Web services have matured, many organizations have exposed cost-effective business transactions and services to partners and employees. Some companies are using Web portals supported by XML and other Web service technologies to bypass application interfaces entirely, enabling users to submit expense reports without logging into an ERP system, or partners to change a shipping and receiving address.

The traditional Web service implementation model doesn't scale well in dynamic enterprises. The primary culprit is the aforementioned classical software development model. IT developers typically start with a problem to solve, then build their Web services application with primary consideration to their data model, instead of to the business processes they could be automating. In this approach, functionality that best exists at its own level ends up at the application layer, where it is most difficult to alter when changes inevitably arise. Soon, the development team is fighting a constant rear-guard action to keep up with changes the company has to make to stay competitive, but never quite catching up because the deck is stacked against them.

In addition to the classic software development model's limitations, Web services have their own limitations. Typically, Web services lack the process intelligence that brings business-level discernment - the use of if/then logic to make sophisticated choices about how to process transaction input. One problem this causes is that the more Web services proliferate, the more challenging it becomes to ensure a given transaction applies the proper service (there may be several "change address" Web services available, for example, although one may be for partners and another for customers). The burden of choosing the right Web service in a given context rests with the application, which adds to the programmer's task.

Moreover, Web services are usually stateless. The management of policies, security, best practices, and so on rests with application developers - an open door for inconsistencies. And when business policies, practices, or rules change, portal developers must code the logic changes into the individual applications because their applications aren't smart enough to adapt on their own.

A better approach is to architect a smart BPM layer that abstracts the exposed Web services as a logical business process. Such a software layer applies global policies, business rules, and best practices to the entire portal platform. It manages and executes business processes centrally, tying exposed services into enterprise applications. It's smart because it takes advantage of advanced decision technology to resolve nuanced business rules in real time.

While the how of a process falls to Web service developers, smart BPM systems apply who, what, when, and where to the business context of a request. It executes the appropriate Web services via an integrated rules engine that models corporate policies, business rules, and best-practice knowledge.

Smart BPM Adds Agility
Smart BPM is crucial to Web services because business rules should be managed by the business, not programmers. Web services governed by smart BPM tailor their actions and responses to the applications calling on them, in effect creating custom services for each user. Intelligent systems leverage inference technologies to choose the correct process based on the context in which the process is used. This eliminates the need for IT personnel to aggregate a set of rules for a specific process, and makes the whole system more adaptable to change. Smart BPM systems scale well because IT staff can concentrate on adding new functionality, exceptions, and Web services instead of hand-coding every rule change into each system it touches.

For example, an address change sounds like a simple Web service. But consider a large national bank. A "simple" address change may consume more than 70 process flows and involve close to 40 back-office systems. While many flows concern themselves with the "hows" of changing the address information in the back-office, many more will need to deal with elements like correspondence, fraud prevention, and auditing. The rest of the context involves delegated business rules for up-selling or cross-selling based on relative customer value, subscription status, demographics, marketing initiatives, change notifications and so on.

If a smart BPM layer manages all of these flows, the different portals involved don't have to know any of the address change details. If the bank changes a customer value policy, the rule is instantly enforced across the enterprise. There's no need for IT to aggregate the rule and distribute the change to multiple systems. This efficiency saves money and time, but its higher value lies in what it can do for Web services as a whole.

Smart BPM's rule-guided intelligence promises to simplify and coordinate Web services for real-world business agility, something that will be critical to all business in the 21st century. While exposing Web services is key to creating automated systems, true agility comes from the intelligent use of business rules, policies, and best practices. Smart BPM is one way Web services are adapting to their own momentum and success.