|
I agree with Joe, in everything he said. I could find nothing I disagree with. I just draw a different conclusion. It centers on the one point: "The ease of interconnectivity between those solutions is the key." I, and I think Nathan agrees, do not believe the ease of interconnectivity is sufficiently easy, to justify the cost savings. That, of course, is a judgment call. But I think the n-tier design methodology applied better in past years, than it does today. The 400 was outrageously expensive, at one time. (No picnic paying for one today...;-) But these days, especially in the area of a pure batch processing, CPW is A WHOLE LOT cheaper than it was when n-tier was accepted as the CW... It's impossible to forecast the future, but if you look at the trends... The iSeries is handling more and more workload. More capabilities than ever... NT, *nix (and Linux), Domino, on top of the traditional line-of-business apps. The question to me is whether or not the situation today, and in the near future, is gonna justify the crippling expense of maintaining multiple platforms. Sure you can hire expertise in each area... It's not the added expense of the people (although, by almost all studies, that tends to even out the initial cost of a 400). The problem with all the people, and platforms, is that it's all the easier for the left hand to have no idea what the right had is doing. That's always been one of the primary difficulties of any business... Why amplify that problem...? The simplicity of a 400 has a cost, in the higher cost of the assets.. It seems to be more widely known that this added cost is more than offset by savings in personnel costs. I'm not sure that the savings in dollars, by reducing the confusion involved in operating more than one OS platform, are as widely recognized. These are definitely intangible savings, which are harder to quantify. They may be harder to quantify, but the savings exist. Matter of opinion whether that justifies keeping your systems on one platform or not, at this stage. Looking at the trends, however, makes me comfortable with that opinion. So I think the question to focus on is whether the 400 CAN provide easy to administer, easy to use, secure access, nad with good price/performance. Or rather, could it be ENHANCED to provide these things better. jt | -----Original Message----- | From: midrange-l-admin@midrange.com | [mailto:midrange-l-admin@midrange.com]On Behalf Of Joe Pluta | Sent: Saturday, December 15, 2001 9:47 PM | To: midrange-l@midrange.com | Subject: RE: Re:Where are all of the /400's going. | | | > From: Nathan M. Andelin | > | > Now that I've begun marketing a framework for developing ILE based Web | > applications, I have an interest in this issue. I hope companies will | > overcome their fear of the Internet and connect their 400s to the Web. | > | > I'd like to discuss specific fears, and talk about 400 | solutions to those | > concerns, rather than the alternative idea of moving data and | applications | > off the 400. Any takers? | | This thread certainly wasn't about moving applications off of the AS/400. | The only issue that was being discussed was the idea of access to | secure and | unsecured data. And perhaps that's the problem; we're still trying to put | all our data processing into the same box (we each have our own box, but | regardless we try to stuff all business requirements into that | box). No one | solution is going to fit all needs, even if they're all accessed via a | browser. | | I don't think anybody would argue that a web page that serves up static | images is a different beast than a web-based order entry application. And | of course, there's a wide gamut of different user needs in | between. It's my | contention that we need to think outside of the box and realize that | different requirements dictate different solutions. The ease of | interconnectivity between those solutions is the key. | | For example, a static public web page is not best served by an | AS/400. I'm | not saying it can't be done, just that there are far cheaper alternatives. | If I go to a CFO who wants just a static web page and try to sell him an | AS/400, I'm probably not going to leave a very credible impression. | | I think we need to define user needs by the business | requirements, and then | map those to the best solutions, rather than start with a solution and try | to fit user requirements into it. Your framework, my legacy | revitalization, | encapsulated servers, each can probably fit a niche. It's when we try to | use the same tool for every job that the process bogs down. | | Joe | | | _______________________________________________ | This is the Midrange Systems Technical Discussion (MIDRANGE-L) | mailing list | To post a message email: MIDRANGE-L@midrange.com | To subscribe, unsubscribe, or change list options, | visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l | or email: MIDRANGE-L-request@midrange.com | Before posting, please take a moment to review the archives | at http://archive.midrange.com/midrange-l. |
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.