[kepler-dev] charter for architecture project

[Shawn Bowers]

Tim (and Aaron):

> All--  The document we are discussing is kepler-docs/charters/drafts/
> Extension_Architecture.doc.  It outlines a project for proposing a
> first draft of a more modular architecture for Kepler that explicitly
> supports extension of the system.  If anyone would like to
> participate in this project, please let us know!

I'd like to generally participate in the architectural (re-)design,
etc., for Kepler, including the parts outline as part of this
"project".

> Feedback and
> suggestions for major changes to the charter all are welcome; the
> document is still in rapid flux.

My main concern with the charter is that the deliverables seem
ambituous in the amount of time given for the project.  My suggestion
would be to either break it up into multiple one-month small projects,
or else relax the timeline.

Another concern I have is that while it is one thing to propose an
architecture, it is another to justify why it is good or better than
another archicture. Thus, I think it would be beneficial to have as an
objective some kind of document describing the characteristics of the
proposed architecture, the benefits, and the motivation for these
benefits.  I think an architecture that supports "extension of the
core system with new capabilities" and "overriding of core subsystems
with alternative implementations" is a good start, but still somewhat
abstract.

You also might consider creating a separate project/charter out of this bullet:

  "List of key 'business use cases' for managing Kepler extensions,
illustrating the needs of different users and including use cases for
versioning extensions and managing extension dependencies."

In particular, this seems less related to the Kepler
architecture/subsystems and more to (a subsystem/approach for)
managing extensions, e.g., via a build system or runtime component.
While important, it seems a bit orthogonal (but maybe I don't
understand the implications/intent of it).

I agree with your comment that detailed UML diagrams should be an
internal objective, at least for this particular project.  Similarly,
while I think it is important to understand the current Kepler
subsystems -- I think documentation of thie could be done at a high
level, if needed, as opposed to via detailed UML diagrams.

I am not sure I understand what kind of diagrams the following would be.

  "Diagrams illustrating differences between current architecture and
proposed new architecture."

Thanks,
Shawn

>
> Cheers,
>
> Tim
>
> On Jun 2, 2008, at 12:01 PM, Aaron Schultz wrote:
>
>>
>> Hi Tim, go for it, it's all yours.
>>
>> Timothy McPhillips wrote:
>>> Hi Aaron,
>>>
>>> I see you checked in a draft charter for the Kepler Architecture
>>> project under kepler-docs/charters/drafts.  May I take the "lock"
>>> on it (figuratively speaking) and add more detail?
>>>
>>> Thanks!
>>>
>>> Tim
>>>
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>