Content Management Systems Reviews - Documentum - Documentum for SharePoint

Documentum has few products for SharePoint users. These products are: Documentum Repository Services for SharePoint, My Documentum for SharePoint, Documentum SourceOne for SharePoint. In this post, I am going to describe these products.

Documentum Repository Services for SharePoint

Documentum Repository Services for SharePoint allows organizations to manage SharePoint Content and leverage it by re-routing content automatically to the EMC Documentum repository. Repository Services for SharePoint aggregates content from disparate SharePoint sites, providing centralized management and the ability to apply compliance, business, and operational control to SharePoint content without impacting the end user. SharePoint does not show that content is being managed by Documentum and SharePoint users and tools are not affected.

These repository services has platform for secure content including common policy enforcement across systems, utilization of existing retention and records processes, and structured disposition.

Unstructured content is not stored in SharePoint and so SharePoint SQL repository is not being overwhelmed by unstructured content thus providing organization with the substantial cost savings associated with hierarchical storage management, de-duplication, and reduced SQL server backup costs.

Repository services stores content in dynamically created folder location where policies and rules can be applied automatically. All of SharePoint related properties are stored in an accessible XML file for future use.

Once stored in Documentum, the content can be managed in the same way as any other Documentum object – retention policy can be applied to the content and it can be categorized as a specific type of content, routed through a workflow, published to a web site, etc.

This capability improves overall content manageability, enhances performance and scalability across organization’s information architecture, and reduces storage costs.

My Documentum for SharePoint

My Documentum for SharePoint provides native access to the EMC Documentum Content Server through the SharePoint user interface. Users can access their Documentum library through SharePoint interface while maintaining control and security over their content through Documentum.

Documentum includes integrated web parts that can be easily used with any existing SharePoint site. These web parts provide direct user access to content that is being managed within a Documentum Content Server repository through the SharePoint user interface.

Users can easily configure SharePoint to include Documentum specific functions such as view, and edit the content, lifecycles, and renditions as well as leverage advanced search capabilities in Documentum libraries.

It also has the following features:

• It provides advanced content protection through a single security model applied to all content, regardless of application. My Documentum for SharePoint is a Documentum client that emulates the SharePoint user experience.
• It provides the appropriate level of centralized document control and policy management to SharePoint users.
• It preserves project information that could be re-used in future.
• It leverages single sign-on using either Documentum or SharePoint credentials.
• It provides virtual document creation capabilities with multiple nested documents in multiple formats.
• It provides renditions management to allow rendition of documents in a variety of popular formats. View all renditions in the repository even those created by other content transformation applications.
• It leverages the full capabilities of Documentum content management platform for secure content including common policy enforcement across systems, utilization of retention and records management processes and structured disposition.
• It supports critical data management requirements, including regulatory compliance, data retention, and document lifecycle management throughout the enterprise.
• Define specific sequence of lifecycle as content passes through specific phases of the lifecycle such as creation, review, and approval.
• Use Documentum tools to customize the display of attributes within web parts providing consistency across all applications. A separate configuration mode affects only the Documentum web parts.
• It provides quick, out-of-box deployment with no customization required.

SharePoint makes content widely accessible while Documentum enhances protection of content. Documentum enables content security and provides solutions for encryption, access control, and fraud protection. This way users can leverage the full capabilities of Documentum content repository while providing easy to use, widely accessible solution for SharePoint users.

Documentum SourceOne for SharePoint

Documentum SourceOne for SharePoint helps organizations to improve performance of SharePoint environment, reduce backup times to meet service level agreements and reduce operational costs.

By externalizing active content, the burden of SharePoint servers can be reduced resulting in quicker search and retrieval times and lower primary storage costs. Storage utilization monitoring ensures that current investments in storage resources are fully optimized.

Inactive content can be moved out of SharePoint environment. By archiving inactive content to a centrally managed archive, your organization can employ proactive information governance strategy and benefit from centralized content archiving. This enables the consistent application of retention, disposition, and overall lifecycle management policies and ensures that the right data is retained and managed according to industry and corporate regulations. By archiving SharePoint content into the same central archive as other unstructured content search and discovery is simplified. Organizations can ensure that critical content is retained and quickly find and produce content when required to do so in audits, investigations, and litigations.

Documentum SourceOne for SharePoint allows user to continue their work in the environment of their choice. It ensures user transparency and maintains complete content accessibility to both active and archived content from within SharePoint. This product leverages Microsoft recommended APIs, maintain native Microsoft integrations, existing workflows, and explicit document links.

Documentum SourceOne for SharePoint enables organizations to manage the explosive growth of information and proliferation of inactive or orphaned SharePoint sites and all the content kept within them. Proactive removal of SharePoint content from supported Microsoft SQL databases and archival them into EMC SourceOne can be automated based on rules and policies.

This product would help to reduce IT costs associated with information retention and disposition by leveraging tiered storage and deduplication capabilities, and driving efficiency in archiving applications. It also enables common policy management and information access across many applications, delivering integrated archiving and compliance.

Content Management Systems Reviews - Open Text

Open Text Corporation is the software company which provides enterprise content management (ECM) software solutions. This software combines content lifecycle management, business processes, and collaboration. It includes the underlying platform to manage most content types, ranging from user generated content in social networks to data in enterprise resource management systems. These ECM technologies can be used to address end user engagement, business agility, and cost and risk reduction.

