Last week, Jean-Jacques Dubray published an article on InfoQ regarding Microsoft's recent announcement of Oslo, a strategy designed to "...take composite applications to the mainstream." Rather than revolving around a single product, Oslo sets strategic direction for Visual Studio, BizTalk, the .Net Framework, Microsoft System Center and a new product called BizTalk Services. On a side note: Arnon Rotem-Gal-Oz hopes that this final project's association with BizTalk is more about branding than actual product similarity, a sentiment I share.

After posting this article, Jean-Jacques sent me an email and asked me to share some of my thoughts on Olso for a follow-up article to be published at InfoQ. I sent my thoughts along on Friday, but thought that I would post them here as well.

When we developed a long-term strategy for Composite Applications at my organization, it was obvious that while Microsoft technologies would have a major role to play in many areas of our future-state architecture, there were several vital pieces missing in the Microsoft stack that we would likely need to find elsewhere. I've always felt that we weren't alone in that sentiment, and the Oslo announcement suggests that Microsoft is also well aware of the gaps in their current offerings. While products like Dynamics CRM and MOSS 2007 offer composition scenarios which I regularly point to as examples of end-user and/ or business analyst composition, Microsoft has long been missing the technologies to unify these experiences under a common framework. Though missing in the products themselves, the Composite Applications vision is one that I have seen preached by Microsoft Architects and blogger's like Mike Walker and others who seem to have a good grasp on the long-term potential of composite applications. The good news about the Oslo announcement is that those individuals are no  longer in the minority. With Oslo, I believe Microsoft has unveiled merely the beginning of a unification strategy that enables composite applications. I believe that this bodes well for clients and non-clients of Microsoft alike.

That being said, There are two reasons why I'm a bit skeptical about the Oslo announcement: For starters, I believe that Microsoft's stated vision for Composite Applications is too narrow. While the Software + Services and SOA visions are needed, I believe that the end goal of any Composite Applications strategy should be to gradually enable composition up the stack toward the end-user. This is done first by providing a SOA which enables true service and process composition, then by extending those principles to developers of customer applications, business analysts and, ultimately, end users. Oslo speaks well to the former, but the latter is auspiciously missing. I actually don't believe that such a goal is absent in the halls of Microsoft, but I do believe that it hasn't permeated across the organization and thus, isn't given a place in the conversation yet.

The second reason I am hesitant to praise Microsoft for the Oslo vision is because their announcement is related to technologies which are anywhere from 1 year to 3 years or more away from release. Most of the tool updates are two releases away. Microsoft is correct when they say in their press releases that 21st century business is moving faster than IT can deliver, but that statement is true today. Organizations need solutions today, not announcements of solutions coming tomorrow. My organization, for example, cannot wait for a repository to manage models, metadata and services (one of the gaps we knew about in our strategy) when our ability to manage all three is already beyond our control. I honestly believe that Microsoft's vision for Oslo is a good one, but they are just now announcing plans to provide functionality that most organizations already know they need, which puts them at a disadvantage with those organizations. I can see a day in my company where many of the pieces in the Oslo stack make their way into our architecture, but today we need to keep moving. Of course, the good news is that when SOA and composite applications are done right, vendor lock-in is reduced and organizations can focus on delivering for the business today instead of waiting for the remaining puzzle pieces to fall in place tomorrow.

 

Back in September, I published a couple of excerpts from an internal paper I wrote on Composite Applications (you can read them here, here and here). At the end of my second post, (which I probably should have broken up into 2-3 posts at least) I discussed the four types of Application Composers. If you missed that section, (which would be proof that I should have broken them up) here's a recap:

 

1) 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.

 

2) 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.

 

3) 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 BPM platforms.

 

4) 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.

 

While these still make sense to me, I think I completely missed number five on this list. It's a bit of a wildcard, and it may not apply to every organization, but I think it will apply to more and more organization in the coming years. Here it is:

 

