Portal Process Process

This page describes the steps required for adding new process support (sometimes called workflows) to the MyFoundation portal. These steps are initiated and supervised by a "champion", which is expected to be a staff member of the foundation.

Preliminary Design

In this step the champion assembles process stakeholders, builds a business case for the automation, and produces scenario sketches for the automated process in action. The step completes when stakeholder agreement has been reached, the development effort has been estimated, individuals have been identified to complete the work and priorities have been established.

Decisions made in this step should be recorded in a foundation wiki page. The prefered outline for such a page is as follows.

• process summary
  • stakeholders
  • existing documents
  • pain-points as-is
• scenarios sketches
  • simplest successful case
  • complications on successful cases
  • failed cases handled automatically
  • failed cases requiring manual intervention
• deployment plan
  • development
    • new components
    • database changes
  • review
    • security/privacy
    • useability
  • operations
    • phase-in
    • promotion

For an example of such a document see the Portal Polling Process.

Detailed Design and Implementation

This step involves taking items identified in the preliminary design and casting them as php scripts in the development sandbox. A copy and modify approach is safe and usually suitable. As such, a process champion with only modest programming skill can reasonably jump into this step single handed and expect the process to warn him when it is time to seek additional help.

Scenario sketches become test scenarios encoded in text files using simple commands to describe user interactions with the portal and the actions that result. Progress can be tracked by noting in the preliminary design when its scenarios have been encoded and run to completion.

New or modified portal components will be developed as they are needed to complete test scenarios. The implementation strategy will be: make it, make it right, make it fast. Components should be continuously reviewed through development for suitability in the context of existing scenarios and refactoring for long-term sustainability.

Database changes will be effected by automatically introducing new columns and tables on first use of components that need them. This may require the use of a "mutator" that populates new fields with data extracted from old ones. Development databases will be frequently reset to as-is schema such that mutators are effectively tested before deployment.

Deployment and Operations

In this step items from the previous step are introduced into the production environment. The portal goal is that deployment should be no big deal and that it can be easily and confidently executed by a single person from foundation IT.

We will develop techniques for supporing IT in the following.

• monitoring
• rollback
• housecleaning

After some suitable period of use the IT department will take over full responsibility for the process, the preliminary design wiki page will be marked as deployed, and the champion's work is done.