Open Text sells software licenses including support and maintenance, offers worldwide consulting services, software training, and individual support packages.

Because Open Text has many products that would be interesting to you, it is impossible for me to describe all of them in one post. I am going to break up the description of Open Text products into few posts. Today, I am going to describe Open Text product offerings in general. In my future posts, I will describe specific products.

Major Open Text Product Offerings

Open Text ECM Suite

The Open Text ECM Suite integrates multiple technologies for document management, records management, web content management, portal, digital asset management, email management, and content lifecycle management. Other components include electronic discovery, auto-classification, document capture, document imaging and digital faxing solutions. The suite provides functions for team collaboration, forums, blogs, wikis, and real-time instant messaging and collaboration. These functions are connected through business process management tools to each other and to other business applications and processes.

Open Text eDocs

Open Text eDOCS products (formerly Hummingbird Enterprise), complement the Open Text ECM Suite. They are integrated with OpenText ECM Suite. eDocs products are used for managing all forms of content and also include collaboration, forums, blogs, wikis, instant messaging, and provide business process management tools. These products are widely used in pharmaceutical companies.

Open Text StreamServe Products

Part of the Open Text ECM Suite, Open Text StreamServe products are customer communications management software solutions that help organizations process and deliver highly personalized documents in any paper or electronic format. They enhance customer interaction capabilities enabling the automation of customer communications for business-to-business (B2B) and business-to-consumer (B2C) marketing, as well as customer service scenarios.

Designed to address the "last mile" of communication between an organization and its customers, StreamServe products help to improve and expand business relationships and customer experience. They enable companies to automatically create personalized documents in high volumes through rules-based dynamic assembly and present them to customers, partners, and suppliers in multiple formats and through any channel they prefer.

Open Text StreamServe products scale across a company's document-driven business processes and are designed for easy integration with ERP and supply-chain systems and applications, including those from SAP.

Simple to deploy and maintain, StreamServe products deliver dynamic composition, document process automation, and output management capabilities to meet the demanding challenges of today’s businesses for producing and delivering highly customized documents in any format.

Open Text Business Process Management Products

Open Text Business Process Management solutions (formerly Global 360 and Metastorm) address the broadest spectrum of process improvement needs. From enterprise architecture and business process analysis to delivering platforms for case management and business process management applications.

OpenText MBPM is the industry leading solution for rapid design and deployment of process solutions for mission critical business applications.

Open Text Process360 for Microsoft SharePoint accelerates the delivery of process applications that leverage your Microsoft technologies (SharePoint, SQL, Lync, Office, Visio, etc.) while improving the management of people and processes.

Open Text Case360 is the solution that allows businesses to rapidly create and deploy business process applications built on a dynamic case management foundation.

Open Text Provision for Enterprise Architecture offers multi-layered visibility into business strategies, including how people, processes, systems, and technologies can be aligned to attain them.

Open Text Provision for Business Process Analysis allows business and IT users to collaborate on process analysis and design to support business process improvement initiatives.

Open Text Portfolio Products

OpenText Portfolio offerings include the following distinct content and data management products and services that are designed to fulfill specific requirements:

Open Text Connectivity Solutions (Hummingbird)

Open Text Content Lifecycle Management, RKYV Edition

Open Text Content Viewing Solutions (Spicer)

Open Text Document & Report Management for IBM AS/400 iSeries (Gauss)

Open Text Eloquent Media Server

Open Text Fax & Document Distribution (Captaris)

Open Text FirstClass

Open Text Integrated Document Management (IDM)

Open Text Records & Documents, Vignette Edition (VRD)

Open Text Report & Output Management (Vista Plus)

Open Text Social Workplace

Open Text Web Site Management (RedDot)

Open Text Workflow Server, .NET Edition (Captaris Workflow)

Please follow me on this blog for a description of individual Open Text products.

Twiki - Open Source Enterprise Wiki

In my last post on wiki applications, I mentioned that there are three types of wiki applications: public wiki, enterprise wiki, personal wiki. One of enterprise wiki is Twiki which is open source wiki. In my today's post, I am going to describe Twiki.

TWiki is a flexible, powerful, and easy to use enterprise wiki, enterprise collaboration and web application platform. It is a Structured Wiki, typically used to run a project management system, a document management system, a knowledge base, a team portal or any other groupware tool, on an intranet, extranet or the Internet. Users without programming skills can create web applications.

Developers can extend the functionality of TWiki with plugins. Users can create wiki applications using the TWiki Markup Language. TWiki looks and feels like a normal Intranet or Internet web site. However it also has a Edit link at the bottom of every topic (web page); everybody can change a topic or add content by just using a browser. TWiki fosters information flow within an organization, lets distributed teams work together seamlessly and productively, and eliminates the one webmaster syndrome of outdated intranet content.

TWiki has been downloaded over 500,000 times and is used daily by millions of people in over 100 countries. Some larger deployments have several 100,000 pages and over 10,000 users. TWiki is developed by an active open source community.

