JH: One of the biggest changes that is going to happen as a result of the movement to Service Oriented Architectures is the dramatic change in the definition of a packaged application. Think about this, Robin. What is a packaged application? It is, in its simplest form, the codification of a set of business processes. With the movement towards SOA we could begin to see more loosely coupled business services combined with process becoming the new definition of packaged applications. In this way, you would actually not have a traditional application—rather you would have a collection of business services that were combined together at run-time that understood business context. Of course this would not necessarily be easy to achieve… but I think that we are witnessing the beginning of a very interesting revolution. What do you think, Robin?

RB: Well. SOA provides the possibility of building business apps in a different way. Initially, packaged business apps were completely inflexible with proprietary everything; from file formats to interfaces. Then with relational database it became possible to get at the data of a packaged app. With web services it becomes possible to pull out specific business functionality—but only if the app vendor makes it easy to do. If the vendor isn't "co-operative enough" then I guess that customers won't do it because the vendor won't support it well enough. But providing a web services interface doesn't change an app much. So the question is, how will the vendors change their packages beyond providing such an interface?

I think this is a tough prediction to make because it depends a great deal on what package vendors are willing to support and how support will work. We already have the idea of "software as a service" and a fairly effective implementation of this by Salesforce.com and Oracle (on-line) among others. But these vendors sell whole applications. I don't see vendors selling part applications. Judith what do you think?

JH: I guess that I see a couple of different dimensions to this issue. First, I am starting to see vendors, like SEEC for example. SEEC is a small software company that has been selling into the insurance industry for many years. Rather than build a traditional packaged application for insurance the company has built a series of business services that can be linked together via web services interfaces to create a customized real-time application. I also see that IBM is beginning to leverage its experience from its business consulting services to begin to codify its best practices across the vertical industries that it has focused on to build what I have been calling "services as software". They are creating frameworks of business services. SAP is also moving from its traditional packaged applications and starting to create industry frameworks based on best practices. SAP has done some very impressive work in componentizing its applications. I think that this is also the way that Oracle will work to create synergy across all of the packaged software companies it has been buying.

I agree with you that the packaged application will not go away. I really think that it is going to look very different five years from now. The focus from now on will be on process rather than integrated business logic. But the question is, where does process start and business services end? What is your view on the intersection of process and services, Robin?

RB: It's a "large" question. We have the basic split between "what" an application does and "how" it does it. The move to SOA means that package vendors (or some of them at least) will be able to present their apps as a set of components simply by selecting out specific web services from their apps. This will make their apps more flexible. But it isn't the only way of making apps flexible. We took a look about 18 months ago at a financial services package from a company called Frictionless. It was very flexible because it was highly parameterized not because of any web services capability (although I think the company was going to provide that). Few people really care how flexibility is achieved, but lack of flexibility is the bane of package apps and this will surely diminish.

So my guess is that there will be a focus on process and producing apps that are robust in the usual sense, but flexible in terms of business process (which very few apps are).

There used to be a considered split between build-your-own and packaged apps, but there was a tendency for development on packaged apps to be done by vendor developers. This needn't be the case once SOA takes off, so I think the package business could change with package vendors considering different business models. With SOA it will be possible for the package user to add functionality to a packaged app. This was rarely done before because it meant altering the source code of the app. Now it can be different.