October 2, 2015 at 12:00 am
Comments posted to this topic are about the item The Work of the Ancients
October 2, 2015 at 12:22 am
I know the UK tax system was supposed to be migrated to a client server architecture when such things were fashionable. As far as I am aware it is still on a mainframe that predates Microsoft.
October 2, 2015 at 12:56 am
I've worked and seen systems that are 20 years old and still works fine and can also be maintained because of decent architecture.
Where I am at the moment however, there is a mix. Only been here for a few month but already suggested that we replace a few bloated systems. One of them is very strange... they build a winforms app that works like a very limited browser to the database where they have built a very limited winforms engine that you configure view's for with xml and listen to this, they even implemented an extremely limited programming language of their own. Then you have to work with xml files that are not true xml to configure data loading and persisting and in these files you have to write the where statements and you can not do joins or go against sp's or views. They have hardcoded references against columns so there is no separation there. If this system was very old and people didnt know better at the time... I could have understood it, but it's only 5 years old and I've suggested to stop all work with it because it's with mild words, horrible for both users and developers. The architects defense is that code only lives for a few years anyway and the application only needs to work, does not have to be pretty.
I felt compelled to write a review of these parts and it seemed that everyone else agreed with my assessment. Sure, such a report could get me fired, I just started at this company a few month ago, but I can not with good heart conceal such facts from the company and not suggest changes and solutions to the current situation with some systems. I was prepared to leave if this would not have gone well, there is no short supply of IT jobs anyway, but were I to stay I wanted to work for change for the best of the company and the developers.
My conclusion is, some people should simply not be in the IT-business. The person behind this mess for instance, I can not assess the unnecessary costs he has caused but, it's not a small amount.
October 2, 2015 at 2:05 am
Some of my systems running on MSSQL now are using databases migrated from Informix on SCO Unix, with only some subtle schema changes (due to the size of the database). Some of them were migrated to MSSQL over 15 years ago and still run today!
October 2, 2015 at 2:31 am
I wrote a system in MS access in 1993 and upsized it to SQL Server in 1996. Its been updated constantly but the core is much the same as it was in 93.
October 2, 2015 at 2:56 am
If you ignore schema updates and changes, development changes, etc... we have three applications over 10 years old, with DB's that have gone through several systems upgrades - SQL 2000 all the way to SQL 2014. One of them in particular has suffered over the years from poor architectural decisions at the time of creation.
October 2, 2015 at 5:59 am
We have systems on 2 platforms. The core systems on the mainframe (with Z/OS and IDMS) are about 20 years old, while the core systems on Microsoft and SQL-Server are 15 years old. Our newest big system is 10 years old
October 2, 2015 at 7:11 am
I was reading a post from someone recently where they noted that they didn't worry to much about the architecture of the system since it wouldn't likely last very long. The poster had a comment that many systems are replaced inside of a few years.
...
The foundation and plumbing of a building tends to remain in place longer than the carpet, windows, and company logo.
The same goes for the databases that underlie applications. I've maintained SQL Server databases that had been in production for 15 years. But the applications stacked on top of the database went though three or four phases of re-architecture over the years, each time coinciding with a corporate merger or acquisition.
VB6 / Windows / Client Server / departmental usage
ASP.NET / Windows / corporate intranet usage
Silverlight / Windows / Web / corporate and client facing
HTML5 / web / cross-platform / public subscriptions
There were revisions to the architecture of the database over that period of time, but not so much that the initial developers wouldn't recognize the data model and ETL processes in last iteration.
Another thing to keep in mind is that the architecture of legacy databases and applications tend to become patterns and frameworks for new (more or less related) projects, so don't think that your architectural decisions exist only in the vacuum of your current project's lifecycle.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 2, 2015 at 7:28 am
I work on a couple systems > 10 years old.
If this guy you refer to only works on systems that are replaced every couple of years, my guess is the systems in question aren't particularly widely used or are POCs/prototypes that got swept up into production too soon. On a more generous note they may just be systems that from the outset are meant to have a short life (although many are aware of the famous 'Space Jam' website that's still out there).
Generally it seems the more successful a system is, success being defined loosely as the business finds it beneficial and grows somewhat dependent on it, the longer it's going to be around. Just on principle it's best to strive for a solid architecture, but this makes it even more important. On the other hand a slapdash architecture may lead to a self-fulfilling prophecy that the system will get replaced soon.
October 2, 2015 at 7:54 am
brad_bowzer (10/2/2015)
I wrote a system in MS access in 1993 and upsized it to SQL Server in 1996. Its been updated constantly but the core is much the same as it was in 93.
Wow, that's pretty old for SQL Server. We have a reporting application/SQL Server DB that goes back to 2002. Of course, talk to a Cobol guy and they'll say they've got architecture going back a lot further 😀
Ken
October 2, 2015 at 8:06 am
The oldest database application I wrote was one I started back in about 1992 (Ingres). It is still running, useful and being maintained. Another system I designed in about '95 is still being used the last time I heard. The system I am currently working on was designed around 1990, but the database behind it has changed a few times over the years.
Most systems I design take at least a year to implement and have designed lifespans of 10+ years. My latest design is expected to last about 20 years (Although continued maintenance will be required to keep it current). Standards based code is almost always the best way to ensure longevity.
October 2, 2015 at 8:28 am
Databases are eternal in my experience. The sun will burn out before most businesses will let go of a database. Migration? Maybe... if they are forced to. We had over 3000 databases at the last place I worked and many of them could have been consolidated but nobody was really making a good case for it and that's been true everywhere I've worked. The reasons are numerous. Some sound , most not in my opinion. It's usually because of fear due to poor planning.
October 2, 2015 at 9:03 am
brad_bowzer (10/2/2015)
I wrote a system in MS access in 1993 and upsized it to SQL Server in 1996. Its been updated constantly but the core is much the same as it was in 93.
That's cool. V6.5 to start and now on a later version?
October 2, 2015 at 9:15 am
Of course, talk to a Cobol guy and they'll say they've got architecture going back a lot further
I couldn't believe it (and now you know how old I am). I data modeled for a project for Cadillac back in the mid 1990's for a cost estimating function. It was originally targeted for Sybase (the predecessor of SQL Server). It ended up being done in PL/1 and DB2 on a mainframe and is still in use today at GM some 20 years later as a corporate system! Still on the mainframe, and the developers who maintain it are now in Argentina. Small world.
October 2, 2015 at 9:40 am
I think it was 6.5, but might have been 6.0. SQL was just $1300 plus another $1500 on a big desktop (like a 120mhz 1-CPU Pentium). It was a small company so that cost was a big risk for them.
When it was first converted to SQL Server the owner came over with a stopwatch to time the difference. In Access without SQL Server it was taking 45 seconds to do a search -- the machines were very slow and running on a thin-net 2mb network, which was about as fast as the average company could afford in 1994.
The first search with SQL Server took less than 1/2 a second. Only then were they happy.
Viewing 15 posts - 1 through 15 (of 61 total)
You must be logged in to reply to this topic. Login to reply