TWiki is installed on many web sites, mainly behind corporate firewalls. Many major companies use TWiki because it is very user friendly compared to some well established commercial groupware systems. Companies are deploying TWiki in different ways, and TWiki is quite flexible to adapt to different needs.

This is a non- comprehensive list of how TWiki is being used:

• to replace a static intranet. Content is maintained by the employees, thus eliminating the "one webmaster syndrome" of outdated and insufficient intranet content;
• as a knowledge base and FAQ system;
• to design and document software projects;
• to track issues (i.e. bugs) and features;
• as a document management tool;
• to collaborate on common goals;
• as a software archive, i.e. the TWiki Plugins archive;
• as a company internal message board, i.e. for job listings.

Twiki Major Features

• Any web browser: Edit existing pages or create new pages by using any web browser. There is no need for ftp or http put to upload pages.
• Edit link: to edit a page, simply click on the Edit link at the bottom of every page.
• Auto links: web pages are linked automatically. You do not need to learn HTML commands to link pages.
• Text formatting: simple, powerful and easy to learn text formatting rules. You write text like you would write an e-mail.
• Webs: Pages are grouped into TWiki webs (or collections). This allows you to set up separate collaboration groups.
• Search: full text search with/without regular expressions.
• E-mail notification: get automatically notified when something has changed in a TWiki web.
• Structured content: use TWiki forms to classify and categorize unstructured web pages and to create simple workflow systems.
• File attachments: upload and download any file as an attachment to a page by using your browser. This is similar to file attachments in an e-mail, but it happens on web pages.
• Revision control: all changes to pages and attachments are tracked. Retrieve previous page revisions and differences between them. Find out who changed what and when.
• Access control: define groups and impose fine grained read and write access permissions based on groups and users.
• Variables: use variables to dynamically compose your pages. This allows you to dynamically build a table of contents, include other pages or show a search result embedded in a page.
• TWiki Plugins: enhance the TWiki functionality with server side Plugin modules. Developers can create Perl Plugins using the TWiki Plugin API.
• Application Wiki: contributors use the TWiki platform to create web applications. The TWiki Variables, Plugins and sample applications offer a rich environment where domain-specific applications can be built efficiently by contributors with moderate skill sets. Developers can create new Plugins to enhance the functionality of TWiki even further.


Some example applications:
• Call Center Status Board: simple status board where time and person can be picked from a list.
• Change Request: generic change request application.
• Meeting Minutes: keep track of meeting minutes with action items.
• Search Book Titles: simple application to search a library of books.
• Simple FAQ: FAQ with all questions on one page and an automatic TOC.
• Templates and skins: a flexible templating system separates program logic and presentation. Skins overwrite template headers and footers; page content is unaffected.
• Managing pages: individual pages can be renamed, moved and deleted through the browser.
• Managing users: web based user registration and change of password.
• What's new: see recent changes of TWiki webs. The change log can also be exported in XML RSS format for news syndication.
• Statistics: create statistics of TWiki webs. Find out most popular pages and top contributors.
• Preferences: four levels of preferences: TWikiPreferences for site-level; WebPreferences for each web; user level preferences; and page level preferences.
• Conflict resolution: content is merged automatically if more than one user edits a page at the same time. In rare cases where a conflict cannot be resolved automatically, users are warned and guided to resolve the conflict manually.
• Referred-By: find out back-links to a page.

TWiki has a plugin API that has spawned over 400 extensions to link into databases, create charts, tags, sort tables, write spreadsheets, create image gallery and slideshows, make drawings, write blogs, plot graphs, interface to many different authentication schemes, track Extreme Programming projects and so on.

TWiki as a structured wiki provides database-like manipulation of fields stored on pages, and offers a SQL-like query language to embed reports in wiki pages. Wiki applications are also called situational applications because they are created ad-hoc by the users for very specific needs. Users have built TWiki applications that include call center status boards, to-do lists, inventory systems, employee handbooks, bug trackers, blog applications, discussion forums, status reports with rollups and more.

The interface of TWiki is completely skinnable in templates, themes and CSS. It includes support for internationalization with support for multiple character sets, UTF-8 URLs, and the user interface has been translated into Chinese, Czech, Danish, Dutch, French, German, Italian, Japanese, Polish, Portuguese, Russian, Spanish and Swedish.

TWiki is primarily used at the workplace as a corporate wiki to coordinate team activities, track projects, implement workflows and as an Intranet Wiki. The TWiki community estimates 40,000 corporate wiki sites as of March 2007, and 20,000 public TWiki sites. TWiki customers include Fortune 500 such as Disney, Google, Motorola, Nokia, Oracle Corporation and Yahoo!, as well as small and medium enterprises,such as ARM Holdings, and DHL. TWiki has also been used to create collaborative internet sites, such as the City of Melbourne's FutureMelbourne wiki where citizens can collaborate on the future plan.

TWiki is implemented in Perl. TWiki is a cgi-bin script written in Perl. It reads a text file, hyperlinks it and converts it to HTML on the fly.Wiki pages are stored in plain text files. Everything, including metadata such as access control settings, are version controlled using RCS. RCS is optional since an all-Perl version control system is provided. TWiki scales reasonably well even though it uses plain text files and no relational database to store page data. Many corporate TWiki installations have several hundred thousand pages and tens of thousands of users. Load balancing and caching can be used to improve performance on high traffic sites.

