advocacy2Add my vote for this tag deployment1Add my vote for this tag create new tag
, view all tags

TWiki Success Story of Wind River

Corporate Environment and Challenges

Wind River provides software development tools, real-time operating systems, and advanced connectivity solutions. Founded in 1983, with 1,900 employees in 16 countries worldwide, Wind River is very much a virtual company; teams working on a particular project are typically spread over many locations. With that we have a big challenge of how to communicate effectively between offices.

Everyone takes e-mail for granted, it is a great communication tool. While it solves some of our challenges, there are flaws: E-mail gets lost after some time, however, the content might be needed again in the future; searching e-mail is limited to the e-mail client; e-mail is not hyper-linked and is not structured, so content can't easily be grouped into related topics; e-mail is not version controlled, e.g. it is difficult to see the big picture of an e-mail conversation; last but not least, we get flooded by e-mail.

A static Intranet that is centrally managed by a Webmaster team implies that content update needs to go through the Webmaster -- by design. Employees who see some inaccurate or outdated content on the Intranet are too busy to find out who is responsible for updates, then send out an e-mail requesting an update. This usually results in an Intranet with static, and often inaccurate, content.

Initial TWiki Deployment

In early 2000, Wind River acquired ISI, together with its subsidiary TakeFive, the birthplace of TWiki. TWiki was initially used by TakeFive as a knowledge base for customer support.

After the merger, Wind River started a large software project involving around 100 engineers located in 7 offices on two continents. With this project we introduced a big change in development style, switching from "big bang" product release cycles (with limited code reuse) to product releases based on technology lines. Technology lines (or components) such as an editor and debugger are developed, tested and released independently. Different products are released based on a set of technology lines. The goal is to be more productive by recycling a lot of code, to be able to react quickly to market requirements, and to achieve a common look for the products coming out of the technology lines.

We have been looking for a web based environment where we can keep track of the technology line's teams, schedules, milestones, interdependencies, meeting minutes, code reviews, and where we can store all of the related documents. We considered eRoom and TWiki. Both products have already been in use; eRoom at ISI and TWiki at TakeFive. We decided to go with TWiki because it was more flexible and configurable then eRoom, even though eRoom had a more polished UI and more out-of-box applications. (Later on, other teams using eRoom dropped it and replaced it with TWiki.)

Initially it was challenging to get the buy-in of collaborating more in TWiki and using less e-mail. Mr. TWiki, PeterThoeny, acted as the collaboration coach. For each office we gave virtual trainings on collaboration; instead of teaching technical details we focused more on "pros and cons of e-mail, webmaster maintained Intranets, and TWiki based collaboration", and "why it pays off using online collaboration".

We created one large TWiki web to manage the technology lines. Many TWiki features like forms, embedded search and templates have been used to get different views into the content, for example "show me all recent changes of a technology line", "show me the teams of all technology lines", "show me all interdependencies", "show me the technology line including freeze points used for a particular product release".

TWiki is Growing Up

Other groups within the company started using TWiki after seeing how easy it is to manage projects in TWiki. A big push in TWiki usage happened after the Corporate Council started using TWiki to document their output.

We developed three skins that mimic the Intranet so that employees would feel at home. One looks exactly like the Intranet, as shown in the TWiki Home example on the right. The default skin has no sidebar and is used for most collaboration. The third one has no edit link, it is for Webmaster maintained content.

Although there is occasional competition, the static Intranet and TWiki complement each other. The Intranet is used for corporate official content, TWiki for product and project related content.

We empower and encourage employees to make changes to the content in TWiki. We have an open setup with soft security that works pretty well; this is based on the audit trail we get because of revision control. Access control is used, but only to shield engineering content from the sales front.

