Principles of Natural Participation

Principles of Natural Participation

* Originally published on BEA System’s Arch2Arch Community December 2007 and Portalsmag.com

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.

The Big Thaw: Natural Participation in Action
A fictional corporation called Blue Walnut Realty (BWR) had a public Web site that allowed customers and business partners to connect with them at www.bluewalnuthomes.com. The Web site had a public-facing section that contained marketing material to help generate sales leads and showcase their services. In addition, the site had two secure areas that allowed home builders and home buyers to access an online application.

The customer application helped potential home buyers keep track of favorite properties that they were interested in purchasing. The secured home builders section of the Web site let builders add and update their property listings within the BWR database so that potential customers could browse and add these property listings to their favorites.

Historically, BWR had used the waterfall development method to support these applications and had released new functionality or adjustments to their Web site on a bi-yearly basis. All development efforts were handled by their development team, which met with business analysts to transform the latest business requirements into solutions.

Over time, BWR had seen their growth slow as smaller, more nimble competitors began to offer similar functionality on their Web sites and more quickly adjust to meet consumer needs.

Recognizing that their Web presence was a crucial element of their overall business strategy and that it would help them grow their business, the BWR CEO and CIO committed to investing in a more flexible Web framework and to researching ways to leapfrog their smaller competitors. To support this new business initiative, BWR also revisited their development processes and began investigating agile development methods. During their investigation, they came across the principle of natural participation in this new framework and decided they would also leverage its methodology.

The results were significant. By adopting a natural participation method of solution development, they quickly found themselves accelerating their initiatives at speeds they hadn’t thought possible. With developers and business analysts collectively contributing in parallel, which was not possible earlier, the same number of resources could now produce much greater results in a shorter time span.

Within a week of moving to the new platform, a new feature was added to the Web site that allowed potential home buyers to start a discussion with BWR staff around potential homes on the same Web page where they stored their favorite listings. This added a much more personal touch to the Web site, and the potential customers were very pleased with the new functionality. The development team invested no effort on this initiative as the business analyst team used native framework tools to create the new interactivity for the prospects.

BWR also wanted to strengthen relationships with the home builders. Immediately after adding the discussion forums, the business analyst team began to weave in targeted marketing materials explaining the benefits of working exclusively through BWR alongside the application that home builders used to add and update their listings. In addition to these materials, the team created specific contact forms to allow the builders to show their interest in specific programs offered in the marketing materials.

A few more weeks down the road and using native portal tools again, the business analyst group set up individually branded logins for all of the major builders to bolster relationships with them. This required no developer assistance or regression testing from the development team as it was native framework functionality. The individually branded logins were something that none of their competitors offered, giving BWR a distinct advantage.

What about the application development staff at BWR? Throughout this entire process, the development team had been freed up to focus on more strategic technology projects. They are now preparing to release a new tool within the site that allows potential home buyers to download their favorite available properties to a GPS device that can easily guide the prospects through a tour of the properties. This is a feature that no competitors have and something that was made possible by using the time not spent updating site content, adding new interactive site elements like the discussion forums, updating site structure, building uniquely branded login areas, or deploying marketing materials for the builders.

How to Implement Natural Participation
Leveraging principles of natural participation requires coordination from a business and organizational standpoint, as well as from a technological standpoint. There is no perfect approach to its implementation, but the overall goal is to obtain benefits from a pragmatic, agile approach to development with multiple parties. Below are some key steps that will help organizations begin to embrace this ideology for projects.

  1. Secure executive sponsorship — Change is difficult. Even though many benefits exist from implementing a model of shared participation for solution development, it will take a compelling executive voice to reinforce the new strategy. In the absence of this support, people will gravitate toward the status quo where they are comfortable.
  2. Know all facets of your application framework — It is crucial to look for areas within a development framework where non-developers can contribute and manage part of a solution. This frees developers to focus on more crucial initiatives and frees the business from the bottlenecks of waiting on the completion of long release cycles to make minor adjustments to a project.
  3. Challenge the current Software Development Life Cycle (SDLC) and release management approach — Too many companies do things “because that is the way we have always done them.” Step back and examine if a traditional model makes sense given the evolution of platforms and their ability to now develop more modular solutions where multiple audiences can manage different segments of a project.
  4. Explore delegation and define governance — Just because a development team may no longer code an entire solution does not mean that it has to result in a loss of control over content. Modern development platforms can provide workflow, auditing, and other methods of managing segments of a solution in a secure and controlled manner.
  5. Identify obvious candidates for delegation — Content, information structure and layout, high-level security, and workflow are just some elements that business users can manipulate within a platform. The business can focus on these portions of a project without affecting development efforts and offloading a significant amount of work from a development team.
  6. Keep all parties informed — The development and business teams should participate in regularly scheduled, brief meetings to inform each other of their project activities at a high level. This will ensure that any change in overall project direction or business requirements will have minimal impact on the work that both parties are doing and how that work is integrated between them.

Conclusion

By leveraging the principles of natural participation, it is possible to thaw enterprise application development, making the most of a portal framework and native tools that enable contribution by non-developers. Each initiative can be evaluated as to whether it makes sense to begin traditional development work for a segment of the solution, or if it is possible to involve members of the business-analyst team to paint that part of the picture. This process leads to greater business agility and allows development teams to focus on higher-value strategic tasks, while business analysts become empowered to “naturally participate” in the overall solution development and increase the business value that IT can offer to its organization.

0 comments