TWiki has database features built into the engine. A TWiki Form is attached to a page as metadata. This represents a database record. A set of pages that share the same type of form build a database table. A formatted search with a SQL-like query can be embedded into a page to construct dynamic presentation of data from multiple pages. This allows for building wiki applications and constitutes the TWiki's notion of a structured wiki.

Structured Content Management

Organizations of all sizes are beginning to realize how content and its reuse across the enterprise can improve productivity. The need for change is driven by the desire to better manage information assets (documents, creative ideas, illustrations, charts, graphics, multimedia, etc.) and eliminate costly processes that fail to facilitate the effective and consistent re-use of content.

Content reuse can take a variety of forms. The most common reuse scenario is dynamically updating multiple web pages when content is added or removed from a site. There are also content reuse opportunities across multiple web sites, as in the case of co-branding and syndication. Content reuse is critical and often complex when supporting print and web publishing. Perhaps the biggest impact content reuse is in efficient multilingual publishing.

To reuse content it must be structured. Structured content simply means that the information is stored in a format that defines and describes the content. Extensible Mark-Up Language (XML) is a simple and effective format for creating and managing information. Using XML you can describe the content that you are managing, so a headline will actually be defined as a headline, and likewise for a price, a product description, a caption, etc.

Although structuring takes some planning, the benefit is enormous. You can easily re-use text and media for a variety of purposes. You can create publications quickly because images and text are easy to find and put together. Updating your publications is easier because you only need to make changes in one place, and it updates everywhere the content is used. Managing structured content happens in an XML-based content management system (CMS).

There are often great benefits to content structure. Benefits include:

• making content more retrievable and re-usable;
• reducing costs and complexity of translation;
• enforcing authoring, style, and branding guidelines;
• improving information interchange.

XML is the industry standard format for structuring content. It is very easy to work with and is easy to migrate to other formats. Graphics, video, Word documents, PDF's and other files are wrapped in XML to provide structure and metadata that makes the files easy to find and manage. XML was explicitly designed to represent the very hierarchical models of content.

There are four basic parts critical to structuring information:

• defining content types;
• identifying rules of content hierarchy;
• creating modular content units;
• applying standards consistently.

Defining Content Types

When you begin to analyze your existing documentation and future requirements, think about your content according to its informational type rather than its format. Procedures, topics, facts, terms, definitions, prices, product numbers, and product descriptions are common information types.

As you continue to analyze the content you create, you will likely discover that many content types are reusable. For instance, you may discover that there is no reason that your product description should be any different regardless of where it is published.

Identifying Rules of Content Hierarchy

The most significant way that structured documents differ from unstructured ones is that structured documents include rules. These rules formalize the order in which text, graphics, and tables may be entered into a document by an author. For example, in an unstructured document, a paragraph has specific formatting - font, size, and spacing. In a structured document, this same paragraph also has an exterior wrapper that governs the elements that are allowed to appear before and after it. The elements' rules are defined in a document type definition (DTD) or schema.

Structured content management implies moving away from formatting cues to signal such relationships within a document and instead working with information rules. This is where the power of the information model comes from, but also the difficulties in change management, in ways authors are used to working with CMS.

Creating Modular Content Units

Structured content management requires that you begin to look at the content you create as separate, identifiable chunks of information that can be reassembled differently depending on audience, purpose, or delivery method. This represents an intentions based analysis, and not an academic exercise. How, where, and when you intend to re-use that content should drive your modularity.

These chunks of information, once identified and tagged, can be reassembled (reused/repurposed) in other information products. They can even be reused in a different order. Modular content from a source document could be reused in a marketing brochure, user manual, and customer-facing web site.

Using Standards Consistently

At a subconscious level, you may understand the importance of following internal standards, branding guidelines, and formalized structure. But, it is human nature to continue to find reasons to override templates or alter the format "just this one time."

Breaking the rules is not allowed when it comes to structured authoring. Reuse is only possible when your information is consistently structured. Imagine how useless a phone directory would be if the data entry clerks at the phone company were allowed to enter information in any order they choose. Some clerks use the first field for first name, others for last name. And instead of last name, first name, ordered alphabetically, what if some of the listings were first name, last name?

Of course, most enterprise content is not as highly structured as a phone book. But if your goal is to reuse content, it must be be structured consistently. If adhering to a particular document standard seems painful, re-examine whether the content is really as structured as you think, or change your expectations about how much information can be re-used and easily shared. Document models can be made easier and more flexible, but with a cost in downstream utility of the information.

XML Building Blocks

You have identified your content types, chunked them into modular components intended for re-use, established the relationships among those chunks, and decided that you can live with them in a componentized fashion to the extent that your team will follow that structure consistently.

These concepts are important in structured XML content management:

• Elements
• Attributes
• DTDs and Schemas

Elements

The basic unit of information is called an element. Elements can be text, graphics, tables, or even containers for other elements. In short, everything is an element.

When you create an information model, you define a document hierarchy. A hierarchy specifies the order in which elements are allowed to be used in a particular information product.

For example, for a set of user documentation, a ChapterTitle always begins a chapter, followed by a synopsis and a bulleted list of topics in the chapter. Elements are powerful tools that allow you to create structured content appropriate for reuse.

