Lucy Tesseras, writes, “Supply chain collaboration has long been talked about as the next big thing, yet more often than not it remains a boardroom discussion rather than an operational reality.” [“Dangerous to ignore it,” Supply Chain Standard, 1 October 2011] That’s why I indicated my interest when Javier Perez, a publicist for Ray Schwemmer and Rick Havrilla, authors of the book Dynamic Collaboration, contacted me to about reviewing the book. The book focuses primarily on internal corporate collaboration, not supply chain collaboration; but, many of the principles discussed by Schwemmer and Havrilla apply to any collaborative endeavor. Schwemmer and Havrilla, CEO and CTO, respectively, and co-founders of CollabraSpace, obviously hope to generate some business leads from their book; but, that doesn’t mean it should be dismissed as a mere marketing ploy.

The book begins with a statement that underpins what is to follow. The authors’ state that “collaboration is crucial for any organization that wants to be productive, adaptable, and creative. … People solve problems they wouldn’t otherwise have solved, get work done quicker than ever before, and feel connected because they are working together toward a common goal.” At least, that’s ideal goal of collaboration. The authors admit that the ideal is seldom achieved. One of the first concepts they introduce is the antithesis of collaboration — information stovepipes. “Stovepipe” is a term more commonly heard in the military than in business circles. In the commercial world, you more often read about silos than stovepipes. Whether you call them stovepipes or silos, they represent the same challenges for businesses. Stovepiped organizations, write Schwemmer and Havrilla, can’t “integrate with or share data or resources with other applications.” They conclude, “The organizational stovepipe is now a concept of the past, overcome by the increasing complexity of the digital age.” On the other hand, “collaboration and the technologies that facilitate it can solve problems at every level of the organization.”

Schwemmer and Havrilla agree with David Coleman and Stewart Levine, authors of Collaboration 2.0, that “if the collaboration strategy in the enterprise is left up to technology people, then technology is what you get. Often these ‘solutions’ don’t solve the real problem, and as a result they are often left unused or abandoned by the business units for which they were developed or purchased.” Much of Schwemmer’s and Havrilla’s book tells you how to implement collaborative systems that are going to be used because they leverage venues already in play. “When people already have data and a history in a particular environment,” they write, “asking them to suddenly start using a different tool isn’t just an inconvenience, it’s a threat to their existing knowledge.” This is the kind common sense observations that make the book a valuable resource to anyone thinking about establishing a corporate collaborative environment.

The approach they recommend is one that integrates collaborative tools with “what’s already there so that the transition between working independently and working collaboratively is seamless.” This should be true whether you’re talking about intra-organizational collaboration or inter-organizational collaboration. The next subject they address — secure information sharing — is also important regardless of whether you’re talking about intra- or inter-organizational collaboration. They write:

“People in the business world tend to want three key features in a collaborative system. First, it must be secure — in the sense that data is in the company’s enterprise data store, and the product uses encryption technologies to protect the confidentiality of the data while in transit and possible while at rest. Second, it must be fully integrated within the presentation layer of corporate applications. Finally, it must be an enterprise solution, meaning that it is supported by the IT department and leverages the other software services within the IT infrastructure.”

They discuss each of those features in some detail. Once the security issue is dealt with, Schwemmer and Havrilla conclude that collaborative tools must be horizontal applications that can be “embedded into tools already being used within the enterprise.” That conclusion segues into their next subject — how to plug collaboration solutions into your existing architecture. They agree with structural architects who claim that form must follow function. The authors don’t minimize, however, the challenges associated with adapting IT architectures. They write, “Creating an IT infrastructure is an ever-evolving job. New needs arise within an organization constantly, and almost as quickly, new technologies arise to meet those needs.” With each change and new technology, questions arise about how they can be integrated into a collaborative network. Good solutions, they insist, will have four characteristics: simplicity, flexibility and maintainability, reusability, and decoupling of functionality and technology. They discuss why a service-oriented architecture can accommodate each of these characteristics. When it comes to collaboration technologies, they conclude:

“When we talk about architecting a secure enterprise collaborative capability, we mean building it into a framework you already have in place. That might sound like a huge investment of time and money, but the service-oriented architecture approach is actually about minimizing the costs of integration.”

Schwemmer and Havrilla make clear, however, that collaboration is not just about technology. They reiterate:

“After all, ‘collaboration’ can’t be defined as any single thing. It happens in a phone call, a meeting, a brainstorming session, and so on. And ‘collaboration technology’ includes any number of components as well, from presence awareness to instant messaging and from shared whiteboards to new friend recommendations.”

They believe, “When you start to think about collaboration as a series of components rather than one large application, you can more easily see how it can integrate into your architecture.” I believe that is true whether you’re talking about intra- or inter-organizational collaboration. That’s why they recommend being cautious about accepting a “solution” from a vendor who wants to sell you a suite of products. Chances the vendor’s products will integrate well, but they may not integrate as seamlessly with other applications. They conclude, “You need collaborative capabilities that will run in anyone’s portal.”

To help get executives’ minds around this concept, they recommend thinking about collaboration as service rather than a product. After taking readers on what they call a “philosophical journey,” Schwemmer and Havrilla get down to specifics. If you are looking to establish a corporate collaborative environment, it’s the specifics to which you want to pay attention. As they say, the devil is always in the details. However, don’t ignore the philosophical journey; it establishes the backdrop against which you will judge the specifics. Schwemmer and Havrilla recommend some steps that they believe will jump-start the installation process. They are:

• Eliminate the barrier to entry for the user community.
• Take an inventory of the web applications most widely used by your organization.
• Decide which collaborative capabilities should be integrated into which applications.
• Incorporate collaboration at a deeper level.
• Work with individual users to determine how the collaborative capabilities they need can best fit into their specific web applications.
• Achieve advanced integration using the application programming interface (API).

They go into detail about each of these individual steps. Architected correctly, Schwemmer and Havrilla assert that a collaborative solution will help eliminate corporate stovepipes. Because so much is being written about the importance of social media, they dedicate an entire chapter to that subject. That chapter is followed by one about building richer “knowledge bases.” They write:

“You’ve heard the term ‘knowledge base’ before, but just like ‘social networking,’ it’s a broad concept. Most organizations are conscious of the need to establish a knowledge base and are actively engaged in doing so. Examples of knowledge bases include document repositories, file sharing sites, websites, and wiki pages, to name a few. The wired world has made it possible to generate exponentially more information than ever before, and that means that organizations are dealing with unquantifiable amounts of data.”

Nowadays you read about so-called “big data.” That is exactly what Schwemmer and Havrilla are talking about. They point out that big data is of no value if it can’t be mined and analyzed. They conclude, therefore, “The key is to start thinking of any collaborative interaction as a part of your knowledge base. … The richer the knowledge base, the better the connections your collaborative software can make.” Schwemmer and Havrilla also address the topic of information overload. Technology can help prevent that by presenting only relevant data to users. They conclude:

“The idea behind enterprise knowledge bases is that rather than running a hundred queries with every possible data set to find the answer you’re looking for, you can enter one query and search everything, from decades-old documents to chats happening in real time as you type.”

Since security tops the list of everyone’s concerns about collaboration and data sharing, they dedicate an excellent chapter to the subject. Then they write a little about new directions in collaboration and conclude with a chapter on the future of collaboration. Anyone contemplating implementing an organization-wide collaboration tool would do well to invest the money and spend the time reading this book. It’s an excellent primer on collaboration, networks, and complexities that surround secure information sharing. I suspect that most organizations want to see how well collaboration works internally before they tackle significant external collaboration. In the supply chain world, however, laggards could lose. If you want to improve your collaboration with others, the challenges and principles discussed by Schwemmer and Havrilla can be applied to both internal and external collaboration.