Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

Collaboration in context with IBM Workplace Collaboration Services 2.5

Chris Reckling (chris_reckling@us.ibm.com), Senior Product Manager, IBM
Chris Reckling is Senior Product Manager for IBM Workplace Application Development tools and technologies.
Sami Shalabi (shalabi@us.ibm.com), Senior Software Engineer, IBM
Sami Shalabi is a Senior Software Engineer with the IBM Workplace server team, based in Westford, Massachusetts. He is the lead architect of the collaborative application infrastructure and has been with Lotus/IBM since the late 1990's. Previous to Lotus Workplace, Sami has worked on both Lotus QuickPlace and Lotus Domino. Sami holds both a Bachelors and Masters degrees in Electrical Engineering and Computer Science from MIT.
Mustansir Banatwala (banatwal@us.ibm.com), Senior Software Engineer, IBM
Mustansir (Miki) Banatwala, Senior Software Engineer, joined IBM in 1998 and has worked on IBM Team Workplace and IBM Workplace Collaboration Services since its pre-release. Prior to IBM, he worked at Wang for 10 years on document management, workflow, and imaging related products. In their spare time, Miki and his wife Rita enjoy parenting their two children.

Summary:  This article examines how people typically work together and interact to achieve their goals, and discusses how IBM Workplace Collaboration Services can help streamline this process and make users more efficient.

Date:  10 May 2005
Level:  Intermediate

Activity:  2536 views
Comments:  

IBM Workplace Collaboration Services 2.5 provides an open, extensible way to add collaborative activities to both existing and new applications. In addition to "out of the box" capabilities such as messaging, calendars, Web conferences, team spaces, and chat, Workplace Collaboration Services helps developers extend the platform to link organizational business processes to the actual methods that people use to accomplish their tasks. This "collaboration in context" allows organizations to optimize processes that involve collaboration among co-workers.

This article examines patterns associated with collaborative activities, with an eye towards demonstrating how these patterns are codified in IBM Workplace Collaboration Services. We’ll then look at ways to add collaboration to an existing application, using an example customer support system. The first part of the article takes you through the concepts and definitions of collaboration in context, while the second half looks at their actual usage within the product.

Business processes and collaboration

All organizations implement processes to carry out their business. Some of these are more formal than others, depending on factors such as the size of the business and the complexity of the work. But whether you are a small business re-ordering supplies or a large organization doing order fulfillment in a warehouse, business processes comprise the day-to-day tasks performed by people in your organization.

Let’s look at a typical business process. In very simple terms, this consists of a starting point, several sequential activities, and an endpoint. A process description such as this describes what needs to be done in what order, but it leaves open the question: how are these activities done? People typically use a variety of collaborative tools -- email, instant messaging, telephone, teamrooms, e-meetings -- to accomplish a task described in the activity. In fact, they are likely to use more than one tool and often apply different combinations to the same task at different times. That’s how people usually work, and up until now software was not always designed to help them. So quite often they ended up working around it.


Our customer support scenario

The example scenario that we will examine in this article involves something central to all of our businesses: customers. In this case, a hypothetical business wants to optimize its response to customer queries. The faster they can respond, the more satisfied the customer will be. Additionally, the more efficient the organization becomes, the less expensive it is to handle customer inquiries.

In its basic form, this customer support process might look something like Figure 1:


Figure 1. Customer support process
Customer support process

In Figure 1, an incident is opened based on a customer query. It can be escalated if not handled immediately by the first line, and finally a response is returned to the customer and the incident is closed.

If you look at how each step in the process is actually accomplished, you might have the customer support representatives bringing in other team members, calling meetings and phone conferences, using email to send notifications, and opening discussion topics related to the incident. The process might look pretty straightforward to a business analyst, but getting it done most often involves other people, outside information, and collaboration.

