Forcasting PEP consumers [was]: [snip] Event Planner Project [was]Re: Event Planning Project

[Trent Shipley]

Joseph, I was about to split this thread with a new subject of:
"IFA project, PEP vision, and PEP working group"

Of course I was really tempted to go for the title:
"IFA project, PEP vision, and PEP squad"
I had restrained myself, but without the discipline of a subject line I need 
not do so.

* The Phoenix Event Planner working group are the associates of PLUG Devel who 
are working on PEP projects.

* I see IFA as what we do *NEXT*.  It is a proof-of-concept project.  I tend 
to see it as a mini-project.  The IFA project is not totally congruent with 
the overall PEP strategic vision.  Nevertheless, the InstallFest problem 
seems to be a subset of the PEP domain and InstallFest has committed to being 
PEPs guinea pig, at least to the extent possible given InstallFest's loose 
organization.

We still need to find out what our customer, InstallFest, wants from the PEP 
Working Group.

* PEP has a strategic vision.  It extends to a lot of potential consumers and 
many revisions over time.  Because of a wide range of application and scale 
realizing PEP's strategic vision can be sketched as a timeline, but will 
require occasional changes in engineering and even architecture.

There is still a lot of brainstorming to be done about PEP's strategic vision.  

On the other hand, because the viability of the project and it's group have 
yet to be demonstrated, system architects need to be a bit agnostic and quite 
sceptical about any strategic plans.


On Friday 2005-03-11 17:53, Joseph Sinclair wrote:
> I never viewed the Installfest as the primary customer.  They are
> providing a convenient focus to the initial iterations, but I never
> intended to create software specific to installfests, I think I
> mentioned earlier that if that had been my preference, I would have
> created something really simple.

You are correct here.

What I am advocating is treating InstallFest as a "real" customer with a real 
account.  Similarly, we treat the PEP Working Group as a brand new firm.  The 
viability of the firm has yet to be proven.  A "really simple" little project 
is just perfect for our brand-new little software production firm.

We build something, finish it, use it.  In the process we build PEP and are 
ready for a somewhat bigger project.  (Yes.  This is a wedding of agility 
theory with capability-maturity organizational theory.)

> I don't think we ever discussed integrating the solution developed here
> into the existing PLUG site.  I, personally, don't think that's such a
> good idea, given that the best way to do that would involve writing the
> system as an extension of PostNuke in PHP.  I think we did discuss
> having an easy-to-use link, and perhaps permitting the
> look-and-feel(L&F) to match the PLUG site L&F, but that's easy enough to
> do in any reasonable architecture.

In prior correspondence I had hoped to be clear that InstallFest consumers 
would see the public part of the application as part of the PLUG site.  That 
is, integration at the level of look and feel only.

InstallFest organizers and other volunteers would presumably have access to an 
administrative interface.  Presumably it would be nice if the administrative 
interface had a consistent L&F with the rest of the PLUG site but its 
consumers would tolerate the product if it were a bit "rough".

Basically, that is a long winded way to say we agree.

> I've been working with lightweight methodologies, primarily XP, for
> around 5 years now, and I have never been able to find in the XP
> methodology anything that suggests you build your system as though the
> current iteration is the entire system.  You don't build *functionality*
> not needed by the current iteration, but you do build this iteration's
> functionality with the understanding of the entire release, and you make
> architectural and design decisions with the entire project vision in mind.

I keep thinking of (ASU Software factory's) Steve Gordon's hatered of software 
"requirements".

As a software shop, the PEP Squad can work with InstallFest to build solutions 
for InstallFest.  That is concrete.  

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.  

For example later on you will turn Bryan's hypothesized need for unconnected 
workstation operation into a user story.  Unfortunately, it is only an 
*imagined* user story.  I would be MUCH happier if it were not an imagined 
story, but based on utterances elicited from a potential consumer or analyst 
participant observation.

At this point, of course, my opinion is based on too much education and too 
little experience.  

My concern is that coding to a strategic architecture at this point is 
premature.  Right now a strategic architecture must be based on poorly 
grounded assumptions about consumers and markets.  To do more architecture we 
should have more real customers and more real research.

<important>
As junior to senior, I want an explanation about why we have enough 
information to GENERALIZE the architecture WELL beyond the IFA account to the 
PLUG/AZOTO account (that I did not know existed until now) and beyond.
</important>

> I think these three things start to bring light to this discussion,
> Trent.  You are trying to see the "best" (i.e.
> simplest/cheapest/easiest) way to build an installfest application, with
> the installfest as a primary customer,

Check.   Although that is short term (2 quarters at most) and tactical.

> and a strong desire to place the 
> final solution in GNUe.  

I am not married to GNUe.   In the short term, I do not even care about it.

I DO think that given what I see as PEP's strategic potential, that PEP would 
gain synergy by being a module in a FOSS ERP/M solution (and GNUe is the only 
one I know about).

> I am trying to see the "best" way to build a 
> full-out enterprise event planning and management system with PLUG/AZOTO
> as the primary customer (much broader needs there), the installfest as a
> nice proxy customer for a few iterations, 

Like I said, I know nothing about the PLUG/AZOTO account.  In business terms, 
I may not NEED to know more about this account, but I think I SHOULD know 
more about it.

Also I am thinking more concretely in terms of customer+architecture as A 
project instead of an overall strategic vision and a grand architecture.

<important point>

So Trent's working methodology:

*  strategic vision = full-out enterprise event planning and management system  
in an ERP/M context
** Strategic vision will be changing all the time.  Resistant to architecture
** Stratigic vision will be realized over time through many projects.
** Projects are informed by overall vision.

* Customer = Project
** project has interations.
** Customers must be treated like customers.  Each gets best eXP service 
available even if that is not maximizing for the strategic vision.

Joseph's working methodology.

*  strategic vision = full-out enterprise event planning and management system 
** Insure high quality, maintainable software by creating architecture NOW!
** Stratigic vision will be realized over time through many interations.
** Iteration = customer

</important point>

Of course, if we have two accounts, and do neither an injustice by sharing 
resources between them, then we should do that.

Nevertheless, This means that the PEP Squad software shop has two distinct (if 
friendly) customers.  It would be unethical to sacrifice InstallFest to 
PLUG/AZOTO.

> a strong desire to see the 
> software built using the platform preferred by those willing to
> volunteer as core developers, 

Fair enough.  You cannot build software without developers and 
para-developers.

> and a desire to ensure it actually gets 
> built, whether I like the final PAD(Platform/Architecture/Design) or
> not.  

YESSS.   Building something deliverable GOOD.    Very GOOOOD.

> Neither position is inherently right or wrong, they're just 
> different.

Exchange of olive branches accepted.


> As far as Bryan's request that a single-user solution be available, I
> agree that, at some point, a single-user system should be available.

Check.

> Since it's utterly insane to expect an unsophisticated user (i.e. church
> admin, "soccer mom", etc...) to install the LAMP components (or GNUe or
> J2EE) on their workstation, 

Could not these be built to "auto-install" in a default configuration?

> I would expect the single-user solution to 
> be an easily downloadable (PDM, Java WebStart, etc...) client
> application capable of running in both online and offline modes, and
> with the option to have no parent server at all.  

I am unfamiliar with these technologies.  Are we basically talking about a 
"fat client"; that is, an application on the user's console?

> This sounds a lot like 
> a user story, so I'll keep a story card for it, assuming Bryan agrees
> with my description.