Attributes

XML elements can be extended to contain more information than just a label. Elements have attributes which is additional information about each element. For example, a chapter element can have an optional attribute of author and the author's university affiliation. These attributes allow to find all instances of a specific author or university.

Because you can classify information based on attributes, you can create new information products from your source content that you would otherwise have to cobble together manually.

Documentation authors have long benefited from adding attributes to the elements of content they create, allowing readers to use "help" applications and user guides more intelligently. Attributes can help indicate in which information products an element should appear, and in which languages. For example, some elements should be present on a web site, but may not be appropriate for a printed guide; others should appear in the Spanish version of a document, but not in the Portuguese.

Attributes make content smart enough to know where to go. For example, elements and attributes can be harnessed to create dynamic content for web-based information products, based on the personal preferences of your users.

DTDs and Schemas

You define the structure of an information product in a document type definition (DTD) or a schema. A schema, unlike a DTD, is an actual XML document, but both are used to define information models. Both provide considerable modeling power and can help facilitate content reuse and multi-channel publishing.

Wiki Applications

Wiki is a Hawaiian word meaning "fast" or "quick". Wiki applications is is collaborative software that runs a wiki. A wiki is a web site which users can add, modify, or delete its content via a web browser using a simplified markup language or a rich-text editor. Wiki allows users to create and collaboratively edit web pages via a web browser. Examples of wiki use include community websites, corporate intranets, knowledge management systems, and notetaking.

Main features of Wiki:

• Wiki users can edit any page or to create new pages within the wiki web site, using only a plain web browser without any extra add-ons. 
• Wiki promotes meaningful topic associations between different pages by making page link creation almost intuitively easy and showing whether an intended target page exists or not. 
• Wiki is not a carefully crafted site for casual visitors. Instead, it seeks to involve the visitor in an ongoing process of creation and collaboration that constantly changes the web site landscape.

Wiki enables users to write documents collaboratively, using a simple markup language and a web browser. A single page in a wiki website is referred to as a wiki page, while the entire collection of pages, which are usually well interconnected by hyperlinks, is the wiki. Wiki is essentially a database for creating, browsing, and searching through information. A wiki allows for non-linear, evolving, complex and networked text, argument and interaction.

A defining characteristic of wiki technology is the ease with which pages can be created and updated. Most wikis keep a record of changes made to wiki pages; often, every version of the page is stored. This means that authors can revert to an older version of the page, should it be necessary because a mistake has been made.

Within the text of most pages there are usually a large number of hypertext links to other pages. Wikis generally provide one or more ways to categorize or tag pages to support the maintenance of such index pages. Users can create any number of index or table-of-contents pages, with hierarchical categorization or whatever form of organization they like. Most wikis have a backlink feature, which displays all pages that link to a given page. It is typical in a wiki to create links to pages that do not yet exist, as a way to invite others to share what they know about a subject new to the wiki.

Wikis are generally designed with the philosophy of making it easy to correct mistakes, rather than making it difficult to make them. Thus, while wikis are very open, they provide a means to verify the validity of recent additions to the body of pages. The most prominent, on almost every wiki, is the Recent Changes page which is a specific list numbering recent edits, or a list of edits made within a given time frame.

From the change log, other functions are accessible in most wikis: the revision history shows previous page versions and the diff feature highlights the changes between two revisions. Using the revision history, an editor can view and restore a previous version of the article. The diff feature can be used to decide whether or not this is necessary. A regular wiki user can view the diff of an edit listed on the "Recent Changes" page and, if it is an unacceptable edit, consult the history, restoring a previous revision.

In case unacceptable edits are missed on the "recent changes" page, some wiki engines provide additional content control. It can be monitored to ensure that a page, or a set of pages, keeps its quality. A person willing to maintain pages will be warned of modifications to the pages, allowing him or her to verify the validity of new editions quickly.

Some wikis also implement "patrolled revisions," in which editors with the requisite credentials can mark some edits as not vandalism. A "flagged revisions" system can prevent edits from going live until they have been reviewed.

Most wikis offer at least a title search, and sometimes a full-text search. The scalability of the search depends on whether the wiki engine uses a database.

There are essentially three types of usage for wiki: public wikis with a potentially large community of readers and editors, enterprise wikis for data management by corporations and other organizations, and personal wikis, meant to be used by a single person to manage notes, and usually run on a desktop. Some wiki applications is specifically geared for one of the usage types, while other software can be used for all three, but contains functionality, either in its core or through plugins, that help with one or more of the usage types.

Public Wikis

Public wikis are wikis that can be read by anyone and they usually (though not always) can be edited by anyone as well with sometimes required registration. Among public wikis, MediaWiki is the major application. It is used for the most popular public wiki, Wikipedia, as well as for the most popular wiki farm, Wikia, and it is the most popular application in use on other public wikis as well. Other wiki engines used regularly for public wikis include MoinMoin and PmWiki, along with many others.

Enterprise Wikis

Enterprise wiki application is used in a corporate (or organizational) context, especially to enhance internal knowledge sharing, with a greater emphasis on features like access control, integration with other software, and document management.

