“Cloud” applications are unlikely to be entirely self-contained and self-sufficient and will need to draw upon enterprise-based applications for functionality and data.
A key issue is how such applications are constructed and how they operate. Essentially we need to be able to handle long-running workflows where the functionality and data are provided by a number of applications, on a number of platforms, in a number of locations, in a number of formats. In practice most information delivery mechanisms will be hybrids utilizing both web-based and enterprise applications and services. A key question is how to meld differing channels and services into a consistent, reliable and trustworthy system.
Some elements of a solution will be realised in the user interface on whichever device the consumer is using, some elements will reside in a hub or integration engine (workflows, for example), some elements (functionality and data) will be provided by “business services” connected to the hub which orchestrates their use. A new term for this kind of assembly is “mashup” - a technique for building applications that combine data from multiple sources to create an integrated experience. Many mashups available today are hosted as sites on the Internet, providing visual representations of publically available data. A more elegant term is “composite application” – a business user’s equivalent of a mashup.
Composite application frameworks have the potential to change the way that applications are constructed, delivered, and experienced by end users. At some levels, however, this complicates the life of application developers, since now more thought needs to be given to which parts of the experience should be surfaced through which vehicles. It also puts pressure on vendors to think harder about developing true service-oriented applications, carefully considering service boundaries for capabilities in composite environments. As composition frameworks become easier to use, and operational and support models evolve to the point that composite applications are as easy to run, then the power of drawing on many vendors will be a strong incentive to accelerate change.
A successful framework needs to significantly reduce the friction across every level of composite boundaries. Collaborative scenarios are not a prerequisite for a composite application but are a natural place for a lighter-weight solution that is relatively simple yet high in value. The ability to compose elements of an application will move upstream to technical business users as these platforms increasingly move toward model, workflow, and rules-driven approaches, and bring to the surface more configurable attributes from business logic.
To realize this, we need to achieve interoperability at both the syntactic and semantic levels with line-of-business applications. Solutions to a number of difficult problems need to become accessible to everyday developers to achieve a full-blown composition infrastructure. Each of these areas warrants an article on its own, and several have already been explored in depth by others. These include:
We address these issues in developing our Business Pattern for health and social care in the following pages, but first we describe, in very simple terms what a Composite Application looks like.
Figure 5 is a representation of a composite application.
At the top are information workers, who access business information and documents through portals that are role-specific views into the enterprise. They create specific documents during the course of business activities, and these activities are part of larger business processes. These processes coordinate the activities of people and systems. The activities of systems are controlled through process-specific business rules that invoke back-end LOB applications and resources through service interfaces. The activities of people plug into the process through events that are raised when documents that are specific to the process are created or modified. Then business rules are applied to the content of those documents, to extract information, transform it, and transfer it to the next stage of the process.
Figure 5 – Structure of a Composite Application
 Adapted from “ Composite Applications – the New Paradigm” by Chris Keyser, the Architecture Journal 10 - http://msdn.microsoft.com/en-us/library/bb266335.aspx
 Adapted from “What are Composite Applications” by Anatu Banarjee, December 2006