Architecture Team Charter

Mission

The Architecture Team designs and implements the overall architecture for Kepler.  This includes design, development, and testing the Kepler kernel, which is the core software comprising the application, execution engine, extension framework, and documentation system. The group is responsible for providing the mechanism for system extensibility required by the other working groups and of less tightly coupled stakeholder projects. This team defines what is and what is not included in the kernel, and is the authority on how the kernel may be extended and how new extension point programming interfaces can be established.

Scope of Activity

THE ACHITECTURE TEAM IS RESPONSIBLE FOR:

1.    The architecture, design, and implementation of the Kepler software Kernel.
2.    The identification, design, and implementation of Extension Points, i.e., software interfaces that can be used by other software to interact with and/or build upon the Kernel and Standard Extensions.
3.    The identification, architecture, design, and implementation of the Kepler Standard Extensions. Standard extensions may be implemented and maintained by the Framework Team or by other Working Groups, but the Framework Team maintains responsibility for compatibility and stability of all Standard Extensions.
4.    The evolution and maintenance of the Kernel, Extension Points, and Standard Extensions.
5.    Testing and overall stability of the Kernel, Extension Points, and Standard Extension implementations.
6.    Determining the composition of releases of the Kepler Kernel and Standard Extensions. Note that the Kernel and individual Standard Extensions may be on different release schedules. This team also provides input to the Kepler Management Team about the composition of Kepler distributions.
7.    Documenting the architecture, design, and implementation of the Kernel, Extension Points, and Standard Extensions and facilitating communication of these via the User Represention and Outreach Team.
8.    Establishing a set of procedures for receiving, documenting, and addressing comments feature requests, and promotion of extensions to Standard Extensions  concerning the Kepler Kernel, Extension Points, and Standard Extensions.

THE ARCHITECTURE TEAM IS NOT RESPONSIBLE FOR:

(this section needs editing, most to be eliminated)

1.    Ensuring that Non-Standard extensions are compatible with (existing or future) Kernel or Standard Extension releases.
2.    Chartering or forming Kepler working groups.
3.    Directly gathering user requirements for the Kernel and Standard Extensions.  (This will be the responsibility of the User Representation Team.)
4.    User support for components outside of the framework. This will be the responsibility of the User Representation Team, Build and Release Team, or individual projects distributing Kepler. (change to positive statement of what FT is supporting)

(Editing stopped here)

GENERAL PHILOSOPHY AND SCOPE OF THE KEPLER KERNEL:

1.    The Kernel should consist of a well-defined, compatible, and coherent set of software components that provide essential functionality for scientific-workflow applications.
2.    The Kernel should consist only of software components that are generically applicable to a wide range of domains, projects, and/or applications. That is, components that are highly specialized or only address the needs of a small subset of domains or projects should not be part of the Kernel, and instead, should be placed within one or more Kepler extensions.
3.    No two components within the Kernel should provide competing or incompatible approaches for addressing the same problems.
4.    The Kepler Kernel should be a standalone, executable system; however, it may not in itself provide all of the features necessary for most applications.

GENERAL PHILOSOPHY AND SCOPE OF THE KEPLER STANDARD EXTENSIONS:

1.    The Standard Extensions provide additional software components that can be combined with the Kernel to support a wider range of scientific-workflow applications.
2.    The Standard Extensions are not required for executing the Kernel.
3.    The Standard Extensions are not required to be standalone executable systems. However, when used with the Kernel, they should result in a standalone executable system.
4.    Multiple Standard Extensions may provide competing or incompatible approaches for addressing the same problem.
5.    The Standard Extensions represent reference implementations of the Kernel Extension Points.
6.    It is expected that the Standard Extensions will be bundled with the Kepler Kernel in standard Kepler distributions.

MANAGEMENT OF THE KEPLER ARCHITECTURE TEAM:

1.    The Framework Team will consist of a Team Lead and any number of Team Members.
2.    The Framework Team will make all decisions concerning the architecture, design, and implementation of the Kepler Kernel and Kepler Standard Extensions.
3.    The Framework Team will establish procedures for receiving and addressing comments and feature requests made by other teams, working groups, and the broader community.
4.    The Framework Team will make decisions based on overall consensus of the Team Members. Team Leads should work to build consensus among members on decisions. However, if a decision must be made and it is clear that consensus cannot be reached, the decision will be made by the Team Leads otherwise the Kepler Management Team will make the final decision.
5.    The Team Leads are responsible for reporting to the other Kepler teams on general progress and status of the group, including proposed, ratified, and active project charters.

Notes on the Kepler Framework Team: The Framework Team is not required to perform all software design and development of the Kernel or Standard Extensions. For example, working groups may be chartered to develop specific aspects of the Kernel and/or Standard Extensions, or existing software developed for Kepler may be used.
 

Glossaries of Terms