Most wiki applications are enterprise solutions including Confluence, Socialtext, Jive Engage, SamePage, and Traction TeamPage. In addition, some open source wiki applications also describe themselves as enterprise solutions including Foswiki which calls itself "free and open source enterprise collaboration platform", and TWiki, which calls itself "Open Source Enterprise Wiki". Some open source wiki applications, though they do not specifically call themselves as enterprise solutions, have marketing materials geared for enterprise users, like Tiki Wiki CMS Groupware and MediaWiki. Many other wiki applications have also been used within enterprises.

Within organizations, wikis may either add to or replace centrally managed content management systems. Their decentralized nature allows them to disseminate needed information across an organization more rapidly and more cheaply than a centrally controlled knowledge repository. Wikis can be used for document management, project management, customer relationship management, enterprise resource planning, and many other kinds of data management.

Features of wikis specifically helpful to a corporation include:

• Allow to connect information using quick and easy to create pages containing links to other corporate information systems, like people directories, CMS and thus build up knowledge bases. 
• Avoiding e-mail overload. Wikis allow all relevant information to be shared by people working on a given project. Only the wiki users interested in a given project need look at its associated wiki pages, in contrast to high-traffic mailing lists which may burden subscribers with many messages, regardless of relevance to particular subscribers. It is also very useful for the project manager to have all the communication stored in one place, which allows them to link the responsibility for every action taken to a particular team member. 
• Organizing information. Wikis allow users to structure new and existing information. As with content, the structure of data is sometimes also editable by users. 
• Building consensus. Wikis allow the structured expression of views disagreed upon by authors on a same page. This feature is very useful when writing documentation, preparing presentations and so on. 
• Access rights, roles. Users can be forbidden from viewing and/or editing given pages, depending on their department or role within the organization. 
• Knowledge management with comprehensive searches. This includes document and project management, as well as using a wiki as a knowledge repository useful during times of employee turnover, retirement and so on.

Personal Wikis

Application that is specifically designed for running personal wikis includes NotePub, Pimki and Tomboy. Other, more general, wiki applications have components geared for individual users, including MoinMoin, which offers a Desktop Edition.

Wiki applications can include features that come with traditional content management systems, such as calendars, tasks lists, blogs, and discussion forums. All of these can either be stored via versioned wiki pages, or simply be a separate piece of functionality. Applications that support blogs with wiki style editing and versioning is sometimes known as "bliki" software. Tiki Wiki CMS Groupware is an example of wiki software that is designed to support such features at its core. Many of the enterprise wiki applications, such as TWiki, Confluence and SharePoint, also support such features, as do open source applications like MediaWiki and XWiki, via plugins.

Wiki software can let users store data via the wiki, in a way that can be exported via the Semantic Web, or queried internally within the wiki. A wiki that allows such annotation is known as a semantic wiki. The current best-known semantic wiki software is Semantic MediaWiki, a plugin to MediaWiki.

SharePoint User Interface

In my last post on SharePoint architecture, I mentioned that there are few parts in SharePoint architecture: farms, web applications, site collections, service applications, administration and security. User interface is represented by site collections. In my today's post, I am going to describe SharePoint user interface.

Site collection is the top-level SharePoint site which contains children sites which are organized in a hierarchy. When you create a site at the root of a Web Application, you create a site collection. In other words, a SharePoint site collection is a hierarchical set of sites that can be managed together. Sites within a site collection have common features, such as shared permissions, galleries for templates, content types, and web parts, and they often share a common navigation. Creation of site collections usually performed by a system administrator.

Site collection has hierarchical structure. When a site collection has been created, next step is to create a site. A site is a single SharePoint site within a site collection. Creation of sites can be delegated to users of a site collection. A site can inherit permissions and navigation structure from its parent site collection, or they can be specified and managed independently.

There are times when it is appropriate to create an entire site collection, and there are times when it makes more sense to create a single site. For instance, if you have many projects that fit within a larger context, it makes sense to create a single site collection for that context, and create sites to manage each project. For example, it makes sense for the engineering department to have a separate site collection from the legal department. An engineering department might have one site collection and use that site collection to house multiple sites, one site per engineering project.

A site may contain sub-sites, and those sub-sites may contain further sub-sites. Typically, sites need to be created from scratch, but sites can also be created according to pre-defined templates that provide previously set-up functionality. Sites have navigation, themes/branding, custom permissions, workflows, and have the ability to be configured or customized in a number of ways.

If the site is used for the document management, next step after the site in the SharePoint hierarchy are libraries and lists. A SharePoint Site is a collection of lists, libraries, pages, and web parts.

A list is a collection of similar items. A list contains columns that define the item metadata. Each item stored in a list shares the same metadata. For instance, you can have a list of links called "my links", where each item has a URL, a name, and a description.

Lists resemble database tables in structure and behavior. Lists support various field or data types, and can have triggers that react to list events such as creating, updating or deleting items. In addition lists can be configured to filter, sort or group items based on item data or properties.

Lists can be based on list templates, such as calendars, contact lists, tasks, announcements. You can create multiple lists based on a single list template. Lists can include workflows.

A library contains documents. In a library a document is the item with library metadata supporting the document. Each item in the library refers to a file that is stored in SharePoint database. A library is a location on a site where you can create, collect, update, and manage files.

