Skip to Content

Contents

  • In My Last Blog
  • Business Process Platforms: Quick Recap
  • Some of the Principal Challenges
  •       Finding the Right Components
  •       Building the Right Components
  •       Configuration Management
  •             Design-Time and Deployment-Time Configuration
  •             Versioning
  • My Next Blog

In My Last Blog

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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Marco ten Vaanholt
    In response to: 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?

    – the answer should be pretty straight forward. If we build a community around BPP = BPX community, we could utilize the common knowledge of many to evaluate and stimulate use and reuse of the best services

    Building the Right Components – If we build a community around BPP = BPX community, we could utilize the common knowledge of many to evaluate and stimulate use and reuse of the best services and components, I would see challenge one and two one and the same

    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.

    Comment: makes sense but I would like to add governance as one of the challenges which you have not mentioned.

    One of the other challenges you did not mention yet is workforce. Currently we do not have a steady workforce that can implement, govern, use and reuse such a business platform. Would like to hear your ideas around them.

    (0) 
    1. David Frankel Post author
      Regarding the problems of finding and building the right components:

      Harnessing the power of community to solve these problems is very important. I did not address that point, and it should indeed be addressed.  The community will help a lot for sure.  However, it will require more than just getting humans to evaluate the services and communicate their findings.  There are techical obstacles that need to be overcome, which are discussed in this blog and in the follow-on blog that discusses how to meet the technical challenges.  But the community can be engaged to help solved those technical problems.

      Regarding governance: Agreed.  It’s becoming clear that fairly sophisticated governance is necessary.

      Regarding building the skills of the workforce:  Agreed.  Building the skills and defining the roles is part of scaling up.

      (0) 

Leave a Reply