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.