LongEx Mainframe Quarterly - August 2012
A year ago I wrote an opinion piece discussing whether there was indeed a mainframe shortage, and what that meant to mainframe managers and users. At that time, I believed there was a moderate shortage of mainframe talent, particularly at the elite or high-end. I believed that many organizations were doing little to address this, and that these problems would become more acute over time. Since then, two things have happened to support my previous opinions. The first is a study performed by Compuware and Forrester Research of 520 enterprise-level CIOs at the end of last year. Amongst other findings, this study reported that 71% of CIOs were concerned that mainframe skills shortages will hurt their business. However 46% of the same CIOs had no plans to tackle these shortages. To put this into perspective, most stated that a mainframe outage would pose a serious business risk costing on average US$14,000 per minute. There's no doubt that a lack of quality technical staff will increase the chances of problems and outages. But more importantly, any problems or outages will also require quality staff to diagnose and repair. And they’ll need to do this under $14,000 per minute of pressure. I’ve noticed a couple of high profile mainframe failures in the past few months that have impacted business performance. These include HSBC (UK), Royal Bank of Scotland, Commonwealth Bank of Australia, and the National Australia Bank. The second thing to confirm my opinions comes from a consulting project. My client was developing a Microsoft Windows based product working with z/OS. They needed to test their product against a standard z/OS feature. They used a z/OS system hosted and supported by an external vendor as their test system. Longpela Expertise was brought in because the external vendor could not get that z/OS feature working. Their staff were excellent at basic z/OS administration. But when faced with a new feature that needed more detailed knowledge of z/OS, together with a willingness to read manuals and investigate new features; they failed. They were not quality staff. It’s easy to see how this comes about. New staff are often thrown in the deep end with no previous z/OS experience, little training, and no one more experienced to turn to. Their workloads are high, the range of knowledge required vast, and they receive little encouragement or time to experiment, investigate and learn. I talk a lot about quality staff: staff with technical knowledge exceeding what is required to do their day-to-day job. Quality staff understand deeper levels - why things happen, not just what. They can work through problems and issues using this enhanced technical knowledge, together with previous experiences and willingness to read (not just skim) manuals and technical documents. Quality staff have worked in different areas of their niche, gaining a wider understanding and experience base. I’ve held a long term belief that such quality technical staff are essential for any IT group, including those that work with mainframes. But quality staff don’t just appear, they are created. They need to be given time and encouragement to explore their given area - a hard ask in today’s corporate environment. They should be given training, and in the mainframe arena mainframe training options are still available. And finally, they should mentor other staff - passing on knowledge and improving their own skills at the same time. |
