Composite applications: The next big thing?
| Provided by |
Composite applications have garnered attention due to a combination of three concepts that have each been "hot" in their own right: process automation, Web services, and a system for developing applications without coding (both packaged and homegrown applications). Organisations must navigate the hype to uncover whether composite applications can provide real business value, and if so, which existing products and technologies can be used to create them.
Meta trend: By 2005, a new set of meta-architectural principles, currently referred to as "service-oriented architecture" (SOA), will be broadly diffused throughout the IT environment in the form of service-oriented business architecture, service-oriented security architecture, service-oriented management architecture, etc. By 2006, SOA will be widely understood and treated as a metadata (or model) interoperability architecture, given its emphasis on interoperable identifiers (namespace metadata), formats (information models), and protocols (process models). By 2007, composite applications will be based on the SOA principles of dynamic, extensible, federated interoperability and enabled by XML-based technologies such as Web services.
In a recent Meta Group survey of portal vendors, half said that they already address the building of composite applications, yet none agreed on what that actually means.
Some define composite apps as the next incarnation of portals, while others describe them as just stitched-together applications from existing systems. Still others think of them as a set of independent services that have been composed with a process engine. Many of the vendors describe orchestrating Web services and application assembly as key elements of composite applications. Buyers must navigate between the various and conflicting ideas about what makes a composite application and ensure that the vendors they choose are in agreement with their own definitions. However, they are labelling other products -- from portals to app integration tools -- as the -best way to build composite applications").
Meta Group defines composite applications as applications built by composing existing apps or services (click here to view Figure 1 ). Although other terms have been used to describe similar concepts (e.g., -system-of-systems," orchestrated apps, integrated apps, federated apps, heterogeneous apps, assembled apps), the industry has never come to agreement on definitions. We prefer the -composite application" term for this purpose (click here to view Figure 2 ).
Although portal frameworks can be used to create composite applications, these applications are a different concept, because they are designed to address a particular function and may not include the contextual relevance that defines portal frameworks (personalisation or dynamic interfaces). In addition, they are not generic (as are portal frameworks) and address a particular function. It is possible that a framework of service-wrappering tools, orchestration tools, process automation, process execution engines, and a page-assembly engine could be composed to produce a generic composite application framework that could be used whenever an organisation needs to generate a composite app. To date, no vendor has announced such an integrated package. Therefore, the key to the value of composite applications will be the use of the consistent set of infrastructure services provided by the composite application framework.
Currently, portal, Web services, enterprise application integration (EAI), and Web development tool vendors are touting the ability to create composite applications. However, this kind of assembly will be most successful in situations where the services being composed act as independent silos and exchange very small pieces of information (e.g., just customer ID) with other services in the composite application. The holy grail of composite applications -- that non-IT organisations could get out of the coding business by just assembling everything they need out of parts -- will remain an issue, because more complex composite applications require syntactic and semantic interoperability that can never be fully addressed.
In 2005/06, vendors will begin to offer pre-integrated frameworks to build composite applications that include Web services-wrappering tools, orchestration, page layout, process automation, and assembly engines. By 2007, portal and composite application frameworks will have merged and become indistinguishable.
There are three main reasons why composite applications are attractive: The first is reuse -- the ability to build new automation processes that leverage the existing transactions and functions in current systems. The second is flexibility -- a desire to build applications without coding and react quicker to the need for new functionality.
The third is process improvement by simplifying access to all the applications required to execute a process, and using model-driven composition tools to simplify the articulation and modification of core business processes. Although such drivers have existed for many years, a confluence of technologies (e.g., thin-client interfaces, process automation, Web services, the growth of service-oriented architecture [SOA] and orchestration tools) is bringing this approach to the forefront. Web services and SOA emphasise coarse-grained design and standardised interfaces that help enable the creation of composite applications. We believe this combination of new technologies and increased scrutiny of customisation/integration costs will cause this new codeless application effort to have more success and reach a broader effort than previous efforts (e.g., Eiffel).
Many types of vendors stand to benefit from the popularity of composite applications. Portal framework vendors (e.g., Plumtree, Oracle, CA, Vignette) correctly see themselves as an ideal environment for creating composite applications, because they already contain capabilities for placing numerous applications side by side in a thin-client interface and provide extra capabilities that can be leveraged (e.g., personalisation, collaboration, Web content management). Web services assembly environments (e.g., BEA Workshop, Bowstreet Factory) concern themselves more with the back-end integration of the Web services than portals.
Although they are also contenders for composite app development, they may struggle without user-interface components. Enterprise application vendors tout their ability to assemble custom applications and processes but have been slow to expose their functionality as Web services, which will hamper their ability to produce composite applications that combine their own applications with those of other vendors. EAI vendors have the most experience at converting object models to enable richer integration and offer the best long-term chances for complex (non-siloed) composite application building. Core development vendors are also moving toward a model-driven development approach that can treat custom-built, existing purchasing capabilities similarly in the model, due to the increasing use of standards such as Web services.
Bottom line: New technologies -- mostly Web services and services-oriented architecture -- are moving the decades-old search for an applications-without-coding environment closer, but differences in the interaction between the components still limit opportunities for success.
Business impact: Creating new applications out of existing applications enables new business functionality to be addressed quickly and at lower cost than traditional coding methods.
| More from META Group | ||||||||||
| ||||||||||
