Partager via

Justifying the need for Composite Applications

  • Article

I recently saw a post from Brandon Satrom as he was asking for feedback on his interpretation of composite applications and the value proposition to his organization. He is definitely on the right track, and not because he is using the guidance that I have been working on at Microsoft :). I will address the content of his post directly here with my opinions.

Brandon articulates the value of composite applications into five factors:

  1. The Cost of Building Applications
  2. The Problem with Processes
  3. The "Consumerization of IT"
  4. The Need for Agility
  5. The Desire for a Single User Experience

Assuming that these are not in order but rather a un-prioritized list of factors to consider going down the composite application route then I roughly agree with most of these.

But let's take a step back for a moment. Like all other complex subject matters there are varying opinions and definitions from smart people in the industry. I have been talking about this subject for about three or so years while at Microsoft and before. I have seen this definition grow and morph into a much more compressive and more importantly actionable concept.

So what are composite applications? Here are some definitions from the industry:

Gartner

Composite applications leverage the business application functionality that is exposed as Web services. The composite application is an abstraction layer on top of a service repository, which orchestrates a new business process and has its own user interface. A composite application may be a process template or a ‘service’.

BEA Definition

Applications that are built by reusing logic from two or more existing applications to form a new application without having to start from scratch. A composite application consists of functionality drawn from several different sources within an SOA. The components may be individual Web services, selected functions from within other applications, or entire systems whose outputs have been packaged as Web services (often legacy systems). 

IBM Definition

To be considered as a composite application, an application needs to comply with a certain architectural design, which is defined by a set of features. Even if it is not an exhaustive list, the following shows the main desirable features of a composite application:

  • Homogeneity to behave as a unique application to different heterogeneous applications or components
  • Flexibility to use service-oriented architecture (SOA) principles such as loosely-coupling and reusability
  • Intercommunication between components
  • Richer user experience to aggregate a variety of application types into a single client view
  • Security such as authentication, roles and data confidentiality
  • Transactional applications, which get the information from multiple sources
  • Reuse computing assets
  • A uniform and consistent graphical user interface
  • Composition of parts or components
  • Aggregates a variety of application types into a single client view
  • Provides anytime/anywhere access in a semi-connected environment. This is not a composite application feature but Lotus Expeditor enhances these capabilities

From a Microsoft perspective we have defined composite applications mostly at a micro level with the great work performed by my team on defining this more with OBA. From a macro level Chris Keyser wrote a great composite applications primer on this subject in the Architecture Journal a few issues back.

My opinion on Composite Applications is similar to IBM's and Gartner's combined. I think Gartner defines the concepts nicely but implies implementation details when they should be left out. What I like about IBM's definition is that they tell you the capabilities of a composite application.

I break a composite application down to the following four core requirements:

  1. Contain an autonomous business process. The goal of composite applications are to have a plug-able black-box applications. To do so, they must have explicit business process or functional boundaries.
  2. Must fit into a heterogeneous environment. Applications that can be implemented in various different ways, this should span multiple implementation types of the same technology and work within environments where the technology is diverse.
  3. Must have Built-In Interoperability. These applications should not have proprietary integration methods but rather have industry standard ways of interoperating with other systems.
  4. Compose in many different ways. Composite applications are self contained applications that can interact with other applications in the same environment similarly to web mash-ups (great article by Ray Ozzie) which are consumer composite applications are a great example of how composite applications have flexible and extensible  UI functionality.

Below is a slide from my presentation from TechEd in Australia.

From a micro level I agree with Don Box's tenets of service oriented architectures. When you read these, they are not exclusive to Composite Applications but rather SOA as a whole. The key here is that composite applications provide a way to implement Service Oriented Architectures. It is important not to confuse the two. SOA provides the principles for building a service oriented <insert what you will here>. It could be at many various levels such as at the application, system, or enterprise level.

  1. Boundaries are explicit. Services must interact across service boundaries, but crossing service boundaries might be costly. Therefore, it is important to know your boundaries. Keep service surface areas small, avoid RPC interfaces, and avoid leaking implementation details outside a service boundary.
  2. Services are autonomous. Ideally, services should be stable, but business needs change frequently. The space between services changes more frequently than the service boundaries themselves. Avoid assumptions on the environment into which the services are deployed. Design, deploy, and manage services independently from one another. Communicate only through contract-driven messages and policies.
  3. Services share schema and contract, not class. Service consumers will rely upon a service's contract to invoke and interact with a service, and will insist that the contract remain stable over time. However, changing business needs will force change upon a service. Therefore, service interaction should be based solely upon a service's policies, schema, and contract-based behaviors. Ensure stability of services (public data, message-exchange patterns, policies). Form explicit contracts that are designed for extensibility. Version services when change occurs. Avoid blurring the line between public and private data representations.
  4. Service compatibility is determined based on policy. Services must be compatible with each other—not just structural compatibility (public data, message-exchange patterns), but also compatible with other semantic capabilities that are expressed through configurable capabilities and service levels. Operational requirements for service providers should be manifested in the form of machine-readable policy expressions.

