Creating backups of Folders with C#.NET

Zipping up folders for backup purposes with C# in .NET2 is painful. Using 3rd party libs is bulky. CodeProject and Geralrd Gibson Jr & Friends to the Rescue. And because regurgitation is useful for later retrieval, here is the "Silent Mode" code snippet that works for me:

internal void Backup()
{
  LogHelper.Info(String.Format("Backing up Folder to {0}...", Config.General.ApplicationDataDir));
  string backupFolder = String.Concat(Config.General.ApplicationDataDir,Config.General.DirectorySeparatorStr,"Backup");
  string backupZip = String.Concat(backupFolder,Config.General.DirectorySeparatorStr,"Backup_",DateTime.Now.ToFileTime(),".zip");
  if(!Directory.Exists(backupFolder)) Directory.CreateDirectory(backupFolder);
            
  byte[] emptyzip = new byte[]{80,75,5,6,0,0,0,0,0, 
                  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

  FileStream fs = File.Create(backupZip);
  fs.Write(emptyzip, 0, emptyzip.Length);
  fs.Flush();
  fs.Close();
  fs = null;

  //Copy a folder and its contents into the newly created zip file
  Shell32.ShellClass sc = new Shell32.ShellClass();
  Shell32.Folder SrcFlder = sc.NameSpace(Config.General.LocalRootPath);
  Shell32.Folder DestFlder = sc.NameSpace(backupZip); 
  //Shell32.FolderItems items = SrcFlder.Items();
  //1564 =
  //+ 4     Do not display a progress dialog box.
  //+ 16     Click "Yes to All" in any dialog box displayed.
  //+ 512     Do not confirm the creation of a new directory if the operation requires one to be created.
  //+ 1024 Do not display a user interface if an error occurs.
  DestFlder.CopyHere(SrcFlder, 1564);
}

Taking Baby Steps (part 3): Dashboards - A managerial love story

Overview
Part 2 of this series "Taking Baby Steps (part 2): Only one person reads my Blog and I've already won" discussed some ways in which posts to personal, work-related Blogs (aka Knowledge Bases) are relevant to our team-mates and managers. Additionally, techniques on targeting posts through use of Tags were also presented.

In this 3rd post, I will talk about Dashboards, what they're for and how to set them up.

The Basic Unit of Information about which people relate at work
Projects.

Just the "sweet spot", please
There is an inverse relationship between someone's social proximity (in a "Social Degrees of Separation" sense) and their

1. Tolerance for Irrelevant Information
   
2. Amount of time willingly spent extrapolating "important" information

That is, the farther apart two people are in a socio-professional environment, the smaller their overlap of interests. Let's say 70% of my time is dedicated to Project A and 30% to Project B. My colleague Bob also dedicates 30% of his time to Project B. What this means is that out of all the information and knowledge I deal with on a daily basis, only 30% of it is relevant to Bob and I only have 30% of my time available to share this information.

Furthermore, depending on the roles being played, it is important to understand which 30% of Project B Bob focuses on. If Bob is the Project Manager, odds are that the details of your application's algorithm beyond a statement that "it works" is not very relevant to Bob. Including Bob in day-to-day, back-and-forth conversation about algorithm optimizations negatively impacts Bobs productivity given his slice of the pie. This should not be interpreted as "Bob should be left in the dark for the other 70%". Rather:

• Amount of information sent through the pipe is important.
  
• Quality of information is very important
• Order of information is also important

Some elaboration. For example, most people skim through email until something of importance catches their eye. Then they will read around that which jumped out. This is an act of validation. The reader is Gauging and Confirming Level of Relevancy. As was stated earlier, we all have a threshold. Whether this is acknowledged or not, we all associate Quality of information relayed to us with the originator of the communication. We even have functionality built into our email clients to reward those sources of information that we believe to consistently relay High Quality information. People whose communications I wish to help penetrate through "my" noise get their own Mail Folder and a Rule. The Folder makes it into my Top 5 and so on. Rather than skimming I tend to read these communications "normally". High Quality/Highly Relevant information from the originator creates a level of Trust. Perhaps its a bit too cliche to claim that Trust allows for solid Feedback Loops. Rather, its very clear that a lack of Trust results in a well stocked Trash.

Ideally, communications to Bob are well targeted bringing the 30% of the project Bob is involved in to the forefront. (Bob thanks me for not wasting his time.)

A not so "Side Note". I really dislike emails that say "FYI" followed by a long thread of bracketed who-knows-what. Figuring out the part that is in fact For My Information will require me to skim not just one email, but all the accompanying threads. Cliff Notes at the top, please!

Information Trickle
Why do "executive" summaries exist everywhere but in our routine communications within our Social Networks? The "Cliff Notes" quip above actually deserves some discussion. Clues about content subject matter and how it pertains to "me" are very helpful because they grant me the opportunity to cash out sooner rather than later. Tags are great but not as great as a one-sentence summary that speaks right to my forehead. Descriptive titles/subjects also help a great deal!

Whether we skim, or jump back and forth as we consume written information, it is still done (for must of us) in a linear way. Pardon the nerdy analogy but this is like a Disk Head tracking back and forth over a Hard Drive. Meta information about files, directories etc in all File Systems is also at the "top". Search Engines construct indexes that pull out relevant information so that from then on the engine can gauge a match - "this data is relevant" - as quickly and efficiently as possible. There are many other examples of almost identical optimizations that happen in technology because we demand it. Somehow, similar optimizations fail to make it into routine meeting, emails, phone conversations, and so on. It would be nice to have that Trickle from High Level but High Quality information to Low Level details in all mediums of communication.

Dashboards are about creating this kind of Information Trickle for other forms of Project-related information.

Dashboards and RSS Feeds go hand in hand

My Dashboard at work contains the following:

• Tab 1: 20,000 feet -
  Idea here is to create that High-level but informative "At-A-Glance" View of team-wide activity. This High Level but High Quality landing page is relevant to anyone who may be interested in the activities of the team. For a manager 1 or more Social Degrees away, this is a good place to begin "dipping" into our "world" without being overwhelmed by all the details. For my team-mates, this Tab can serve as the Sync-Point for meeting agendas, follow-ups, Iteration refinement and so on. My team-mates will most likely want/need to drill deeper, the manager 1 or more Social Degrees away will not!
  
  Specifically, our first Tab contains:
  
• Changes to Production - Feeds that describe changes to portions of the "production" environment we are responsible for. This is a feed coming out of our Turnover Control System. It's not RSS at this point but hopefully will be soon.
  
• Work plan for the entire team spanning 2 weeks time (this is the Two-week Iteration). This is just an aggregate feed that collates Two-week Iterations from individual product blogs based on the "iteration" Tag.
• Top 5 Bugs or Issues spanning all our products. This is yet another RSS Feed filtered for items tagged or flagged as "important" from our issue tracking system.
  
• Links that allow the reader to subscribe to any of the RSS feeds exposed on the page
  

• Tab 2-x: Product-specific pages
  Each of these Tabs is dedicated to a specific Product/Project the team works on. These tabs are a natural "drill-target" from the 1st Tab. My Product Tabs contain:
• Changes to productions affecting this specific product
• Iteration posts for this product. This is a regular RSS Feed coming form my Product Blog filtered on the "iteration" tag.
• News Items or Alerts coming from the Blog or the Product Site. (The Product Site tends to target the end-user/customer. It's not very technical but provides enough insight about the Product's stage in it's life cycle, and the standard "what" and "how")
• Top 5 Bugs or Issues for this specific product/project
• Links that allow the reader to subscribe to any of the RSS feeds exposed on the page

RSS Feeds are a natural way to "summarize" content that lives elsewhere. As you can see, no content is actually managed by the Dashboard. The Dashboard simply assembles information into easily consumable pieces. The Trickle is enabled by:

• At-a-Glance views of tightly-correlated information
  
• Ability to stay High-Level yet still obtain more detail. The reader can explore Product-specific Tabs without leaving the context of the Dashboard.
• Link-backs to the source of information. The reader can drill even deeper by clicking on any item in any of the feeds and be taken to the full "article". The reader does this by choice - this is key.

Technologies at Play

1. Blogs with RSS capabilities -
   Blogs tend to be more appropriate for Weekly Summaries and Iteration posts. My Blog allows me to publish via email so I don't have to change my habits to post. I publish from my Email Client.
   
2. RSS Web Part -
   RSS is not just about getting news from slashdot. It can be a very powerful Glue for information that lives everywhere yet needs to be correlated in a single View.
3. A portal framework with a Tabs Layout -
   The Sharepoints of the world all have this built in. Acquiring RSS Web Parts is also not too difficult. Some Wikis out there (like Twiki or Confluence) allow you to inject all sorts of content into a single page view, including RSS. These are all basic things. As always, your friendly neighborhood IT department will have some options for you.
   

How to get started
Naturally, I recommend taking "baby" steps. Most teams will fall into two categories:

1. A lot of unorganized documentation floating around in multiple formats
2. All project-related know-how is stored in the brain of the guy two weeks away from retirement

For folks that fall into the 1st group, it's a matter of figuring out the kind of information that is most useful to highlight on a dashboard. Some teams I've worked with went straight to:

• Top Bugs
• Testing Results
• Latest activity around portfolio work for a client

Folks falling into the 2nd category should consider starting with Personal, Ad-hoc Knowledge Bases and expanding out from there.

In general, the type of information that is of Highest Value to your social network should be exposed first. The gains will be emergent and will inspire further investment into not just the Dashboards but also into creating and persisting the High Quality data underneath.

Conclusion and what's up next
Dashboards just front the Collaborative Environment. If the information in Product Blogs, Wikis, etc is not up-to-date, Dashboard's highlights are meaningless. It does take some work and consistency to provide this kind of transparency to your team, your manager and your customers.

Typically, gate-keeping Knowledge Bases and their Dashboards is the responsibility of Team Leads and Product or Project Managers. To get started though, all you need is a Champion, someone who will get the team going, while incrementally proving value. Once your manager is convinced (unless of course you are the manager) some top-down "encouragement" never hurts.

In my next post, I will propose a 10-Step Plan to putting these concepts to practice so we can move on to topics such as Wikis, Issue Tracking, and Interruption Management.

Firefox EWG - Meeting #3

Summary
Call on Sept 19th was about useful Extensions for the Enterprise. A larger portion of the meeting, however focused on the apparent dwindling interest in Enterprise Firefox within the larger community.

Is the Enterprise simply not ready to bring Firefox in-house? Or, are the majority of institutional adopters simply happy with a consumer product floating about?

Perhaps one of the problems is that we still talk about Firefox as a Web Browser as opposed to a "Productivity Platform" for the Desktop.

Firefox is a Productivity Platform
All the features that make Firefox a consumer favorite deal with productivity. Tabs, keywords, search bars, extensions, dictionaries, etc help us be effective and productive in our work and home lives. When consumer says "better usability", enterprise says "better productivity".

Mike Kaply spoke about adoption at IBM. Developers are finding ways to enhance the end-user experience by writing custom extensions for Firefox. Whether the extensions glue several applications together or simply automate the tedious process of filling out web-forms, end result is a boost to productivity.

If Firefox is the gateway or glue between what's on the Desktop and what's on the network, potential for productivity-boosting application is something to ponder.

Raising awareness
Mike and I are going to take lead on a few initiatives to help raise awareness on the Enterprise Firefox front:

• 10 Steps to adopting Firefox in the Enterprise -
  Now that we've begun to pool experiences, we should be able to bake out a definitive guide of sorts for things to consider when bringing Firefox into an enterprise environment
• Good Ol' Conference -
  We will begin looking at opportunities to present at some Conferences
• Blogging - check...
• Code Day and Training -
  The learning curve for any kind of Mozilla-related development is rather high. Perhaps training targeting institutions and enterprises (like an Enterprise track) will help developers scale this wall.
  
• Enterprise Firefox Incubator -
  Talk has alway been cheap. As we address settings management, security, tools etc we will kick off projects within the Enterprise Working Group.
  

Enterprise Working Group Incubator
On my end, I'm going to kick off some projects for the Incubator. Specifically there has been interest in:

• Mission Control - how to get up and running, what the back-end implementation can look like and benefits over GPO
• Customized Reporter Extension - so that you can redirect Broken Website reports to a repository on your intranet
• Managed Security Zones for Firefox - how to configure and lock capabilitiy.policy settings in Firefox, how to create a "trusted" zone and fully leverage Web2.0 technologies within your trusted intranet.

As always, if any of these topics or projects are of interest to you, please visit http://enterprisefirefox.org, participate in the calls or simply leave a comment on this here Blog.

Third Firefox Enterprise Working Group Meeting August 22nd

Third call is scheduled for Wednesday, August 22th at 10:00am Pacific, 1:00pm Eastern, 17:00 UTC. Details:

• 650-903-0800 or 650-215-1282 x91 Conf# 280 (US/INTL)
• 1-800-707-2533 (pin 369) Conf# 280 (US)
• IRC - irc.mozilla.org - #ewg

The theme is “Extensions.” Please check out the EWG Wiki page for more information.

Firefox EWG - Meeting #2

Overview
This call focused on the Enterprise Wishlist. What are some common problems that need resolving and what features can we vote "up" as a Community?

Topics covered:

• Addon Management
• Do enterprises wish to control updates to addons or the application itself?
  The general sentiment seems to be "yes". At one extreme an enterprise may wish to allow the user's browser to pull updates directly from Mozilla. At the other extreme, an enterprise may wish to provide an intermediary point so that all internal browsers pull updates from this point. The intermediary infrastructure then has to have a way of pulling latest updates from Mozilla, either manually or automatically.
  
  So, first, we need to understand how to configure for each scenario. Second we need to understand how to set up our internal infrastructure to facilitate the second scenario.
  

• Distribution
• MSI packaging -This seems to be something everyone wants.
• Ability to easily repackage the browser so we can add in our own "default" addons.
  
• Distributors that create packages for others to deploy cannot use the Firefox brand as part of their package. However, enterprises that deploy for internal audience only can use the Firefox brand. Can we work through these issues to make distribution channels more accessible?
  

• Settings Management
• Group Policy - a non-trivial problem to solve. Need to work on proper GPO integration!
• GPO vs Mission Control - pros and cons - will schedule a separate meeting to discuss these issues.
  

• Security Zones
• By design, Firefox does not allow cross-domain scripting. For an intranet, this can effectively break Web2.0 where developers want web technologies to federate. With IE, subdomains on a common domain are placed in a Trusted Security Zone. The relaxed security settings allow full-blow AJAX federation and interoperability. Similar capabilities exist in Firefox but they are no where near on par with IE.
  
  Firefox has a notion of a "security setting". There are even policy.* settings that make it possible to simulate Security Zones. This is great! However, Firefox treats policy.* and other security settings differently from rest of the settings. In fact - according to Mike Kaply - it is a completely different API. Mission Control cannot manage these settings which means we can't enable them across the Firm. This is a real challenge. How can we allow Mission Control or GPOs to enable these settings in a managed manner?
  

Personal Musings
My team compiles our own version of Firefox from the latest "stable" source. We make no changes to the code base. Why do we do this?

1. Set our own version and timestamp info for the executable and the dlls. This helps us differentiate between "supported" Firefox and a "renegade" Firefox within the Firm. We actively discourage users from installing vanilla or "renegade" versions of anything. This is simply a security precaution for a Fortune 500. All software deployment goes through this pipeline. An unpatched Firefox within our environment that admits an exploit vector could be disastrous for business.
2. We enable and compile in the "Autoconfig" mode that allows us to run Mission Control for settings management.
   
3. We introduce some custom extensions and themes that we want to include in our package.
4. We drop in config files for Mission Control

Points 3 and 4 don't really have much to do with compilation. Using Mike Kaply's technique for repackaging Firefox (see here) we can drop in our custom stuff without having to re-compile. Points 1 and 2, however really prevent us from taking advantage of a third-party MSIs. In fact all packages of "vanilla" Firefox are pretty much useless to us.

My point, we really do need an Enterprise Firefox package that's separate from the Consumer package. But what is it? What's the common denominator? One enterprise will want to manage settings with GPOs. Another one will want Mission Control. A third will want both. Is it possible to instrument a flexible package that can be configured? Maybe asking enterprises to compile their own version is not such a big deal when instructions on doing so are bullet proof. Much to think about...

Agile Development Methodology

The original version of this document was created and put into action by my friend and ninja, Azubuko (Buko) Obele while we worked at our first start-up. The document has since undergone some revisions as I've adopted it for my own purposes over time. This is an agile, iterative approach to product life-cycle management and it work in small and large firms alike. (Buko, you're a genius).

Processes and Methodologies

This document specifies recommendations for the software development process and the IT infrastructure strategy for developers and managers.

Overview

Philosophy

The intent of this document is to establish a foundation for development traditions and ultimately a company culture whose central philosphy of the development strategy is to maximize communication, collaboration, feedback and transparency. In doing so, the company will succeed in constructing an adaptive development infrastructure that can rapidly address changing business requirements and market realities.

Communication will ensure that the company's software and infrastructure development efforts are focused on addressing concrete business requirements.

Colaboration will allow the company to encapslate areas such as knowledge and distribution, reuse and automation, and proper allocation and management of resources. This will ensure productivity and efficiency.

Transparency will ensure that the company's development efforts are generating value and that risks are apparent.

Feedback will ensure that the development efforts are in fact meeting concrete business requirements and allow governence teams to understand the "current" situation and plan for the future.

Core Competency

Middle-tier vendors are moving into the forefront consolidating and standardizing services that may be purchased "off the shelf". This long list of solutions includes groupware solutions, Customer Resource Management (CRM) solutions, datasource abstraction tools, corporate communication tools, and enterprise-level SDKs and utilities among many. While it may "seem" easier to integrate vendor components, long-term customization and Quality of Service (QoS) costs may hinder the company's competitive edge. On the other hand there is no sense to "re-invent the wheel" especially when the middle-tier vendors have nearly perfected the services and components they sell.

Finally, it is always advantageous for the company to participate in IT Infrastructure Strategies mentorship and advisory programs offered by such industry leaders as the META Group, Inc.

Product Driven

Development Teams are encouraged to think in terms of "products" as opposed to "projects". A product is a deliverable with a well defined cost and risk and one that will create some well-defined value for the customer and company. A "product" should include all implementation, development, and operation costs of underlying infrustructure and application. The composite should be treated as part of the company's "portfolio". Tactical and Strategic methodologies will allow the company to effeciently grow and reassess the portfolio.

Tactical or "per-project" planning is conducted for each new application or infrustructure-driven project. The phases of Tactical planning are described as part of the Development Process section.

Strategic or "periodic" processes deal with periodic reassessment of the company's IT portflio, including Infrastructure Impact Assessment (IIA) and Prdictive Cost Modeling (PCM).

Agility and Velocity

The development process should capitalize on the company's energy and small size. The ability to quickly respond to evolving requirements and market conditions will allow the company to remain agile and adaptive. The ability to quickly initiate product development while sustaining a high, predicatble rate of development will allow the company to retain a high velocity. To accomplish this, the development process itself must follow "Agile" methodologies with a focus on Test-driven development while keeping unnecessary documentation and meetings to a minimum.

Risk Management

Enterprise-scale infrastructure deployment and large-scale software development is inherently a high-risk/high-rewards endeavor. Methodologies and processes must reduce risk whenever possible. Risk assessment must take complexity, time to market, and specific business-related value into account. Commitment to collaboration, communication, transparency and feedback will also help make high-risk scenarios manageable. Long-term projects with large iterations should be avoided as they tend to require large investments of time and resources and are inherently lacking in agility. It is recommended that focus is on test-driven development, continuous integration, short iterations to create immediate value and to produce tangible returns, centralization, and portfolio view of infrastructure patterns and services.

Development Process

Inception

The goal of the product inception phase is to identify and define the business problem. The result of the inception phase is a high-level description of the product's purpose and a non-exhaustive set of produt requirements. It should be clear from the onset who the product is used by, what "pain" the product should "cure" or "alleviate", what potential value the poduct brings to the company and in technology-neutral, abstract terms, what the product should do. How the product will work is irrelevant at this stage; only the Why and What matter. A product idea may only pass this phase if the risk is justified by value.

Business, Infrastructure, and Software development governance teams should be heavily involved in this process to present a holistic view of risk and reward. The deliverables of this phase should be (1) Meeting Notes and (2) Product Requisition Document (PRD).

Service Level Metrics, Feature Planning, Use Case Definition

The goal of this phase is to evaluate risk and to ultimately bring it under control. At this stage, the infrustructure planner should work with the product managers to define a potential solution and agree upon service levels. The product managers should describe a series of well-defined use cases and rate them in terms of risk. These use cases will describe the solution to the business problem from the application perspective.

Business specialists working with Software development management teams and Infrastructure planners should deliver a Feature Specification Document (FSD), Service Level Metrics Document (SLMD).

Development Planning

The primary goal of the stage is to bring the technical risks under control. Issues such as performance, scalability, reliability, and security should be addressed and metrics for product success should be established. The infrastructure planner should leverage as much existing infrastructure as possible, and infrastructure standards and processes where innovation allows. The planner should propose a blue-print for solving the business problem on the infrastructure level. Application management teams should define the solution in terms of application architecture. The infrastructure planner and application managers should collaborate to address technical risk and anticipate future risks and requirements. Application architecture and infrustructure architecture must address services, service level matrices, the complexity of the solution, estimated time to market and provide a model of projected costs. A basic prototype or other form of "proof-of-concept" should be used in a Test Lab setting to evaluate the doability of the proposed solution.

At this stage, the deliverables are a Release Plan (RP), Application Architecture Specification (AAS), Assemble Infrastructure Plan Draft (AIPD), and Predictive Cost Model Document (PCMD), Functional Prototype (optional).

Implementation

In this phase product development is borken down into a series of iteration cycles. The length of the iteration cycle will depend on the complexity and scope of the product. It is recommended that the iteration cycle be between two and four weeks in length.

This strategy puts concrete deliverables in the hands of customers who will inevitably provide invaluable feedback. The result of this kind of iterative loop is a quantifiable reduction of risk.

The deliverables are Iteration Plans and Checkpoints.

Release

A product is expected to transition through multiple "minor releases" before a "major release". Minor releases should occur frequently (at the discretion of product management). The purpose of any release is to determine of a set of risks has been successfully eliminated. Major releases will generally evaluate a much larger set of risks than Minor releases and will ultimately determine the success or failure of the product. Each release must be accompanied by a Release Contract in order to define and hold accountable every party involved in the release. The Release Contract must be approved by each party involved before the Release Conract is executed.

All functionality deemed in "alpha" or "beta" stages should adhere to release procedures as they will ultimately face some or all clients. Monitoring utilities should be enabled on live systems, customer feedback forms should be integrated into the product along with automated critical error/crash reports if possible. Feedback and system logs are envaluable in qualifying product performance in "live" environments.

Deliverables for this stage are Release Contract, Product, Product Evaluation

Deployment

Test-driven development requires continuous integration of code written by the development teams. Integration may take on the form of code merges within a Code Versioning repository (CVS) followed by deployment to Testing or Staging servers in the Test Lab. A "Release" is merely a deployment to "Live" (client-facing) environment with the assumption that the release passed all testing in the Testing Lab under live conditions. Deployments to Testing environments should occur frequently (on a daily or even bi-daily basis) by developers acting individually or in teams. Focus must be on unit, functinoal, and stress testing which for most cases, can be automated by easily atainable tools and utilities (JUnit, Cactus, etc.).

Testing will provide insights into the problem domain and expose architectural weaknesses in the infrastructure and the application forcing the management teams to revisit the planning stages. All "bugs", suggestions, and issues must be submitted to a task management application (JIRA) and resolving the riskiest ones should be a priority while the problem area is still "fresh".

Deliverables for this stage are Regression Testing Reports (RTR) as well as tuned Application Architecture Specification (AAS), Assemble Infrastructure Plan Draft (AIPD), and Predictive Cost Model (PCMD) documents.

original: Azubuko Obele
contributions: Yuriy Krylov

Taking Baby Steps (part 2): Only one person reads my Blog and I've already won

Overview
My last post entitled "Taking Baby Steps (part 1): Personal, Ad-hoc, KB", suggested that Knowledge Workers should embrace a Blog (at work) as a personal Knowledge Base. The focus was on the Network of One and some of the wins on a, facetiously, "selfish" level. Laying a foundation for productivity-focused collaboration is realizing that the "hidden hand" also works wonders in a collaborative setting.

In this post, I will talk about some ways in which this Network of One also benefits folks One Social Degree away -- even if it's just one other person. This is the Network of Two.

Who is One Social Degree Away?

• People who directly depend on your work
• People whose work you directly depend on
• Your manager
• Your intern
• Your service team overseas
• Your client
  

At work, our "social network" of peers is typically well established. We are hired into teams, we have colleagues, team-mates, customers. Someone depends on what you produce - these people will benefit from the knowledge you share.

Syndicate updates via RSS/Atom
Any good Blogging software already has syndication capabilities built in. Simply advertise the URL to your Blog's "feed". All you need is an RSS reader. Some come integrated with your email client, others are standalone or web-based. Your friendly, neighborhood IT department should have something to meet your needs.

But this is a post on the Network of Two. Your manager is, in fact, the first person to whom you should advertise your RSS feed. Your immediate manager will always be your #1 fan.

Managers love Workstreaming
Once your manager subscribes to your RSS Feed, and you make a selfish commitment to maintain your very own knowledge base, you will automagically keep your manager concurrent with the happenings in your daily work-life.

The Network of Two and effective Workstreaming will emerge when you begin to cater "some" posts to your immediate audience. Hint to your manager that something is especially important to her with Tags such as "important" or "for larry".

The key is to allow the Blog/KB to become part of your natural routine. There are no rules of how much to post or how often. Just keep things relevant.

Completing the Feedback Loop
You know you've established a successful Feedback Loop within your Network of Two when:

• You find a "comment" on your Blog from your manager

I really want that first point to stand out - there are other indicators and emergent efficiencies when this Feedback Loop is completed:

• Meetings between you and your manager are shorter and more to the point
• You spend less time figuring out things you've forgotten
• You manager seems more helpful and, in general, more knowledgeable about what you are working on
  
• Sometimes the last point allows your manager to spot problems early and offer some very timely wisdom.
  

And so on...

Extra Brownie Points
The rarely seen but often sought after "Manager's Blog" where you get to leave comments.

Reverse Mentorship
I read my intern's blog every morning and I learn a book's worth every week. Just yesterday, I received a very in-depth refresher course in Java's SOAP API.

What about the team-mates?
My team works on many projects at the same time. I'm only a lead on one or two of them. This means that I need extra help staying up to speed on projects where I play a secondary or tertiary role. I read my peers' Weekly Update-tagged posts only. Good Blogging software will allow you to subscribe to a filtered subset of all the posts based on one or more Tags. How does my RSS reader know it's a Weekly Update? The Tag is "weekly".

For these secondary projects, reading "weekly" posts is enough for me to stay on track. This is especially helpful when I come back from vacation and dread opening my INBOX.

Non-urgent Information Only
Many folks try to misuse RSS by using it for Alerting purposes. This is not what the syndication medium is for. If you want to catch someone's attention because you require Immediate Feedback, use the phone, send an instant message, meet them at the Cooler.

RSS is best suited for Knowledge sharing that does not require immediate response. Your audience consumes the content at their own leisure, at their own pace. If you use RSS for anything else, it will very soon become as noisy and convoluted as email is today.

Final note of advice here -- turn desktop popups for RSS Updates off. Unless the Alerting mechanism is really smart, it will never know what is truly important to justify the time wasted recovering from the Interruption. I'm busy and need to focus, stop competing for my attention because my feed from pizza.com has an update.

Up Next, Too many Feedback Loops?
Every communication medium will be abused and misused. You may find yourself subscribed to too many feeds claiming importance. My next post will talk about cutting through noise with RSS and Tag-powered Dashboards.

Firefox EWG's first call is a success!

Thanks to everyone who attended the first Enterprise Working Group for Firefox call. We're still waiting for a statistic on how many folks were on the call and on the irc channel -- I'd ballpark the figure to be somewhere in the mid 20s.

Special thanks to Mike Kaply for MCing the call and to JT Batson and Basil Hashem from Mozilla for providing insight and effectively validating this initiative.

Very Brief Summary
The theme of this meeting was "Experience". Folks on the call shared their personal experience with Firefox in an enterprise environment. There were clear areas of interest and overlap.

My main take-away has been this: It cannot be understated nor unappreciated that "Enterprises" do, in fact, share pain-points and challenges and therefore must come together to form a real, effective Community.

Some identified synergies
By no means a completed list, but here is what jumped out at me:

• Packaging.
  
• Story around MSIs and MSTs vs some open source formats. Most Enterprises are heavy Windows users. At what point does the lack of these hinder adoption?
• What is feasible? What can Mozilla own and what can and should the Enterprise Community own?
  
• Patch Management.
• If an organization is not very Agile and agility assumes that not everything is perfect out of the box, is Mozilla's patch cycle too agile for "enterprises"?
  
• How are others patching Firefox on desktops without having to uninstall and install the entire product?
• Settings Management.
  
• What are some trade-offs between GPO and Mission Control?
  
• Not all settings are manageable.
  
• What settings should be exposed by all extensions to enable pref-level lockdown?
• Can we drive best practices for deploying plugins and extensions? There is very little documentation on where Plugins should go and how to configure in the registry.
• How do we prevent some critical settings from being "tattooed" into prefs.js? I.e. mcontrol and user agent settings should never be written to prefs.js when in Enterprise mode.
• User Profiles
• How can profiles/certificates be migrated with minimum impact to the end-users?
• Does having Firefox and IE share bookmarks help adoption? Can Firefox "piggy-back" on Favorites? How can it be done easily?

Follow-ups
Attendees were asked to contribute content to the http://wiki.mozilla.org/Enterprise wiki. Content will be refactored as we overflow. Mike and I will put up a page for each Meeting where we can post and track agendas, follow-ups etc and will work to keep content organized.

Up Next (August 8th)
Next call is scheduled for August 8th, same time, same station. Topic will be "Enterprise Wish List" and should be a fun, rowdy call!

Come one, come all. Help us spread the word.

To be politely blunt, we're committed to helping this community thrive. There will be wins. To my "enterprise" peers, you cannot afford to not have your interests represented - the potential for the Enterprise Web Browser as the Knowledge Worker's Killer App is too real.

Taking Baby Steps (part 1): Personal, Ad-hoc KB

Overview
This collection of posts is part ideology and part methodology aimed at Knowledge Workers still struggling to embrace the Blog and Wiki whateveryoucallit. I don't blame them. The words "Blog", "Wiki", "Tag", and so on, meant very little to me as well until I put each of the technologies to a very specific use.

What started out as a system to manage developer teams overseas turned into a Pipeline for Knowledge Sharing within a Team.

To me, collaboration is a Bottom-to-Top story. It begins with a very selfish Network of One. And that's OK! If you can't prove value to yourself, how can you prove it to the guy sitting next to you at meetings?

Mental Filters
Like many Knowledge Workers, I suffer from information overload and a bad memory. First step is always admitting you have a problem, right? Now, I tend to ask myself two questions whenever I deal with information:

• Is it useful to me now?
• Might it be useful to me later?
  

If there's even a remote chance that I'm dealing with Useful Information, it needs to go into my Knowledge Base. This is my Mental Filter. All incoming information competing for my attention goes through this and other filters.

A Blog is a Personal, Ad-hoc Knowledge Base
It just so happens that the simplest and most complete Knowledge Base I know of is my Blog. It's mine. It's for me. I don't care about structure, colorful phrasings, or a full bibliography. I just need useful knowledge sans the BS. If I take the time out of my Very Busy Schedule to throw something into my Knowledge Base (KB), I owe it to no-one but myself to only post useful and Highly Relevant information.

I also haven't figured out how to not live in my INBOX so I want to be able to email my KB.

Side Note: But wait, why not store everything in email and search there? With Blogging, selfishness turns into something very useful for the rest of the Team. Email just doesn't have that kind of potential for collaboration.

Finally, I want control over the organization of my Knowledge Base but I don't have time to organize into pretty folders. I just want the information I need at my fingertips with minimum management. And while on the topic of being selfish, I want the search functionality to work for me; I want to help it help me. I want to be able to Tag my KB posts with words or phrases that serve as Keys to Knowledge in my head. It should be easy for me to share these Keys with the cyborg extension to my head that is my personal KB. The search functionality in my KB should pay special attention to these Tags a.k.a Keys. It's a matter of improving relevancy and hence my productivity.

A note about Privacy Concerns
Start with a Blog that your Firm provides for you. It should be internal and inaccessible from the outside world by the outside world. Don't worry about protecting your posts from the prying eyes of colleagues. Focus on yourself. Only your immediate network will ever care about what you have to say anyway. Post openly, but only post work-related information. Remember, you don't have the time to post on anything else.

What kinds of things should I post about?
It took me a bit of trial and error to figure out my Blogging sweet-spot. At first you'll post too much or too little. Remember, it's for you so figure out what works for you.

Some ideas on what you may want to track in your KB:

• You figure out how to do something, save yourself brain space, write yourself a mini how-to
  
• You solve a problem, post solution so you don't have to solve it again
• Someone owes you a TPS report
• You've identified follow-up items at your 3-hour meeting
• You wish to condense your meeting to 15 minutes by posting an Agenda to your KB
• Someone else posted something that may be useful to you later

Ans so on...

Conclusion
When picking out a KB starter-kit, be selfish. My recommendation is to go with a Blog. Blogs have many useful features; clearly I've only scratched the surface. But really, the other features will come in handy later. Here is what you should ask of your Personal, Ad-hoc Knowledge Base Blog:

• Can you email it?
• Can you tag posts?
• Can you tag posts within your email?
• Can you search it?
• Are your search results influenced by the tags you assign to your posts?

Good news is most Blog implementations already do this. Your friendly, neighborhood IT department will help you set one up.

Up Next
In my next post, I will talk about how KB-directed Selfishness is, in fact, very useful to Team-mates.

Ant Build Script for Mozilla Extensions

I play with Mozilla Extensions in EclipseIDE and generally like the Ant build system. Not an expect at Ant by any means so if anyone out there wants to make improvements to these, please share. The relative paths to directories are set in the build.properties file so that it shouldn't matter what folder layout one uses. If I make improvements to this over time, will post updates, feel free to drop feedback.

build.xml

<?xml version="1.0"?>

<project name="Firefox Extension Builder" basedir="." default="package">
 <property file="build.properties" />
 
 <target name="setup" description="create dir structure for project">
  <mkdir dir="${content.dir}"/>
  <mkdir dir="${skin.dir}"/>
  <mkdir dir="${install.dir}"/>
  <mkdir dir="${locale.dir}"/>
  <mkdir dir="${defaults.dir}"/>
 </target>
 <target name="clean" description="Delete previously generated jars">
  <delete file="${install.dir}/**" verbose="true"/>
 </target>
   <target name="createjar">
    <delete file="${install.dir}/${project.name}.jar" verbose="true" failonerror="false"/>
     <zip destfile="${install.dir}/${project.name}.jar" excludes="*CVS*/**">
      <zipfileset dir="."
           includes="${content.dir}/**, ${skin.dir}/**, ${locale.dir}/**"/>
     </zip>
   </target>

   <target name="createxpi" depends="gen_manifest,createjar">
     <zip destfile="${install.dir}/${project.name}.xpi">
        <zipfileset dir="${install.dir}" includes="${project.name}.jar" 
                  prefix="chrome" />
            <zipfileset dir="${install.dir}" includes="${manifest.src}"/>      
      <zipfileset dir="." includes="${install.src}" />
      
   </zip>
   </target>
   
   <target name="gen_manifest">
    <copy file="${manifest.src}" tofile="${install.dir}/${manifest.src}" overwrite="true"/>
    <replaceregexp file="${install.dir}/${manifest.src}" 
     match="^(content\s+\S*\s+)(\S*/)$"
     replace="\1jar:chrome/${project.name}.jar!/\2"
     flags="g" byline="true"/>
    <replaceregexp file="${install.dir}/${manifest.src}"
     match="^(skin|locale)(\s+\S*\s+\S*\s+)(.*/)$"
     replace="\1\2jar:chrome/${project.name}.jar!/\3"
     flags="g" byline="true"/>
   </target>
   <target name="package" depends="clean,createjar,gen_manifest,createxpi"/>       
</project>

build.properties

project.name=${your_project_name}
content.dir=chrome/content
skin.dir=chrome/skin
locale.dir=locale
defaults.dir=defaults
install.dir=install
manifest.src=chrome.manifest
install.src=install.rdf

Enterprise Firefox Adoption Part 2: Where are my Bookmarks?

All these Bookmark syncing engines out there are great. Unfortunately, many large enterprises are simply at a point where policy restricts or greatly limits an employee's ability to expose information outside of their Firm. Bookmarks are no exception to the rule. Talk to a friend who works in Finance, you'll hear interesting stories directly from the battle field.

I don't have a solution for the above - this will take more scaffolding work. I do, however, want to raise the issue of synchronizing bookmarks between different browsers on a single Desktop -- for starters.

Some more realities of Firefox Adoption in the Enterprise:

• Not every business critical application will work with Firefox on Day 1 if all you have deployed Firm-wide is the Not Firefox Browser.
  
• Users will continue to use the Not Firefox Browser. Assume this is forever.
  
• Mose users will have years of bookmarks stored in the Not Firefox Browser and this list will grow.
  

As you can see, simply "Importing" Not Firefox Browser's bookmarks into Firefox just doesn't solve the problem. When multiple browsers live side-by-side in an Enterprise, users will want bookmarks to always be in sync between All browsers on All Desktops that they may ever use.

This is a two-step project:

• Step 1: how do I make Not Firefox and Firefox share bookmarks on a single Desktop?
  
• Step 2: how do I roam these as I move around from Desktop to Desktop?

Challenges
Theoretically, it is not very difficult to write a Desktop application that will listen for changes to your Not Firefox and Firefox bookmarks, resolve the differences, update each repository, etc.

But did you know that with Firefox 2, there is no easy way to reload bookmarks from disk while Firefox is active? The Bookmark Service just doesn't expose that functionality. Furthermore, when you shut Firefox down, it will out-dump bookmarks stored in memory back into the bookmarks.html file, effectively trumping any changes you've made to the file with your Syncing Engine.

Of course, there are workarounds and it is possible to hack your way around everything BUT who has the time or the will to do that??

What would an Architect say?
Managing two or more discrete, proprietary repositories for Bookmarks on the Desktop is a huge pain for the End-User, the Support servicing these Users, and for IT trying to enable this synchronization.

Any architect would already be thinking: "Centralize & Federate - store in one spot, leverage the one spot, make things easy".

Plain Old Favorites indeed!
At what point does it make sense to replace Firefox's Bookmarking engine with something else? I don't want to replace the whole interface per se, just don't want bookmarks stored in bookmarks.html anymore.

In fact, I want to leverage the Favorites folder for storage on my Windows Desktop.

Perhaps the File System implementation for bookmarks is not as flexible as what Firefox 3 promises to deliver via SQL Lite for Places. Still, the Favorites solution exists today and it is the greatest common denominator for a bookmark datasource. That is, by design, every browser can understand the File System with ease. Not to mention, it is a lot easier to get Firefox to read files for bookmarks than it is for IE to learn to read bookmarks.html - for example.

This is why I think that Alex Sirota's PlainOldFavorites extension is brilliant as a vehicle for Firefox Adoption.

Immediately, I spot some some tiny performance issues and a feature gap between what Firefox's bookmarks engine offers and how much of it is implemented under the auspices of "Favorites". Still, this is much simpler than having to engineer synchronization for two distinct data sources.

This also makes Step 2 much more light-weight and simpler to implement.

Part 3 of this post will focus on my research on PlainOldFavorites as an Adoption vehicle. I hope Alex Sirota will help me out...

Enterprise Firefox Adoption Part1: IE Skin not Blasphemy

If IE is the dominant browser within your environment, consider Usability obstacles to adoption.

Firefox may be super user-friendly on its own but if your non-IT people predominantly use IE, are trained to use IE, have nothing but IE at home, and are too busy to care otherwise, Adoption will have to come through a gradual Transition.

Adoption through Transition
Give your users what they are already familiar with. Let them learn the benefits with minimal rides on the learning curve.

If IE is the incumbent browser and you want to deploy beyond IT pockets, consider packaging up Firefox with an IE-look-alike skin. "Looks Familiar" theme extension is a good place to start. I've customized it a bit in-house to retain Firefox-unique branding and saved a bundle on my car insurance.

Jokes aside, little things like this really ease the pains of adoption while keeping training costs low.

First "Firefox Enterprise Working Group" Call Scheduled!

Please see Michael Kaply's Blog entry: "Firefox Enterprise Working Group Update". Rock'n'Roll!

"Firefox Is More Secure Than IE" Should be Treated as a Myth by the "Enterprise"

There are evolving factors that in practice make Firefox less of a target for malicious attacks - and these factors have very little to do with strength of code.

Some educated guesses on why Firefox is perceived to be more secure than IE:

• Brand perception - Firefox is the perceived underdog, the champion of community and open standards, in league with the equally polished and spotless Google. Common perception of Microsoft in the techie world is not quite that. If an ambitious hacker only has time for a well executed attack on one browser, which do you think she'll choose to pursue? Those savvy enough to do damage play nice with Firefox.
• Different code - Holes in software are a bi-product of the act of coding in of itself. There are very few and largely insignificant similarities (I'm assuming) between Firefox's and IE's code base. Those things that are attack vectors on one browser will most likely pose no threat to the other browser simply by virtue of dissimilarities in implementation. Spend enough time hacking at Firefox, it's possible to bring the vulnerability reports up to par with IE's.
• Market share - IE dominates the market place and therefore the same Wisdom of Crowds that builds Firefox on one side of the spectrum plays a hand in breaking IE on the other side of the spectrum. Different communities, same principle.

In summary, when Firefox and IE are both on equal footing when it comes to market share, it will be very foolish of Enterprise Adopters to assume anything other than equal footing when it comes to vulnerabilities and exploits.

In fact, this mindset is a healthy one to have now as well.

Enterprise Firefox Can Live Happily With IE

Emergent Value in Firefox
Firefox is emerging as a:

• Developer Platform
• Extensions for the Web Developer like Firebug, LiveHTTP Headers, WebDev Toolbar etc are ideal for the Web2.0 developer of any organization.
• The Browser itself can be enhanced through Addons. Integration with other desktop components and the potential there has barely been tapped.
• Productivity Platform
• Knowledge Workers spend significant amount of time interacting with web-based information. The niceties of Firefox tabs, bookmarks, integrated search, and all the other things we already recognize as award-winning implementations within the browser keep us productive. The next opportunity is in Extensions that focus on creating efficiencies and improving productivity for busy people in a busy work environment. These will create significant value for Enterprises. Large firms are willing to pay for such things too...

IE in the Enterprise
In my humble opinion, Internet Explorer is a more mature Enterprise-scale Browser because:

• Microsoft invests in Enterprise features such as
• GPO settings management
• Centrally managed Active-X whitelisting capabilities to control what Addons are allowed to live in IE
• Microsoft is familiar and accessible
  
• The patch process is well understood by engineers and is consistent with other Microsoft products that are as incumbent in large firms
  
• Support - you can open cases with Microsoft around enterprise issues and someone is paid to address your inquery
• Microsoft reaches out to large firms and asks how they can improve their product
• Efforts around IE have been revitalized and they've begun to really listen
  
• They have the resources to not just listen
• They dealt with enterprise customers regularly and hence they understand the requirements
  
• They are also a very friendly and brilliant group of people

"So what?" you say. "Firefox is still a better browser!" you say. "Look at IE7!!". "Who cares about Enterprise anyway?".

It pays to be Enterprise-friendly

• Large firms train people on how to use the tools made available to them in their workplace because the work force needs to be proficient and hence efficient, and productive. For non-techies, ease of use is directly related to familiarity. Product A may be 10x better than Product B but if I'm proficient with Product B I will install and use Product B at home.
  
  Enterprise Users are influenced by Enterprise Software when choosing how to be Home Users. The choice does not always exist when moving in the reverse direction. This is not because Corporate IT is evil but because most User-preferred software simply does not meet the criteria for firm-wide deployment and is hence too much of a risk for pocket deployments as well. See my post entitled "Why Vendors don't get Enterprise 2.0" for a more in-depth discussion on what it means to be Enterprise-friendly.
• Developing with the Enterprise in mind forces you to make better Architecture and Design decisions. Simply put, you wind up with a more robust, more secure, and a more flexible, manageable product. Home Users can appreciate this too.
• Enterprise is a dependable source of revenue. Open Source is no exception. There is vast opportunity in offering support, training, and consulting services to large firms who, more than ever, are in a buy-vs-build mode.
• The "large Firm" world is a different world and will innovate around a product in very unpredictable and oftentimes very valuable ways.

Firefox in the Enterprise
Most Fortune 500 companies don't have much experience dealing with Open Source software vendors. Mozilla Corp is especially interesting because like Google, money to pay for a staff of 80-something people (correct me if I'm wrong) comes from online ad revenue referrals via the integrated search feature. Home Users, due to sheer volume, generate significant revenue from this source. Mozilla Corp is not in the business of selling software. On one hand, it can be argued that the evolution of the project itself is revolutionary and that it is what it is today because of it. On the other hand, it itches to ask if the story around adoption for Enterprise customers would have been a rosier one if Mozilla did make money from Licensing or Support fees. In short, there's a disconnect between revenue and product and hence a lack of accountability for the components that big firms demand and are used to paying for.

Free comes with a price. I would imagine that this makes Fortune 500s uneasy.

It is completely understandable that in the last few years Mozilla has been preparing for the Firefox 2 release in competition with IE7. This competition happens on a Home User's playground. For Mozilla Corp, user base is directly related to revenue. For Microsoft, Enterprise licensing fees make up a significant portion of revenue, plus they are the incumbent player - they can afford to add value in areas that Mozilla has not gotten around to yet.

These areas are:

• Enterprise Settings Management -
  
• How do we flip a setting on every Desktop in the event of a vulnerability?
• How do we prevent users from altering settings that are deemed risky?
• How can we enable and lock Security Zone-like implementation in Firefox?
• Granular Addon Management -
  
• How can we prevent a user from installing or uninstalling an extension without having to compile extensions into the browser itself?
• How do we internalize extension repositories so we can "Bless" extensions before our users get to them?
• How can we disable an extension or plugin on all desktops in the event of an emergency?
• Patch management -
  
• How do we not have to recompile and repackage Firefox every single time a critical vulnerability is released? (For large firms with a 3-6 month turnaround time for patches, aggressive patch releases by the vendor is not always a good thing!)
• Can Firefox installations take advantage of self-repair (an MSI feature)?
• Can we get MSI installers?
  
• Maintenance, Support
• We're on our own --
  

The truth is that those of use dealing with Enterprise deployment challenges are verbalizing the following: "How can we get Firefox's enterprise capabilities to be on par with those of IE?"

Sympathetic Souls
Firefox is the embodiment of Wikinomics-driven success. All this moaning and complaining is out of love, really.

The Enterprise Work Group around Firefox being shaped is a real thing. Community Incubation of Firefox is already a success story - now we just need to collectively learn how to involve the true Enterprise players.

Bring Enterprise to Firefox
One of the goals of the Enterprise Work Group is to create a resource, a support network, an Enterprise-level Community Incubator, really, for Firefox and the Enterprise-scale firms that recognize the aforementioned emergent benefits. It is also being established to apply unified pressure on Mozilla to rally around Enterprise needs. To be fair, there is no reason for Internet Explorer, Safari, and Opera to not be on the discussion table. "Enterprise Browsers Work Group" is really where I think we should end up but as with most things, progress comes from taking baby steps.

As was mentioned in my previous post (and Mike Kaply's post), we want this effort to be organic and inclusive and hence anonymous. We want to break down the walls that have historically prevented the firms that have the potential to be most influential in shaping core products from participating in community-driven projects. If you choose to participate, please help us respect the anonymity of participants -- at least until we all harmoniously come to a point where even this wall is no longer necessary.

Bring Firefox to Enterprise
The aforementioned benefits are very powerful motivators for decision makers in large firms to consider bringing Firefox into their environment. In fact, today most proposals will be driven by the Development Platform point. I personally don't like this selling point because I don't believe that it is solid enough to penetrate beyond IT pockets within an organization nor strong enough to solicit the required attention to the Enterprise features.

Bring Firefox in as a Contingency Browser
In software and infrastructure development and planning, the word "Enterprise" usually implies that availability, fail-over, and redundancy have been considered. Business-critical systems and processes demand it.

If the Web/Enterprise 2.0 revolution is taking place (and it is) and the most tangible evidence is in the proliferation - or migration from Desktop apps to - Rich Internet Applications, why are large Enterprises satisfied with a single browser?

For every IE installation on a Desktop there should be an installation of Firefox for those rare occasions when a critical vulnerability to an ActiveX control turns RSS-syndicated-to-millions-of-hackers-exploit with attack vectors sold on Ebay or traded on MySpace and you're forced to push out a policy that at best disables that ActiveX control bringng down a business process that your most prolific business unit depends on or at worst forces you to prevent IE from launching, period. Ask around, it happens.

I prefer to simply fail over to Firefox.

Enterprise Working Group

To cut to the chase, I own engineering and deployment efforts around Firefox at a Fortune 500.

Disclaimer: I don't know everything there is to know about Firefox. However, I do know a little bit about what it means to deploy and maintain Firefox within a large enterprise where security and manageability take priority over usability every single time.

If you've read Mike Kaply's posts on Firefox in the Enterprise Part 1 and Part 2 then you already know that an Enterprise Working Group is taking shape. It's time to raise the bar for products that claim to be enterprise friendly! Why not start with Firefox?

In my musings on Enterprise 2.0 I often hammer on the fact that E2.0 is more than just Web2.0 for enterprise customers. Making Firefox Enterprise2.0-friendly is a whole other side of a shaping, Wikinomics-driven, revolution in how innovation and even incubation happens inclusive of large banks, software firms, and head-to-head competitors.

The Enterprise Work Group is being shaped by Mike, myself and other reps from our peer institutions to primarily tackle Firefox but (at least for me) also to tackle so much more...

We are our own Case Study and our own proof of ROI on how large institutions where technical innovation tends to be a well-guarded secret are adopting to and in turn helping shape what I refer to as Community Incubation.

We will be scheduling a call and will be posting rules of engagement so that anyone interested in Enterprise Firefox can participate without fear of violating Codes of Conduct or disclosing sensitive information. Please bear with us as at times it really feels like we're in Star Trek mode -- going where no-one has gone before...

Why Vendors don't get Enterprise 2.0

Enterprise 2.0 is NOT simply Web 2.0 haphazardly packaged up for Enterprises
After spending three days at CMP's Enterprise 2.0 conference in Boston, I'm convinced that most Vendors don't quite get it (yet).

In fact, the Vendor climate was such that a more appropriate classification for most sales pitches is SMB2.0 - Small to Medium Sized Businesses only. Globally distributed institutions need not apply - or rather cannot apply... The Vendors are just not ready. The solutions or products hyping up the E2.0 story are:

1. Redundant - unique positioning and value proposition is at best, in the Ajaxy interface.
2. Unmanageable - little consideration for centralized settings management and lockdown
   
3. Narrow - you have to assume that in most cases Corporate IT gets the value proposition of asynchronous collaboration -- Wikis and Blogs. Stop talking up "Yet another Blog or Wiki", show integration, management, interoperability, extensibility. All purchases go through Corporate IT. Learn to work with them.
   
4. Monolithic - Do not plug into existing infrastructure and platform investments. On some level a Blog is nothing more than a datatype. When pondering synthesis and integration, this is an interesting thought...
   
5. Unproven - I'm not talking about ROI numbers, that's a different point. The vendor has to respect decades-long relationships that most Enterprise-scale companies have developed with the Microsofts, IBMs, SAPs, and Adobes of the world. It is unlikely that the vendor can compete with them head to head on a platform level nor (and more importantly) on a "trust" level. Say whatever you want about the giants, they've earned their stay.
   
6. Non-compliant - The need for archival and retrieval, granular micro-information management, and so on is huge in the world of finance. If you sell in the New York area, these are your biggest (if not only) real Enterprise clients.
7. Can't prove ROI - This is the classical Chicken and the Egg problem but it can be solved!

Yet, instead of figuring out how to work with Corporate IT most vendors and even leading researchers in the E2.0 field marginalize these gaps in favor of stories of egalitarian and productive workforces powered by social networks and asynchronous web-based collaboration tools.

Selling a piece of paper with the word Blog on it
I am convinced that the following can outsell every new Blog, Wiki, Document Management, etc vendor in the space today:

1. Develop components that fall under:
1. Enterprise Security
1. Integrate with existing SSO solutions an Enterprise uses
1. Polls LDAP or some other corporate directory for all user/group information and ACLing
   
2. Enterprise Management
   
1. On the Desktop: exposes every single setting or tweak to GPO management, packages updates as MSTs,
   
3. Service Oriented Architecture for Federation
1. On the Desktop: provides an open API and modular components that can be plugged into, extended or swapped out for other in-house components
1. On the Server: uses scalable, open standards implementations with open API and ability to delegate services (data storage, tagging, feed subscription and what not) to other in-house components
2. On a piece of paper, write the word Blog or Wiki representing the cool Ajax or Flex-driven interface with a promise to finish the actual implementation later...
   

Stop vilifying Corporate IT!
Please stop promoting the "Corporate IT, get out of the way!" mentality. No sane and risk-minded institution will permit discrete sectors of the user-base to just deploy whatever Blog or Wiki or Issue Tracker they want. Spaghetti Infrastructure is extremely hazardous and unacceptable. The complexity of having to clean up the infestation of SMB2.0 products will leave a very bad taste in the mouths of those that make purchasing decisions, period. Furthermore, it will derail Evangelism campaigns that many of us working in Corporate IT are working our Butts2.0 off for.

Although I will cover Adoption in a later post, for the sake of continuity, E2.0 Adoption is both, a Top to Bottom and a Bottom to Top story. Business Units and Corporate IT have to move together and meet in the middle. Vendors must be able to meet the demands of this "middle". Nothing else makes sense.

Inside Corporate IT
Enterprise-class institutions invest millions if not billions of dollars into IT, annually. Agility and competitive advantage in today's market demands the best of what technology sectors have to offer. Corporate IT exists and recruits the Best in strategic fields to follow trends in technology and to leverage the best-of-breed products in-house. In short, don't ever underestimate what Corporate IT understands about collaborative technologies and the E2.0/Web2.0 space.

In some sense, many Corporate IT silos are 1 to 2 years ahead of the vendor with respect to the required sophistication of any consumer product. Most are developed in-house and are guarded as a corporate asset. This is not the Vendor's fault! Maybe Corporate IT doesn't publicize requirements nor participates in Community Incubation as much as it should. This is a separate battle and should be a big part of what defines E2.0.

However, it is also true that the Vendors don't bother to ask and are then very surprised at how forthcoming large institutions are about their needs. It's much easier to repackage a consumer product and find an SMB who will drink the cool-aid, buy the product and in turn, become a statistic to justify First-round funding for a startup. Don't get me wrong, SMBs are a great place to get your feet wet but the vendors aren't marketing to SMBs per se, they are marketing poorly baked consumer products to Enterprise customers.

Something's not right here. To be successful, Enterprise customers and Vendors must learn to communicate needs before the products are fully baked. Otherwise this is all just a waste of time as fledgling companies swimming in the E2.0 pool will simply be drowned out by the few that actually Get It. Wikinomics has to happen at Inception and Development stages of Blogs and Wikis too. Vendors will be surprised at the Top 10 requirements lists for a product to be considered Enterprise2.0-friendly by the actual Enterprise.

Risk Management
Corporate IT is not in the business of Security - this view is extremely narrow. Corporate IT is in the business of Managing Risk. Risk management covers every tier of technology from Infrastructure to the JavaScript that makes the async calls somewhere else. Everything is scrutinized. Everything is consolidated, centralized, made lean and mean if for no other reason than to make the act of scrutinizing a bit more manageable. Yes, even Managing Risk is Managed against Risk. The penalty for goof-ups is extremely costly. Spaghetti Infrastructure and redundant deployments of monolithic apps that cannot be scrutinized in a manageable manner is a time-sucking, money-wasting, Very Bad Thing.

Enterprise technologists think of Technology-based Solutions as portfolio items and have learned (perhaps the hard way) to develop Infrastructure along-side Software, not as an after thought. If you sell to corporate IT, Enterprise2.0-friendliness has to also be shown from the Bottom, Up.

Build vs Buy
Core Competency is loosely "Buy don't Build whatever it is you need but are not selling". Why is it then that many Banks and non-Software/Middle-ware institutions build their own solutions in-house that are years ahead of what vendors are delivering? There is no blame-game being played here, it's just the state of things. Community Incubation parlayed with Wikinomics and Open Source can help address this problem. More posts on this coming soon...

Some Advice to Startups Claiming Eneterprise2.0-friendliness

• If your product is reminiscent of Sharepoint or WebSphere or any other collaboration platform from the Microsofts and IBMs of the world, you will not be able to sell above SMB level. Plug into existing platforms, don't re-invent the wheel, and don't think for a second that one of the behemoths of software will not throw a couple of millions into their own product and not knock you out of the market. Integration through Federation and Synthesis is key.
• At the moment, hosted solutions are a huge turn-off for institutions dealing with SOX compliance - this is pretty much every Bank and Financial Firm.
  
  Banks and Financial Firms will never agree to storing internal anything but throw-away data on the vendor's servers. This is hardly the penetration that the Startup should want. Instead, build an Enterprise Appliance. Sell something that can be brought into the intranet so that data never leaves or enters the firm without absolute and granular control.
  
  Will this story change in the next 3-5 years? Probably. SaaS is just too good to let up. Managed services make financial sense -- they just make the "big boys" very nervous, especially when dealing with unseasoned and unproven vendors.
  
  Appeasement till Transition is key. Changing culture and mindsets around corporate assets is extremely tough. There is a tipping point though. To reach critical mass you have to prove value without being too radical in approach. Solve small problems well, integrate, piggy-back, then make transition appealing.
  
  
• Expose APIs, develop to a Plugin Architecture, expose ALL settings for run-time configuration. If a setting is locked, disable or simply don't show the setting in the Control Panes.
  
  At some point, I will talk about Thin Platforms and how and why these can safely be Open Sourced without disrupting existing revenue streams.
• Stop popping up alerts that notify me when something new happens. If this feature is a must have, please allow me to turn it off or pipe the output to some other service that can control the disruption caused to my very busy work-life.
  
  For example, it doesn't make sense for RSS readers to pop up alerts telling me about the new feeds that were synced to my desktop. The whole value proposition of RSS is that I can check these any time and therefore don't want to nor care to know that I have yet another post to read. I have good old email for that.
  
• Provide Beginner and Advanced modes that toggle the verbosity or amount of detail/options in configuration panes. Exposing as much as possible to runtime tweaking is great but it scares the Average Joes. Most Corporate IT will set the best defaults and lock the risky ones. No need for the end-user to see everything but the most obvious and necessary settings.
• Be aware of how many mouse clicks or actions it takes to get to a feature that makes your product's Top 10 features list. If users can't find it in 0 to 1 clicks, most just won't use it.
• White Labeling. It has to be very easy for institutions to impose their own brand and styling to anything that has a front-end.
• Pictures and Video Tutorials please. Corporate IT has to train it's end-users in large quantities, quickly and cheaply.
  
• Understand Single Sign On, support it. Application based ACLs are more powerful than HTTP level authentication when SSO is in play. Allow LDAP-derived and ad hoc groups/roles when exposing or protecting information owned by your service.
  
• If you expose RSS feeds, expose URL parameters that filter, scope, limit and style your feeds.
• For any concrete web pages that are served up, allow URL parameters that will hide headers, footers, sidebars. The Thin Integration this enables is extremely powerful.

That's all for now. The list can and should grow into a Checklist or a Guide of some sorts. Please feel free to comment, argue, correct, or add to this list.