[Zope] Zope, ACS E-commerce & Authentic Service Delivery Systems

[Richard Volpato]

   Back from Easter, back to see what's been happening.....

   On re-reading the Zcommerce discussions regarding Zope, ACS 
and the nature(s) of e-commerce, it seemed an opportune time 
to flesh out some of the issues raised (particularly in Walter's 
analysis:  
http://lists.codeit.com/pipermail/zcommerce/2001-April/000418.html). 
  
   I end with some recommendations.  I am not a developer, but I am 
pushing for Zope deployments in various settings.  I have tried 
to fill out the issues rasied with some examples - which has lengthened 
this comment. 
 

Overview  
=========  
 

    We are all agreed that Zope needs an e-commerce 'story'.   
The story has to be about something real and compelling and 
not simply hype or a hobbled 'add-on'.  Zope has some special 
qualities.  These is its  'meta-data facilities' and delegation. 
 There is, I think, a deep link between the strong facilities 
for meta-data and delegation in Zope and the capacity to transform 
e-commerce from:  
 
(a) the servicing, via a shopping cart, of a (typically fickle) 
customer, to 
 
(b) enabling buyers to co-produce and augment, for themselves, 
the value in what they are buying. 
 

   The example of Amazon.com illustrates this - many users enjoy 
browsing rather than just buying there and  many buyers contribute 
reviews, lists, and auction items.  In Amazon's  'engine' lies 
a collaborative filtering mechanism such that the very trail 
of purchases becomes part of the 'map' to inform others.  The 
necessary SQL for building this is already in Arsdigita's  ACS 
code. That is no surprise; after all, ACS is a community-building 
infra-structure rather than a content management system.  Of 
course, the *whole point* is that these two (interactive web models) 
are converging.   
 
    Now for some more detailed thoughts É..  
 
 
            Customer  <===>  Member 
    ====================================	  
 
 
   If e-commerce is seen as an 'add-on', I think a mistake is being 
made. Such an 'add-on' will look like some shopping cart with 
a 'back-end' that helps a solitary customer buy some 'thing'. 
 
 
   Huge parts of the economy involve more than this.  Many service 
areas  - from  financial planning, education, health, lifestyle, 
travel,  welfare, etc - all involve service professionals working 
to transform a client. There is a tug-a-war going on in the 
economy as to whether 'clients' can be reduced to 'customers' 
or whether they get better service as 'members' of groups focussed 
on their problem.    
 

   These services are labor intensive and thus, not very scalable. 
However they become easier to deliver and more profound in 
their effects if the 'clients' find a way to transform each 
other. Thus a classroom enlivened by discussion is easier to 
teach than one passively responding to the 'teacher'.	The 
'web' has pivotal role to play in these service settings. Unfortunately, 
 the drive for 'web enabled service delivery' has missed the 
point of giving clients a voice and tried to commercialise the 
wrong aspects.	 It is only now with the kind of architecture 
offered by Zope that a path to authentic web support becomes 
feasible.  
 

   The web appears to offer 'scalability'.  While services may 
be labor intensive, what is labored over  (ie The Content) appears 
not to be: vast numbers of web sites offer financial advice 
without the adviser, curriculum without the teacher, exercise 
regimes without the trainer, itineraries without the travel 
agent; health without the doctor etc.  
 

   Yet this kind of web delivered Content is often "dead on arrival". 
Either interactivity is lost; content is not refreshed fast 
enough, there is not enough (any!) personalization, localisation 
or sequencing; the modes of delivery are too demanding or standardised, 
the 'Content' was just plain mediocre to start with etc.  Sure 
initially,  'customers' feel they have choice, cheap deals and 
are freed from the condescension, price fixing and the repeat 
'sessions' of service professionals.   They are discovering 
that much of this was a costly chimera	 
 

   The challenge is to scale the service via a platform that gives 
voice to, and can collect money from, clients. 
 

   If the web can enable clients to witness the effects of their 
collaboratively achieved self-transformations, then they are 
'hooked' (for all the right reasons).  This is where Zope has 
a compellingly powerful architecture - except for a  'blind 
spot' regarding 'e-commerce'.  
 

   In my own experience, I have seen University curricula reduced 
to pedagogical pap through such web tools like WebCT: Courses 
as different as physiology and history all start to 'look and 
feel' the same.   Zwiki's alone, make for a more compelling 
experience, let alone another design I have worked on: the Web 
Enabled Authoring of Research (WEAR) which exploits Zope's capacity 
to delegate authoring, editing and templating. In this way, 
using  social data and field research, students can write chapters 
of real  books and become 'authors' rather than memorising readers. 
 
 
   In short, the WWW is currently full of 'scaled-up' content-for-service 
that have reduce clients to customers and lost service quality. 
 
 
   Before highlighting the revolutionary potential Zope has in 
this context - of scaling up service enactment, rather than 
service content - it is worth contrasting what Arsdigita does 
in this regard.  Arsdigita has a keen appreciation, that if 
people have a problem or puzzle, and they are given a 'voice' 
through which to share commonalities, then they begin to 'help 
themselves'  (eg as the many thousands of  photographers, mostly 
in small US  towns can and do share their lives at Photo.net). 
   
 
   Ironically, Zope is often described as a framework for "customers 
