Below is the template for the conceptual design report that will be used to launch the DOE Systems Biology Knowledgebase (Kbase). This living document will change as input is obtained from the workshops and from you, the community, and as pilot projects are initiated and completed.

1. Purpose
1. Vision: Kbase provides a computational environment for researchers to contribute data and analysis methods to model dynamic cellular systems at a high level of accuracy and, by extension, many of these systems within a cell and within a community of cells and organisms, all interacting with their environment. Ultimately, Kbase will allow users to perturb a cellular system and observe the result.
2. Detailed scientific objectives and how Kbase provides a solution: What systems biology problems will Kbase address? (from science workshops)
2. Requirements
1. Use cases: Comprehensive usage examples to meet scientific objective. Scenarios or vignettes; provide scenarios that tie multiple use cases together (an end-to-end picture that meets science objective) (from science workshops)
2. Which scientific objective(s) and scenario(s) will be addressed first, and which will be addressed thereafter?
3. What data would be contributed?
4. What analysis methods exist or need to be developed?
5. What kind of hardware will be needed?
3. System architectural details
1. Available tools to implement Kbase
1. Software
2. Databases
3. Hardware
4. Relevant architectural approaches
5. Successful open development methodologies
6. Existing systems such as IMG, RAST, CAMERA
7. Community de facto tools and databases available from organizations
2. Gaps in existing tools and hardware
3. Data management, modeling, and representation
4. Distributed computing model
5. Architectural strategies and decisions that affect the overall organization of Kbase. These include things such as:
1. Programming languages, database systems, libraries, etc. to be supported.
2. Reuse of existing software components to implement various parts/features of the system (which tools listed in 3.1.1 and 3.1.2 above).
3. Data and software synchronization across sites if a distributed model is embraced. External databases vs. local copies.
4. User interface paradigms (web, thin clients, thick clients, others?).
6. How the system is divided up into subsystems, what is unique to each subsystem, and which elements of the subsystems are shared.
7. How will subsequent scientific objectives and scenarios affect the Kbase architecture?
4. Design (this is distinct from governance in that governance decides what, the design indicates how)
1. How would data be contributed?
2. How would new types of data be contributed?
3. How would new analysis methods be contributed?
4. How would Kbase be modified and improved?
5. Implementation Plan [include elements of software project management (PM), software configuration management (CM), and software quality assurance (SQA)]
1. Review specific scientific objective and scenarios will be addressed.
2. Process by which Kbase will be implemented (PM).
3. How will it be operated?
4. How will it be maintained?
5. How will software be tested (testing strategy SQA)?
6. What will the change process look like, and how will the change control and bug tracking be implemented (CM)?
7. How will software be compiled, deployed, and released (deployment and release strategy CM)?
6. Governance Model – Governance in the enterprise software domain of Kbase can be thought of as the development and enforcement of policies and procedures. Policies in this context can be thought of as design decisions combined with enforcement. Since a primary goal of a good architecture is to define a modular system and well-defined abstractions, choices that are made along the way in this regard need a level of enforcement. Governance starts with a vision of what the governance process will accomplish. This vision should be a collective effort of the people who will use, design, build, and pay for Kbase. Most of all, tolerance must be the social norm in the Kbase governance model.
1. Define a tolerant governance model.
2. Define a board of review that will be responsible for the development, maintenance, and change of policies.
3. Develop an interoperability framework that discusses standards are the basis of interoperability and the details of these standards.
1. An interoperability framework should list the standards that Kbase will use, point to reference information, and indicate the status of the choice (such as approved,
   de facto, emerging, sustained, being phased out, being phased in, etc.)
2.  A standard that has a status of 'sustained' is a special case where although a newer standard or alternative standard has been chosen, the sustained standard will be supported by Kbase.
4. Identify centers of excellence within the community that can support governance and interoperability standards.
5. Define different classes of participants (i.e.,users, developers, committers, subproject managers)and their roles in the open Kbase development process, in governance, in project management, etc.
6. Define a governance process that will produce policies, xml schemas, wsdl documents, ontologies, and other artifacts that must be distributed to the Kbase community of users, developers, etc.
7. Make the products of governance searchable, versioned,and easily referenced (URI). And in many cases, make the products of governance machine-readable.
8. How and where will we create a registry of governance artifacts? If using Netbeans or Eclipse, does a plug-in exist that links the registry to the IDE?
9. What tools are available to automate as much of the governance process as possible?
10. On the issue of enforcement or compliance
1. Role of PM team to keep subprojects compliant
2. Role of executive team to keep project compliant
3. Link funding and compliance where possible
4. What are the corrective actions when a part of a subsystem or system is found to be non-compliant?
5. How are exceptions to policy handled and supported?
11. Transition from largely independent efforts to community working together.
12. Principles: open contribution, open development.
13. Editorial organization and process.
14. Deciding which data and data types are to be contributed (proposed by users…).
15. Deciding which new analysis methods are to be contributed (proposed by users…).
16. Deciding which standards to endorse (proposed by users…).
17. How to keep the Kbase user community engaged in the software development life cycle and invested in it so they feel some ownership of success. Who are the enthusiastic communities?
7. Appendices
1. Workshop Report
1. Supercomputing
2. Plant and Animal Genome
3. DOE Genomic Science PI Meeting
4. JGI User Meeting
5. Knowledgebase Systems Development
2. Specific scientific objectives from the workshops or proposed by others. Rather than include multiple examples in the main document, each example will have its own section.
3. Technical software engineering documents