In my last blog, entitled Business Process Platforms and Model-Driven Service Composition Tools, I described the rise of business process platforms and the opportunities that they portend. I also mentioned that the transition to business process platforms presents some challenges and thus will be gradual. In this blog, I examine some of the principal difficulties.
Business Process Platforms: Quick Recap
A business process platform is a new type of platform that has two basic parts.
Technical Software Platform: A technical software platform is a set of technical capabilities that are packaged so that application developers can use them to build applications more easily than would otherwise be possible. It includes database and network management systems. It also includes middleware that manages transactions, componentization, security, persistence, data transformation, web services, and so on. The steady rise in the abstraction level of technical software platforms has enabled a similar rise in the abstraction level of programming languages and model-driven development tools.
Application Platform: An application platform consists of frameworks of reusable, executable business-oriented services, – such as a post-to-ledger service – and executable business processes composed of multiple services, such as an order entry process. Application platforms enable a further rise in the abstraction level of model-driven tools that compose services into more complex services, processes, and applications. An application platform sits on top of a technical software platform.
Some of the Principal Challenges
As we scale business process platforms (BPPs) up, a number of issues arise. I focus on three specific challenges having to do with the application platform, the most novel part of the BPP: Finding the right components, building the right components, and configuration management.
Finding the Right Components
Over time, business process platforms will offer increasingly large portfolios of reusable services, as well as larger numbers of processes that are composed from those services. With a vast array of reusable components from which to choose, a basic problem confronts those who build new applications or business processes from the components: How do you find suitable services and processes to reuse? That is, how do you identify components that may be suitable for building your new service, process, or application? And, once you have identified candidate components, how do you evaluate the list of candidates? How do you determine whether the multiple components that you wish to reuse to build your new offering are compatible with each other?
Building the Right Components
An application platform is the latest evolution of service-oriented architecture, and service-oriented architecture is the latest incarnation of component-based development. The idea of building software from reusable components has often not worked in practice as well as hoped. It is not easy to anticipate the needs of those who want to assemble things from components. It is particularly difficult in large platforms intended to support a multitude of business needs including enterprise resource planning, customer relationship management, supplier relationship management, and so on.
Configuration Management
Just because you can compose applications from reusable components relatively quickly does not mean that all traditional challenges across the software lifecycle go away. In fact, some of them can get worse if not handled properly. Configuration management is one area that can be particularly complicated.
Design-Time and Deployment-Time Configuration: Each component may have a set of properties that the application modeler or developer sets at application design time. For example, a design-time configuration property of an accounts payable component might indicate whether to use cash or accrual accounting; the application developer sets the property's value when reusing the component to build an application. Furthermore, the component may have a set of properties to be set at deployment time – that is, at the time when the application that reuses the component is deployed. An example of a deployment-time configuration property for our accounts payable service is a reference to a relational database source that the component uses for persistence. There may also be technically oriented deployment-time properties, such as one that determines whether the service communicates via JAVA/RMI/IIOP, WSDL/SOAP, or something else. The more that we fulfill the dream of assembling applications from components, the more complex managing these configuration properties becomes, because each component is likely to have its own set of configuration parameters. It can be daunting to debug errors that arise from subtle incompatibilities among configuration property settings for multiple components.
Versioning: The fact that each component that makes up an application has its own lifecycle and version history complicates matters further. You not only have to worry about whether you've deployed the right version of an application at a particular site. You also have to worry about whether you've deployed the right versions of all of the components upon which the application depends.
My Next Blog
In my next blog I'll outline some key strategies for overcoming these difficulties.
