Number 10
April 2004

Business Process Platforms

 

Every time a new generation of application architecture has taken hold, it has brought with it a new kind of software platform. The shift from mainframes to client/server brought us client-based environments such as PowerBuilder and Visual Basic. The move to multi-tier applications that followed gave us application servers such as the .NET Framework and products based on J2EE. With the advent of service-oriented architecture (SOA), we're on the threshold of yet another generation in application design. Just as before, this change is bringing with it a new kind of platform, one explicitly designed to support business processes.

To understand why this is happening, think about what service-oriented applications are really like. The great promise of this approach is that all applications expose their services in a common way, ideally via the common protocol of SOAP. But while building services is clearly a good thing, what will call these services? In some cases, the client will be something that provides a user interface, such as a Windows desktop or a web-based portal. In others, the client will be another service, since composite services are sure to be a reality. But in many (maybe even most) situations, the client will be software that implements a business process using a diverse group of services. A primary benefit of SOA is that by allowing access to diverse services, it should make creating and changing business processes faster and easier. As the figure below shows, it makes sense to imagine the business process in the center of the applications it depends on.

So why is a new kind of platform required to do this? The goal of any software platform is to provide the right set of broadly useful functions, allowing developers who use that platform to spend their time creating business value rather than repetitively building infrastructure. For example, both the .NET Framework and J2EE application servers provide mechanisms for interacting with browsers, accessing databases, exposing SOAP-based services, and more. Both are good choices for building web-based applications, and they're also good platforms for creating service-oriented applications. Yet neither of them on its own is the ideal platform for implementing the business processes that make use of those services. The reason for this is simple: the infrastructure support required for a business process just isn't the same as what's required for a web-based or service-oriented application.

There's no consensus yet on exactly what functions a platform for business processes should provide, but here are a few obvious candidates:

  • The logic of a business process tends to rely on a set of basic primitives, including decisions, loops, service invocation, and a few more. Using a full-blown programming language such as Java or C# to create this logic is overkill. One option is to use simpler scripting languages, but a more popular choice today is to express the logic of a business process graphically. Taking this approach can make processes easier to create and modify, and it can also allow the business people who really understand a process to be more involved in developing the automated version. Accordingly, a platform for business processes should include a graphical tool for creating those processes and a way to actually execute these graphical descriptions.
  • Given that not all applications will speak SOAP anytime soon, a platform for business processes should also support other mechanisms for interacting with existing applications. IBM's WebSphere MQ, connectors for common packages such as SAP, and many other technologies are important here. In the short run, expecting SOA to be all about SOAP is folly.
  • Unlike services, which are often designed to return a result quickly, business processes tend to take time. When people are involved in the process, as they often are, this time can be measured in hours, days, or weeks. A platform designed to support these kinds of long-running processes should have built-in support for managing the state of a process that may wait days for a response, providing compensation when long-running transactions fail, and other problems faced by real business processes.
  • Running business processes need to be monitored, both by IT staff and by the business people who use them. Commonly referred to as business activity monitoring (BAM), this function is difficult to provide in a general way for processes built directly on the .NET Framework or a J2EE application server. A platform designed for creating business processes, however, should have this capability built in.

Rather than using a platform designed for something else, such as an application server, it makes sense to build the business processes that use an SOA world's services on a foundation expressly created for this purpose. While there are plenty of unanswered questions—implementing complex processes is inherently challenging—building on a foundation intended for this purpose looks likely to be the most successful approach.

This explicit focus on business processes is hardly an original insight—people at many organizations had this idea quite a while ago. In parallel with SOA, a discipline called Business Process Management (BPM) is emerging around the notion of implementing, managing, and monitoring business processes. Still, the emphasis for many technology people looking at SOA so far has been on the service side of this new architecture. Building services is clearly necessary, but it's not enough.

There's no agreed-upon name for a business process platform yet, so for now, let's call it a BPM server. Like the application server market in the late 1990s, the market for BPM servers has several small players and a few big ones. As with application servers, this market is sure to consolidate, with just a handful of companies getting the lion's share of customers. The most obvious candidates for winners include the three companies who dominate the application server market: Microsoft, IBM, and BEA. Each has products in this area—Microsoft's BizTalk Server, IBM's WebSphere Business Integration suite, and BEA's WebLogic Integration—and each has a natural constituency for its offerings. BizTalk Server, for example, is built on top of the .NET Framework, so Microsoft-oriented organizations are likely to adopt it, while WebLogic Integration is built on BEA's WebLogic Application Server, providing a similar bias. (This bias is less clear with IBM's very broad offering, since much of it is the result of acquisitions.) Another firm, WebMethods, also provides a BPM server that has significant market share, which suggests that it may also be a survivor.

Whoever the winners are, a new kind of software platform is emerging. What you may have thought of as specialized integration servers are now becoming full-fledged foundations for business processes. Application servers will still be important, but they're no longer the whole story. Just as in previous architectural shifts, the move to service-oriented applications is bringing with it a new kind of platform for application development.

 

 

 

 

 

 

 

David Chappell's Upcoming Speaking Schedule

I'm convinced that the move to SOA implies the rise of BPM servers like BizTalk Server. In line with this, Microsoft is sponsoring a multi-city U.S. tour this spring on which I'm giving a presentation called "BizTalk Server 2004 in a Service-Oriented World". The dates and cities are:

April 6: Boston, Massachusetts

April 8: Washington, DC

April 20: Bellevue, Washington

April 21: Portland, Oregon

April 27: Philadelphia, Pennsylvania

April 29: Pittsburgh, Pennsylvania

May 3: New York, New York

May 6: Denver, Colorado

May 18: Dallas, Texas

May 20: Houston, Texas

May 25: San Diego, California (Microsoft TechEd Conference)

June 17: Chicago

 

 

   

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in thirty-five countries. David's books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, Microsoft, Stanford University, and other technology vendors and users.

 

 

©Copyright2007 David Chappell and Associates
All rights Reserved.

 


To subscribe or unsubscribe to this newsletter, go to
http://www.davidchappell.com/newsletters.