We have heard of web 2.0 with enough explanations “I think Web 2.0 is…” Even though there is no crystal clear definition that everyone agrees upon at least now we are used to this term and we hear a few jargons around it and look at a site and say “Oh yeah, a Web 2.0 site..”. Whether we agree upon those jargons as part of web 2.0 or not one must definitely admit that one of the aspects of web 2.0 being effective user participation. An increased user participation makes a site really powerful as the data needed to power the site comes for free and in abundance without any stopping. This culture has tremendously picked up and applications of all sort is coming up that is typically run by user’s data. Enterprise 2.0 is another phenomenon that pops up then and there if not as frequent as Web 2.0. Nevertheless it is matter of time this word is going to become a common term too. While I am not interested in trying to define Enterprise 2.0, what I am interested is the user participation part of Web 2.0 that is going to be prevalent in Enterprise 2.0 as well. User participation in Web 2.0 translates to employee participation in Enterprise 2.0.

The difficulty in current enterprise environment is there are too many teams that work in silo. There is no single point of means to say what’s happening as a project irrespective of how many teams under different areas of project is working on. At one point or the other these teams have to meet the dependency of each other and when they get together there are always surprises because a team doesn’t know what or how the other team is operating on and if it will satisfy the dependency needs. Rather than working as silo teams, if each and every employee is able to participate and provide update on his/her activities at a central point that gets distributed to every other member then that gives an opportunity for constant communication and collaboration. Thus a set of tools that can help make the teams collaborate and work effectively within an organization is a must. One can argue that there are already tools that do this and in fact a simple solution would be to have a common storage space where each employee could put a document containing his/her status of work. But these are formal traditional approaches that have not been very effective because usually an employee is more bothered about his/her work and tends not to see what is happening around. What we need is an informal environment and a tool that can help in an effective collaboration. Take wiki as an example, there is no predefined rule or structure to building content in a wiki. Each and every user has the same set of rights and privileges as any other user and is free to add information and link to other areas as well. Another good tool might be to have an intranet blog for each project and make each member author of the blog, so that he/she can post the updates. An RSS feed reader could be used to distribute the new content to the entire project team automatically.

Does it mean that the teams should stop creating documents and other necessary artifacts related to a project? No not at all, what employee participation helps is to capture unstructured information that gets accrued on a day to day basis. This unstructured information is an important piece that can bring to notice something going wrong at an early stage and reduce major damages later. Take for example a developer running into an issue and troubleshooting or in a situation where he/she is stuck because of dependencies. How often does other members related to it get to know about it? Give him/her a template and ask him/her to write a document, do you think it would be effectively followed? I don’t think so. But if there is an informal environment where an employee can add content free without any structure it could be effective. A developer would be more than willing to write a post on how he/she fixed an issue or explaining the situation he/she is stuck rather than creating a document.

What will make such a culture reality is when there is an attitude shift and willingness to accept such a change and work towards building it. This is easily said than done as it is not possible with one or two employees doing it but the entire organization adapting to it. It may be late but it is the near future.

While there are many blog software’s as well as online blogging systems where users can register and start blogging right away, why another blogging system? Well Tumblr is like any other blogging system but makes it easy for starters and also for users who want to just blog a quote, a photo or a simple message clearly differentiating from a post where normally an article is expected. But Tumblr can still be used to write posts like any other blog. For starters and those who want to quickly share a message Tumblr is a right starting point.

Have you ever come across a situation where you have to test an application having features that require using email-id? Let’s say an user registration module that requires unique email id. One is you could use your personal email id, but that is one time and then you cannot use the same id. Another option would be to create different email-ids with one of the free service providers like gMail or Yahoo! mail. Think about the server space that would be wasted for creating these email ids used for temporary purpose.

Guerilla Mail would be handy in such a situation. It provides temporary email ids which require no registration and has an expiry time of 15 minutes. You can read and reply to the e-mails using the Guerilla Mail. In case you require more time in order to complete the task then, a link is provided which when clicked resets the timer.

Thanks to my friend Sowmya Ambiti who pointed me to this site.

Before the development starts and before the design is done for the project the technology stack for the system has to be clearly identified. While a simple programming language could be selected to complete the system and often that was how it was couple of decades back these days we are more into higher level of abstractions that allow us to focus on just the problem. For example to develop a web application one doesn’t need to write an application server that has to handle the request and response and many other low level functions. Imagine if we were still stuck with how the trend was couple of decades ago probably I wouldn’t be writing this blog post now.

OK the point is now we have lot of tools, technologies and frameworks (TTF - is not a known acronym but for the sake of this post) that we can one off use them and not worry about taking care of so many low level details. Because these TTF go through the same process as any other project would go through to make it free from critical errors. But a task that still remains is the selection of the tools, technologies and frameworks that will aid in effectively building the system. The selection not only includes if the TTF meets the specific needs of the system but also how it can integrate well with other TTF’s with not much friction. Before the TTF’s can be selected the primary language(s) under which these TTF’s would work is as well as important. This by itself should be thought through with some of the performance requirements of the system and most important the skill set available within the organization. The selection process of the TTF’s should include not any lesser than the following.

Meets good enough requirements - While logically one won’t select a TTF that doesn’t meet all of the requirements of a system be aware of TTF’s that can do more than what is needed. While selecting such a tool may not affect the behavior of a system but it could choke the environment loading what is not required. Trying to find a tool that meets the requirement exactly maybe difficult but look if the TTF provides a way to use only those components required through plug and play or load what is required.

Environment Support - A TTF is also a program and requires an underlying environment that supports it. The TTF should support the language or the operating environment under which the system is deployed. The important point is to look for the supported versions and also look at the release notes for the specific platform.

Integration - As I mentioned earlier if there are more than one TTF’s involved and if they have to talk to each other look for compatibility. If they operate under different environment then a middle tier that can help bridge the TTF’s maybe required or look if the TTF’s provide support to talk over the network in technology-agnostic language such as XML.

Cost - The budget allocated for project and how much of it can be spent for the TTF’s is an input here. While open source TTF’s has been blooming crazy for every known area, there are few areas where commercial ones still hold the upper hand. The cost comes into picture in such an instance. Also the support provided could vary depending on open source or commercial (again depending on the package if commercial) which by itself is a criterion (see next point).

Support - What type of support is available for a specific TTF? Look for community forums, developer forums, discussion boards and any other groups other than the support provided by the company if any.

Help documents - Look for the help document provided by the TTF and how extensive it is and how easy it is to refer, use it.

IDE (Integrated Development Environment) support - Does the TTF provide any plugins for the IDE (selection of IDE if one doesn’t exist for the organization by itself has to go through certain criteria’s) the development team would use.

Tests - These days some of the TTF’s bundle with certain tests that asserts the proper functioning of the TTF. Look if one is available for the TTF you are evaluating.

While it is not an exhaustive list and there could be additional checks pertaining to specific requirements the above are some of the points to look for. Said that the selection process by itself is not something systematic or has any formula to select or not select. Such a selection process requires some experience and insights either from experts who have gone through it or from the past experiences. Sometimes failures teach better lessons.