As a mainframe programmer and business executive, I’ve learned all about the necessity of educating the next generation of systems programmers and application developers. But how soon is soon enough to influence these people?
My dad was one of the first programmers at his insurance company. He took me under his wing as a 12 year old and kept me excited about programming. My junior high school had teletype HP 2000 computers, punch card machines and a variety of wire on board IBM systems. I took typing in 9th grade to reduce my punch card error decks. Nerd, yes, but thinking of a career already.
National Engineer’s Week beginnings
Years later, attending a seminar hosted by the National Reconnaissance Office, I heard an elderly (70-ish) engineer explain how he and his peers had formed the basis of National Engineers Week to attract the next generation. Based on national pride and a common goal set by President Kennedy to get a man on the moon, he and his peers had gone into engineering to meet those goals. He questioned where today’s call to arms was. Where was the national pride to make a difference? A good question, that I don’t know the answer to either. His goal was to continue to make a difference in his own way.
Likewise, I’ve attempted to make that one of my career goals. No, make it a life goal: mentoring a new generation. When my son graduated high school, I offered internships at IBM to anyone that desired them. One student took me up on the offer after a year of college. Five the next year and a couple more after that. But the result was one high school class of 90 students resulted in five students with full-time jobs at IBM. This is the same school that has the only Future Farmers of America chapter in the county. My job was to open doors and pave a path. The students had to convince hiring managers (internship and full-time) of their value and did.
Elementary School After School Programs
I’m beginning a four-week after school program for grades 3 to 5 in my school district. It started by trying to recruit people at IBM to come to the district for National Engineer’s Week. It didn’t take long for me to decide to do it myself. With the assistance of a local teacher and the school principal, we decided to make this an after school club, once a week, for the month of February. It’s “math” centric, but the reality is, it’s about patterns. Patterns are everywhere in math, science, art, music, programming and business solutions. I had the pleasure to go into the school and give each class a tutorial on patterns in business and the evolution of programming. That was the teaser to getting them to attend the after school program. I don’t know how many will attend the program, but there was a tremendous amount of interest shown in the class. Some immediately grasped the discussion and could predict what I would say next. Several told me that they already wanted to become engineers. This was great news.
Become a coach. Pay it Forward.
We’ve developed a syllabus based on six topic areas and then gathered a large number of websites to aid the kids on their own. There are some terrific resources out there available to anyone that wants to do this themselves. Kids need a challenge, but they could also use a coach. I encourage anyone reading this to volunteer to make a difference in someone else’s career. Pay it forward and you, as well as your students, will reap the benefits in the future.
In the 1960’s, the IBM mainframe led a transition in business processing from a paper centric transaction processing environment to an IT centric processing environment. The combination of the Personal Computer and introduction of modems and later the Internet changed the IT community from being internally facing to customer centric computing. The introduction of the PC Server created “commodity centric” computing and, typically, folks running in that environment were against IT centric operations as the PC server could bring Department centric computing to individual business units.
The unintended consequence of all this was fiefdom’s were created to manage server silos. Over a decade of server deployments, individual IT organizations may have been created with business related names (e.g. Point of Sale org, Analytic org, Web hosting org, Claims administration org). The reality is each of these organizations might be dependent on a specific server infrastructure. As a result, the introduction of any other server infrastructure, for example mainframe to PC server or centralizing on a mainframe from UNIX or PC servers would be viewed as bad. The reality is no single server is capable of meeting all the IT needs of a business unless they are very, very small. And even then, multiple applications, which typically means, multiple server instances or operating system instances, will be required.
I am mainframe centric
I have no hesitation to say I am mainframe centric. That statement, alone and without context, will scare many people away from me as an IT consultant. One of the things I learned very early in my career is that Security of infrastructure is about People, Process and Technology. While the mainframe may be considered the most secure platform, technologically, my forensic experience at a variety of customers proves that poorly trained people and bad processes were the weakest links to security. But more important, much of that “poor security” happened at the end user device – formerly a PC, but now, including Smart devices, such as phones and tablets. If those devices aren’t secured with passwords and enterprise data residing on them isn’t encrypted, then they become the weakest link. And if the user of the device saves their userid and password in their browser so they can reconnect quickly, well so can the bad guy that steals their device and now, the bad guy has unfettered access to those “more secure” systems that execute transactions or provide data access on behalf of the end user that lost their device. I’ve spent over ten years looking at how back end systems can make the front end devices more secure. So I guess I am Security centric, as well. I’m also web, mobile and application development centric.
Most Application Developers are PC Centric.
If you started out as a mainframe programmer, you probably signed on to the mainframe with a 3270 emulator and used panel driven or command line driven tools to edit files and submit jobs to compile and execute the programs you created. The IT capacity that was used to do this type of development drove up the cost of operating the production mainframes.
The advent of the Personal Computer changed all that. Windows and Linux desktops provide graphic user interfaces. Fourth generation tools will help you graphically design the logic of an application and generate the source code in a variety of different programming languages that best suit the operations environment that you might run the program. With open system interfaces and common programming languages, one development tool might create code to run on dozens of operating systems and hardware architectures. These are the type of tools used to build most middleware that is sold to run across “your favorite” operating system.
Well, that hybrid development environment didn’t end up as simple as that. Tiers of deployment platforms were created. If it was developed on a PC, then the first choice for a deployment platform was typically a PC server. Other platforms, like UNIX and the mainframe, were considered primarily as production platforms. They didn’t distinguish very well or price differently for developers. As a result, it became unaffordable to develop for a mainframe because the development group or a new Middleware vendor, couldn’t afford a mainframe or UNIX server to test their code, so again, by default, most new applications were targeted to PC servers.
Most Web Servers are PC Centric Most Analytic Servers are PC Centric
Need I go on? A mantra for the client/server computing era was Move the Data to the Application. This led to copies of data everywhere, but also led to theft, loss, data breaches and server sprawl. Virtualization of server operating systems has helped to reduce server sprawl, but security remains complex. Business resilience, environmental needs (floor space, energy, cooling) and labor costs remain highly complex as well.
I said earlier that I am mainframe centric. But I can also say, unequivocally, that the mainframe can NEVER solve all of your business problems by itself. Why is that? Because it is blind and deaf. The 3270 terminal and punch card are long gone as input output devices. The modern mainframe requires a graphically enabled front end device, such as a Point of Sale device, ATM, PC or Smart Device. It still requires communications but now it leverages TCP/IP instead of SNA. So any business leveraging a mainframe is now a multi system business. Even the zEnterprise, with its introduction of the System z Bladecenter EXtension can’t solve all of a business’ problems because it doesn’t handle virtual desktop infrastructure nor manage the deployment of end user devices.
So let’s go back to solving business problems. We don’t need to discuss server types, but we can make some statements that should prove true, irrespective of server deployment model.
Share data – the fewer copies of data, the easier to manage security and resilience. Sharing data for read/write access (transaction processing) along with read only access (Query and Analytics) will enable a combination of workflows that include real time analytics (fraud detection, co-selling) in a basic transaction.
Move applications to data – copying applications is far easier and less time consuming, in addition to more secure and resilient, than moving data. Virtualization technologies enable a simple way to bring applications and data together in the same infrastructure and improve latency and simplify business resilience.
Look for tortured data flows – there never will be a single copy of data, as there should be, at minimum, backup copies and disaster recovery copies. But if you can reduce the number of data moves, leveraging direct access to data, instead of file transfers or unload/reload workflows, a business can dramatically reduce operational complexity.
The fewer parts (servers and data) the better – there will be less environmental costs, software license charges and reduction in complexity for security, capacity management and business resilience management.
Use stateless devices/applications for end user connections – the end user wants direct access to data and transactions, but the less data stored on the end users’ device, the better. Cookies should be the limit of context stored on an end user device. That way, if the device is lost or stolen, no corporate data is lost. It will be stored centrally. This can be true of thin client computers as well as web access to a transaction processing environment.
Never give developers direct access or copies of Production data – Development systems are generally not production systems. There is no logging, limited or no security and rarely an audit of critical data. This is the simplest target for a hacker or insider to attack in order to gain access to personally identifiable information or corporate jewels. Developers should have cleansed data through anonymization tools or other creations to ensure that the production environment remains protected.
Measure availability end to end. I’ve seen server shops (of all types) claim four or five nines of availability for their infrastructure. That’s a nice internal measurement. If the end user, a consumer, is trying to access their data on a back end server and the security server, the web proxy server, a router or some other networking infrastructure is down then the business is down to them. Availability should be a business target not a server only target.
Identify the security of users from end to end. When looking at transaction logs, a business should be able to see the identify of the individual that initiated a request. If the logs only identify the id of a down stream server, then additional logs and correlation is required from more expensive products to identify the end user. The more misdirection the greater the risk to security and data theft. Ensure that the originating user is easily identifiable at each step of the business workflow.
Industry standard benchmarks are irrelevant to business workflows. They may help distinguish one component alternative from another. But since we’ve already determined that a hybrid environment will be required for production purposes, there are very few, if any, benchmarks that provide a true end to end workflow that mimics multiple business operations. Much like lawyers, benchmarks can offer guidance and may explain risks, but they are not the decision makers. The business application owner must weigh the total cost of operations and the incremental costs of maintenance for the entire business operations vs. just the component parts identified by a benchmark.
I first published “Porell’s Pointers” using Lotus Freelance for OS/2 circa 1990. The pointers covered then were server agnostic and remain true today. Sure, they were mainframe centric then and could be considered so today. But they make sense even if a UNIX system is the largest in your organization. They make sense if a PC server is the largest in your organization.
If you can follow these suggestions, but also think about the scale of operations needed for your business, consider the mainframe as a core component of your end to end workflow. Unlike most other servers, it excels at large scale, managing service level agreements (SLAs) for read/write and read only data, providing cross platform security infrastructure and managing availability and business resilience at an application level. The combination of z/OS, z/VM with Linux for System z, along with PC servers and desktop or Smart Devices will be a winning combination to satisfy the majority of your business problems. But once you look at a hybrid solution, then security, availability, disaster recovery, application development, analytics, capacity management and backup and archive should be cross platform or hybrid solutions as well. A wealth of middleware exists that can operate across platforms. This can be the beginning of a new operations model built on business problems rather than server specific domains. Damn the Server Fiefdoms! Full speed ahead with an organization that collaborates for shared business success. Happy programming!
I’ve found that many times in my career, a decision that was made for one reason, had unintended consequences in another area. Sometimes, these were good things and sometimes, they were not. I’ve decided to write about some of these activities in this blog. So you’ll see this title, as a recurring theme throughout my writings.
Here’s a list of the items I’m thinking about writing. Let me know what you think is most interesting to you and I’ll try to get them done earlier than the others:
z/OS “stabilizes” it’s Shell and Utilities offerings at very old code levels- Rocket Software “fixes” that. Done.
OS/390 and z/OS are a better package, but they lost their sales channel. Now Solution Editions and new workloads help to drag z/OS. TCO and High Availability remain king.
Apple and IBM mobile deal is pretty cool, but reminds me that Apple MacOS and z/OS are a lot alike – tons of value in a single package – Done
Use of z/OS Unix System Services introduces “surrogate” security – which might end up giving too much authority to an individual – what can be done to reduce that risk.
MVS and zVM might have been considered the first cloud platform, but no one originally marketed it that way. Now, ASG’s Cloudfactory provides an Amazon Web services like front end for z/OS workloads. Done
The IBM Mainframe is advertised as hacker proof, but the weakest link is not the mainframe, it’s the end user interface and people using them. What can be done to help prevent problems? Use of Intellinx zWatch is one method that a wide range of customers use to prevent human errors across platforms.
Application development on the mainframe wasn’t always as simple as it was before the IBM Rational products came along and the Unit Test feature was added, which is also known as the zPDT . This was difficult to bring to market. For the first time, IBM separated development pricing from production pricing.
Linux is ported to S/390 in December 1999. Novell is offered the opportunity to be the first vendor on Linux on S/390. They say no.
Human Resource lessons learned in a 30+ year career.
High availability lessons learned. It’s not always the technology, it’s the process.
Multi Level Security – probably the answer to a lot of cloud sharing problems, but no one knows what it is or does. It’s in production in some very secure locations today. Done.