Microsoft has taken Composite Applications to the next level with the re-usable building blocks and reference architectures released by many of the groups out there. Patterns and Practices on the Composite Application Block (CAB) then the Smart Client Factory and now Acropolis. This isn't to say that there isn't any thought leadership or examples of composite applications by other vendors. I get my paycheck from Uncle Bill so I will mention our technologies.

Taking my opinions on Composite Applications and contrasting them to Brandon's there are similarities.

The Need for Agility this is the top priority for IT organizations to stay relevant to the business. All the benefits the Brandon mentioned are spot on but I would expand them a bit. All of the reasons listed though were reacting to business needs. Agility is also about future strategy by allowing our architectures to proactively address future business challenges and drivers as well as reacting to current trends.

Agility often defined as the ability of a firm to sense and respond to business opportunities in order to stay innovative and competitive in a turbulent and quickly changing business environment. An agile firm (one that demonstrates agility) has the capabilities and processes to respond to unexpected environmental changes.

 - Wikipedia

I really like the Wikipedia definition of agility. The definition clearly shows us the forward and current state thinking aspects of agility. I talk a bit about the future state in my sessions about composite applications. When we architect our solutions the technology, process and ultimate implementation of that solution will inevitability change. Composite application architectures allow us to build solutions with this needed flexibility.  

The Desire for a Single an improved User Experience (UX) , this one is an important one. Understanding that we are not talking about creating one reusable interface but rather an improved experience for the actual users of the solution. This coincides with creating agile architectures and not trying to prescribe to the business what we feel is a good interface but rather letting them. New trends both consumer (Web 2.0) and enterprise (Portal or Smart Clients) come and go. There are very few that have stand the test of time. So with that knowledge are architectures must adapt to change.

The "Consumerization of IT" is one of the possible results of User Experience aspects. The consumer technology solutions definitely have potential plays in the enterprise, especially the collaboration technologies which span consumer and enterprise.

The Problem with Processes. I think Brandon is on the right track here and I agree with what he talks about here. I would a few comments to further refine. Composite applications are able to leverage various types of workflows.  Composite applications themselves do not improve the process directly. Workflow definition still involves a set of architecture decisions in a workflow engine. However, composite applications make a great choice for surfacing these workflows due to their service oriented nature.

Below is a slide I use often to describe the various levels of process. As you can see the technology choices to implement change. As architects we should pick technologies for their strengths. For example, we wouldn't want to use BizTalk for instant messaging and collaboration.

I wrote an article on MSDN called Architecting Enterprise Loan Workflows and Orchestrations in this article I talk about these concepts in detail using the Loan Origination RAP as a working example.

 

image The Cost of Building Applications is a big challenge for IT. I would make this a bit more generic because it's not just about the cost of building but also the cost to:

  • Maintain - We are seeing from analysts such as Accenture that maintenance is accounting for 70% of the total IT time in enterprises. This is a staggering number when you contrast this to the 40% of new development in integration. So would it be safe to say that 17% of the time is really spent on new development?
  • Integrate and Interop - I would add interoperability here. Composite applications foster the notion of interoperability.
  • Enhance - The composite nature allows for easy additions to solutions when proprietary implementations inhibit this behavior.

With these factors we need to make sure the technology choices we make doesn't hamper IT or the business to create the right new applications instead. We want to build our solutions that it ensures future flexibility rather worrying about the legacy applications. Ideally this shouldn't be our primary concern.

The underling goal here is to Reduce the Cost of Technology Investments.

Overall Brandon did a great job justifying the need for composite applications. I hope this had helped and I would encourage you to provide feedback on my explanations as I didn't go into great detail on some of the topics. Additionally, refer back to the four basic requirements of a composite application as they show some clear benefits as well.

 

Tags: SOA Smart Client Composite Applications Architecture OBA

Comments

  • Anonymous
    August 26, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/08/27/justifying-the-need-for-composite-applications/

  • Anonymous
    August 28, 2007
    My news favorite drink: A StarBucks Black Eye . SOA Service Oriented Infrastructure Building Justifying

  • Anonymous
    August 28, 2007
    Thanks for the great feedback Mike! I plan to work a lot of this into the final paper.

  • Anonymous
    September 21, 2007
    Several weeks ago Brandon Satrom and Mike Walker created two great posts giving the justification for

  • Anonymous
    September 21, 2007
    Several weeks ago Brandon Satrom and Mike Walker created two great posts giving the justification for

  • Anonymous
    September 16, 2008
    What you don&#8217;t know can hurt you. Sometimes the world can change under your feet and you never

  • Anonymous
    December 02, 2008
    My news favorite drink: A StarBucks Black Eye . SOA Service Oriented Infrastructure Building Justifying the need for Composite Applications Enterprise Architecture Agility, Feedback, and Enterprise Architecture CLR/Orcas/Silverlight Sharing Code Between