Of course, this type of effort presents several challenges:

  • Users must maintain context in their heads as to what collaborative content is associated with the activity they are engaged in, and with which people they collaborated. The support representative needs to know that the two emails, one document, and three e-meetings they had are part of the same Escalate activity.
  • Users must de-focus as they switch between applications supporting the business process and collaboration tools, as each provides its own user experience. This exposes inefficiencies in the methods used to complete the process.
  • Collaborative content remains dispersed in the organization and disassociated from the business process that generated the collaborations in the first place. Customer information and incidents are stored in one system, and other related content is stored somewhere else, making it hard to search and relate to each other.
  • What can we identify as possible areas of optimization?

One way to address these challenges is to ensure that the collaborative tools that people use are presented in the context of the activity they are doing. This prevents people from having to maintain the context in their heads and ensures that they are still focused on the task at hand. For example, how many times have you been filling out an expense report and gotten sidetracked in your email while looking up the applicable guidelines for your trip? Wouldn’t it be nice to have the appropriate email already available as soon as you specified that the expense report is for a particular event? One excellent example is provided by the Notes 6.5 client whereby all people involved in an email thread are dynamically added to your instant messaging contact list and grouped under that thread’s subject line. It creates an instant messaging group in the context of the email thread.

Another way is to capture the contents of the collaboration that takes place and to associate this captured content with the activity. This allows that content to be referenced later while reviewing the activity that took place. This way you could attach all related emails, documents, and chats to the expense report itself. Many times we find ourselves spending time searching for emails that were exchanged on a topic that often is defined by a business activity that took place, whether it’s an expense report, a purchase order, or an employee candidate interview. A third way allows business processes to be enhanced by using collaborative tools that are available to accomplish that process. In the case of a customer support system, when someone reviews an open incident, it is better to be given a list of all people that were previously involved with the case, as well as all saved chats and documents related to that particular query. In this example, the system guides the user to instant messaging to have chat sessions that are saved with the incident, creating an optimal way to collect information for analysis and later re-use.


Working with business objects

Collaboration in context integrates collaborative tools, content, and users with an established business process. Integration takes place in the user interface and the data model. Let’s look at how it all breaks down, so we can put it back together later with help from IBM Workplace Collaboration Services.

The first concept to understand is the "domain object." A domain object is an item you are working with in a business process. Every business process contains domain objects. For example, a customer relationship management process contains the following related objects: marketing campaign, customer account, contracts, service request, and partner. A human resources system contains employees and resumes; a procurement application might have vendors, purchase orders, and products. A typical software development process includes requirements, code, defects, and builds.

The domain object is the item that the user interacts with to complete the process. In our customer support scenario, the domain object is the incident that the customer opens with the support representative. When the incident needs to be worked on, there might be emails, meetings, and chats going on with various members of the organization. The account representative may have to get involved, as well as experts on the topic at hand.

Figure 2 shows what this could look like:


Figure 2. Domain object Incident with collaborative tools and people
Domain object Incident with collaborative tools and people

The domain object (Incident) is surrounded by collaborative activity. The different colored icons represent the different people who could be called in on the incident, including the account manager, the product manager, and the support representative. As the incident progresses toward resolution, we add more activity and more people can become involved. There could be documents created and online discussions held by the group working on the incident (see Figure 3).

How do we handle these ad hoc interactions, secure them, and provide a flexible method for applying access rules? That is where the role-based community comes into play. If you abstract the people away from the collaboration tools and the domain object, and give them a label, then you have a role-based community, as illustrated in the upper-left corner of Figure 3. Now we are capturing the role of a user in a process, rather than the actual name of the person acting in that role.

Another benefit of using role-based communities is to provide flexible access to the tools that are available within a given situation. For example, you may want to allow all roles to add topics to a discussion forum, but only people in the support representative role to add new forums. Perhaps product managers are allowed to read documents, but not create them. Assigning roles to component privileges is called "community role-mapping." Figure 3 shows how all of this fits together:


Figure 3. Mapping community roles to component roles
Mapping community roles to component roles