who have customers who have customersÉ." While the technology 
that achieves this, is superior to Arsdigita, the way it is 
talked about seems to me to be far less provocative to true 
to the architecture its describes. We need to emphasize the 
the value of, rather the capacity for, delegation,  in a business 
context.  Otherwise, the community creation capacity that goes 
with delegation  (as implemented in Zope) is hidden.   Indeed, 
I think, Zope's content management regime has the (unintended?) 
consequence of being a uniquely scalable "content-for-service 
delivery" regime.  
 

   Service delivery in these contexts, means service consumption, 
which can mean transforming 'clients' into members. Regardless, 
they mostly want to pay.   This is why there is a deep need 
for e-commerce to be intimately tied to content management  

 
   More importantly, the meta-data tagging available in Zope enables 
'contributions' to be assessed and potentially monetised as 
credits - thus enabling 'eager but poor' clients  to pay through 
contributions of labor rather than cash -  something Arsdigita 
has  built into is customer relations module.
 

   Zope I am sure means many things to different users.  I think 
there are good reasons for thinking it has a strategic role 
to play in being a platform for delivering the kind of content 
that gets used in various service transactions, not simply users 
'browsing' for 'dynamic content'.  The individualised, fickle, 
meandering, whimsical 'customer' can be left to the existing 
'B2C' regimes (best exemplified by the deep experience in this 
area that pornography sites have).
 
 
    Incremental Featurism  <===>  Strategic Architectures        
                ============================= 
 
 
     Wish lists for software always abound: "wouldn't it be nice 
if we had this or that feature". Wish lists always get too long; 
 developers get too busy, investors get too fixated on the 
'winning formula'; and customers ponder on what is hype.   One 
protection against this, that Zope has, is its development, 
focussed on architecture rather than features.	      
 

    With a sound architecture, features can be added easily.   Without 
it, featurism creeps in and discussion lists get bogged in choosing 
between listed wishes.	This architectural aspect is still missing 
from Zope's  integration of, rather than just access to,  RDBMS 
applications.	E-commerce is one such RDBMS application (despite 
views to the contrary by some on this list).   Were the integration 
to have architectural integrity, then  developers could enjoy 
the kind of Rapid Application Development comparable to that 
provided for ODBMS applications which  are so well catered for 
by ZODB.       
 

    It is this part of the e-commerce story that Arsdigita ACS  
has such immediate value and relevance.  If, as I argue, there 
is a strategic point to enabling 'members' to have voices (rather 
than just enable customers to confront things), then the  'community 
building' wisdom in ACS is worth investigating.   The work-flow, 
customer support and e-commerce modules immediately reveal (in 
their extensive documentation) that they provide far more than 
'shopping': they engender membership.  
 

    Zope is already well suited to delegate the building of  'service 
bundles' to suit particular contexts (of members with particular 
needs). This will develop further as the web moves towards 'peer-to-peer' 
configurations.  But even here, there is a  need for a commercial 
infra-structure to service 'membership', otherwise developers 
will end up looking for 'micro-payment' mechanisms which, I 
think, are too onerous for users to routinely engage (even if 
'micro-payments' looks like a 'cool' feature). 
 

 
   Dot-Coms <===> Dot-Nets      
      ======================	     
 

  Dave Winer somewhere contrasts Dot-Nets with Dot-Coms. Dot-Nets 