5) External Developers - These are developers who reside outside of one's own IT organization, but who have development expertise that they wish to leverage to create value-added services that benefit your organization. Their primary interest is in consuming available organizational data and recombining this data with external data or services to create new composites not offered or envisioned by the organization itself.

 

Now I think that the reason I missed this was because I was thinking internal only when laying out a strategy for Composite Applications in my organization. However, my fearless leader and I have been talking at length about creating a framework by which certain subsets of our information (the right information, of course) could be made available to anyone with the wherewithal to create useful services that we never thought of. Thus, our framework for Composite Applications now has another persona to enable.

 

So what do you think? Is this a valid addition, or did I have it encompassed in another one of the four? Furthermore, is just one more enough? That fifth category encompasses a ton of people, so do I need another for the technically savvy end user who doesn't write code, but who screams at creating inventive Yahoo! Pipes applications. I suspect that #4 could represent this individual with a slight modification, but what do you think?

 

 

For the past couple of weeks, I have been doing an in-depth look at various mobile communication technologies (SMS, EMS, MMS, etc.) for the purposes of incorporating these technologies into our existing strategies. While the scenarios vary, most of the use-cases driving us to SMS et al. revolve around information delivery in areas where Internet connectivity is problematic, yet cell phones abound. It sounds counter-intuitive maybe, but in many regions (like Africa for example), it's far easier to put up a cell tower than it is to lay cable of any kind. Thus, mobile technology can be found in many places where land lines and Internet access cannot.

 

Being the agenda-pusher that I am, I can't pass up an opportunity to integrate this technology study with work I have already done and am doing. Since my biggest interest right now is in the Composite Applications space, I wanted to use one of the demos in this study to prove out (to some degree) the composition argument I have been making both in this blog and internally. Thus, I created a demo scenario for this study that sends a 1-way, application-originated SMS Text Message through an SMS Gateway (Clickatell in this case) to a mobile subscriber when a particular field on a list in MOSS is changed. Now, this scenario isn't rocket science, nor is it earth-shattering. What it is, however, is me taking my own medicine. If I'm going to preach the Composite Applications gospel, I'd better try it on for size myself. Here's how I implemented the scenario:

 

I started by creating a stand-alone custom activity in Windows Workflow Foundation. The code, with some key details removed, is included below. Note: In order use this yourself, you'll need access to an SMS Gateway (like Clickatell, which is used here) and access to their HTTP API, if they have one. Not the only way to send a text message, I know, but SS7 Gateways can provide guaranteed message delivery to the subscriber.

using System;
using System.ComponentModel;
using System.IO;
using System.Net;
using System.Text;
using System.Workflow.ComponentModel;
using System.Workflow.ComponentModel.Design;

namespace MyCompany.Workflow.Messaging.Activities
{
    public class SendSMSActivity : Activity
    {
        public static DependencyProperty NumberProperty = 
            DependencyProperty.Register("Number", typeof(System.String), 
            typeof(SendSMSActivity));
        public static DependencyProperty MessageProperty = 
            DependencyProperty.Register("Message", typeof(System.String), 
            typeof(SendSMSActivity));
        
        [DesignerSerializationVisibilityAttribute
            (DesignerSerializationVisibility.Visible)]
        [BrowsableAttribute(true)]
        [DescriptionAttribute("Destination number of SMS message")]
        [CategoryAttribute("SendSMSActivity Number Property")]
        public string Number
        {
            get
            {
                return ((string)(base.GetValue(SendSMSActivity.NumberProperty)));
            }
            set
            {
                base.SetValue(SendSMSActivity.NumberProperty, value);
            }
        }

