Aldon's CMS Change Management Software -Reply -- MIDRANGE-L

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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *