I am currently heading up a project to build an enterprise blogging solution at one of the big-4 consulting firms. There are over 100,000 people in the firm. For a future Web Office solution, here's what I need:

1 - Tools to Define Types of Blogs

On the net, some of the most successful blogs are tightly defined. For internal enterprise blogs, that translates into a limited group of types of blogs, of which there will be many instances of each type. Examples include Bio Blogs, Client Blogs, Project Blogs, Product Blogs, and more free wheeling Expert Page Blogs. If a company has 100,000 people working for it, expect to see 100,000 different Bio Blogs. Defining a blog type means describing how it looks (CSS) and how the blog is organized and works with data. With SixApart's MovableType, this would mean defining the collection of templates included with this specific Blog Type. The Blog Type Definition would also need to include the list of Plug-ins needed to run that Blog. Finally, the Blog Type Definition will need to be paired with tools to capture and track each instance of the Blog Type. A company will need a list of the 100,000 Bio Blogs.

2 - Tools to Auto Generation an Instance of each Type of Blog

A company with 100,000 people needs to have a tool that quickly and easily walks their employees through the process of setting up a Bio Blog or a Client Blog or a Product Blog. Take a look at the sign-up process for Blogger or TypePad to get an idea of what I mean. A true Web Office Solution will give me the tools to quickly specify this.

3 - Tools to Capture Data as the Web Office Blogs are Being Used

This is the most powerful concept so far. It is based upon a simple principle:

Web Office Technology needs to add value to what people are doing anyway

Put more technically, Web Office Technology needs to add value by capturing data from existing and inevitable work-flows.

One practical way to accomplish this is to define semantic or meta XML pages that sit behind each blog. These XML files would represent a data store of the thing that the blog is about. For a Bio Blog, the XML would be a kind of HR data store, keeping track of things like what projects that employee was working on, who they reported to, who reported to them and their contact information. The XML Page Behind could also act as a loosely coupled interface to the blog. For example, if someone was added to a project, the act of adding them to the project blog could track back to the XML Page Behind. This information could them be built into the Bio Blog in a myriad of different ways. A mechanism for making this happen cleanly needs to be built into the ideal Web Office solution

Another practical way to add value during the course of existing work would be to define a directory for each type of Blog. The directory for Bio Pages could keep track of two simple things: all the Bios and the associated ping URLs for the track back mechanism described above.

These XML pages and the associated directories are the beginnings of an API to all the content being generated. For example, the XML pages behind a simple BIO Blog can be used in HR applications. Change who someone reports to in a BIO Blog and it could update the HR system, keeping the whole company's org-charts live and up to date. Add someone to a project blog, and it updates a project tracking application through RSS.

4 - A single GUI and Workflow for all text Content Creation

Check out Zimbra. The ideal Web Office solution will enable users to use that single interface to generate all email, blog and Wiki entries. This means less to learn.

The same email / blog / wiki GUI should be able to useful as a replacement for most Word Processing that is done today. See my AJAX killed the Word Processor for more explanation. The main thing that the ideal Web Office solution needs here is a

5 - Voice / Screen Video capture and post

Build a presentation using Web version of PowerPoint, such as S5 Presents. Then, convert it into a Flash presentation, or a QuickTime movie complete with your voice over. This combines all the power of blogging with the personal human contact and emotion possible with voicemail. Adobe / Macromedia have something can do this. It's one of the minor features of Breeze. A more straightforward version is available from Wondershare - it's called SameShow. If this functionality has to be done with a local fat-app in the short, so be it, but it has to integrate with the spirit of the single GUI mentioned above. That means it has to have the same access control definition functionality, the same ability to capture history and allow for changes.

6 - IP Telephony Integration

We want to be able to record a conference call and forward the recording to the project blog. Maybe that means that the project blog has a voicemail inbox. Maybe that means sending the recording as an email to the chairperson, who can then forward the email to the blog for posting.

7 - Integrated Internal / External RSS reader - Web or Email

With everyone in the company publishing content, an RSS reader that can easily integrate both internal and external RSS feeds is critical. The people I have talked to like My Yahoo for it's newspaper like feel. The reader will have to seamlessly integrate with content access control restrictions. If users have access to a restricted piece of content, they should only be see the content without being required to enter their ID and password many times over.

8 - Mobile Integration

For the most part, this isn't nearly as hard as it sounds. Most Blogs and Wikis can accept and convert emails into posts. Additional features that might be useful would include integrated GPS information, including location and time stamping on camera phone photos - although those features would have fairly limited applications.

A Riya style face recognition system integrated with your cell phone's camera to help you remember a co-worker's name would be useful, but it also might be fairly big-brother scary. Not sure if it would raise to the level of "being evil", but it might get close.

9 - Democratic Access Control - LDAP for Everyone

The folks at Microsoft who designed Active Directory assumed that, while a company might need many groups and many roles, the company would only need a few "administrators" to determine who belonged to which group.

This kind of power needs to be totally democratized in a full blown Web Office solution. If I start a new Project blog, I need to be able to set it up so that only specific people and people with the title of "Senior Manager" can see the blog.

Some Open-Source advocate out there might argue that any restriction is not going to support innovation. While many people in many companies seem to control access to information too much, there are certain instances where access control is going to be required. For example, if a hospital started to use Web Office technology and had internal patient blogs, it would make sense that only appropriate medical staff could have access to the blog for a particular patient. The same is true for banks protecting financial information.

I should note that SocialText does have this kind of control already build into their Wiki application.

10 - The Web Office Solution needs to be Tools Centric

I have said this in an earlier post entitled: "Don't Automate - Build Tools."