are companies that have business models which do not require 
vast 'customer bases' (enticed with 'free stuff').  Dot-Nets 
harmonise and modulate the productive capacities that are already 
there - providing a medium for new synergies of production. 
 In economic terms, it's the economies of Scope rather than 
 the economies (and tyrannies) of Scale.    
 

   Zope is a synergy-engendering platform.  I think, there are 
many new markets for Zope in the 'old economy' offices and factories, 
rather than new economy 'dot-coms'.  
 

  A nice example of this is 'call-centres'. They use phones, but 
they are still factories, (in effect).  Their main source of 
'energy' that powers these monsters of 'customer care' is the 
emotional toning of the telephonists (dealing with travel bookings, 
electricity bills, medial issues, appointments, etc). I have 
been trying to convince one financial institution   (which has 
moved to 'call centres') to imagine that some kind of software 
 (eg Zope) could 'dissolve', as it were, the whole phoney (sic) 
edifice of telephonically delivered customer care - replacing 
it with 'digital communities of care'. These in turn reduce 
the need for one-to-one consultations that are highly costly 
in service industries. 
 

   In many contexts, clients prefer to set up their own information 
portal and meetings - if only they could get  such an arrangement 
in place. Zope is precisely this kind of software. However for 
this to be operational, it desperately needs a transaction engine 
capable of doing e-commerce in the style noted above.	    

 
  Note that DC itself could never take responsibility for acquiring 
the core competency to deal with any one of the specifics mentioned 
above such as travel bookings, utility billing etc.  Nor could 
it fathom the actual enterprise engines behind these service 
delivery systems.  But DC does have a framework for the purely 
web side of any such project that is very suitable for Rapid 
Application Development and the evolution of web supported (real) 
services and transactions.     
  

   In my case, I'm not a developer with a deep understanding of 
the technology issues.	Nor am I one of these "dot.com" entrepreneurs 
who will disappear with the NASDAQ bubble.  I sit on Boards 
and undertake social renovations in areas that are not very 
web-enabled (suffice for e-mail and browsing). One Board (of 
a superannuation fund) we are studying technology that I know 
is going to be critical to the future of this "old-economy" 
service industry that has "members" (contributors) with "information 
needs" about pressing life-planning problems.  


  Many such sectors are still just "testing the water" 
with brochure style web sites.  But those in the industry (for years) 
know a lot more about  how business actually works than 
any "dot.com entrepreneur" and will be the ones paying 
for web development long after they are gone. 
At the moment it's difficult to get even small investments 
from Boards that don't yet understand what they are going to 
need.  Worse, Dot-Com companies offer expensive but 'all-in-a-box' 
solutions that seem attractive until the inability to factor 
in localised business processes and understandings become obvious. 
      
 
   Road Map and Stepping Stones	 
        =======================    
 
     First, make the e-commerce 'story' a real journey of development 
with the hallmark architecture that binds the other core components 
of Zope       
 

    Second, adjust to the qualitative 'leaps' involved in thinking 
about an erector set for content management (Zope) with a web 
based community erector-set (Arsdigita).  I think, by the way, 
Userland offers something of a bridge and supplement to both 
in various contexts.	   
 

   Third, develop a (sub?) group of z-commerce that can combine 
the business solutions issues (noted above) along side the technology 
 issues so that we get a dot-net style development, as opposed 
to a dot-com.	     
 

    Fourth, I would recommend from a business standpoint that the 
e-commerce module of ACS be looked at seriously (and this includes 
the workflow and customer support modules in ACS).	 
 

    Fifth, pool any extant efforts in this regard into a common 
project  (with DC's blessings).      
 

   Sixth, by building this open source community and managing the 
content of the e-commerce story we will have enacted the structure 
that illustrates what we would then be selling.   
 

I'd certainly like to join in taking up proposals suggested 
in this list to start figuring out here,  how we can get people 
who need  business solutions together with people who understand 
technologies like Zope and OpenACS.   We can then figure out 
ways and means of raising funds for what needs to  be done together 
with specifying what the business requirements actually are. 
  


Richard Volpato
2 Park Street,
FITZROY NORTH, VIC 3068