Help with Business Case

[Guest.Visitor]

I've been asked to help my VP put together a business case to support amalgamation of multiple AS/400s onto a great big LPAR'd iSeries. I know you guys don't have a lot of knowledge about our particular business needs but if you have any ideas about general items I should consider, I'd be most appreciative.

[Guest.Visitor]

While waiting for responses ... here's some more info ... We currently have 3 AS/400s ... 310, 620 and 730. Looks like the 730 could be upgraded to an 830/840. Maybe that's the way to go?

[Guest.Visitor]

Need to be fair on this, so I will present some quick thoughts for both sides. PRO: 1. Single box = 1 set of licences to worry about (both IBM and third party) 2. Single physical box so slightly simpler management 3. Can have a dedicated Save partition with data mirror which equates to less downtime for backups etc. 4. You can "load" the interactive CPW into one partition, reducing it in another. This lets you mimic the interactive performance of your starting machines in the partitions, to a certain extent. 5. You should get more "bang per dollar" with a bigger single machine. 6. There should be a lower total maintenance cost with 1 box versus 3 boxes. 7. High speed Virtual Opti-Connect will give better pass through, mirror etc than a LAN connect. 8. Easier to justify a better tape drive with a bigger machine (although the use of a dedicated Save partition could justify a lower spec tape drive). CON: 1. If you have a major failure such as a power supply, you lose all the partitions. 2. If the Primary partition needs to be IPLed, then all partitions need to be shut down and IPLed. 3. If the Primary partition "dies", then the other partitions go as well, and then need to go through an Abnormal Recovery IPL - which can take hours. 4. If a disaster occurs, it is harder to find a replacement for a bigger machine. It is also harder to find a hot site. 5. Management of the partitions is done under SST/DST which requires some additional skills to normal operations. 6. You will "lose" more of the machine's total capability by going to LPAR than by setting up multiple software environments within a single partition. Your IBM sales rep will be able to give you the $$$ benefits either way, and I don't intend to even try on that score. With respect to Business arguments (other than money), the above are all I can think of off the top of my head. If I think of any more, I'll add them later. Russell

[Guest.Visitor]

You should move to two boxes. They should live in different places and mirror one another. Putting your eggs in one basket is never the answer if you can avoid it.

[Guest.Visitor]

KC M2, That seems somewhat extreme for most environments. What you suggest would double your hardware, software, and operational expenses. The only time I have seen valid justification for that type of enviornment is when mandated by law or when the projected cost of downtime is greater than the cost of mirroring. It seems to me that you would only mirror critical business processes and this really has little to do with the original question. David Morris

[nycsusan@hotmail.com]

But what if your entire business is critical? I worked for a company that handled pharmacy claims. Our contract stipulated that we adjudicate (approve or reject) each and every transaction within 3 seconds (or some such small amount of time). But forget the contract, people need prescription drugs 24 x 7. There are lots of medical emergencies in the middle of the night. If our system went down, people could not get their drugs unless the pharmacy made special arrangements. It affects peoples lives, in other words. We had 3 machines total. One was for development, two for production. One production box was dedictated for online claims adjudication and the other for batch processing (mail order prescriptions, cutting checks, EOB statements, etc.) If the production online machine ever failed (and it DID after an installation!) the batch machine was to be used as the claim engine and batch processing woudl be put on hold until the problem(s) could be resolved. All files on the 2 production machines were kept in sync with Mimix. I don't know what business Herb's company is in, I am just throwing this out as one example where at least 2 machines are needed. Banks or security firms might be other examples. Yes, it's expensive to have more than one machine, but it can be more expensive NOT to have that backup if your business depends on it. FWIW.

[Guest.Visitor]

Can we assume your three existing machines are in the same location today or do you also need to address the benefits/issues of centralisation ? My off the top of my head comments... If this is the case I dont see that you'll get much of an operations saving (i.e. reducation of staffing) Since you would still be managing 4 systems (primary partition plus 3 application partitions). Have you assesed if you could consolidate the applications/users onto a single system ? Is the strategy to consolidate the applications or remain running different applications ? Do users access a single system or multiple ? You should check with your 3rd party application providers on pricing. That used to be a big cost in customer's consolidating, since many of the applications were priced on the AS/400 application server model, vs AS/400 Enterprise server model. In your case you for each application you would be running using a subset of capacity. A number of years back one benefit for a client was there was a high degree of data exchange. Information flows between the 2 systems did not happen until end of day. In moving to a single system and consolidating the database the flow of information is realtime.(Obviously this is a business saving and not an IT). Since currently the hardware cant be dynamically reconfigured across a partition then resource balancing is not available. If you run all in a single partition then you have opportunity to resource balance. You should look at cost to increase capacity for a single application. As the systems get bigger the incremental jumps are larger and hence more costly (e.g 8 CPUs to 12 CPUs to 24 CPUs), so you can end up with paying for future capacity and todays prices and that is not a good deal. The new Capacity on Demand pricing seems to address the increments since it is on a single processor basis. Check out <a > href="http://www-1.ibm.com/servers/eserver/iseries/hardware/ondemand/present/cuo d/cuodpresent.html" Capacity Presentation </a> and you can see you will pay a premium for using COD. David

