Re: OGo/Plone integration

On June 4, 2004 09:43 am, Michael Brown wrote:
> Hi Helge et all!
>
> > Support requests should be handled by a good
> > ticketing application,
> > like RT or Bugzilla. This is not really a groupware
> > nor a CMS topic,
> > though obviously there are integration points ;-)
>
> No arguments there, but integration is good from a CRM
> point of view. 

The problem here is that acronyms such as CRM always mean something different 
to all clients. Hence these tend to be custom jobs. 

> I agree with Kelly's comments about 
> RT; Jesse did a fine job with it, and it's a great
> application.  Integration is the only issue.  I worked
> for a big hi tech company, and almost all the
> applications were "islands in the stream".  There was
> way too much duplicate, or conflicting information, or
> none at all, and chasing it down was always difficult.

See above and very common when propriatory API's, and file formats are used to 
deploy systems. How do you think the industry got to the state its in..:)

>  Bringing everything together (somehow?) into
> something like OGo would really benefit a lot of
> companies by providing an accurate overview of their
> customer relations - be it internal or external
> customers.

This needs some very carefull analysis as there are many things to consider 
starting with hardware.....all the way up the ladder to system architecture 
and application design. 

> > If you have low requirements: tasks + projects. If
> > you have higher
> > requirements, see above.
>
> Tasks and projects are good.  Tasks should support
> dependencies at some point for real project management
> applications.  Maybe something like RT's "depended on"
> or "depends on" features.

Again, "real project management applications" are always open to definition 
hence customization. I can list at least 5 that are used at corporate levels 
and that most people have never heard of. Then there are issues associated 
with propriatory vendors. Very difficult issues. 

> > > Also, Plone has a workflow system.  How would OGo
> >
> > handle that?
> >
> > A somewhat too generic statement? Do you have an
> > application in mind or
> > just try to be buzzword compliant? ;-)
>
> < ;-P >Helge, I'm shocked!  Are you suggesting I use
> buzzwords for the sake of using them? </ ;-P >  :-)
>
> Seriously though, workflow (business process, document
> flow, whatever) is common everywhere in business, and
> it would be good if OGo had some sort of more advanced
> version of business logic available.

Why? Would you want to do a thesis in vim? Some would I would not. OGo is good 
for what it does. As long as it remains open and robust features can be added 
as required by clients or deployments. However to distract developers from 
adding core features complete without a solid business case, is IMHO a big 
drain on resources. 

To understand workflow as its used in zope/plone, you also need to understand 
its limitation in terms of inputs and outputs. As far as I can tell, at this 
time, the workflow system is not amicable to integration with OGo other then 
as a start or end point. Certainly the functionality to include any OGo 
module as an intermediary element in the chain is not present as of yet and 
would take some very serious rewiring of both zope's workflow engine that 
plone uses, plone itself in terms of forms and ZODB access and respective OGo 
modules and associated API's. In short it sounds nice, but it will be a bear 
to implement. It can be done but not by generalists. Requires expertise in 
both Zope and OGo wiring.

> In documents, at 
> the least there is Create -> Submit ->
> Review{Approve/Reject} -> Publish (like the OGo
> plone).  In the company I used to work for (5k people
> on campus) there were hundreds of documents being
> used/worked on at any one time.  There was an
> electronic document review process (workflow) that
> notified the signoff "committee" as to the state of
> documents (pending review, pending acceptance, etc)
> and the signoff status of each member, working towards
> final approval by the lead.  That kind of thing...

Thats native in zope with a little effort. Naitve in plone which rides on top 
of zope. Can easily be done, in fact I would say that component is almost a 
no brainer for a zope developer. Like one weeks effort max to have a tested 
prototype in place. However, hooking OGo into this mechanism, unless there is 
business case that can produce the correct workflow model and points of 
integration, what is the purpose. If it works, why mess with it. Adding OGo 
as the last element of the workflow scheme is not that difficult. Similarily 
using OGo modules to initiated a workflow scheme in zope is also not that 
hard, nothing more then an XML-RPC call that is scripted to be event driven. 

What I am suggesting is that the ideas are good, but need far greater levels 
of refinement prior to considering the level of effort involved. Secondly 
there needs to be a solid use case and business case to do the same. 

Example:

I had a client who wanted a very similar concept external website integrated 
selectively with OGo.(much more but will spare the details)  We did a 
complete design for them, retained the appropriate subs and presented our 
case. In the end, the client remained with his internal workflow 
engine....waite for it....Outlook task management...and dumping files to the 
website manually. Go figure, and they had very deep pockets and were involved 
no less with application development. So if you have an outfit of that 
caliber who supposidly understands software development rejecting 
OGo-Zope/Plone integration on costs and a preference for using Outlook task 
management, the use case and business case must be very effective in order to 
clients or users to invest the dollars that are required. In the end, it was 
not even expensive, all things considered. Just another intangible that needs 
to be considered. 

> > OGo _has_ group permissions for almost all objects
> > in OGo. We miss
> > roles, especially for administration.
>
> Roles would be handy.  That way you could have stuff
> like "signoff_required", "Manager", "Owner", etc.  and
> have that part of the workflow system as well as
> overall OGo system administration & permission
> structure.

Why...why would you expect this capability from a groupware application. I can 
rationalize documentation management no problem, but I would much prefer to 
have OGo as a starting or end point, not as a workflow management system. 
Just the load on the system alone that such a concept would introduce would 
slow OGo down to a crawl I would presume. There are feature request and 
design consideration, and architecual issues involved here. Personally I am 
not against any of this, rather simply pointing out that OGo has maintained a 
rather well planned and execute balance between features and performance. I 
would hate to see wish list items unless supported by real world use and 
business cases deter from that inherent strength. 


> Gotta run and feed my baby.... then back to work when
> she naps.  The joys of starting a business at home!
> (Actually, it is nice... challenging, but nice.)

Beware of social isolation. Make it a point to meet with someone, anyone, even 
if its a conversation with a stranger while getting pampers, at least for one 
hour each and every day. Learned from experience that once the thrill of 
working from home wears off, you can get very very isolated by brrying 
yourself in your work. As with all things in life balance is the key.

You have some good ideas. I am not trying to discourage you rather nit picking 
to get you to dig deeper if these matters interest you. Again, best of luck.

/ch
-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss