Site architecture patterns, Install Profiles, & automated site configuration

EDIT: There will be a BOF discussion tomorrow, Wed morning at 9:00am here at Drupalcon. Please join the discussion and share your thoughts.

Setting up Drupal sites requires a lot of time clicking through forms and redoing common tasks. This can be automated and reused to save time. Install profiles were built to help solve this problem, but there are limitations. We'd like to discuss these limitations and figure out what can be done to address them and plan the next steps and evolution of automated site configuration? Also, what needs to be done or changed in Drupal core to facilitate this?

Defining site architecture and best practice patterns

It would be great to be able to define common and specific site architecture and best practice patterns in a format that is easy to read and work with and can easily be shared and collaborated on. Ideally the system would support different backends to allow site configuration documents in multiple languages.

Projects and implementations

Install Profiles (http://drupal.org/project/Installation+profiles)
Install Profile API & Profile Wizard, CRUD (http://drupal.org/project/install_profile_api)
Profile Generator (http://drupal.org/project/profile_generator)
Civic Space APIs (https://customprofiles.civicspaceondemand.org/api/file)

Related Projects and discussions

Cocktail - CCK Type Language: (http://raincitystudios.com/blog/cocktail-cck-type-language)
GHOP - Drupal automated staging toolkit project proposal: (http://code.google.com/soc/2007/drupal/appinfo.html?csaid=AD069F51C0E75638)
Distributions Group: (http://groups.drupal.org/distributions)
Effectiveness of install profiles?: (http://groups.drupal.org/node/6820)
Drush: (http://drupal.org/project/drush)
HostMaster2: (http://drupal.org/project/hostmaster)
AutoPilot: (http://drupal.org/project/autopilot)
Multisite Management Tools Review: (http://drupal.org/files/issues/review_0.pdf)

Limitations in Install Profiles

Here are some of the limitations with install profiles that would be great to address:
It's a one time initial setup and can't change anything on the site after the initial configuration.
You can't create separate, smaller groups of features and configurations that can be combined together and mixed and matched individually or as a group.
It can be hard to read and work with since it's in PHP code and so there is a disconnect between site planners/architects.
It's not possible to setup all the desired settings/configurations (ie., API and additional module support.)
It's hard to manage changes to the profile or setup as requirements and best practices change (which they constantly do.)
Can't easily have slightly differing configurations (would need a separate install profile for each.)

Proof of concept solution

We started work on a project called Patterns that attempts to address and solve some of these points and limitations. Our idea was to make a simple, flexible, powerful custom module/system to handle definitions of site configurations that was easy to change, update and manage. We decided to create a module that supports definitions of requirements (patterns of any type) and runs/enables them on an new or existing site. We also created a very simple install profile that's sole purpose is to set up the Patterns module.

It's in an early proof of concept stage. You can find the project placeholder on Drupal here:

http://drupal.org/project/patterns

Here are some design ideas and implementation details:

Overview

The patterns module will enable the setup of complex and detailed sites without actually doing any of the setup yourself. A pattern will be a collection of rules, definitions, and dependencies that will automatically setup and create simple or complex features for you. Patterns allow you to define features and functionality for a site in a standard text format (currently XML with planned support for other formats,) or directly on the site, and then apply them to an already running site. An administration page will let you enable (and possibly disable or remove) each pattern that has either been provided by default, contributed, or created specifically for the application at hand.

A typical example would be to easily and simply setup a fully functional forum with user registration, authorization, avatars, comments, captchas, views and more without touching a single setting. Of course the unique, specific settings for the site at hand can be adjusted like usual, however basic settings can also be tweaked when turning on the pattern.

For those that need more control over the setup of their desired features, patterns could possibly guide the user through all of the setting pages and settings that are available for a particular feature set. They could have stop points that prompt the user for a specific choice or input (similar to Photoshop actions.)

Patterns primary uses

Define reusable site architecture patterns and best practices that are easy to update and maintain.
Quickly setup and configure new (and existing!) sites based on site architecture documents/patterns. (Next evolution of Install Profiles)
Migrate changes, updates and new features from you local development environment to dev server to QA site to the final production environment. (Change Management)
Possibility of making a specific pattern to update/change a site(s) from some other known configuration (legacy best practice to current best practice for instance)

Architecture Overview

Base install profile (setup Patterns module)
Patterns Drupal module
Patterns component modules
Hooks/API
Pattern XML files
Stop points for allowing the user to set/change a value
Pattern groups/subgroups

Most patterns will be made up of a combination of any/all these components:

Module(s)
Module settings
CCK Content Type(s)
Fields
Field weights/order
Views
Type
Fields
Panels
Blocks
Permissions
Content/Nodes (not finished yet)
Files
Other patterns!

Features:

XML based. Keeps it open and flexible so you can possibly use other systems to process or work with the XML
Creation of content types and fields
Creation of views and settings
User and node creation
Setup of user roles and permissions
Automatic and assisted panel creation
Automatic and assisted menu setup
Basic conflict checking and resolution
A pattern can be a list of other patterns
Support for tokens from the Tokens module

Challenges

XML Based (other formats may be more readable or better to work with.)
Keeping component modules up to date
Resolving conflicts in patterns and pattern dependencies
Getting parts of this into Drupal core

Primary plans and ideas for the future

Nicely formatted view of the pattern live on the site (currently it just displays the raw XML)
Extensive pattern administration:
Pattern builder: choose configuration components from an existing site to make a pattern out of specific parts (or the entire site)
Import from another site/file
Export to another site/file
Record patterns when setting options or configuration
Stop points (to ask the user for an input or value)
Pattern versions and dependencies
Display and automatic downloading of patterns from a central repository
Run/control from the command line (Drush integration)
Add/Import by URL (with ability to choose from a list of available ones)
Publish/Export list of patterns to URLs, Master site (enable repository functionality) and individual patterns
Repository system (list of available sites to check for patterns)
Ability to easily add your site automatically to the repository list
Version checking

Possible other side benefits and solutions

Central or distributed pattern repositories with community managed best practice patterns
Unified API for configuration import/export
Change Management solution
Development shops can share common configurations and work together to improve them.

Sorry for the overload of information here. We'd love to hear your thoughts and feedback and work together to create a solution is properly planned and can hopeful integrated with core for Drupal 7. What do you think?