iQuest Studios

Hey,
Tomorrow is the deadline for submission of entries to blog4biz.sg. So tonight I finished off my last entry to that competition, in hope of winning something for myself. I realised I have pretty much written out of point - they were asking us to discuss social computing tools as intra-organization collaborative tools, while I was pretty much writing about how social computing tools WILL NOT work in the intra organization environment. Never mind, rejecting the idea still falls under the very wide definition of “discussion”.

Anyway, below is my essay, titled “The Winning Solution”. It is a bit long, and some points may seem a bit abrupt, but please remember that the essay took me 3 whole days to write, since I still got my End Of Years to study for, so my train of thoughts keep breaking off. Word Count: 2972 words, so I suggest you read it if you really got the time to.

What really will make a successful intra-business collaboration application?

Firstly, as you may have noticed from many of my posts, I have always placed great emphasis on the security of the system. This is also not groundless. In the competitive business world, where any advantage you have can bring you billions of dollars worth of profit, businesses will be searching for any edge over their competitors. Some may get desperate, and resort to illegal methods such as breaking into a rival cooperation’s IT infrastructure. Hence, without a solid security system in place to prevent against such attacks, a company can lose billions of dollars. Especially now that we are talking about a collaborative system, where ideas are shared across the server, winning ideas can be stolen by rival companies, developed and patented before you can do anything to stop them. You may discount this as paranoia, but in the corporate world, where everything runs on money, it is not unlikely at all. Hence a successful business system must start with having stringent security measures such as data encryption, firewalls, IP white-listing and constant updating of the server system to protect against any attacks by external users. This is simply not provided by Wikis or blogs, which does not even offer basic text encryption.

Allow me to elaborate a little on my point. Many users here have suggested the usage of corporate blogs, Wikis, social networking sites such as FaceBook, Second Life etc. I don’t really want to kill off these ideas, but the fact remains that such systems do not have the measures to fend off any attacks on the system. Should any attempt be made to break the system, I have no doubt at all that such systems will collapse almost immediately. Especially on the usage of external applications such as Facebook and Second Life, where the data is not actually transmitted on the company’s server, but instead passed around on public servers, where it can be intercepted easily. Moreover, blogs and Wikis are susceptible to Denial Of Service (DoS) attacks, and this can bring the entire IT infrastructure of the cooperation down, should the company not invest in server clusters and load balancing routers. Hence, such solutions are not really applicable in the corporate world unless businesses are willing to spend a few thousand dollars to improve these systems with at least a few security systems, in terms of both hardware and software.

Secondly, the business application needs to integrate tightly into the current IT infrastructure. I believe all major business will already have some form of IT infrastructure in place. Should a intra-business collaboration tool be used without tight integration into the company’s current IT system, it will be a major waste of time, energy and money. This is because there has to be separate training, development and maintenance costs. The staff may also not be familiar with the interface and this can cause lots of frustration, energy and time wasted. And in the business world, where a little time and energy can translate to millions of dollars, it can possibly mean the loss of a few million dollars in revenue. Hence, it is of vital importance that such a tool actually integrate well into the existing IT system.

So again, based on this criteria, Wikis, business blogs, and any other third party software face another disadvantage. Many companies have a network where the employees can login with their username and password to access the system files. However, this login system will be hard to integrate into any Wikis or blogs, and the companies definitely have to pay more to create a custom application to provide the bridge between the IT system in the company network and the Wiki or blog. When we are talking about third party applications or software, such as commonly used IM clients, integration will be even harder, as companies will have no physical access to the servers or any choice over how the database is designed. Hence, I would strongly advise against deploying Wikis, blogs or any third party application as an intra-business collaboration tool.

Another factor is the flexibility of such a system. In the fast changing world, the ability to keep up with the latest technology is vital to a cooperation’s survival. Without flexibility, businesses will no doubt field, especially in this globalized world. There is a saying which says that, with globalization, “it is no longer a game of the big eating the small, but a game of the fast overtaking the slow”. Therefore, such a collaboration system will have to be flexible and easily extendable, to keep pace with the ever changing models of research and development. Also, with different companies,R&D and operations protocol may differ greatly. Therefore, one common system cannot suffice for all the different cooperations.

