Business Collaboration is something that people do as a group. There are no limitations to size. The group could consist of members of a department, cross-department, cross-enterprise within a territory or theater, or truly global in terms of members, where they come from and the range of their specialties. Collaboration must have a purpose- an end goal; to that extent I consider collaboration to be a group activity for making the best informed decision and communicating that decision to stakeholders. The decision could be as simple as where to host the holiday party (not that that’s really simple) to as complex as deciding business strategy that affects the company’s future.
What is collaboration architecture then? Since collaboration is goal-oriented it naturally involves business processes and/or workflow, which are ideally driven by solid business architecture, but collaboration capabilities are enabled by a combination of collaboration services and communication services. The collaboration services are provided by a set of tools and applications such as; wikis, blogs, calendaring, e-mail, instant messaging, document repository, desktop sharing, the list goes on and on. The communications services are powered by the foundation of; network transport, signaling, voice and video, quality of service, transcoding/transrating, policy, federation, management and more.
The Cisco Collaboration Architecture is a model that combines collaboration applications and communication services to articulate Cisco’s capabilities and offerings. The communication platform is represented by a set of layers that provide capabilities from network services to medianet services to collaboration services to client services that expose communications functionality to the collaboration platform and ultimately end-user devices. If you haven’t clicked on the image to launch the interactive flash I recommend you do. It’s a cool tool to see what the different building blocks of the architecture are and what products, solutions, demos and developer resources fit in each of those building blocks.
While every “collaboration vendor” will strive to be the “one-stop shop” the scope of collaboration is too extensive, it’s more important to allow collaboration assets from multiple vendors to be plugged into a shared framework or communications platform. The question then becomes; should the communications platform be network-based, server-based or a hybrid? A few years ago, I would have said the network should be transport only, but after looking at the capabilities of the network, I can see where the network becomes the communications platform that applications use common services from to support collaboration enabled business processes that transcend organization and enterprise silos. The beauty of common services is all applications can access and consume them thereby standardizing key functionality and breaking communication silos.
Expect more on the concept of a network-based communications platform as part of the collaboration architecture. What considerations have you given to your collaboration architecture? What considerations have you given to a communications and/or collaboration platform? What core common services would you gain the most benefit from? Take a look at the interactive flash and let me know your thoughts.
****** Background Information about the Collaboration Architecture Blog Series ******
This blog is part of the Collaboration Architecture Blog series. View the brief video below to find out what this blog series is, and why you should read, subscribe, and post your feedback. View all posts in this series.
Posts to the Collaboration Architecture Blog are made at least once a month. Subscribe via RSS feed so you don't miss the next one.