        [DesignerSerializationVisibilityAttribute
            (DesignerSerializationVisibility.Visible)]
        [BrowsableAttribute(true)]
        [DescriptionAttribute("Text of SMS message")]
        [CategoryAttribute("SendSMSActivity Message Property")]
        public string Message
        {
            get
            {
                return ((string)(base.GetValue(SendSMSActivity.MessageProperty)));
            }
            set
            {
                base.SetValue(SendSMSActivity.MessageProperty, value);
            }
        }
        
        protected override ActivityExecutionStatus 
            Execute(ActivityExecutionContext context)
        {
            string response;
            
            try
            {
                // Send the SMS Message
                response = SendSMS(Number, Message);
            }
            catch (Exception e)
            {
                response = e.Message;
            }

            // Raise the PageFinished event back to the host
            messageSentEvent(null, new MessageSentEventArgs(response));
                     
            // Notify the runtime that the activity has finished
            return ActivityExecutionStatus.Closed;
        }

        public delegate void MessageSentEventHandler(object sender, 
            MessageSentEventArgs e);

        private event MessageSentEventHandler messageSentEvent;
        public event MessageSentEventHandler MessageSent
        {
            add
            {
                messageSentEvent += value;
            }
            remove
            {
                messageSentEvent -= value;
            }
        }

        public string SendSMS(string number, string text)
        {
            WebClient apiRequest = new WebClient();
            apiRequest.Credentials = CredentialCache.DefaultCredentials;

            //Add a user agent header in case the requested URI contains a query
            apiRequest.Headers.Add("user-agent", 
            "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 2.0.50727;)");

            //Add the SMS details to the apiRequest object
            apiRequest.QueryString.Add("user", "xxxxx");
            apiRequest.QueryString.Add("password", "xxxxx");
            apiRequest.QueryString.Add("api_id", "xxxxx");
            apiRequest.QueryString.Add("to", number);
            apiRequest.QueryString.Add("text", text);

            string baseURI = "http://api.clickatell.com/http/sendmsg";

            Stream responseStream = apiRequest.OpenRead(baseURI);
            StreamReader reader = new StreamReader(responseStream);
            string responseCode = reader.ReadToEnd();

            //Clean up in-memory objects
            reader.Close();
            responseStream.Close();

            return (responseCode);
        }
    }

    public class MessageSentEventArgs
    {
        private string response;
        public string Response
        {
            get { return response; }
        }

        public MessageSentEventArgs(string response)
        {
            this.response = response;
        }
    }
}

