Legacy systems; was: RE: [AM] ZZZ

(responding to Dagna)


> LEGACY SYSTEMS ARE THE ONES YOU WISH YOU
> COULD LEAVE BEHIND YOU


>> I'm not sure I understand the full ramifications of the
>> problem, but it seems to me that a large part of the problem 
>> in this case was the failure to uncouple the meaning of the 
>> data from the implementation.  Applications are going 
>> straight into the database rather than going through an 
>> interface. Say, using embedded SQL rather than stored 
>> procedures. (No doubt there are other ways to provide such 
>> an interface).

Oh - and Views, thanks for the reminder, whoever that was.

> DG: All the things that seem so obvious and easy now were
> once pretty revolutionary. Consider that most companies do
> the important and/or time consuming processes first, so the
> stuff the business really depends on (order processing,
> producing bills, recording customers) is often the oldest.

So the most important is likely to be the most fragile and
sclerotic, <select your own geriatric disease descriptor>
of the code and data.

> Replacing these systems is a scary prospect - they hold
> business rules and processes as well as data - so new
> developments have to fit into the existing landscape. Working
> out what there is, how it fits together, what it all means, and 
> how to insert new stuff in so that the ugly joins (transformations)
> are minimised, is what keeps me in gainful employment.

I'd hope that new developments start replacing bits of that
landscape.

> I have the impression that few (if any) new companies bother
> with a formal data or application architecture - they are small
> enough that they know how it all fits together, and they only
> have one billing system, order processing system, HR
> system... Ten years and/or a few takeovers and mergers
> on, the picture is very different, and the Architecture Team
> appears in a corner somewhere. (A nice, quiet team, no
> trouble to anyone. Trust me, I'm an Architect!)

...the ones that tell you the architecture to use before you tell
them the problem that needs a solution?  I met them already.

> Two examples. I changed employers in 1999; my old
> employers had a major system (one of two that the company
> totally depended on) which celebrated its 21st birthday in about
> 1995. It was written in Assembler.

That just *has* to be cheaper to replace than maintain?

> My new employers had a major system that stored its data on
> magnetic tape. (That isn't this employer, BTW). The data from
> both of these systems got sent all over the place, and any
> change to either could have an impact on the rest of their
> systems.

I guess it would be feasible for a new system to support the
old interfaces.  Costly and nasty, but possible?

> Even a small impact per system adds up when you
> hit a high enough percentage of the 120-odd systems you
> have. (I have a theory that 120 is a magic number - having
> worked at three large companies all with about that many
> major applications.)
>
> A lot of these old systems don't have databases - they have
> files. They don't always have indexes. Updates are FUN.
> (Especially when the storage medium is absolutely serial -
> mag tape.)

One would think that tape devices must have a limited
future.  Any ideas?

> I think that Y2K inspired many companies to bite the bullet
> and replace their old systems with the modern, relational or
> OO version. But my impression is that most companies didn't
> - when a system has been in place for ten years or more,
> maintained in house, then the likelihood that anyone knows
> everything it does and what, exactly, each little wrinkle in the
> code is for, is slim. Even if the documentation exists, it can
> be tough to put all the pieces together and work out what the
> new one needs to do and how the data is migrated.

Hmm - replacing the system doesn't need to duplicate
functionality exactly, as long as the interfaces fill the
needs of interfaced systems.  Yet data migration still
needs to happen, and might need special programs to
be written to snatch the data out of the system... and if you
don't do this at the last minute, you need to keep the new
data updated with any changes going through the legacy 
system...  Decoupling the legacy system in-situ may be
a better approach (putting internal interfaces in place,
allowing all sorts of nice tricks...)

> My first warehouse project, one of the two source
> systems was a fifteen year old, in-house, major system.
> To be sure that we knew how it worked, we had an experienced
> analyst have her own copy and put individual transactions
> through and check all the data files after every program in
> every batch to see what it did. As she found things, I modelled
> them and then we talked to the developers and said 'is that
> right' - a lot of the stuff was things that had been forgotten over
> the years. We had documentation going back to the original
> file layout sheets, and the original developers were still with
> the company (one was head of IT), and we had very
> experienced developers working on the system and doing the
> analysis. It still took us a year - two people, one full time, one
> most of the time. (Experiences like this are, I think, what make
> some of us old hacks nervous about Agile methods, or anything
> else that seems to promise speed - we are afraid for the
> documentation and have too many grey hairs gained in
> maintenance over the years.)

Time will tell how well 'agile' code stands the test of time.
If it gets into the hands of non-agile teams, I would expect it
to start degrading.  Yet until then it should be self-explanatory
and have some essential maintenance documentation.
'Should' is one of those get-out words though, and I can see
a few years where agile has gone mainstream but the
teams don't have the quality of guidance, and such things
will slip.  Yet that's the sort of thing giving us the current
headaches - OO ideas that never made it as far as the
database; code being maintained way past its sell-by
date and becoming harder to replace as it becomes harder
to maintain, etc. etc.  There never have been enough good
developers to go round.

While you were doing a forensic analysis of the existing
system, was there a business or domain model for
comparison?  I always like to have an ideal to work
towards in case any opportunity to change something
peresents itself.

> Encapsulation can fix all this! The database gets hidden, and
> you just see the API... So you go and see the users, and tell
> them that you want to encapsulate your major databases, and
> that it will cost x thousand/million and they won't notice the
> difference.

Hmm... maybe not the way to sell the idea?  ;-)

> You have to have pretty clued up users if they are going to see
> that this should be done before their new toy (sorry - tool) gets
> bought, and that it is worth doing something that they won't notice.
> Or you can try to steer the conversation so they first see the
> problem, then they ask 'what can be done'. This will take time
> (days or weeks, often years). If you can get them sold on the
> scale of the problem, then getting buy-in for encapsulation is
> much easier - it is way cheaper than redeveloping the original
> app. (Based on gut feeling rather than metrics).

Also makes it easier to replace parts of the system when that
becomes necessary, if they are already cut into smaller
pieces behind interfaces.  Just make sure the replacement
pieces support the idela interfaces in addition to the
legacy interfaces  ;-)



Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------