[Guest.Visitor]

Herb, Actually, the more I think about it, the more arguments I can give you against going to LPAR on one big box. In fact, my recommendations would be: 1. Two biggish boxes using Mimix or Data Mirror or similar product to keep the database copies in synch, and splitting the normal processing load between them. This gives you your own effective hotsite. Preferable to separate the two boxes geographically to prevent double disaster. 2. One big box using software environment (library lists etc) to separate the different apps. 3. One big box using LPAR to separate the different apps. 4. Your current scenario using 3 varying sized boxes. However, the big decider has to be the business requirements, the application requirements, and the dollars, preferably in that order. Russell

[Guest.Visitor]

Susan I agree with what you wrote, but what KCM wrote was: <font color > blue> You should move to two boxes. They should live in different places and mirror one another. Putting your eggs in one basket is never the answer if you can avoid it. </font> And I think what David Morris was pointing out was this was a gross generalisaton. In fact if this was the case then most AS/400 implementations would should be avoided. The second is that consolidation/centralisation is a different issue to business resumption planning, although they do overlap. In banking it depends what application is running. Online Retail Banking yes you need duplication, although I do know banks that dont have this in place. Some other back office styled applications, can fall back to manual processes. My own thoughts is with e-commerce style applications than 24 x 7 will become more of an issue. This trends will happen when you move application delivery from internal users, to external users (e.g. The impact of ATMs had on banking, when up to that time the only option was a branch). David

[Guest.Visitor]

<font color=blue>But what if your entire business IS critical? </font> But what if one day a programmer made a mistake and the database was updated incorrectly ? Then you have two consistent, but wrong, versions of data. David

[nycsusan@hotmail.com]

Then you back out the installation! Go get a backup file from just prior to the implementation or the last nightly back up. I see this as a separate issue. If a bad program corrupts data files, you will need to go get a back up regardless of how many files the program corrupted. If a programmer leaves you with one file of corrupted data, how is that better? You still will have to go to a back up to recover from a corrupted file.

[Guest.Visitor]

With the limited info I made a general statement. This will hold true more often than the inverse. Susan hit the nail on the head, AND my suggestion does consolidate. They currently have 3 boxes. So 2, last time I checked is less therefore a savings in dollars. To respond to a rogue pgm corrupting the database and in turned mirrored over we had this occur. We didn't have to go to backup. We also journed the production files, stopped the link, rolled back to proper point and all was well. One big LPAR'd machine leaves you exposed to fire, flood, earthquake, or a busted sprinkler pipe. Then you get to find an AS400 and test your backup. Not a lot of fun.

[Guest.Visitor]

Thanks for all the info ... this has been really helpful. To answer some of the questions ... I work for a large funeral home business (OK, OK ... let's get the jokes over with)... We are currently in Chapter 11 (protection from bankruptcy ... for more info do a web search on "bankruptcy loewen group") and have filed a plan to emerge in Q1 2001. In order to facilitate this process we are undergoing a number of rightsizing and reengineering processes. Part of this plan is the consolidation of several offices into a smaller number. This includes relocation of 2 computer rooms (we're selling the buildings). We have looked at ASPs and found them to be pretty expensive so now we're trying to fit the existing systems into our own smaller space. This is where the amalgamation idea came from. We do have a comprehensive DRP in place that includes retaining space on IBM AS/400s on the other side of the country (Toronto). Because of the nature of our business we wouldn't be hurt terribly by a few days delay in getting up and running so we're not really concerned about that issue. At least not to the extent that we'd want to keep a hot, mirrored machine at the ready

[David Abramowitz]

I don't mean this as a joke, but how does a funeral home go broke? Isn't anybody dying? Dave

[Guest.Visitor]

Herb, In that case, I would definitely go with option 2 (different soft environments on a single box) or option 1 without bothering with data mirror. In fact, you could keep the 730, and simply upgrade the 620 a little to incorporate the 310 applications on the same box. Less cost in hardware, less cost in licences, less disruption. Russell

[Guest.Visitor]

Actually, death rates are down (apparently). Unfortunately, in our case, that's bad for business. But, with Georgw W in, we're expecting better business!! Do the Web search I mentioned to find out HOW it happens.

[Guest.Visitor]

One of our major problems is space, though. We simply don't have enough room to house all the hardware (with our office consolidation going on).