One of the basic tenants of the Read/Write Web, or Web 2.0, is the empowerment of knowledge workers. The idea is simple. Give people the tools to build their own knowledge distribution solutions. Blogger or TypePad let anyone efficiently and easily communicate with the world.

This might be a philosophical approach to Web Office / Applied Web 2.0, more than a requirement, but it will define the difference between a system that is successful, and a replication of the many failures that have littered the road to collaboration knowledge sharing Nirvana.

If your IT people start asking questions like "What is your process?", you know they have not understood this point.

Backpack is a great example of a tools centric Web Office solution.

Practically, in the case of Blogs, this will mean that users will need to be able to create non-content types of posts. For example, they might want to post a list that can be ticked off over time. They also might want to post a survey, or a simple calculation or analysis tool build in a spreadsheet interface.

The way that these tools get integrated into existing work-flows will be important. In MoveableType, for example, blog administrators can extend the blog's capabilities by using Plug-Ins. The Plug-In's are really powerful tools, and because it is relatively easy to write a customized plug-in, developers can add all sorts of functionality to a MoveableType blog.

The problem with MoveableType's Plug-Ins, however, is that they are only usable by the people who administer the blog. Most corporate users will be able to write a blog entry, but they will not be willing to even learn what an HTML tag is. Hence the need, mentioned above, for a Zimbra or Gmail style GUI. Within this GUI, just as there are Bold, Italics and HREF buttons today, the ideal Web Office solution will need to allow for additional tools that facilitate a WYSIWYG drop in of other tools, like lists, pictures, maps, spreadsheet based analysis tools and surveys.

Plug-ins will need to be targeted at the end user, not the blog administrator

11 - Web Office will benefit from integrated social networking - such as LinkedIn

When are the folks at LinkedIn going to create an open API to their system? You would have thought that they would have learnt from the success of SalesForce or Google's map API.

People connections are going to be as important to the successful of a business using Web Office / Web 2.0 technologies as they are to any company today. Technology can only help by helping us to better leverage who we know.

To that end, an integration with something like LinkedIn is critical. It is important to understand that this has to be provided by a 3rd party service. It does no real good for each company to try and build its own version of this kind of business focused social networking service.

For more details, see my article entitled: LinkedIn is Web Office Technology

12 - Enterprise Digg

Even if your boss hates your idea, if 200 people in the company digg your idea, the CEO has to pay attention.

To learn more about this requirement, see my article entitle: Enterprise Digg

13 - External Feed and Service Integration

One of the main promises of Web 2.0 powered Web Office solutions is that companies will be able to bolt together many internal and external services. Some of the services will have to be provided outside the firewall. LinkedIn provides one of these types of services that can never possibly be brought within the firewall. What good is it to me if it only links me with people within my company?

Some feeds and services will be easy to integrate. The security risk they represent is scarcely different from surfing a web site. Others will not be so trivial.

No doubt, large companies like Microsoft will try to solve this issue by providing a platform that everyone else can sit upon.

I think that this is the wrong approach, because not everyone will want to jump on the Microsoft service authentication platform. A Web 2.0 Service Authentication platform would encrypt the service request, validate the service user and validate the service provider.

There are two alternatives. The first would be to have each company negotiate individual contracts with each vendor. So, if a big software vendor wanted an official group on LinkedIn and greasemonkey plugin that shows how everyone on the net is Linked to their sales staff, the software company would have to negotiate directly with LinkedIn.

The second alternative would be some kind of standard. I'll try and write more on this at a later date.

14 - Flexible Folksonomy Powered Internal Search and Tagging

Internal knowledge management used to begin with a group of arrogant people sitting in a room and defining the taxonomy of all information that would ever be stored in the knowledge management solution. In order for the internal search engine to work, everyone in the company would have to learn the taxonomy, and stick to it rigidly. Old internal search engines were provided my companies like Verity. If you want to see how well all of this worked, take a look at how how poorly Verity's stock has performed compared to, say, Google.

Search is one of the most critical tools that justifies the move to Web Office technology. Efficient innovation is the other.

If internal search is going to allow for innovation, the Web Office search tools most not require any participation from the users. As far as I can tell, only Enterprise Google understands this so far.

To make an Enterprise Google work, the Web Office solution needs to automate the cross linking process as much as possible. Add someone to a Project Blog, and, through the loosely coupled track-back process described above, a link should be added to that person's Bio Blog. The link on the Bio Blog should link to the project. Repeated through out the system, this will speed the development of the kinds of HTML cross links that help Google produce relevant search results.

Requiring no participation from users on the one hand is important, but the system should also provide lots of ways to leverage simple participation from users. An enterprise version of Del.icio.us' social bookmarking would add a great deal of value. As would an enterprise version of Technorati. Both tools add value to existing information.

15 - Everything in Web Office must have an API

The day that people really began to understand the potential of what is now called Web 2.0 occurred when Paul Rademacher released Housingmaps, his Google Maps / Craigslist mash-up.

The ideal Web Office solution will figure out how to put an API on every piece of information that is entered into the system.

Maybe you want to see every post that mentions a client and was written by a given person.

Maybe you want to map where people post from.

Maybe you want to chart when popular / useful posts are written, or who writes them.

Maybe you want to build a Interest Rate Swap pricer in Excel, post it to a site, and have other people in the company integrate the prices into their presentations.

Every new tool, and every piece of functionality should be bolted in with an open API, or at least an internally open API.

Paul Rademacher proves that you have no idea what people are going to do with your tool, but you know that with great Web Office technology, every knowledge worker can be turned into an Innovation Creator, and every Innovation Creator is capable of potentially building the next great tool within your company.

Diggable