Moduluar Integration [was] Guinea Pigs [was] EPP [snip]

[Trent Shipley]

On Monday 2005-03-14 11:05, Bryan.ONeal@asu.edu wrote:
> Just a note on ERP integration:
> We will need to track resources that may already be available in other data
> arenas, such as people, equipment, locations, etc.  

Indeed.  And this is why I was really looking at a tightly integrated package 
such as ERPM.  

One thing we want to look at with EPP is reusing existing functions.

Armchair analysis leads to the expectation that event planning and production 
(Event Planning and Production Project??) has some basic dimensions.

Time:  Calendaring and deadlines are mission critical.  Timing is everything, 
especially for something like a campaign advance team.

Inventory:  Artifacts things that move.  Everthing from chairs and tables, to 
balloons, and stages and sound systems.  And not least, catered food.

Facilities:  Things that do not move.  Rooms, grave sites and so on.  This can 
also be thought of as space.

People: Agents participating in the event.

That is four critical categories of things.


The strategic vision, in my opinion, should look at using existing software 
and the use of EPPP by other software.


> We should design to 
> track this information in a way that fits the greatest common denominator
> of our potential users. 

I'm thinking LEAST common denominator here.  For each area where we can 
recycle existing FOSS functions, lets do it once NOT generically.  (The only 
exception being loose coupling to the database, maybe.)

It is this "all things to everyone" that makes ERPM packages of such 
questionable value in promoting overall enterprise productivity.

> Actual integration can then be modularly added on 
> through DB query's, LDAP connectivity, etc..  (JAVA handles these very
> easily, but I understand most languages could replicate the same thing with
> a page of backend a page of business logic and a page or two of GUI, so
> again language is not a concern at this time)

In my experience this is much easier to say than to do.  The PERL mantra 
"there is more than one way to do it" is entirely correct.  It makes 
producing general solutions for going concerns a real nightmare.  Adding 
connectivity options is easy, but if integration with EPPP remains difficult 
for entry-level programmers then we will have a long way left toward 
producing a general solution.

Indeed, it would probably be easier to duplicate a lot of EPRM functionality 
(like building inventory management and facilities scheduling from scratch as 
stand-alone modules) than to design EPPP so that hooking up to Oracle 
Applications, PeopleSoft, and SAP is almost painless.

And that project story leads to EPP as the camel's nose for a FOSS ERPM 
project.

> On Sat, 12 Mar 2005, Trent Shipley wrote:
> > On Saturday 2005-03-12 14:04, Joseph Sinclair wrote:
> > > Trent Shipley wrote:

> > <snip/>
> >
> > > ERP is [just] an inventory/accounting activity that doesn't mesh well
> > > with events planning
> >
> > My understanding of ERPM is more inclusive.  It is really database
> > integration across the enterprise.
> >
> > <snip/>
> >
> > > 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.
> >
> > In my experience, there is NO SUCH THING as a "simple" link into an
> > existing ERPM.  Peoplesoft, at least, doesn't do a good job of hiding its
> > data layer. There is no neat API.  Usually you have to hack directly into
> > the database layer that is enormous and unspeakably complex.
> >

<snip/>