The connections that exist between domain objects, the people, and the tools, comprise the collaborative context. In Figure 3, these are represented by the lines from the incident to the community, tasks, emails, meetings, chats, documents, and discussions. The context is the specific business activity: the task of responding to a customer query. When a domain object is used within a business process with a relationship to a collaborative context, it is called a collaborative domain object.

The concepts of domain objects, collaborative context, community roles, and collaborative domain objects are essential to solving the problems discussed previously concerning collaboration in context. They allow organizations to optimize the collaborative capabilities of their business processes. By enabling people to use collaborative tools in the context of business process activities, they maintain the user’s focus on the problem at hand. Tools can be presented directly to users while they are working on an activity, saving time and energy. The collaborative context helps the system capture people’s interactions as part of the activities performed, so they are visible to others and can be shared among the community. Finally, transparency into the real work behind a process helps people learn from previous activities how to best accomplish a current task.


Collaboration in context in action

The remainder of this article covers two examples of how these concepts work in IBM Workplace Collaboration Services 2.5. First, we’ll take a look at an IBM Workplace application template. The advantage of examining the patterns that occur within a business process is that software can be built to optimize those patterns for the user. This is exactly what the teams at IBM have done.

IBM Workplace applications

An IBM Workplace application encapsulates a business process, its roles, its collaboration tools, and its domain objects, into a reusable template. It is deployed into the Workplace environment and can be managed as a separate component in the system. For example, a Customer Support Escalation template can be created and reused for many such incidents, also known as critical situations. It can contain a discussion forum, community roles, and the incident itself. The template is a description of the application, somewhat similar to a food recipe. When it is instantiated, Workplace reads the recipe and recreates the application, providing the unique collaborative context that links everything together.


Figure 4. IBM Workplace Customer Support Escalation application
IBM Workplace Customer Support Escalation application

In the example shown in Figure 4, a particular incident has been escalated and needs to be worked on by a team of people. The incident details are contained in a portlet that accesses the customer support tracking system. In this simple example, the escalation contains one tool (the discussion component) and the list of people who are working on the escalation (the role-based community), contained in the membership portlet on the Members page (Figure 5):


Figure 5. Members page, showing role-based communities
Members page, showing role-based communities

The conceptual model of the application (Figure 6) shows a list of the critical situations that represent the escalations in the business process. The critical situation is the collaborative domain object because it has a collaborative context, which relates the group of related objects and people in the context of this particular process.


Figure 6. Conceptual model of an IBM Workplace application
Conceptual model of an IBM Workplace application

The important thing to note is that the collaborative context is held in the application itself. It is represented by a set of portal pages, the roles that are defined, and the domain objects that are presented in the template. The beauty of the system is that the developer (or user) doesn’t have to do anything specific to take advantage of these facilities -- they are built-in and available for use out of the box. The patterns that we discussed earlier in the article are a natural part of the environment, making it easy for both end users and developers to realize the inherent benefits.

Workplace Builder

Workplace Builder is a tool you can use to create application templates, using a browser-based editor. Only users with the proper policy defined in the administration tools are able to edit and create templates. Developers can export their template definitions into a file and import it into another server. Opening a template allows the user to work directly with the application, set up roles, and add components to it.

Adding a component to a page adds it into the collaborative context. All components and other portlets contained by the template are automatically linked to the community roles that are defined in the template. If you have created a custom component and implemented certain interfaces using the IBM Workplace API Toolkit, then that component can be smart about interacting with the template editor, providing roles and parameters to it, as well as creating its data storage.


Figure 7. Editing a template
Editing a template

To better understand role-based communities, it is helpful to look at the implementation in the application template editor. Figure 8 illustrates the process of creating a new role in the template.


Figure 8. Creating a new role
Creating a new role

The role has a name (in this case Support Rep) which will show up in the membership portlet (Figure 5). After that, the main task is mapping the role to the domain objects’ access privileges contained in the template. So, for example, the Support Rep role can have User access to the discussion component and Author access to the issues component. This is what we call community role-mapping. A user will inherit those privileges by being placed in the Support Rep role.

