In my last post, I posted an except from a strategy document I am working on around the creation of a Composite Application Framework (CAF). The section I posted dealt specifically with the need for application composition within IT. Soon after I posted, Mike Walker, an Architect with Microsoft’s Architecture Strategy team, posted a response with some thoughts of his own. As I said in the comment section of that post, I think Mike’s additions were right on and plan to incorporate some of his thoughts and comments as I revise that section in the final publication. 

In the first section of his post, Mike took a moment to define the term “composite applications” using definitions from Gartner, BEA, IBM and pointed to Chris Keyser’s Architecture Journal paper from January, “Composite Applications: The New Paradigm.” The last was a key piece of my research and I highly recommend reading it as it discusses composition from a broader view than just SOA, which is contrary to the focus of most first generation thinking on composite applications.

Mike’s definition aligns with what I included in the second section of my research paper, which I am posting here. This section shifts the focus from justifying the need to understanding all of the terms in the CA universe as we’ve defined it. Thus, it includes a bit more than just defining Composite Applications. Mike, I’d be interested in further thoughts or feedback you might have on this section. Same goes for anyone who wants to jump in. Here’s section two:

Composition: Assembling Assets into Applications

In order to create a Composite Applications Framework (CAF), one must first understand the vocabulary of composition and composite applications. This section introduces several terms and concepts important to the creation of a CAF. They are:

1. Composition

2. Composite Assets

3. Composite Applications

4. Composition Tiers, Composite Types and Containers

5. Composers

Composition

According to Wiktionary, composition is the combining of different parts to make a whole. In the context of technology, composition is the combining of technology assets to create an application or solution which provides value to the business. According to Keyser, the term itself is a “… shift in computing from brittle, monolithic, developer-centric applications solving one particular problem, to agile, contextual, user-driven applications to support a particular business process.” (2006, p. 5) In addition to agile and user-driven applications, composition also “… includes personalization and customization abilities, so that users can easily and quickly modify specific functionality in the solution.” (Banerjee, What are Composite Applications?, 2006) In essence, composition is the assembly of assets into applications which can be created and/ or modified quickly and are user-driven in nature. Thus, enabling composition of assets into applications is the key and ultimate goal of a CAF.

Composite Assets

Within the realm of Composite Applications, a composite asset is a discrete object with standalone value and functionality which can be combined with other objects to create an application of greater value than the sum of the individual objects. Typically, this combination is in support of a business process or set of user goals. Within a CAF, the following objects can be considered assets for composition (Adapted from Banerjee, Building Office Business Applications, 2006 and What are Composite Applications?, 2006):

Documents	Dashboards
Business Activities	Portal Sites
Business Rules	Portal/ Web Pages
Schemas	Data Connections
Metrics	Authorizations
Web Parts	Reports
Web Services	UI Screens

It should be obvious from this list that the creation of composite applications goes far beyond the assembly of WebParts on a screen to create a single interface. In fact, composite applications span all of these types and all of the traditional application tiers. To create a successful CAF, IT should create a CAF that allows most, if not all, of the assets listed above to be used in the creation of Composite applications.

Composite Applications

The term “composite applications” evokes many different meanings in the current landscape of information technology. A few examples are:

• Applications created via the assembly of SOA services;
• The Business user’s equivalent of Web 2.0 “mashups;” (Keyser, 2006)
• Another form of integration and application development; (Frye, 2005)

While these are all valid interpretations, they are also nearly all tied to first generation ideas around the meaning and intent of composite applications. Core to that idea was that the only useful assets for composition were either Web Services or entire User Interfaces. Thus, much of the current writing and thinking around composite applications centers on either the composition of fine-grained SOA services into “right-sized” business services, which are then wrapped in a UI and delivered to the user, or the creation of Web Parts which are dragged onto a portal screen, skinned and placed wherever the user desires.

While we still hold the first generation thinking around composite applications to be true, we believe that composition is more than simple service composition or the creation of WebParts. Furthermore, composition is a reality for all of the assets listed above and also at every tier of an application and for each major type of composite application. Thus, a candidate definition of a composite application is “… a collection of software assets that have been assembled to provide a business capability. These assets are artifacts that can be deployed independently, enable composition, and leverage specific platform capabilities.” (Banerjee, What are Composite Applications?, 2006, p. 12)

Composition Tiers, Composite Types and Containers

Because a CAF should support more than service and WebPart composition, it is important to understand the tiers of composite applications, types of composite applications and the containers available at each tier. An understanding of each enables solution teams to determine the appropriate placement for a composite application.

Composition Tiers are application layers that provide services to composite applications.

Composite Types are categories of composite applications which map to each composition tier.

Containers are shells which can host any or all of the assets that make up a composite application.

Presentation Tier - UI Composites

The primary function of the presentation tier is to present business information to knowledge workers and actions to perform on said information. Composition at this tier is called composition “at the glass.” (Sholler, 2006) UI Composition is one of the most common forms of composition and is often assumed to be the only tier at which composition takes place because of its broad use and visibility. However, this misconception often causes organizations to attempt to create a CAF simply by creating a “whole cloth” UI through which all applications must be surfaced. The result is a single interface (instead of a unified User Experience) which ends up constraining business users and diminishes the value of a CAF.