Due to the popularity of Wikipedia, many fellow bloggers here have actually overestimated the power of Wikis. The success of Wikipedia itself does not show that Wikis are powerful collaboration tools. After all, Wikis are defined to be “a web application that allows users to add content, as on an Internet forum, but also allows anyone to edit the content.” as quoted from http://en.wikipedia.org/wiki/WIKI. One must also remember that the “pedia” of Wikipedia comes from the word “encyclopedia”. Therefore, the success of Wikipedia can only be accredited to the creativity of the Wiki application in sharing information, not collaborating on information.

Yes, some of you have suggested that we make use of the Wiki application to display and share information, such as project documents, and this can be automatically indexed by the Wiki’s built in search engine. However, this is just equivalent to storing text files made in Notepad on a file server. Wikis do not support advanced file formatting, which may be needed in some documents to bring emphasis to certain points. Powerpoint presentations also cannot be uploaded and viewed instantly without having to download them. However, as I have stated above, Wikis is good for displaying information and can be deployed for this function solely. However, this means that the company is wasting money and energy deploying and maintaining a separate system from its collaboration tool. It is just like an employee doing 1 part of the report on his office PC, another part on his home PC, another part on his co-worker’s PC and another part on a friend’s Mac, when everything can be done on a single laptop, and compatibility problems can be avoided by integrating the entire collaboration process. the Extra effort will also have to be put in by the Management to ensure that no abuse of the system takes place.

Also, these Wikis cannot be limited to the companies’ intranet. To allow for the most effective collaboration, the collaboration tool must be accessible 24/7 by project team members. Hence, it have to open to the public as employees will have a hard time accessing the company’s intranet after office hours, unless they are working overtime in the company. Hence, this makes the system very vulnerable to attacks.

As for blogs, its rising popularity is caused by the sudden influx of bloggers on the net within the past few years. Many cooperations therefore thought they could get on the band wagon, and be seen by consumers as “up-to-date” and technologically advanced. This is true to a certain extent, where blogs can be deployed by companies with the resources to keep their consumers updated on their products. Therefore, blogs actually act as a bridge for the companies to reach out to their existing clients and/or potential clients. However, blogs cannot be deployed as a collaboration tool as they do not serve this function. After all, the word “blog” is the short form for the phrase “Web Log”. Hence, blogs function as nothing much more than an online diary, except maybe with the ability for viewers to actually leave their comment. Otherwise, the basic function of blogs still remains as a diary. Ever since when has project team members collaborated on a single project by writing their ideas on a common diary? Log books, AFTER the product idea has reached a mature stage suitable for testing, is common, but as of what I know, diaries have never been used to collaborate on a project idea.

Some also mentioned the use of Facebook here. Yes, there may be lots of “apps” for Facebook, and truth be told, I am not a Facebook user, so I cannot be the best judge of how powerful Facebook really is. However, using it for a collaborative purpose definitely is not suitable. After all, it was designed to be a social networking site and not a business collaboration tool.

Due to the rising popularity of these applications (Second Life, Wikis, blogs, Facebook, Instant Messaging etc.), many people and even corporations have overestimated their power. In trying to catch the band wagon, they fail to examine the true purpose of the application and whether it will really suit their needs. The original purpose of these applications were all mainly designed for the personal user, but many businesses have actually overestimated the power, and deployed it in their work environment. The original intention of the application plays an crucial role in whether the application will be a successful collaboration tool or not in the end. It is just like trying to use a screwdriver to cook, just because many others make use of screwdrivers to repair stuff. Although certain parts of the applications may be useful, corporations must be careful of what applications they deploy, or else they will just end up with a patchwork of applications held together weakly by bridging applications. Hence, before corporations jump onto the social computing tools band wagon, perhaps it is best that they examine how well these tools will serve their needs in the next 5 years, otherwise they would just merely end up wasting energy and resources on something that does not work.

What I would suggest is a customized business collaboration tool that will really serve all of the organization’s needs for the next 10 to 20 years to come. In this tool, we can make use of the few more useful functions from these social computing tools, instead of deploying everything in a bid to create an effective collaborative environment.

Firstly, I would suggest developing a desktop application. This is because, even with the new Web technologies such as AJAX, a web application will never have the same type of responsiveness as a desktop application, even though the desktop application may be web based. The application should be designed in such a way that even without an active Internet connection into the company’s servers, the application can still perform some basic functions. This can be done by providing a file cache, copying files related to the project from servers using a passive internet connection while the Application is running. This ensures that the project member will have at least one version of the file even while he is not connected to the internet (which will probably be rare now days anyway).