You can customize libraries in several ways. You can control how documents are viewed, tracked, managed, and created. You can track versions, including how many and which type of versions, and you can limit who can see documents before they are approved. You can use workflows to collaborate on documents in libraries. You can specify information management policies to manage the handling and expiration of documents within libraries.

There are few types of libraries:

Document library is used for all types of documents.

Picture library is used to store digital pictures or graphics. Although pictures can be stored in other types of libraries, picture libraries have several advantages. For example, from a picture library you can view pictures in a slide show, download pictures to your computer, and edit pictures with graphics programs. Consider creating a picture library if your team reuses many graphics, such as logos and corporate images, or if you want to store pictures of team events or product launches.

Wiki page library is used create a collection of connected wiki pages. A wiki enables multiple people to gather routine information in a format that is easy to create and modify. You can add to your library wiki pages that contain pictures, tables, hyperlinks, and internal links. For example, if your team creates a wiki site for a project, the site can store tips and tricks in a series of pages that connect to each other.

Form library is used to store and manage electronic forms.

Reports library helps organizations create, manage, and share information contained in business data web parts, key performance indicator (KPI) web parts, and Excel web access web parts used for business intelligence analytics. The Records Center site template has a reports library by default, but anyone who can create document libraries within a site collection can create a report library. The reports library includes a version history for each report, and archives previous versions. Users can create new versions of reports for special events or milestones, and later revert to a previous report.

Translation management library - helps organizations create, store, and manage translated documents by providing both views and specific features that facilitate the manual document translation process. The translation management library is designed specifically to store documents and their translations. The library tracks the relationship between a source document and its translations, and it groups all of these documents together to make them easy to find. Additionally, the library can be configured with a special translation management workflow that is designed to help manage the manual document translation process.

Data connection library is used to centrally publish connection files to make it easy for users to find and use the data sources they need. Data connection files are easy to create and update, and solution designers can easily reuse them from within the Microsoft Office system client applications.

Slide library is used to share individual slides from a presentation, reuse slides, track the history of a slide, compile individual slides into a presentation, and receive notifications when a slide in a presentation has changed. Users can publish slides to a Slide Library from PowerPoint.

SharePoint has three primary page content-types: Wiki pages, Web-part pages, and Publishing Pages. The default page type is a Wiki Page, which enables free-form editing based on the ribbon toolbar. It is possible to insert Web-parts into any page type.

Web parts are sections that can be inserted into Pages in SharePoint sites. Their typical uses are displaying content defined in the web-part's settings, displaying items from lists and libraries, providing access to features in the SharePoint.

SharePoint site can also be created as Wiki site, blog site, project management site, etc. I described Wiki sites in one of my previous posts on SharePoint, In my future posts, I will describe other site types.

Business Analysis - Use Cases

In my last post on business analysis, I described user stories and gave a comparison between user stories and use cases. In my today's post, I am going to describe use cases.

A use case (a case in the use of a system) is a list of steps, typically defining interactions between a role known as an "actor" and a system to achieve a goal. The actor can be a human or an external system.

There is no standard way to write a use case, and different formats work well in different cases. There are few templates to use for a use case.

Simple Use Case

Title: goal the use case is trying to achieve

Main Success Scenario: numbered list of steps

Step: a simple statement of the interaction between the actor and a system

Extensions: separately numbered lists, one per Extension

Extension: a condition that results in different interactions from the main success scenario. An extension from main step 3 is numbered 3a, an extension from main step 4 is numbered 4a, etc.

Complete Use Case

Title: an active-verb goal phrase that names the goal of the primary actor

Primary

Actor

Goal in Context

Scope

Level

Stakeholders and Interests

Precondition

Minimal Guarantees

Success

Guarantees

Trigger

Main Success Scenario

Extensions

Technology and Data Variations List

Related Information

Casual Use Case

Title: goal

Primary Actor

Scope

Level

Story: the body of the use case is simply a paragraph or two of text, informally describing what happens

Example of a Simple Use Case

Use Case Name: Place Order

Actors: Shopper, Fulfillment System, Billing System

Use Case Description: after the user selected items to purchase, user orders the items. The user will provide the payment and shipping information. The system will respond with confirmation of the order and a tracking number that the user can use to check on order status in future. The system will also provide the user with an estimated delivery date for the order which will include all selected items. The user may already have an account with the company with billing and shipping information.

Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but don't to be human. An actor might be a person, a company or organization, a computer program, or a computer system — hardware, software, or both. The term "actors" are frequently interchanged with the term "users".

Actors are always stakeholders, but many stakeholders are not actors, since they never interact directly with the system, even though they have the right to care how the system behaves. For example, the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance could all be stakeholders but are unlikely to be actors.

Similarly, a person using a system may be represented as different actors because he is playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account, or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank.

Actors are often working on behalf of someone else. If actor is "sales rep for the customer" or "clerk for the marketing department" to capture that the user of the system is acting for someone else. This tells the project that the user interface and security clearances should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results.

A stakeholder may play both an active and an inactive role. For example, a Consumer is both a "mass-market purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product). In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional beneficiary" (a stakeholder who benefits from the use of the system). For example, when user "Joe" withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.

