Principles of Natural Participation

by John Brunswick


Blogs, wikis, and other Web 2.0 components are powerful tools born out of the consumer Web. At this point, a growing number of people have had exposure to tools like Flickr,, and Blogger in their everyday lives. As enterprise software vendors move to deliver toolsets that allow for similar contribution within the enterprise, a new range of possibilities emerges—the cornerstone being the further empowerment of an organization's business analysts.

This article looks at how natural participation can help an organization build applications in a more agile manner, using increased collaboration and communication between business analysts and developers.

Natural Participation

Organizations are beginning to recognize the value of deploying consumer Web tools to obtain basic benefits like internal knowledge sharing. This being said, they often overlook deeper benefits that the elements, and, more importantly, their methodologies of collaborative contribution can provide. Due to their ease of use, organizations can leverage these tools to allow for natural participation within their traditional application-development processes, allowing both developers and business analysts to jointly contribute to solution development.

Natural participation is an agile, cost-effective, and logical participation model made possible by portal or portal-like frameworks that let business analysts design processes, content, structure, and other elements of a solution in parallel and in participation with a traditional software development team. A tremendous amount of business value can be gained from the speed, ownership, and maintenance in a solution-delivery model that stresses participation of the business units involved in creating the overall solution, while not relying exclusively on a development team to carry their vision to completion. Natural participation can be thought of as "Agile Development Plus"� to further accelerate overall solution delivery.

As an example of how natural participation could be applied to a non-technical task, imagine multiple participants actively assisting in creating a painting on canvas. Based on their strengths, the participants would contribute their various degrees of skill and help where it made sense. Perhaps a particular team would focus on painting trees from a template to free up the highly skilled artists to work on the complex and unique details of the people in the painting. When the work was done, viewers would appreciate a single painting for its overall qualities, not knowing that multiple authors with various competencies were involved.

Whether developing an online mortgage application or a business-to-consumer Web site, this participatory method is made possible and effective by leveraging Web 2.0 principles of contribution.

The Frozen, Monolithic Past

Applications have historically been deployed by IT teams based on the waterfall development model, which results in monolithic, often cumbersome solutions. All elements of an application have been controlled by the development team including textual content, taxonomies, site structure, surveys, dashboards, and other elements. Although many great solutions have been built this way, unfortunately it has cast the development team as the bottleneck.

Here are some drawbacks of the traditional development model:

  • The team is slow to react to business needs.
  • The development team becomes the bottleneck for initiatives.
  • There is more code to maintain.
  • There is more code to test.
  • Regression testing is needed for application updates.

It we take the monolithic model to its extreme, it could take weeks to adjust the destination of a simple hyperlink within a Web-based application. If an item of content needs to be changed or the structure of the site requires adjustment, the development team is always tasked with this effort, reducing available resources for other projects. A series of regression tests may also be needed to ensure that the application is able to continue functioning without being affected by the recent change.

Once again, many outstanding solutions have been developed this way, but we can all agree that this process is not without significant drawbacks.

Passing the Baton

Members of application development teams take great pride in delivering solutions to the business, and rightfully so. They have worked hard to gain thorough insights into complex systems that they weave together to meet the needs of the business. This can also make it difficult to relinquish control over portions of applications and move to a more iterative, natural participation model of development.

When it comes to control, it is only logical that concerns over development efforts running wild without the steady hand of IT would abound as business analysts begin to have further levels of participation. To combat this fear, enterprise vendors have been careful to not overlook governance and security controls, establishing approval processes, appropriate access, and auditing possible within their new tools.

Once IT realizes that their efforts are best spent focusing on high-value strategic tasks to drive their own efficiencies and cost reductions, resistance to this change falls away.

Pages: 1, 2

Next Page »