Like I said, nothing earth-shattering. However (and I won't go into the details of WF here as there are plenty of good resources that do that) the end-result is a stand-alone Workflow Foundation Activity which encapsulates the business logic for distributing an SMS Text Message via our Gateway provider and which can be hosted in any application that provides the WF runtime. This Activity can easily be dropped into a container Sequential or State-Machine Workflow project (as I did when testing this activity on my machine), or it can be deployed to MOSS as a stand-alone activity which can be included in a Workflow built using SharePoint Designer. Two scenarios with different composers, both using the same asset. That's the vision of Composite Applications. (As an aside, with the recent Oslo announcement, I imagine that we're not far from a day where that same activity could be also be reused in BizTalk and Microsoft CRM, among others).

 

So what do those scenarios look like? For the developer adding a custom activity to a WF Workflow, it's a simple matter of dragging the activity from the Toolbox to the designer, then binding to the DependencyProperties (Number and Message in this case) and creating an event-handler to receive the event raised by the activity (in this case, sendSMSActivity_MessageSent). See the image below for an example:

 

For an individual slinging SharePoint Designer, the experience is different, but also quite powerful. However, The first step I must take as an activity developer is to deploy said activity to the MOSS server. This requires deploying the Activity assembly to the GAC on the MOSS server, adding said assembly as a safe control in the web.config file, and adding the Activity to the WSS.actions file (or a new .actions file in the same directory, which is probably a better idea), which SharePoint designer uses to load up the list of available workflow actions. All of this can be done via a feature in SharePoint (I know that the first two can and I think that the last can, so feel free to comment if I am incorrect). Here is the code for the WSS.ACTIONS file (Added in the <Actions> section):

<Action Name="Send an SMS Text Message"
  ClassName="MyCompany.Workflow.Messaging.Activities.SendSMSActivity"
  Assembly="MyCompany.Workflow.Messaging.Activities, Version=1.0.0.0, 
    Culture=neutral, PublicKeyToken=fe2315b70tbc147c"
  AppliesTo="all"
  Category="Messaging Actions">
  <RuleDesigner Sentence="Send %1 to number %2">
    <FieldBind Field="Message" Text="this message" DesignerType="TextBox" Id="1"/>
    <FieldBind Field="Number" Text="this number" DesignerType="TextBox" Id="2"/>
  </RuleDesigner>
  <Parameters>
    <Parameter Name="Number" Type="System.String, mscorlib" Direction="In" />
    <Parameter Name="Message" Type="System.String, mscorlib" Direction="In" />
  </Parameters>
</Action>

Once that entry has been added, the activity is ready to be included in an SP Designer workflow. In this example, I bound the workflow to a custom list created in a demo site, set a condition to check the value of a key field, then added the "Send SMS Message" activity and configured its inputs. In this case, the message is constructed from existing information in the list and the destination number is determined by looking up the mobile phone of a user in another list. An image of the Workflow Designer Wizard in SP Designer can be seen below:

 

If the workflow validates, we're in business and the activity will run each time a list item is added or updated and the field in question isn't blank. Here is the Workflows application page, as seen from MOSS itself:

 

In addition, that activity is now available to include in any workflow where sending an SMS notification is a requirement. You be the judge if this is a blessing or a curse... In either case my hope is that this post illustrates the power of composition. And MOSS is just an example in this case, not the end-all for composition by any means. What important in any composition scenario is a platform and technologies that provide the ability to create reusable assets and then reuse those assets across tiers and containers.

 

I published v1 of my Composite Applications Framework document last Thursday and am pretty pleased with the result. As with all things, it will evolve and improve over time, but I think it was a decent first salvo. I am indebted to Mike Walker and Todd Biske for their input. My favorite part about blogging is being able to have access to and input from such brilliant people.

As I worked back through the draft of the document, I realized that some key visuals were missing in relation to the various composition terms I wrote about in my last post, as well as a view of the CAF architecture. I don't have time to go into these in detail, but I'll post them here. Feel free to refer back to my previous two posts for more context. As always, I'd love any feedback that anyone is willing to throw my way.

This first image was designed to depict the relationship between some of the composition terms I used in my last post.

The second image expands on the first, but includes example tiers, containers and assets. Many of these examples are specific to the Microsoft universe, specifically MOSS 2007, while others are generic.

The final image depicts many of the technologies that I believe play a key role in a CAF. This is not meant to be an end-all-be-all list, or even the best depiction available. Just food for thought.

So there you have it.

On a personal note, I'm off for a two week computer-less vacation this afternoon, so the blog will be silent during that time. I'll be back in the swing of things on September 22nd and hopefully I won't be so buried in the blogs I read that I'll have a moment to write a thing or two that weekend.

 

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

 

If you've been following me on twitter, you'd probably be able to venture a guess as to why I've been mostly silent for the last two weeks: I've been frantically working away at an internal strategy and vision for a Composite Application Framework (CAF). I finished a draft Wednesday and am going through a self-imposed peer review process before publishing next week. In addition to internal peer review, I wanted to start engaging some peers in the blogging world for their opinions on the ins and outs of both the need for and the creation of a CAF in an enterprise. Part of that includes, of course, some discussion around the meaning of "Composite Applications" and CAF, which has several meanings: from being synonymous with SOA (only the beginning IMO) to Web 2.0 in the Enterprise (or Enterprise 2.0 if you like, which I do not). However, before I get into the weeds of terminology, I wanted to share an excerpt from the document that establishes the need for composition period, be it via SOA or Web/Enterprise 2.0. I've taken out anything specific to my company, but the rest is true to the first draft of the doc. I would love to have feedback from Mike Walker, James McGovern, Todd Biske, Nick Malick, Mike Kavis and anyone else who wants to weigh in. Going forward, I plan to post some additional sections from the doc for your consumption, review and feedback of any kind. I hope it at least generates some good discussion. So without further ado...

 

The Need for Composition

To understand the value that a CAF provides for an organization, it is important to first understand environmental trends which are driving IT organizations to reevaluate their current delivery models and to pursue composition strategies. In particular, I believe that there are five factors which illustrate the need for an application composition strategy. These factors are:  

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 

The Cost of Building Applications

A current reality many organizations face is that IT costs are increasing while businesses are asking for more controls on IT spending. While the high cost of IT solutions isn't new, more and more organizations are pointing to the cost of integration as a major culprit behind IT cost overruns. According to Ebstrategy.com, "The cost of integration is rapidly becoming a significant barrier to the deployment of new business applications. EBS estimated that in large corporations, approximately 40% of the cost of new applications is spent linking disparate business processes and applications rather than delivering new business functions." (E-Business Strategies, Inc.) Furthermore, Dr. Jean-Jaques Dubray of Attachmate argues that increasing integration costs are a sign that IT is nearing or has crossed the point of "negative ROI," beyond which the costs, risks and complexity of integration make it nearly impossible for the organization to realize any ROI from its efforts. (2005, p. 9) The figure above illustrates this theory of increased cost and decreased value as the number of systems in an organization increases.

 

As a result of this increased cost, Dubray concludes that "...companies are limited in their ability to improve existing business units operations or expand their businesses because all changes in a company's operation translate into modifying or creating new [Line of Business (LOB)] systems." (2005, p. 9) The increased cost of applications due to integration cost and the resulting limitation in IT's ability to deliver value to the organization contributes a great deal to the perception that IT is too expensive and slow to respond to the needs of the business.

 

In response to increased cost and this perception, Dubray argues that IT "...can no longer afford to build assets that cannot be reused in future contexts." (2005, p. 9) Instead, IT must view everything it creates for the business as a collection of discrete and reusable assets. In addition, IT must create a framework that enables both the creation of reusable assets and the reuse of those assets in the creation of solutions.

The Problem with Processes

The systems that IT creates are typically designed to manage discrete steps in a structured process. An example is web content creation, which typically involves story creation, moderation, publishing and retirement. Historically, IT systems have focused on automating approval, publishing and retirement and have been successful at creating value along these steps. However, the largest step in this process (in terms of elapsed time) is usually the first: story creation. It is also likely the most collaborative and would likely consist of several "ad-hoc" process steps where the author collaborates with other individuals to check facts, obtain more information and even elicit feedback on the document in progress. But the system in question assumes that a completed draft is step 1 in the process. The result is that most applications "...do not enable rich collaboration across functional boundaries. This usually leads information workers to use personal productivity tools to perform the complex interactions required to conduct business. However, this in turn leads to a loss in productivity, as users are forced to cross from one set of tools to another, often manually moving the data through means such as cut-and-paste." (Banerjee, 2006, p. 12)

 

IT cannot focus merely on process automation to create value for the business when the reality is that most processes involve "...much more work between elements than is represented in the initial structured process. This work is often collaborative in nature. Innovation frequently takes place outside structured processes in the collaboration interactions, where imagination predominates, where the creativity of information workers is truly tapped, and where the critical business differentiation occurs." (Keyser, 2006, p. 3) Instead, IT should seek to create applications that enable and enhance the productivity of information workers along both structured and ad-hoc processes, as illustrated in the Figure above (Banerjee, What are Composite Applications?, 2006).

The "Consumerization of IT"

The "Consumerization of IT" is a term coined by Gartner to describe the effect of popular technology outside of the enterprise on the expectations and needs of knowledge workers within the enterprise. Gartner argues that knowledge workers are learning new and creative ways to use the web for productivity and collaboration and that they will expect to have these methods and tools available to them in the workplace. According to Keyser, "Based on working with Web 2.0, users will increasingly expect to exert more control over their work experiences and to participate in them. They will expect business applications to adjust to the way they work, rather than accept a suboptimal experience." (Keyser, 2006, p. 2) An example of this shift has been illustrated by a recent poll conducted on Facebook.com by the Gilbane Group (Gilbane, 2007).

 

In this poll, participants were asked to select from a list of collaboration technologies which they plan to use in their jobs the most over the next two years. The respondents were then broken up into two groups (18-24 year olds and 25-34 year olds) and a visualization of the results can be seen in the figure above. While it's a bit of a surprise that younger knowledge workers will expect to use social-networking sites and SMS text messaging as a part of their jobs and not merely for play, a key piece of information in this unofficial poll is that many younger workers would prefer not to use email as a collaboration tool.

 

The implication, in my opinion, is that IT cannot paint users into a corner by offering one prescribed way in which to accomplish a task or achieve a goal when another tool or method might enable users to be far more productive. In reality, the "Consumerization of IT" means that the use of technology and the tools at an information worker's disposal are becoming a large part of job satisfaction outside the walls of IT. IT organizations should recognize this trend and seek to provide solutions with the flexibility to meet the technology demands of information workers.

The Need for Agility

Many organizations frequently express a desire to obtain the flexibility to quickly respond to meet new opportunities and demands as a "high priority" which they expect IT to enable. (Keyser, 2006, p. 2) As an organization grows, there is an increasing need for IT to provide the organization with:

• A platform for rapid decision-making;
• Tools to help the business sense and respond to changing market conditions;
• The ability to align business needs with current and future IT assets.

 

To support these business needs, IT organizations should be able to provide applications which are:

• Quick and easy to deploy;
• Easy to modify, customize and extend;
• Aligned with the current and future needs of the business.

 

All of these factors illustrate the need for IT organizations to provide infrastructure and solutions which enable an organization to respond quickly and easily to change.

The Desire for a Single User Experience

As organizations grow their products and services, they typically outgrow the LOB systems they purchased or built to manage their earlier products and services. Those legacy systems are typically run to support the existing business, while new systems are created in new interfaces and bolted into the organization to run new businesses. The result for most users, who typically work with similar business processes across all products and services, is a small to large number of disparate systems within which they perform their daily work. Over time, the business begins to call for integration and a unified User Experience for knowledge workers in an organizations. Organizations who have been successful at implementing SOA usually lay the groundwork for meeting this need, but the path to a single User Experience includes a framework which brings data, processes and interfaces into a shared and consistent experience for knowledge workers.

 

It is important to note here that a single User Experience is not a single user interface or a single system. Rather, a single User Experience is offered by a platform and a controlled number of user interfaces which provide familiar interactions to knowledge workers regardless of the medium, be it Office client, web application, mobile device or smart client. 

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.

Dubray, D. J.-J. (2005, May). Composite Applications: Value Proposition and Architecture. Retrieved August 20, 2007, from ebMPL.org: http://www.ebpml.org/capp.ppt 

E-Business Strategies, Inc. (n.d.). Composite Applications - Frequently Asked Questions. Retrieved August 20, 2007, from EBS Web Site: http://www.ebstrategy.com/selfservice/composite/composite_apps_faq.htm

Gilbane, F. (2007, June 20). More Data on Facebook users and Enterprise 2.0. Retrieved August 20, 2007, from Gilbane Group Blog: http://gilbane.com/blog/2007/06/more_data_on_facebook_users_an.html 

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

Platt, M. (2007). Web 2.0 in the Enterprise. The Architecture Journal , (12) 2-6.