Re: Aldon's CMS Change Management Software -Reply

Scott:
Thanks for your very lengthy review.  I appreciate the detail.  Would you
mind if my client contacted you if they have any questions??  I usually
don't like calling a vendor supplied reference list... you know they are
usually going to give a good review, otherwise they would not be on the
reference list.  I thought this would be a better way to get some unbias info.
Thanks & regards,
Carl

At 10:47 AM 7/24/97 -0400, Scott Cornell wrote:
>We have just recently completed installing Aldon CMS
>product at our site.  The following is a (admittedly long)
>synopsis of our experiences.  DISCLAIMER: I have no
>connection/financial interest/relationship with Aldon
>Computer Group beyond being a customer. 
>
>For some background, our shop runs vendor purchased
>software with extensive MIS modifications at 12 remote
>sites.  We also have a number of smaller in-house
>developed apps.  Each remote site, to varying degrees,
>also has site specific changes to the vendor code as well
>as in house stuff.  
>
><Begin CMS review>
>- CMS is a good product: relatively easy to install &
>pretty flexible in terms of what you can do, supporting
>multiple releases of an app, achieving, object level
>auditing, object distribution, etc.  Aldon tech support has
>also been very responsive when we've had a problem.  The
>hard part during initial install was getting all our apps
>cleaned up so's Aldon would work with 'em - primarily
>finding the correct source for every pgm (a real treat
>when the vendor doesn't even have the right source
>anymore!).
>
>- Aldon "gotchas" are relatively few, but they do exist
>  - Job logs tend to be cryptic when a compile or promote
>fails - all you see is a message about "Call to Aldon pgm
>XXXX failed"  but the WHY it failed isn't there.
>  - Aldon's not really good w/PF-LF relationships.  If you
>check out an LF without checking out the associated PF, an
>EMPTY copy of the PF goes into your development library.
> This leads to head scratching when a developer attempts
>to test a new pgm using an LF pointing to an empty file.
>  - Aldon's kind of picky about AS/400 authorities.  We
>have a number of sites where a senior developer also
>wears the SECOFR hat.  Aldon doesn't like people
>w/SECOFR authority doing remote promotions.  One also
>has to be careful about matching authorities during
>remote development - if the actual coding occurs on a
>remote system, the developer has a user profile on both
>the local box as well as the central "Aldon" box.  If the
>authority on the remote object is too restrictive, Aldon
>can't bring it back to promote it into it's release hierarchy.
>  - Aldon requires a single thread release path for any
>application defined in it.  Thus, we had to really juggle to
>get our support environment set up, mostly the site
>specific changes.  A plain vanilla Aldon set up would have
>us create a base library, a vendor change library, a
>corporate change library, and 12 separate site change
>libraries for each of the 20 odd vendor applications we
>support.  When you realize that (in most cases) 5 or 6
>vendor apps work in concert, each needing AT LEAST 4 or
>5 Aldon libraries to be in the LIBL, you can see that we
>filled up the 25 available slots pretty quickly, especially
>during QA testing.  What Aldon needs is the ability to
>specify a given "release" or "application" as a child to many
>other releases - sadly, you can't really do that.
>
>- The REALLY hard part (not related specifically to Aldon,
>but a general "start from scratch" CMS project comment)
>was getting buy in from all our developers (both in our
>corporate offices as well as remotely.)  Our new setup is
>that all source code is  centrally located and any
>changes at any given site(s) must but checked out and
>promoted through Aldon.  No restrictions on what
>changes can be made - just log 'em into Aldon.  Despite
>this, for some reason, people feel "naked" when they can't
>just bop in, change a pgm, and bop out without telling
>anyone about it.  The objections were voiced (of course)
>as "What if it's 2:00 AM and the corporate 400 is down?",
>but since we bent over backwards to provide source
>access backups (via an RS/600, E-MAIL, AND/OR on site
>tape achieves), I suspect the real objection was simply "I
>don't have a copy of the source immediately at hand
>anymore!"  Upshot: I don't know how "locked down" your
>client's looking to make their shop, but people will fight
>any perceived "restriction" tooth and nail, saying "Aldon
>hampers my job performance" when it's really "Policies
>enforced via Aldon hamper my ability to anything I #%@$
>well please any time I want" - which, of course, is the
>whole point of change management to begin with.  Be
>prepared to be kind of unpopular!
>
>>>> Carl Galgano <cgalgano@ediconsulting.com>
>07/23/97 03:40pm >>>
>One of my clients called me today looking for a
>recomendation on Aldon's CMS
>software.  I only have experience with SoftLandings's
>Turnover so I can not
>give them any hands on eval.
>
>Can anyone out there give me the goods and bads (if any)
>on this software.
>
>TIA
>Carl
>Carl J. Galgano
>cgalgano@ediconsulting.com
>EDI Consulting Services, Inc.  
>540 Powder Springs Street
>Suite C19
>Marietta, GA 30064
>770-422-2995
>
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>* * * * *
>* This is the Midrange System Mailing List!  To submit a new
>message,   *
>* send your mail to "MIDRANGE-L@midrange.com".  To
>unsubscribe from     *
>* this list send email to MAJORDOMO@midrange.com and
>specify            *
>* 'unsubscribe MIDRANGE-L' in the body of your message. 
>Questions      *
>* should be directed to the list owner / operator:
>david@midrange.com   *
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>* * * * *
>umidr
>
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>* This is the Midrange System Mailing List!  To submit a new message,   *
>* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
>* this list send email to MAJORDOMO@midrange.com and specify            *
>* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
>* should be directed to the list owner / operator: david@midrange.com   *
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
Carl J. Galgano
cgalgano@ediconsulting.com
EDI Consulting Services, Inc.   
540 Powder Springs Street
Suite C19
Marietta, GA 30064
770-422-2995

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *