EPP [was much longer]
Joseph Sinclair
plug-devel@lists.PLUG.phoenix.az.us
Sat Mar 12 12:36:02 2005
This is a multi-part message in MIME format.
--------------020202060006000401010405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Trent Shipley wrote:
> <<SNIP>>
>
>Well then let's do THAT big enough thing directly. In that case let's drop
>IFA as some sort of stage or sub-project or whatever and go strait for what
>we expect to be the system's core competence, "the larger event planning
>community" (whatever that means).
>
>
That's exactly what I've been advocating. The only thing I was doing
with installfests is taking their user stories and moving them up in the
iteration plans so they can start using/showcasing the system while it's
still in development.
><snip/>
>
>
>
>>The people working this project (nobody's agreed to PEP yet, I actually
>>prefer EPP, for Event Planning Project, until the community is large
>>enough to select a formal name) are not a software shop. They're
>>volunteers in an open source project. The project sponsoring group
>>(sort of) is PLUG.
>>
>>
>
>I have trouble seeing PLUG as a proper sponsor. EPP's working group needs to
>be seen as a thing-to-itself. It has close ties to PLUG, but since PLUG is
>an informal association, EPP is already as institutionally rammified as PLUG.
>
>
>
They're not a "proper" sponsor. They're a "sponsor", in that we need, I
think, to keep the EPP group strongly associated with PLUG/AZOTO.
>>>The problem I have is not that there should be a strategic vision beyond
>>>IFA and corresponding architectural plans, it is that architecture needs
>>>to be based on so many highly speculative functions ... it all amounts to
>>>theoretical business theory. I would feel MUCH more comfortable working
>>>off a larger architectural plan if I knew the plan was based not in
>>>theory but in grounded research.
>>>
>>>
>>The point of using lightweight development is to compensate for the fact
>>that we
>> a) don't know a lot of things about what the user community needs are
>>
>>
>
>Agreed.
>
>
>
>> b) don't have the resources to perform grounded research in this area
>>
>>
>
>I'm not sold on this. Bryan, Shubes, and I have all offered to do research.
>The problem isn't finding researchers, it seems to be finding potential
>consumers willing to be researched.
>
>
>
by research I was thinking the "professional market research" type, not
the "find some potential customers and ask them what they want" type.
>Do we have a critical mass of participating consumers or not?
>
>
No.
>I am still pretty much leaning toward hunting down three or four more
>consumers and pumping them for grounded domain knowledge.
>
>
Go ahead. I'm certainly not going to stand in the way of that if anyone
wants to volunteer to do so. I just don't have the background to go to
it myself.
>
>
>
>>Why not take advantage of that and build to the larger vision?
>>
>>
>
>Indeed. Given the path you want to take, why not do JUST that and do it
>directly (albeit iteratively).
>
>
>
>
Agreed, let's do that.
>What I do not understand is your objection to making a module in an ERP/ERM
>tool. I know some folks are just ERP/ERM skeptics. I understand where they
>are comming from. It can be faster to hand-code your accounting system from
>scratch in COBOL than to set it up in an ERP/M system. The advantage of ERPM
>is that when you are done Accounting will automatically be integrated with
>Inventory and Human Resources. With each module built from scratch you are
>soon overwhelmed by the need for custom two-way interfaces.
>
>
>
ERP is an inventory/accounting activity that doesn't mesh well with
events planning. If we use an enterprise framework (whichever we end up
choosing) we can integrate with the appropriate external modules just
fine. Integrating with ERP would just impose constraints without
providing any benefit in this case. None of the common functionality in
ERP/ERM will support any normal function in the event planning space,
unless the company is in the business of providing events, in which case
a relatively simple link into any existing ERP system would be
appropriate and sufficient.
>>>** Stratigic vision will be realized over time through many interations.
>>>** Iteration = customer
>>>
>>>
>>Iteration == a small block of useful functionality
>>Customer == a large community that will (I REALLY REALLY REALLY hope)
>>grow and evolve over time
>>
>>
>
>I have a problem with this definition of customer. It strikes me as
>poltically naive.
>
>
Yes, it is naive. I always prefer a naive definition for customer.
Handling political realities is done as necessary in practice, never in
definition.
>What does AZOTO (Hans?) want anyway?
>
>
A minimum of support for planning the following event types:
a) Monthly installfests
b) Semi-annual mega-installfests
c) An open-technology conference
d) An open-technology symposium
e) An open-technology meet-and-greet
f) An open-technology exposition
>If InstallFest is a subset of AZOTO (and not , why not do the reverse, design
>and build AZOTO then prove the solution's generality by applying it to
>InstallFest? If it is important that the first project in EPP's strategic
>arc be "big enough" then lets not shilly-shally with InstallFest. Lets go
>for it.
>
>
>
The plan (in my view) is to build the first release for AZOTO needs.
The user stories will be organized to build the functionality to
implement the AZOTO requirements in approximately the order listed above.
>So it is an application designed to minimize the load on enterprise sys
>admins.
>
>
The WebStart-like technologies allow the developer to build an
application for local use without worrying(much) about the network,
while allowing the deployer/packager to easily manage changes and the
deployment of fixes without user interaction required.
>When do we need to cross this bridge?
>
When someone requests the offline/near-line client capability and
someone volunteers to build that functionality.
--------------020202060006000401010405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Trent Shipley wrote:
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite"><<SNIP>>
<pre wrap="">Well then let's do THAT big enough thing directly. In that case let's drop
IFA as some sort of stage or sub-project or whatever and go strait for what
we expect to be the system's core competence, "the larger event planning
community" (whatever that means).
</pre>
</blockquote>
That's exactly what I've been advocating. The only thing I was doing
with installfests is taking their user stories and moving them up in
the iteration plans so they can start using/showcasing the system while
it's still in development.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap="">
<snip/>
</pre>
<blockquote type="cite">
<pre wrap="">The people working this project (nobody's agreed to PEP yet, I actually
prefer EPP, for Event Planning Project, until the community is large
enough to select a formal name) are not a software shop. They're
volunteers in an open source project. The project sponsoring group
(sort of) is PLUG.
</pre>
</blockquote>
<pre wrap=""><!---->
I have trouble seeing PLUG as a proper sponsor. EPP's working group needs to
be seen as a thing-to-itself. It has close ties to PLUG, but since PLUG is
an informal association, EPP is already as institutionally rammified as PLUG.
</pre>
</blockquote>
They're not a "proper" sponsor. They're a "sponsor", in that we need,
I think, to keep the EPP group strongly associated with PLUG/AZOTO.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The problem I have is not that there should be a strategic vision beyond
IFA and corresponding architectural plans, it is that architecture needs
to be based on so many highly speculative functions ... it all amounts to
theoretical business theory. I would feel MUCH more comfortable working
off a larger architectural plan if I knew the plan was based not in
theory but in grounded research.
</pre>
</blockquote>
<pre wrap="">The point of using lightweight development is to compensate for the fact
that we
a) don't know a lot of things about what the user community needs are
</pre>
</blockquote>
<pre wrap=""><!---->
Agreed.
</pre>
<blockquote type="cite">
<pre wrap=""> b) don't have the resources to perform grounded research in this area
</pre>
</blockquote>
<pre wrap=""><!---->
I'm not sold on this. Bryan, Shubes, and I have all offered to do research.
The problem isn't finding researchers, it seems to be finding potential
consumers willing to be researched.
</pre>
</blockquote>
by research I was thinking the "professional market research" type, not
the "find some potential customers and ask them what they want" type.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap=""></pre>
<pre wrap="">Do we have a critical mass of participating consumers or not?
</pre>
</blockquote>
No.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap="">
I am still pretty much leaning toward hunting down three or four more
consumers and pumping them for grounded domain knowledge.
</pre>
</blockquote>
Go ahead. I'm certainly not going to stand in the way of that if
anyone wants to volunteer to do so. I just don't have the background
to go to it myself.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Why not take advantage of that and build to the larger vision?
</pre>
</blockquote>
<pre wrap=""><!---->
Indeed. Given the path you want to take, why not do JUST that and do it
directly (albeit iteratively).
</pre>
</blockquote>
Agreed, let's do that.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap="">
What I do not understand is your objection to making a module in an ERP/ERM
tool. I know some folks are just ERP/ERM skeptics. I understand where they
are comming from. It can be faster to hand-code your accounting system from
scratch in COBOL than to set it up in an ERP/M system. The advantage of ERPM
is that when you are done Accounting will automatically be integrated with
Inventory and Human Resources. With each module built from scratch you are
soon overwhelmed by the need for custom two-way interfaces.
</pre>
</blockquote>
ERP is an inventory/accounting activity that doesn't mesh well with
events planning. If we use an enterprise framework (whichever we end
up choosing) we can integrate with the appropriate external modules
just fine. Integrating with ERP would just impose constraints without
providing any benefit in this case. None of the common functionality
in ERP/ERM will support any normal function in the event planning
space, unless the company is in the business of providing events, in
which case a relatively simple link into any existing ERP system would
be appropriate and sufficient.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">** Stratigic vision will be realized over time through many interations.
** Iteration = customer
</pre>
</blockquote>
<pre wrap="">Iteration == a small block of useful functionality
Customer == a large community that will (I REALLY REALLY REALLY hope)
grow and evolve over time
</pre>
</blockquote>
<pre wrap=""><!---->
I have a problem with this definition of customer. It strikes me as
poltically naive.
</pre>
</blockquote>
Yes, it is naive. I always prefer a naive definition for customer.
Handling political realities is done as necessary in practice, never in
definition.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap="">What does AZOTO (Hans?) want anyway?
</pre>
</blockquote>
A minimum of support for planning the following event types:<br>
<tt> a) Monthly installfests<br>
b) Semi-annual mega-installfests<br>
c) An open-</tt><tt>technology </tt><tt>conference<br>
d) An open-</tt><tt>technology</tt><tt> symposium<br>
e) An open-</tt><tt>technology </tt><tt>meet-and-greet<br>
f) An open-technology exposition<br>
</tt>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap="">
If InstallFest is a subset of AZOTO (and not , why not do the reverse, design
and build AZOTO then prove the solution's generality by applying it to
InstallFest? If it is important that the first project in EPP's strategic
arc be "big enough" then lets not shilly-shally with InstallFest. Lets go
for it.
</pre>
</blockquote>
The plan (in my view) is to build the first release for AZOTO needs.
The user stories will be organized to build the functionality to
implement the AZOTO requirements in approximately the order listed
above.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap="">So it is an application designed to minimize the load on enterprise sys
admins.
</pre>
</blockquote>
The WebStart-like technologies allow the developer to build an
application for local use without worrying(much) about the network,
while allowing the deployer/packager to easily manage changes and the
deployment of fixes without user interaction required.<br>
<blockquote cite="mid200503120309.32276.tshipley@deru.com" type="cite">
<pre wrap="">
When do we need to cross this bridge?</pre>
</blockquote>
When someone requests the offline/near-line client capability and
someone volunteers to build that functionality.<br>
<br>
<br>
</body>
</html>
--------------020202060006000401010405--