Look for actors among the stakeholders of a system, the primary and supporting (secondary) actors of a use case, the system under design, and finally among the "internal actors", namely the components of the system under design.

The relationships between all the use cases and actors are represented in a Use Case Diagram.

A use case diagram is a graphical representation of a user's interaction with the system and depicting the specifications of a use case. A use case diagram can portray the different types of users of a system and the various ways that they interact with the system. This diagram is typically used in conjunction with the textual use case and is often accompanied by other types of diagrams as well.

While a use case itself might drill into a lot of detail about every possibility, a use case diagram can help provide a higher-level view of the system. They provide the simplified and graphical representation of what the system must actually do.

Limitations

Limitations of Use cases include:

• Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere. 
• Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s). 
• Use cases are complex to write and to understand, for both end users and developers. 
• As there are no fully standard definitions of use cases, each project must form its own interpretation. 
• Some use case relationships, such as extensions, are ambiguous in interpretation and can be difficult for stakeholders to understand. 
• In Agile methodology, simpler user stories are preferred to use cases. 
• Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI should not be reflected in use cases, it can be awkward to remove this aspect of design, as it makes the use cases difficult to visualize. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix. 
• Use cases can be over-emphasized. For example, driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques. 
• Use cases are a starting point for test design, but since each test needs its own success criteria, use cases may need to be modified to provide separate post-conditions for each path.

Business Analysis, User Stories, and Agile Methodology

In my last post on business analysis in content management, I mentioned that methods used in business analysis are: focus groups, documentation analysis, surveys, user task analysis, process mapping, stakeholders interviews, use cases, user stories, personas, storyboards, etc. In my today's post, I am going to describe user story method.

A user story is a short, simple description of a feature told from the perspective of the person who desires the new system capabilities, usually a user or a customer of the system. It is one or few sentences in the everyday or business language that captures what a user does or needs to do as part of his or her job functions.

User stories are used with Agile software development methodologies as the basis for defining the functions that a business system must provide. It captures the "who", "what" and "why" of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for a business user as that user's primary way to influence the functionality of the system being developed.

User stories are a quick way of handling users' requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing business requirements.

During the process of collecting users requirements, a business analyst gets together with a users' representative to identify the specific needs of the business and create user stories.

As the customer conceives the user stories, business analyst writes them down on a note card with a name and a description which the customer has formulated. If the business analyst and the user find that the user story is lacking in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory often using the INVEST guidelines.

The INVEST guidelines was created by Bill Wake as the characteristics of a good quality user story:

Letter	Meaning	Description
I	Independent	The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N	Negotiable	User stories can always be changed and rewritten.
V	Valuable	A user story must deliver value to the end user.
E	Estimatable	You must always be able to estimate the size of a user story.
S	Sized appropriately or Small	User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T	Testable	The user story or its related description must provide the necessary information to make test possible.

User stories generally are not created to be too definite once they have been written down because requirements tend to change during the development period.

User stories generally follow the following template:

As a "role", I want "goal" so that "benefit".

As a "user" I want to "do something" so that "I can accomplish goal".

As a "user" I want "function" so that "value".

There is also shorter version:

As a "role", I want "goal/benefit"

For example:

"As the CTO, I want the system to use our existing orders database rather than create a new one so that we don’t have one more database to maintain.

"As a user, I want the site to be available 99.9% of the time I try to access it so that I don’t get frustrated and find another site to use."

"As an estimator, I want to see all items I need to estimate this season so that I can see the volume of my work."

"As a user, I want to search for my customers by their first and last names."

 "As a user closing the application, I want to be prompted to save if I have made any change in my data since the last save."

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

As a central part of many agile development methodologies, user stories define what is to be built in a project. User stories are prioritized by developers to indicate which are most important. User stories then will be broken down in tasks and estimated by developers.

One of the benefits is that they can be written at varying levels of detail. We can write user stories that cover large amounts of functionality. These large user stories are generally known as epics. Here is an example epic from a desktop backup product:

"As a user, I can backup my entire hard drive."

Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two:

"As a power user, I can specify files or folders to backup based on file size, date created, and date modified."

"As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved."

Agile projects use a product backlog which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog item.

While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of a user story (“As a user, I want…”) is incomplete until the discussions about that story occur. It is often best to think of the written part as a pointer to the real requirement. A user story could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.

Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the user to validate it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered.

Agile methodology favors face-to-face discussion over comprehensive documentation and quick adaptation to change instead of fixation on the problem. User stories achieve this by:

• Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks. 
• Allowing a developer and a user to discuss requirements throughout the project. 
• Needing very little maintenance. 
• Only being considered at the time of use. 
• Maintaining a close user contact. 
• Allowing projects to be broken into small increments. 
• Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process. 
• Making it easier to estimate development effort. 
• Require close customer contact throughout the project so that the most valued parts of the project get implemented. 

Some of the limitations of user stories in agile methodologies:

• They can be difficult to scale to large projects. 
• They are regarded as conversation starters.

While both user stories and use cases serve the purpose to capture specific user requirements, there are major differences between them:

User Stories	Use Cases
Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.	Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.
Can be accompanied by Acceptance Testing procedures for clarification of behavior where stories appear ambiguous.	May be delivered in a stand-alone document.