For security, I would recommend a minimum of 128-bit data encryption on the client side, with extra security features such as a software based keyboard to prevent against key logging. On the server side, I would recommend firewalls to fend off any DoS (Denial of Service) attacks. Especially now that we are talking about a desktop application, we can include an unique signature to identify the application, hence preventing any DoS attack that takes place through the HTTP protocol. Also, I would recommend a load balancer and a server cluster, especially if the company is large and there are many project teams. With a server cluster and load balancers, the company can ensure that should one server unexpectedly go down, the progress of all of the projects will not come to a standstill. I would recommend at least a 100MBit/s connection for small medium companies with around 50-100 users and a 1Gigabit/s connection for a larger corporation with around 200-300 users. For extra security, I would recommend a remote backup external hard disk which creates an updated backup of project files every 15 minutes, with a full backup archived every week. This way, even if the entire server cluster crashed (which is highly unlikely), there will still be a file backup.

Now, on to the basic application design. Although I know that different corporations have different collaboration protocols, hence the need for the collaborative application to be customized, but, they should at least share some common application design.

First, there is a need for different levels of users. No point pretending that a single user level will suffice in the collaborative environment. User levels should be split into Overall Projects Manager, Project Leader and Project Members. Project members should be further broken down into different levels, if the levels are usually fixed (such as the list provided by ProjectGilli under his post “Intra-company communications for project managers”. This ensures that only the right people see what they are supposed to see, instead of allowing for free-for-all access to all project files and documents (some of which may even be of a sensitive nature) on the project server.

Also, with the exception of the Overall Projects Manager, project members should only be able to access files that concerns the project. This will ensure the security of the entire system, and at the same time help keep the space used up by the file cache on the project member’s local hard disk to a minimum. File permissions, kind of like the file permissions on Unix based systems, should be setup for the project files. This way, we can ensure that should a certain project file needs to be shared across several project, all of the project members can access that file, and that file only.

The application should of course contain a search engine, with smart indexing that delves into the files’ contents, instead of just file names. This way, project members can search for relevant keywords inside the file, and not just the file name, which may not always be the most accurate way of describing the files’ content. The search engine should also index files on the user’s local hard drives, comparing it with that on the company server, preventing repeat search results and yet at the same time providing an alternative should a file go missing, or if the user chooses to work in an offline environment. The search engine should also automatically add tags to the document as it scans the file’s documents, making it easier to other users to search for the right document.

The ability for Wikis to link to other related files is perhaps one of the most useful features of Wikis. This should definitely be integrated into the system.

The application should also have a whiteboard like function, where the project members can scribble out project ideas, brain storm with fellow team members or just plain use it to de-stress a little. Mindmaps created through this method can then be saved on the company’s servers for further consideration in the future. This provides a means for quick, on the fly document creation, the same type of feature offered by blogs.

The application should also contain Instant Messaging features, with automatic creation of contact lists based on the project team. Of course I would strongly encourage encryption of the messages to provide an extra layer of security added to the 128/256 bit encryption that should be offered by the client. The application should also provide at least basic video conferencing features, to allow for even more effective collaboration.

Added to all of that, of course, one of the most important feature that such an application should have is ease of use and if possible, a beautiful interface. After all, the application is supposed to increase efficiency, not decrease it with extra technical support requests and time wasted while employees are still trying to adapt to the system. A nice looking interface will be an added bonus that will definitely go a long way in encouraging company employees in making full use of the collaboration tool.

Here, I have only provided a very sketchy framework on what basic features such a collaborative application should have. Again, it is supposed to a customized application, and different corporations may add to it or remove some features listed here if it feels that these features are redundant.

Of course, the price of deploying such a system will not come cheap. However, by looking at the long term effects, I would definitely say that such a system will be worth the money. After all, it will also not cost a lot of money as compared to deploying Wikis or corporate blogs. Even with those Wikis and blogs, companies will have to pay to purchase servers, and even server clusters if it is a large enterprise, and other security software such as firewalls etc. So pretty much the extra cost of deploying such an application will only come from the money paid to developers for them to develop this customized application. It is just like paying extra for a designer suit that is specially tailored as compared to just buying any plain old shirt on the street.

In conclusion, although social computing tools are the “in” thing now, companies should not blindly jump on the band wagon and go with something that will not last in the long term. Instead, companies should access its needs, both short term and long term, and create a customized collaborative application that will last for at least 10 to 20 years.

Anyway, that was just my attempt to get the prize (a MacBook for first, a Nokia E90 as second). Just hope that I do win something.

Till next time,
cheers