A tech writer gave this feedback: "I've become a big TWiki fan. I was skeptical at first, since I usually don't want to bother with things like "collaboration" software. But TWiki has been genuinely valuable in several projects I've worked on in the past 18 months. TWiki encourages simple, consistent markup using a simple, easy-to-learn markup language. For most purposes, the TWiki markup language has just the right balance of versatility and simplicity. (But TWiki is also flexible. You can put any HTML tag into a TWiki page if you need to, and you can attach documents as well.)"

We installed many Plugins available at the TWiki.org web site, like ActionTrackerPlugin, CalendarPlugin, ChartPlugin, HeadlinesPlugin, SpreadSheetPlugin, TWikiDrawPlugin and more. We also developed a few Wind River specific Plugins, for example one Plugin pulls bug tracking data out of an Oracle database and shows it embedded in a TWiki page. Some engineering groups use it to prioritize bug fixes for an upcoming release.

We also built several web based applications on the TWiki platform. One application is a test tracking database where we keep track of test results. Testing an embedded OS including all development tools is a challenge. There is a so called "matrix of pain" where tests need to be done across multiple dimensions like: (Target processor) X (target board) X (host OS) X (windowing system) X (compiler used) and sometimes a few extra ones. The database has two parts:

The first one is the Test Case Documentation Database defining all the possible Test Cases of products, regardless of the release. To manage the complexity of the tests we defined a hierarchy of 4 levels: Test Areas have Feature Sets, which have Test Cases, which have Test Configurations.

The second database is the Test Tracking Database. It has Product Releases, which have Test Phases (Alpha, Beta...), which have a set of Test Runs containing Test Configurations. Test Runs are instantiated Test Cases, pulled from the Test Case Documentation Database. Predefined reports and query by example forms are used to mine the data, for example to see the percent complete of a Test Phase based on the Test Areas.

All this magic is done using TWiki forms, template topics, formatted search, Spreadsheet Plugin and a custom Plugin. This could be done also with a relational database. The advantage of TWiki is that it is very easy to build web based applications using templates and forms. In addition, contributing content can be more natural for the users compared to a relational database application. This is because a TWiki application has structured data, but the user has the flexibility to add unstructured content, such as additional text or attaching test result output files to a Test Run page.

Some groups initially installed their own TWiki at their local offices. Today all installations have been merged into one big TWiki at the Alameda, CA headquarters. This was possible because the reliability and speed of the WAN connecting Wind River offices improved.

Click to enlarge
Click to enlarge
Click to enlarge

Structure of Test Database

TWiki in Full Swing

TWiki based collaboration gradually increased. TWiki is used by all business units; we now have over 1000 registered users (more than half of the employees), 350 regular contributors, 15,000 pages, 100,000 page views per month and 10,000 page changes per month.

TWiki is mainly used by engineering groups, including test teams and tech writers, but also in QA, customer support, product marketing, business development, technical sales, IT, operations and cross functional councils. It is not so much in use by sales and administration because they are intimidated by their perceived complexity of using TWikiShorthands instead of a WYSIWYG editor like MS Word.

Each group is using TWiki in a little bit different way. It can be any combination of: Sharing a project notebook; tracking features, issues, milestones, meeting minutes or release notes; sharing files; listing experts in a field; sharing a glossary of terms; keeping track of test results; keeping track of Balanced Scorecards and more.

One project manager said that his managers spend 20% less time documenting their projects using TWiki compared to the previous setup using HTML editors and FTP.

After two years TWiki is now a mission critical platform for the company. As an executive puts it, "from the PowerPoint presentations in our Quarterly Business Reviews with the CEO we dive into TWiki to get the details".

Monthly page updates


TWiki collaboration helped Wind River to be more efficient and helped to improve the exchange of information. Good coaching, teaching best practises, listening to user requests and fine-tuning the system have been keys for a successfull TWiki deployment.

Through TWiki Wind River has been able to further flatten the flow of information within the company. Here is an analogy. Remember the days before e-mail? Internal communication was letter and fax, usually moving in a hierarchical manner -- up the org chart ladder and down again. E-mail changed all that into a more efficient horizontal way -- TO the recipient and CC the boss. A static Intranet is hierarchical -- update of content is centrally managed. A dynamic Intranet like TWiki is flattened -- employees contribute to the content. The Webmaster now has a different role; he/she is the coach assisting teams with best practices.

