|
|
 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:
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 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
|
|
||||
|