There are other features of the Workplace Builder tools, but the subset covered here are directly related to the collaboration in context topic. See the Resources section at the end of this article for more information about Workplace Builder.

"Collaboration extended" applications

Every organization has existing applications on which they rely. As we have seen, the actual way that people work often includes collaborative activities and objects. A "collaboration extended" application is simply an existing application enhanced with collaborative tools, content, and people.

For example, imagine that an organization already has a customer database and a process for tracking customer incidents. Figure 9 illustrates this application. The application uses portlet wiring to associate a customer ID to the incidents database. It provides "on the glass" integration of two disparate applications. When the customer detail view loads onto the page, the customer ID is automatically passed to the incidents portlet, which then displays the list of open incidents for the customer.


Figure 9. Customer incident tracking application without collaboration
Customer incident tracking application without collaboration

Using IBM Workplace Collaboration Services, a community and other collaborative tools can be added, optimizing the process and capturing the ad hoc information exchange that so often occurs in collaboration. Figure 10 shows the sample customer support application extended with collaboration. The customer portlet is accessing an existing customer database. The incidents portlet has pulled up a list of incidents for the selected customer and one incident is being viewed. This particular incident, number 966, has a collaborative context and community associated with it. These are displayed at the bottom of the page. You can relate the external application to the collaborative context by using the incident ID as a key. The portal displays the relevant information on the page in each portlet through portlet wiring, dynamically passing information from one portlet to another at runtime.


Figure 10. Customer incident tracking application with collaboration added
Customer incident tracking application with collaboration added

The conceptual model for this is very similar to the previous model for an IBM Workplace application:


Figure 11. Collaboration extended application conceptual model
Customer incident tracking application with collaboration added

In this case, there is an existing database, or catalog of incidents. These are the domain objects at this point in the business process. When an incident is viewed, it passes its ID number to the collaborative context. The collaborative context relates the domain object to the community and other tools. The difference with this model is that you're working with a domain object that already exists, not creating a new one like the critical situation object.


Conclusion

Collaboration in context is central to IBM Workplace Collaboration Services. It allows you to optimize the collaborative capabilities of your business processes. The concepts we have presented in this article apply both to new business situations that warrant a new application and to existing applications. By understanding the model, you can build new collaborative tools or use the ones that IBM gives you and easily integrate them into your own business practices. By maintaining the context of a user’s activity, the application can present tools and people related to the activity. And by associating a collaborative activity with a process, all of the activity can be captured, stored, shared, and retrieved. Taken together, organizational efficiencies are realized.


Resources

About the authors

Chris Reckling is Senior Product Manager for IBM Workplace Application Development tools and technologies.

Sami Shalabi is a Senior Software Engineer with the IBM Workplace server team, based in Westford, Massachusetts. He is the lead architect of the collaborative application infrastructure and has been with Lotus/IBM since the late 1990's. Previous to Lotus Workplace, Sami has worked on both Lotus QuickPlace and Lotus Domino. Sami holds both a Bachelors and Masters degrees in Electrical Engineering and Computer Science from MIT.

Mustansir (Miki) Banatwala, Senior Software Engineer, joined IBM in 1998 and has worked on IBM Team Workplace and IBM Workplace Collaboration Services since its pre-release. Prior to IBM, he worked at Wang for 10 years on document management, workflow, and imaging related products. In their spare time, Miki and his wife Rita enjoy parenting their two children.

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.


Report abuse help

Report abuse

Report abuse submission failed. Please try again later.


developerWorks: Sign in


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


Rate this article

Comments

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Lotus
ArticleID=82847
ArticleTitle=Collaboration in context with IBM Workplace Collaboration Services 2.5
publish-date=05102005
author1-email=chris_reckling@us.ibm.com
author1-email-cc=
author2-email=shalabi@us.ibm.com
author2-email-cc=
author3-email=banatwal@us.ibm.com
author3-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.

For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Special offers