About Wind River

Wind River is a worldwide leader in integrated embedded software solutions for creating reliable and innovative connected devices. Wind River provides development tools, operating systems, and advanced connectivity software for use in products in network infrastructure, digital consumer electronics, automotive, industrial, and aerospace/defense markets. Wind River is How Smart Things ThinkTM. Founded in 1981, Wind River is headquartered in Alameda, California, with operations worldwide.

Copyright © 2002 Wind River Systems, Inc. ALL RIGHTS RESERVED. This story may be reproduced, please inform PeterThoeny if you intend to do so. Wind River Systems, the Wind River Systems logo, and How Smart Things Think, VxWorks are trademarks or registered trademarks of Wind River Systems, Inc.

Related Topics

-- PeterThoeny - 13 Jul 2002

Three Years Later

TWiki expanded its role as a mission critical system at Wind River. All engineers are registered, as well as a large percentage of other departments. We now have over 1600 registered users, 500 regular contributors, 70,000 pages, 200,000 page views per month and 20,000 page changes per month.

With so much content it is getting more difficult to find content and navigate to it. As a workaround, some users started to rely too much on bookmarks. We addressed this issue as follows:

  1. Simple TWiki HomePageNavigation - the TWiki Home is now a simple search page, with tabs for FacetedNavigation, where users can navigate by hierarchically listed webs or by employee org structure
  2. We implemented an Engineering Portal with hierarchically organized team home pages
  3. Over time we moved a lot of content from unstructured free-form Wiki content into StructuredWiki applications
  4. Get an experienced librarian to help reorganize and retire content

We built many mission critical TWikiApplications. Here are a few:

  • TWikiNewsPortal - the Intranet home is now a TWiki driven employee news portal where employees can post news and editors can review and release the news. Employees can subscribe to news channels of interest. News feeds are delivered to the Intranet home, via RSS-feed and via aggregated e-mail.
  • Engineering Portal - each team has a home page with a common layout for easy navigation. The team home page has a team logo; a short "what we do" description; a "where we are in the org" tree based on the RenderListPlugin; a section listing current projects; and a customizable sidebar with quick links
  • Product Release Dashboard - shared notebooks where engineers and product marketing folks keep track of software releases, store and sign-off related documents
  • Peer Review Notebooks - track and document code reviews based on Fagan inspections
  • Integration with Bug Tracking System - automatically link to bug entries such as BUG:12345, and dynamically generate trend reports and trend graphs in TWiki pages based on SQL queries.
  • Inventory System - to track capital assets of the Engineering department
  • Document Database - document management system to store and index external documents
  • Corporate Glossary - listing company specific terms, industry terms and acronyms
  • Engineering Handbook - place for new employees to answer "how do I" and "what is" questions
  • Engineering FAQ - place for employees to look up frequently asked questions
  • Escalations Tracker - customer escalations are tracked with a TWikiForms application. A FormattedSearch lists external and internal contacts, escalation date, deadlines, related defect numbers and product. The deadlines are color coded using SpreadSheetPlugin formulae: Green for OK, orange if within 7 days, and red if deadline is passed
  • Support Status Board - to keep track of who is on call in the support department
  • Professional Services Opportunity Tracker - to track work opportunities
  • Corporate Calendar with Official Holidays - where teams can import the data into their own team calendar using CalendarPlugin

Some of these applications are fairly simple, others are sophisticated applications that took time to design, implement and deploy. All applications have one thing in common: They started as a need while working with free-form Wiki content. It is important not to over-engineer things; keep it simple, and add structure only as needed. As a result you get custom tailored applications that do exactly what the customer wants.

-- PeterThoeny - 29 Jul 2005

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2010-07-04 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.