Instead of a one-size fits all CAF with exclusive UI composition, organizations maximize the value of a CAF by leveraging composition at the level where it is the most appropriate option for a given composite application. In the case of UI composites, these are most appropriate when the resulting composite application should describe the sequence of interactions the end user will need to follow in order to use the application. (Sholler, 2006) In addition to sequenced composites, UI composites are also appropriate for “informal and unintended compositions.” (Keyser, 2006, p. 3) In both cases, an Enterprise Portal environment is the ideal host for these types of composite applications.

Application Tier - Service/ Integration Composites

Composition at the application tier typically involves the creation of new services from existing services to enable a business process or set of user goals. Composites created from existing services are new services themselves which may also be candidates for composition. These services are usually managed by an integration/ orchestration engine such as Microsoft BizTalk Server. Similar to Presentation Tier composites, these composites can have UI elements and trigger user interactions, but the key difference is that the actual composition takes place at the service level. These types of composites are most appropriate when the composition describes automated business activities or a subset of an automated business process. (Sholler, 2006)

Data Tier - Data/ Information Composites

Composition at the Data Tier consists of creating services for managing the content and relationships of a business entity. These services are designed to be the building blocks for the creation of other services and are typically not surfaced to a UI. Data Tier composites are most appropriate for consolidating views of shared reference information and are usually the foundation for SOA. Key to the success of Data Tier composition is the establishment of Enterprise Information Management (EIM) processes and practices in an organization. EIM practices, especially those targeted at Master Data Management (MDM) go a long way toward addressing many of the entity aggregation and information integration issues which typically plague SOA and CAF implementations.

Productivity Tier - Ad-hoc Composites

Productivity Tier composites are composites used to manage the “rhythm of the business:” those ad-hoc interactions, collaborations and processes which all knowledge workers rely on to accomplish their goals. While discussions around SOA, Enterprise Service Buses (ESBs) and open standards like WS-* and Service Component Architecture (SCA) are valuable, they are all focused on managing and exposing structured business logic. However, the greatest business value for composition can be found at the Productivity tier. (Keyser, 2006) Furthermore, the very idea of composition begs for a framework which supports ad-hoc processes. According to Banerjee, “By their very nature, composite applications presume that composition of solutions can occur after assets have been built and deployed-and so need to explicitly account for people-to-people interactions among information workers that are essential to complete any business process. Usually these interactions are not captured by structured processes or traditional business applications.” (Banerjee, Building Office Business Applications, 2006, pp. 12, 13) These types of composites are most appropriate when processes either cannot or need not be defined, or when the business requires a solution that works “in between the boxes” of defined processes.

Each of these tiers and types provides a set of containers within which assets can be hosted. Examples of containers at each tier are:

• Presentation - Outlook, Excel, InfoPath, WSS WebParts
• Application - Web Services, LOB Systems
• Data - Analysis Services, Data Warehouse, EIM services
• Productivity - MOSS Document Libraries, Excel Services, Workflows, Business Data Catalog

Composers

One of the key questions related to the creation of composite applications and a CAF is “Who composes?” That is to say, “What roles would be involved in the assembly of composite applications?” Organizations have several options when determining the primary composers of composite applications and the choice has implications on the design of both a CAF and the experience in creating composite applications. Some likely composers of composite applications are:

Business Service Developers

These are IT developers focused on providing value-added common business services to all customer solutions teams. Their technical depth is high and a CAF targeted at these users would be similar to what is provided by SOA today.

Customer Solution Developers

These are IT developers focused on creating customer-centric solutions by leveraging software infrastructure. Their technical depth is moderate to high and a CAF targeted at these users would need to abstract away service creation and assembly.

Business Analysts

These are customer consultants focused on helping customers determine which business needs are best met with technology. Their technical depth is moderate and a CAF targeted at these users would draw many features from current leading BPM platforms.

End Users

These are the users of the solutions created by customer solutions teams. Their technical depth is low and a CAF targeted at these users would need to abstract away nearly all of the technical aspects of application creation and should provide very intuitive context- and metadata-driven methods for application assembly and customization.

For many organizations, it would be advisable for a first generation CAF target Customer Solution Developers as the primary composers of applications, with some configuration, customization and personalization provided to business analysts and end users. Once the CAF is in place, the framework should evolve over the long term to push composition out to Business Analysts and eventually to end users.

References

Banerjee, A. (2006). Building Office Business Applications. The Architecture Journal, (10) 12-19.

Banerjee, A. (2006, December). What are Composite Applications? Retrieved August 20, 2007, from MSDN Architecture Center: http://msdn2.microsoft.com/en-us/architecture/bb220803.aspx

Banerjee, A., Moinuddin, M., & Walker, M. J. (2006). Office Business Applications: Building Composite Applications Using the Microsoft Platform. Redmond: Microsoft.

Frye, C. (2005, July 20). The role of composite applications in an SOA. Retrieved August 20, 2007, from SearchWebServices.com: http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1109080,00.html

Keyser, C. (2006). Composite Applications - The New Paradigm. The Architecture Journal , (10) 2-5.

Phifer, G. e. (2007, July 13). Hype Cycle for Web and User Interaction Technologies, 2007. Retrieved August 20, 2007, from Gartner

Sholler, D. (2006, December 12). Three Approaches to Building Composite Applications. Retrieved August 13, 2007, from Gartner