Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
I second everything Frank said. My company- one of the largest plumbing/hvac wholesalers in the country, has very successfully developed almost all back office processing systems (Payroll, GL, AP, Cash Mgmt, Securities Mgmt, etc) in house over the past 3 decades (2 of which I've been a part of). While everyone and their third cousin may indeed be using packaged software, I believe the ones who can figure out how to cost effectively *not* be part of the pack, are the ones who will rise above the pack. If you have strong IT, Finance, and Executive Management all working hand in hand, you can develop custom systems which will give your company a competitive advantage. Nearly every time we've done a make vs buy analysis it has not even been close. There are a few exceptions- Fixed Assets, for example, where the frequent and sometimes complex tax law changes made it a better option to buy a package that is maintained by experts. And a few other add-on enhancement products, such as an OCR scanning solution as a front end to our AP system, to replace hand-keying 800,000 paper invoices a year. No way could we develop and maintain that kind of special software. But for our core business processing, outsourcing or packages just ain't gonna cut it. Bill Frank Swarbrick frank.swarbrick@ EFIRSTBANK.COMTo Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List ibm-m...@bama.ua Fax to .edu Subject Re: Complexity (was Re: Convert DB2 07/14/2009 08:32 on z/OS to Oracle on z/Linux?) PM Please respond to IBM Mainframe Discussion List ibm-m...@bama.ua .edu On 7/14/2009 at 5:11 PM, in message a3a2b85f0907141611v32ced8ebl7b44ce513b35a...@mail.gmail.com, Tony Harminc tz...@attglobal.net wrote: 2009/7/12 Chris Craddock crashlu...@gmail.com: Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. Building your own is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. I'm sure you are right. But the piece that puzzles me is that there seem to be so many companies whose core business is really just moving bytes from place to place, who nonetheless think outsourcing is a Good Idea. I'm speaking most obviously of banks, but pretty much all financial services businesses, insurance, and so on are in the same place. Sure, it doesn't make sense for each bank to write their own operating system, web browser, etc. etc., but the actual applications *are* the core of their business. What they can and typically do [try to] outsource is precisely the things that benefit least from leveraging work across multiple customers, i.e. operations and helpdesk. I can testify that we are one bank that has written all of our core banking applications. Not to mention our Internet banking site. We actually have our own homegrown Human Resources and General Ledger systems, but are in the process of migrating those to packaged applications since they are in need of updating and not part of our core business. In my opinion both of these are good things. I can't imagine how our business would function if we had packaged core applications. Our
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
I am quite curious as to how our GL system conversion will come out. Interestingly, our developer who was primary on our mainframe GL system for the last few years has transfered to the packaged applications team and will implement the packaged GL application (Oracle PeopleSoft Enterprise General Ledger). She's taking many, many classes, and already she's opined that there will be boatloads of customization. (Not sure if opined is the correct word, but I've always wanted to use it in a sentence!) Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 On 7/14/2009 at 6:44 PM, in message c3dc50f77dfe2f4e814a9575dadca9430254f...@corpusmx10c.corp.emc.com, Chris Edwards edwards_ch...@emc.com wrote: Stone soup anyone? A man is traveling the tribes of Africa. Each night he walks into a village and offers to provide his special stone soup in exchange for a place to sleep. He takes a large stone from his swag and boils it in a large pot of water. After a while he asks the villagers to try it. Of course it is quite bland so he asks them to fetch various vegetables and a piece of meat. Eventually they have a lovely meal after which the man gets a place to sleep the night and in the morning picks up his stone and moves on to the next village. The players in this story? Man: Consultants (lots of them!) Stone: Off the shelf S/W of your choice Villagers: Any large organization of your choice Veges and Meat: The customization of afore mentioned S/W :-) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Wednesday, 15 July 2009 10:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?) On 7/14/2009 at 5:11 PM, in message a3a2b85f0907141611v32ced8ebl7b44ce513b35a...@mail.gmail.com, Tony Harminc tz...@attglobal.net wrote: 2009/7/12 Chris Craddock crashlu...@gmail.com: Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. Building your own is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. I'm sure you are right. But the piece that puzzles me is that there seem to be so many companies whose core business is really just moving bytes from place to place, who nonetheless think outsourcing is a Good Idea. I'm speaking most obviously of banks, but pretty much all financial services businesses, insurance, and so on are in the same place. Sure, it doesn't make sense for each bank to write their own operating system, web browser, etc. etc., but the actual applications *are* the core of their business. What they can and typically do [try to] outsource is precisely the things that benefit least from leveraging work across multiple customers, i.e. operations and helpdesk. I can testify that we are one bank that has written all of our core banking applications. Not to mention our Internet banking site. We actually have our own homegrown Human Resources and General Ledger systems, but are in the process of migrating those to packaged applications since they are in need of updating and not part of our core business. In my opinion both of these are good things. I can't imagine how our business would function if we had packaged core applications. Our users want too many special customizations, and they want them now! :-) As for outsourcing totally, we'll have none of that! Frank The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
snip I am quite curious as to how our GL system conversion will come out. Interestingly, our developer who was primary on our mainframe GL system for the last few years has transfered to the packaged applications team and will implement the packaged GL application (Oracle PeopleSoft Enterprise General Ledger). She's taking many, many classes, and already she's opined that there will be boatloads of customization. (Not sure if opined is the correct word, but I've always wanted to use it in a sentence!) /snip Having used ORACLE GL (not the PeopleSoft version) in a prior life, I was not very impressed. Performance was poor and the code that I had a chance to look at was awful. A PFCSK could do better! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
What is a PFCSK? On 7/15/2009 at 3:03 PM, in message 6cd8dd927eba514e9db1e36304be38d7117ad...@hou-mail.kbm1.loc, Staller, Allan allan.stal...@kbm1.com wrote: snip I am quite curious as to how our GL system conversion will come out. Interestingly, our developer who was primary on our mainframe GL system for the last few years has transfered to the packaged applications team and will implement the packaged GL application (Oracle PeopleSoft Enterprise General Ledger). She's taking many, many classes, and already she's opined that there will be boatloads of customization. (Not sure if opined is the correct word, but I've always wanted to use it in a sentence!) /snip Having used ORACLE GL (not the PeopleSoft version) in a prior life, I was not very impressed. Performance was poor and the code that I had a chance to look at was awful. A PFCSK could do better! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick What is a PFCSK? Pimply Faced Computer Science Kiddie. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
2009/7/12 Chris Craddock crashlu...@gmail.com: Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. Building your own is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. I'm sure you are right. But the piece that puzzles me is that there seem to be so many companies whose core business is really just moving bytes from place to place, who nonetheless think outsourcing is a Good Idea. I'm speaking most obviously of banks, but pretty much all financial services businesses, insurance, and so on are in the same place. Sure, it doesn't make sense for each bank to write their own operating system, web browser, etc. etc., but the actual applications *are* the core of their business. What they can and typically do [try to] outsource is precisely the things that benefit least from leveraging work across multiple customers, i.e. operations and helpdesk. Curious... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
On 7/14/2009 at 5:11 PM, in message a3a2b85f0907141611v32ced8ebl7b44ce513b35a...@mail.gmail.com, Tony Harminc tz...@attglobal.net wrote: 2009/7/12 Chris Craddock crashlu...@gmail.com: Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. Building your own is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. I'm sure you are right. But the piece that puzzles me is that there seem to be so many companies whose core business is really just moving bytes from place to place, who nonetheless think outsourcing is a Good Idea. I'm speaking most obviously of banks, but pretty much all financial services businesses, insurance, and so on are in the same place. Sure, it doesn't make sense for each bank to write their own operating system, web browser, etc. etc., but the actual applications *are* the core of their business. What they can and typically do [try to] outsource is precisely the things that benefit least from leveraging work across multiple customers, i.e. operations and helpdesk. I can testify that we are one bank that has written all of our core banking applications. Not to mention our Internet banking site. We actually have our own homegrown Human Resources and General Ledger systems, but are in the process of migrating those to packaged applications since they are in need of updating and not part of our core business. In my opinion both of these are good things. I can't imagine how our business would function if we had packaged core applications. Our users want too many special customizations, and they want them now! :-) As for outsourcing totally, we'll have none of that! Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
Stone soup anyone? A man is traveling the tribes of Africa. Each night he walks into a village and offers to provide his special stone soup in exchange for a place to sleep. He takes a large stone from his swag and boils it in a large pot of water. After a while he asks the villagers to try it. Of course it is quite bland so he asks them to fetch various vegetables and a piece of meat. Eventually they have a lovely meal after which the man gets a place to sleep the night and in the morning picks up his stone and moves on to the next village. The players in this story? Man: Consultants (lots of them!) Stone: Off the shelf S/W of your choice Villagers: Any large organization of your choice Veges and Meat: The customization of afore mentioned S/W :-) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Wednesday, 15 July 2009 10:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?) On 7/14/2009 at 5:11 PM, in message a3a2b85f0907141611v32ced8ebl7b44ce513b35a...@mail.gmail.com, Tony Harminc tz...@attglobal.net wrote: 2009/7/12 Chris Craddock crashlu...@gmail.com: Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. Building your own is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. I'm sure you are right. But the piece that puzzles me is that there seem to be so many companies whose core business is really just moving bytes from place to place, who nonetheless think outsourcing is a Good Idea. I'm speaking most obviously of banks, but pretty much all financial services businesses, insurance, and so on are in the same place. Sure, it doesn't make sense for each bank to write their own operating system, web browser, etc. etc., but the actual applications *are* the core of their business. What they can and typically do [try to] outsource is precisely the things that benefit least from leveraging work across multiple customers, i.e. operations and helpdesk. I can testify that we are one bank that has written all of our core banking applications. Not to mention our Internet banking site. We actually have our own homegrown Human Resources and General Ledger systems, but are in the process of migrating those to packaged applications since they are in need of updating and not part of our core business. In my opinion both of these are good things. I can't imagine how our business would function if we had packaged core applications. Our users want too many special customizations, and they want them now! :-) As for outsourcing totally, we'll have none of that! Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
On 12 Jul 2009 14:00:07 -0700, patrick.oke...@wamu.net (Patrick O'Keefe) wrote: That is probably the inevitable future, but the time frame is not at all clear, and the ecomonic break-even line between do it in-house and buy it changes over time. When you pass development and maintenance over to an outside vendor you also pass off control. The vendor's service had better be a very good match to the business needs or the economic advantage disappears. But all they need are effective promises. Once the old shop closes down, it costs too much to undo the change. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
On 12 Jul 2009 11:39:56 -0700, bshan...@rocketsoftware.com (Bob Shannon) wrote: Well, what I know is that when companies built their own applications, they talked about gaining a competitive advantage. When's the last time anyone heard that? When companies built their own applications, they could last twenty years or more. What's the life expectancy today? When companies built their own applications, the applications did exactly what was required by the business instead of requiring the business to change to accommodate the software. Does one size really fit all? There always have been compromises between what users think they want and what we could deliver. Then when we built systems to last 20 years or more - business needs changed and we tried, with limited success, to change as well. Will we ever go back? Perhaps not, but outsourcing application development or buying off the shelf software may be more fad than panacea. More likely it will be like buying anything else. There will be a fair amount of choice in buying a software package - as there is in buying a car or a delivery service or a printer. But the market for building a software package, a car, a delivery service, or a printer to meet our business needs is limited, considering the costs and benefits. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock Chris Craddock wrote: [snip] Folks hate to hear me say it, but just about everything we know about IT today is wrong. We're never going back to the home grown development cottage industry and sooner or later the in-house IT function is going to go the way of the dodo too. Our kids and grandkids are almost certainly NOT going to be doing IT as we know it. Pretty scary thought for some, but going to happen nevertheless. Well, there ya' go, pointing out the 800 pound gorilla in the room. Well observed and well said. So, some inferences... * At some point in time, companies will only have workstations (probably thin client machines that use software on some server somewhere else); no servers; no mainframes Just a cloud that computes. So, what's in the cloud? Who cares? as long as it works correctly and is available when I want it. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
Chris Craddock wrote: Unlurking for a moment... [snip] On Thu, Jul 9, 2009 at 6:50 AM, Steve Comstock st...@trainersfriend.comwrote: Timothy Sipples wrote: I'm also observing more and more organizations finally figuring out that dis-aggregating existing architectures is exactly the wrong direction to head. The management costs and service quality dimunition, in particular, are just not worth it, and they're getting more costly every year. I find I'm getting more and more enthusiastic about not making things more complicated than they need to be, as a general rule -- indeed, to seek opportunities for simplification. And more and more people seem to be coming to the same conclusions nowadays. You seem to be presuppose some innate rightness of having all of the work in one big box, when in fact, there are huge benefits in scalability and managability from breaking up and distributing work. That's pretty much the point of sysplex after all. You're also presupposing that there are inherent service and quality impacts when you disaggregate. That may often be true in practice, but there's no underlying law of nature that makes it so. To-wit, the previous point about sysplex. Rather than adopting a complexity is bad position, it would be more apt to paraphrase Einstein... A system (theory) should be as simple as possible, but no simpler. Sysplex is more complex than single instances of plain old MVS, but the benefits far outweigh the complexity. The same is true of distributed systems. Not all complexity is bad. Well, yes. That's why I have trouble getting excited about Web Services. Talk about complicated. Write the service code Describe in WSDL Register in some repository When someone looks for the service, negotiate a price Once accepted, let the requestor run the service Bill me later For goodness' sake: write your own subroutine and be done with it. well in fairness, only the first two are actually requirements for a web service. The first one you have to do no matter whether you're doing web services or CICS/Cobol so I don't see it being relevant to complexity and the WSDL-related tasks are largely done by tools, not by humans. Publishing web service endpoints in a registry is a good thing to do because it allows for run-time binding which makes the applications a lot easier (not harder) to manage and makes them more resilient and flexible. You can move application parts around without changing any code or parmlib-like configuration data. I don't know of anyone doing the negotiate a price/bill me later thing with web services but I guess in theory it could be done. So boiling the meat off the bones here, the only real extra work is the (tool-assisted) WSDL processing and service registry stuff. I will admit they can look a bit intimidating but, in return you get flexibility that you can't even dream about if you just write your own subroutine and be done with it. If what you're trying to accomplish looks like a simple subroutine call, then it probably is simple enough to be one. OTOH if you're trying to juggle data from multiple places to buy stuff online, pay for it, arrange shipping etc. then it would be the height of insanity to just write your own. Those tools have not become pervasive because they are complex and hard to use. They are pervasive because they are powerful and useful. Well, that brings up the old build or buy conundrum. But either case, if you have a tool to do multiple pieces, whether you purchased it or built it yourself, I still don't see a case for setting it up as a Web Service. That was what I was driving at before. You don't need to set up WSDL and register the service, then use UDDI to discover the service. You have it, just use it. I don't think it's the height of insanity to just write your own; depending on the service, it might be a strategic way to get some competitive advantage (provide additional features and services that only your company offers). (Of course, if you decide to build your own, it might end up being inferior to the one your competitors use, then you're up a creek. An excellent reason to hire competent people and keep them updated with training. Ahem.) Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Ask about being added to our opt-in list: == == * Early announcement of new courses == == * Early announcement of new techincal papers == == * Early announcement of new promotions == -- For IBM-MAIN subscribe / signoff / archive access instructions, send
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
On Sun, Jul 12, 2009 at 11:14 AM, Steve Comstock st...@trainersfriend.comwrote: Chris Craddock wrote: Unlurking for a moment... SNIP If what you're trying to accomplish looks like a simple subroutine call, then it probably is simple enough to be one. OTOH if you're trying to juggle data from multiple places to buy stuff online, pay for it, arrange shipping etc. then it would be the height of insanity to just write your own. Those tools have not become pervasive because they are complex and hard to use. They are pervasive because they are powerful and useful. Well, that brings up the old build or buy conundrum. But either case, if you have a tool to do multiple pieces, whether you purchased it or built it yourself, I still don't see a case for setting it up as a Web Service. That was what I was driving at before. You don't need to set up WSDL and register the service, then use UDDI to discover the service. You have it, just use it. There are some subtle assumptions and gotchas in you just use it. Either the thing you just use is bound with the rest of your application (not very flexible, but certainly easy) -OR- you have to locate and bind to it at run time. We have used versions of that since the jurassic era. Dynamic loading, or link, or (much later) DLLs and RPCs. They're all kissing cousins and they all have the same basic issue who you gonna call? It gets a lot worse if you plan to call/use the thing in a lot of places. Each of those places need to be individually told in their own way where to look. The point of a web service (or a REST service for that matter) is that there is an architecture for locating and binding to the who you gonna call at run time. You don't have to use it. In fact, most people who do use web services don't use a registry at all. However, if you don't use the registry then you have the same problem that has existed since the beginning of time. Somebody has to tell the code (via DD statements, or input parameters, or configuration files) where to look and who to call. That is a fundamental weakness because if you need to change that, you typically end up having to make manual changes all over the place to get the smoke and mirrors to line up again. That configuration effort is a weakness because human beings make more mistakes and take longer to get anything done. Using a registry and a dynamic location/binding protocol eliminates that. Adding the complexity of a registry in one place allows you to remove a lot of configuration in many other places, so while it may look like being an imposition on the simple way, it is actually a net reduction in complexity and yields a lot of operational flexibility. I don't think it's the height of insanity to just write your own; depending on the service, it might be a strategic way to get some competitive advantage (provide additional features and services that only your company offers). (Of course, if you decide to build your own, it might end up being inferior to the one your competitors use, then you're up a creek. An excellent reason to hire competent people and keep them updated with training. Ahem.) Unfortunately for many of us who have made our careers in this business, the economics just aren't there anymore. Nobody does phones in house anymore because there are companies only too willing to do it and hand you a bill. Hardly anybody does their own payroll anymore. Same reason. Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. Building your own is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. Realistically no company in its right mind is going to invest development and maintenance effort in something they can buy and have somebody else on the hook for maintaining it. That's what all the buzz about *-as-a-service is about. We didn't have the software technology, or processor capacity, or network bandwidth to solve the problem back in the day, but we do now. That's why we still have datacenters full of home grown stuff and while that home grown stuff is still hanging in there, most new stuff is in one way or another getting service-ized and eventually getting hosted outside of the traditional data center, even if it is still within the corporate intranet. Folks hate to hear me say it, but just about everything we know about IT today is wrong. We're never going back to the home grown development cottage industry and sooner or later the in-house IT
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
Folks hate to hear me say it, but just about everything we know about IT today is wrong. We're never going back to the home grown development cottage industry and sooner or later the in-house IT function is going to go the way of the dodo too. Well, what I know is that when companies built their own applications, they talked about gaining a competitive advantage. When's the last time anyone heard that? When companies built their own applications, they could last twenty years or more. What's the life expectancy today? When companies built their own applications, the applications did exactly what was required by the business instead of requiring the business to change to accommodate the software. Does one size really fit all? Will we ever go back? Perhaps not, but outsourcing application development or buying off the shelf software may be more fad than panacea. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
Chris Craddock wrote: On Sun, Jul 12, 2009 at 11:14 AM, Steve Comstock st...@trainersfriend.comwrote: [snip] Unfortunately for many of us who have made our careers in this business, the economics just aren't there anymore. Nobody does phones in house anymore because there are companies only too willing to do it and hand you a bill. Hardly anybody does their own payroll anymore. Same reason. Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. Building your own is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. Realistically no company in its right mind is going to invest development and maintenance effort in something they can buy and have somebody else on the hook for maintaining it. That's what all the buzz about *-as-a-service is about. We didn't have the software technology, or processor capacity, or network bandwidth to solve the problem back in the day, but we do now. That's why we still have datacenters full of home grown stuff and while that home grown stuff is still hanging in there, most new stuff is in one way or another getting service-ized and eventually getting hosted outside of the traditional data center, even if it is still within the corporate intranet. Folks hate to hear me say it, but just about everything we know about IT today is wrong. We're never going back to the home grown development cottage industry and sooner or later the in-house IT function is going to go the way of the dodo too. Our kids and grandkids are almost certainly NOT going to be doing IT as we know it. Pretty scary thought for some, but going to happen nevertheless. Well, there ya' go, pointing out the 800 pound gorilla in the room. Well observed and well said. So, some inferences... * At some point in time, companies will only have workstations (probably thin client machines that use software on some server somewhere else); no servers; no mainframes * You want networks? We got networks. Let us come and design and install just the network for you * Datacenters will only be owned by companies that sell time or services on their systems, which are likely to look more and more like UNIX and Linux instead of z/OS and VSE and z/VM and z/TPF * IT directors, or CIOs, or whatever they will be called, will consult with a small group to select the mix of software they want to rent / license / use to run their business * The only software developers will be employees of ISVs; of course, these employees will be virtual: - work mostly at home or out of networked office centers rented out by specialized companies - have no benefits; well, some employees might be full time and get some contribution to a SEP/IRA by the company; other than that, it's get your own health, life, retirement, and other benefits yourself; vacation time is your choice and unpaid - be paid either hourly or on a project basis; only the few full time employees will be paid a salary So if I'm going to stay in the business of training z/OS application programmers I'll have to sell to ISVs. Only. (Actually, ISVs have been a growing part of my clientele these days, so that part's not too far off, perhaps.) It has the ring of truth to it. But, like many on the various listserv's, I'm hoping the transition won't be done until I'm ready to retire. Timing is critical here. I remember one morning going down to breakfast at some hotel in St. Louis thinking, This is sure a young man's game. I was in my 30's at the time. Well, I'm still in the game; I'm now 65; on medicare; but still working, and doing well at it. Good thing I have a backup plan; instead of this flaky computer business I'll get into something solid like acting. :) Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Ask about being added to our opt-in list: == == * Early announcement of new courses == == * Early announcement of new techincal papers == == * Early announcement of new promotions == -- For IBM-MAIN subscribe /
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
On Sun, 12 Jul 2009 13:20:59 -0500, Chris Craddock crashlu...@gmail.com wrote: ... Realistically no company in its right mind is going to invest development and maintenance effort in something they can buy and have somebody else on the hook for maintaining it. That's what all the buzz about *-as-a-service is about. ... ... Folks hate to hear me say it, but just about everything we know about IT today is wrong. We're never going back to the home grown development cottage industry and sooner or later the in-house IT function is going to go the way of the dodo too. ... That is probably the inevitable future, but the time frame is not at all clear, and the ecomonic break-even line between do it in-house and buy it changes over time. When you pass development and maintenance over to an outside vendor you also pass off control. The vendor's service had better be a very good match to the business needs or the economic advantage disappears. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
On Sun, 12 Jul 2009, Chris Craddock wrote: snip Unfortunately for many of us who have made our careers in this business, the economics just aren't there anymore. Nobody does phones in house anymore because there are companies only too willing to do it and hand you a bill. Interestingly, we still have our own telecommunications department because we have __NOT__ found a 3rd party who will guarantee our current service levels at even our current expense, let alone for less. Hardly anybody does their own payroll anymore. Same reason. Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. Building your own is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. This is supposedly where we are going. But the cost to convert is an obstacle for us. So, we are basically doing it as we try to convert from legacy systems to new systems. I don't know exactly why, but it is not going very smoothly. snip Folks hate to hear me say it, but just about everything we know about IT today is wrong. We're never going back to the home grown development cottage industry and sooner or later the in-house IT function is going to go the way of the dodo too. Our kids and grandkids are almost certainly NOT going to be doing IT as we know it. Pretty scary thought for some, but going to happen nevertheless. I agree, long term. I still have concerns about what is going to happen to a business in any give country if they are offshored and the communications goes through hostile territory. Or gets taken out by some insane group. Or the comm goes through a friendly area which later becomes unfriendly. One problem that I've noticed is that we don't place as much emphasis on redundancy as we used to. So we have more single points of failure. I remember in the past having two separate leased lines going through different circuits to a given critical location. The Internet is supposed to be self healing. But as it is commercialized, that is not as important. Having multiple circuits to a single location is simply expensive. And short term bottom line managers today don't seem to have the old mindset. But then, perhaps the problem is with me and not them. Maybe the risk is worth the reward (greater profit). That's why Intel machines are now good enough even though the reliability of the z makes them look sick. Just cluster the systems applications so that a failure just doesn't much matter. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
Chris Craddock writes: Once you have to undispatch work and dispatch something else in the interim it matters a whole lot less whether the thing that the interrupted work is waiting on lives on the same processor or on Mars. As soon as two or more pieces of your application are no longer in the same memory, it doesn't matter a whole hell of a lot how far apart they are - particularly if you don't control the whole thing. I was with you up until Mars. :-) Yes, there can be a big(ger) difference between same memory and not. But a radio link to Mars (metaphorically speaking) is also very different than an ethernet cable between two boxes in a server room. If it weren't, nobody would be sweating kilometer/mile counts in synchronous flavors of GDPS, for example. You seem to be presuppose some innate rightness of having all of the work in one big box Never said one big box. Didn't even hint at that, in fact. I am hinting at the word fewer, though. Although boxen isn't the only measure I'd use or even necessarily the best one. I am prepared to advance the radical notion that the customer (who shall remain nameless) who has the following logical architecture for Internet banking (*simplified* high-level view): End User - ... - firewall - HTTPS server - firewall - front-end presentation server - back-end presentation server - MQ server - front-end Tuxedo server - mid-tier Tuxedo server - back-end Tuxedo server - LU0 - CICS Transaction Server - has completely lost the plot. (And they know it now, which is good.) By the way, most or all of those tiers are clustered, and there are about three widely separated data centers involved in that flow as it executes, excluding DR centers. Yes, that's the (inbound) flow for account balance, please. Rube Goldberg would be proud. :-) For perspective, later today I'm going to demonstrate my iPod connecting directly to CICS TS doing exactly the same thing. I said: I'm getting more and more enthusiastic about not making things more complicated than they need to be Einstein said: A system (theory) should be as simple as possible, but no simpler. Einstein said it better, but obviously we agree. :-) For what it's worth, I am in general agreement with your comments about Web services. - - - - - Timothy Sipples Consulting Enterprise Software Architect IBM Japan, Ltd. e99...@jp.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
Timothy Sipples wrote: Nobody so far has mentioned another factor: as you increase the distance (latency) between applications and databases, CPU and memory consumption increases on both sides. I call this phenomenon proximity effects. These proximity effects can be extremely large in many cases. I'm also observing more and more organizations finally figuring out that dis-aggregating existing architectures is exactly the wrong direction to head. The management costs and service quality dimunition, in particular, are just not worth it, and they're getting more costly every year. I find I'm getting more and more enthusiastic about not making things more complicated than they need to be, as a general rule -- indeed, to seek opportunities for simplification. And more and more people seem to be coming to the same conclusions nowadays. Well, yes. That's why I have trouble getting excited about Web Services. Talk about complicated. Write the service code Describe in WSDL Register in some repository When someone looks for the service, negotiate a price Once accepted, let the requestor run the service Bill me later For goodness' sake: write your own subroutine and be done with it. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Ask about being added to our opt-in list: == == * Early announcement of new courses == == * Early announcement of new techincal papers == == * Early announcement of new promotions == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
Unlurking for a moment... On Thu, Jul 9, 2009 at 6:50 AM, Steve Comstock st...@trainersfriend.comwrote: Timothy Sipples wrote: Nobody so far has mentioned another factor: as you increase the distance (latency) between applications and databases, CPU and memory consumption increases on both sides. I call this phenomenon proximity effects. These proximity effects can be extremely large in many cases. I would buy Large in some cases but by no means all. Once you have to undispatch work and dispatch something else in the interim it matters a whole lot less whether the thing that the interrupted work is waiting on lives on the same processor or on Mars. As soon as two or more pieces of your application are no longer in the same memory, it doesn't matter a whole hell of a lot how far apart they are - particularly if you don't control the whole thing. I'm also observing more and more organizations finally figuring out that dis-aggregating existing architectures is exactly the wrong direction to head. The management costs and service quality dimunition, in particular, are just not worth it, and they're getting more costly every year. I find I'm getting more and more enthusiastic about not making things more complicated than they need to be, as a general rule -- indeed, to seek opportunities for simplification. And more and more people seem to be coming to the same conclusions nowadays. You seem to be presuppose some innate rightness of having all of the work in one big box, when in fact, there are huge benefits in scalability and managability from breaking up and distributing work. That's pretty much the point of sysplex after all. You're also presupposing that there are inherent service and quality impacts when you disaggregate. That may often be true in practice, but there's no underlying law of nature that makes it so. To-wit, the previous point about sysplex. Rather than adopting a complexity is bad position, it would be more apt to paraphrase Einstein... A system (theory) should be as simple as possible, but no simpler. Sysplex is more complex than single instances of plain old MVS, but the benefits far outweigh the complexity. The same is true of distributed systems. Not all complexity is bad. Well, yes. That's why I have trouble getting excited about Web Services. Talk about complicated. Write the service code Describe in WSDL Register in some repository When someone looks for the service, negotiate a price Once accepted, let the requestor run the service Bill me later For goodness' sake: write your own subroutine and be done with it. well in fairness, only the first two are actually requirements for a web service. The first one you have to do no matter whether you're doing web services or CICS/Cobol so I don't see it being relevant to complexity and the WSDL-related tasks are largely done by tools, not by humans. Publishing web service endpoints in a registry is a good thing to do because it allows for run-time binding which makes the applications a lot easier (not harder) to manage and makes them more resilient and flexible. You can move application parts around without changing any code or parmlib-like configuration data. I don't know of anyone doing the negotiate a price/bill me later thing with web services but I guess in theory it could be done. So boiling the meat off the bones here, the only real extra work is the (tool-assisted) WSDL processing and service registry stuff. I will admit they can look a bit intimidating but, in return you get flexibility that you can't even dream about if you just write your own subroutine and be done with it. If what you're trying to accomplish looks like a simple subroutine call, then it probably is simple enough to be one. OTOH if you're trying to juggle data from multiple places to buy stuff online, pay for it, arrange shipping etc. then it would be the height of insanity to just write your own. Those tools have not become pervasive because they are complex and hard to use. They are pervasive because they are powerful and useful. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
Chris Craddock wrote: Unlurking for a moment... On Thu, Jul 9, 2009 at 6:50 AM, Steve Comstock st...@trainersfriend.comwrote: Timothy Sipples wrote: Nobody so far has mentioned another factor: as you increase the distance (latency) between applications and databases, CPU and memory consumption increases on both sides. I call this phenomenon proximity effects. These proximity effects can be extremely large in many cases. I would buy Large in some cases but by no means all. Once you have to undispatch work and dispatch something else in the interim it matters a whole lot less whether the thing that the interrupted work is waiting on lives on the same processor or on Mars. As soon as two or more pieces of your application are no longer in the same memory, it doesn't matter a whole hell of a lot how far apart they are - particularly if you don't control the whole thing. I'm also observing more and more organizations finally figuring out that dis-aggregating existing architectures is exactly the wrong direction to head. The management costs and service quality dimunition, in particular, are just not worth it, and they're getting more costly every year. I find I'm getting more and more enthusiastic about not making things more complicated than they need to be, as a general rule -- indeed, to seek opportunities for simplification. And more and more people seem to be coming to the same conclusions nowadays. You seem to be presuppose some innate rightness of having all of the work in one big box, when in fact, there are huge benefits in scalability and managability from breaking up and distributing work. That's pretty much the point of sysplex after all. You're also presupposing that there are inherent service and quality impacts when you disaggregate. That may often be true in practice, but there's no underlying law of nature that makes it so. To-wit, the previous point about sysplex. Rather than adopting a complexity is bad position, it would be more apt to paraphrase Einstein... A system (theory) should be as simple as possible, but no simpler. Sysplex is more complex than single instances of plain old MVS, but the benefits far outweigh the complexity. The same is true of distributed systems. Not all complexity is bad. Well, yes. That's why I have trouble getting excited about Web Services. Talk about complicated. Write the service code Describe in WSDL Register in some repository When someone looks for the service, negotiate a price Once accepted, let the requestor run the service Bill me later For goodness' sake: write your own subroutine and be done with it. well in fairness, only the first two are actually requirements for a web service. The first one you have to do no matter whether you're doing web services or CICS/Cobol so I don't see it being relevant to complexity and the WSDL-related tasks are largely done by tools, not by humans. Publishing web service endpoints in a registry is a good thing to do because it allows for run-time binding which makes the applications a lot easier (not harder) to manage and makes them more resilient and flexible. You can move application parts around without changing any code or parmlib-like configuration data. I don't know of anyone doing the negotiate a price/bill me later thing with web services but I guess in theory it could be done. So boiling the meat off the bones here, the only real extra work is the (tool-assisted) WSDL processing and service registry stuff. I will admit they can look a bit intimidating but, in return you get flexibility that you can't even dream about if you just write your own subroutine and be done with it. If what you're trying to accomplish looks like a simple subroutine call, then it probably is simple enough to be one. OTOH if you're trying to juggle data from multiple places to buy stuff online, pay for it, arrange shipping etc. then it would be the height of insanity to just write your own. Those tools have not become pervasive because they are complex and hard to use. They are pervasive because they are powerful and useful. Yeah, you're right: I mixed in various pieces, some of which don't belong. First, you're either a provider of a service or your a consumer of a web service. Of course, you could be both. In fact, that seems to be what people are doing right now: creating their own web services and consuming them themselves; in this case, you don't even need a registry. I was under the impression that one of the appeals to some software company might be to be a provider of services for a fee. In this case, you need to use WDSL to describe your service, you need to register this service somewhere that everyone can get to, and then you need to wait for some consumer to come along. The service consumer, on the other hand uses UDDI (I think that's the acronymn) to find a match for a service it needs; then expect to pay on a per use, or a subsrciption, or some other basis. Without the payment angle,
