When asked to talk with the
architects and builders working on our home, we have to be careful about what
we ask for and much is the same when we talk about NonStop with our CIOs – are we
ensuring the right message about NonStop is always being communicated?
I
swore I wouldn’t build another house and yet, here we are some twenty years
later, and having another go. Building isn’t for the faint of heart nor should
anyone building a new home from scratch think that it can be done on budgets
created early in the process. But perhaps the biggest issue that comes up early
in the process is that there is a huge difference between the opinions of the
architect, the project manager and the builder. When we last built a home – the
one we just sold after a marathon effort – the architect, the project manager
and the prime contractor were one and the same. But this isn’t the case today
and you quickly realize that in dealing with these individuals you have to
change the language you use even as you are oftentimes left to reset your
expectations.
Many years ago I wrote a number of posts to this blog that looked at different roles and responsibilities we come across within IT today – posts that I listed under the label of C4 - Artists and Technicians. The individuals referenced in those posts included CTOs, CIOs, data center managers, architects and even the CBO – yes, the Chief Blogging Officer. The common theme across all these posts was simply to remind readers that the old lines that separated programmers from analysts from operators not to mention the EDP or MIS manager, is long gone and with their demise, we need to be cognizant of the language we use when interacting with rich variety of skilled IT personnel now on hand.
Few of us could have predicted the rise of DevOps just a decade or so ago and for people who baulked at the creation of systems programmers versus application programmers versus database administrators – it really is important that we explain technology carefully even to those we expect should know exactly what we are talking about. When it comes to NonStop and the NonStop community, it is of more importance than many of us care to admit, but the wrong phrase at the wrong time can set an IT organization down a path we may not have anticipated. If we are looking to expand the market presence of NonStop then we should always consider carefully what we tell our managers and what explanations we provide when it comes to exactly what resources are needed to ensure NonStop systems continue to support mission critical applications.
There have been many examples through the years where we have experienced a divide even as we share a common language. Take for instance the early discussions between data center operators and those responsible for telecommunications. Whereas the request to “scratch a data set” may mean the operator needs to delete a file, to those working with phones, it may mean defacing a telephone. What brought this to a head this week was a conversation with a member of the NonStop vendor community who told me of how CIOs he talked to couldn’t find college graduates who knew how to program NonStop! Ouch – even as I cringed at what was said I did understand the sentiment, but really?
By comparison, these CIOs knew of many talented college graduates who knew how to program Linux and Windows and I have to admit, my countenance fell as an overwhelming sense of sorrow quickly set in. When it comes to today’s NonStop systems who on earth programs NonStop! And the very same can be said about who on earth programs Linux? Surely, even the most talented and experience CIO should realize we don’t program NonStop or Linux, but rather, we program in C / C++, Java, Python, JavaScript and so on. Some vendors may be using low-level languages to better interface with the Operating System but that is the role of vendors and that is one of the main reasons we buy their middleware and solutions – so we are not exposed to programming at this level.
When was the last time we heard a CIO ask for someone to program the equivalent of Pathway? Or, EXPNET? Clearly, we write programs to run under the monitoring oversight of Pathway, EXPNET, and so forth. Furthermore, with most NonStop users buying solutions from prominent vendors these days, the extent of “programming NonStop” is either via script modifications / extensions to what the vendor provides, changing some table entries, or should programming be involved, utilization of one of the programming languages already referenced. The HPE NonStop team has covered a lot of ground over the past few years to ensure even the least experienced college graduate can bring with them their skills in one or more of C / C++, Java, Python, JavaScript, etc. and be productive on NonStop almost immediately.
Maintaining this “handle with care” or “needs special attention” attitude when it comes to NonStop isn’t doing any of us any good. Before anyone throws water all over my arguments, I am not saying that within the NonStop vendor community there remains a need for architects knowledgeable in all things NonStop who steer development projects down the right path – they will always be valued and their value is commensurate with the experience they have accumulated over time. However, with this said, it doesn’t rule out just how straight-forward it is to have Java or JavaScript code redeployed on NonStop with the rest of IT unaware of the port.
When it comes to mission critical applications, there remains the need to deploy them on platforms that provide the very best uptime possible and this remains the almost exclusive domain of NonStop. After decades of effort, no other vendor can provide the level of uptime – and yes, with it, the ability to scale out, ad nauseam. This is what we need to be telling CIOs today – forget about programming NonStop and instead, tell them how NonStop supporting a new application will ensure its operation 24 x 7 and hence, be better suited to running those mission critical applications without outages or loss of data, and yes, can be written / maintained in exactly the same programming languages / frameworks as are supported on other platforms, including Linux and Windows. And this message is going to become even easier to convey with so much being discussed about transformation to hybrid IT!
It’s becoming a lot easier because of more work being done by the NonStop development team as they add more and more features to NonStop SQL/MX (NS SQL). Among the most obvious inclusion that will help sway conversations in NonStop’s favor is the Oracle compatibility NS SQL is gaining. Just as you don’t program NonStop, Linux or Windows, when you dive into the languages popular with college graduates you will find considerable dependence upon SQL support and for many developers, this simply translates to Oracle. Now, no worries; you will be able to leverage these skills while writing programs for NonStop systems. And why NS SQL? Well, it’s that hybrid IT story again.
As the team at NonStop gets more exposure to this major initiative of HPE, they are seeing more interest in having NonStop a part of the hybrid and in particular, having NS SQL accessible from Linux and Windows on the basis of DBaaS! Many of the IT folks I have talked to weren’t expecting this development but if you track the presentations coming from HPE IT for more than a year now, you will see NS SQL occupying center stage when it comes to supporting mission critical data. Again, mission critical runs 24 x 7 so why would you continue to rely on any other SQL not designed to run, out of the box, 24 x 7 – something that NS SQL has being doing since it was first released back in the late 1980s.
In talking to the architects, project managers and builders working on our new home I need to be careful of what I say as every now and then, I only add to the confusion. Likewise, we do have to be careful about what we tell our CIOs. We don’t need NonStop people so much as we need C / C++, Java, Python, JavaScript, etc. programmers and should they have skills in SQL, all the better. Many years ago, I was first recruited to be an applications programmer and in time, I became a systems programmer with responsibility for communications and data base management systems and I view this as a natural progression. If you are seriously concerned about having architects on hand, why not give the programmers a start and let them develop additional skills over time. After all, almost every programmer working on NonStop today didn’t suddenly come into work as NonStop architects … but they did get a lot of encouragement along the way. So, once again, let’s all tell the same story and let it be the right story – you need programmers and that’s all you need!
I
swore I wouldn’t build another house and yet, here we are some twenty years
later, and having another go. Building isn’t for the faint of heart nor should
anyone building a new home from scratch think that it can be done on budgets
created early in the process. But perhaps the biggest issue that comes up early
in the process is that there is a huge difference between the opinions of the
architect, the project manager and the builder. When we last built a home – the
one we just sold after a marathon effort – the architect, the project manager
and the prime contractor were one and the same. But this isn’t the case today
and you quickly realize that in dealing with these individuals you have to
change the language you use even as you are oftentimes left to reset your
expectations. Many years ago I wrote a number of posts to this blog that looked at different roles and responsibilities we come across within IT today – posts that I listed under the label of C4 - Artists and Technicians. The individuals referenced in those posts included CTOs, CIOs, data center managers, architects and even the CBO – yes, the Chief Blogging Officer. The common theme across all these posts was simply to remind readers that the old lines that separated programmers from analysts from operators not to mention the EDP or MIS manager, is long gone and with their demise, we need to be cognizant of the language we use when interacting with rich variety of skilled IT personnel now on hand.
Few of us could have predicted the rise of DevOps just a decade or so ago and for people who baulked at the creation of systems programmers versus application programmers versus database administrators – it really is important that we explain technology carefully even to those we expect should know exactly what we are talking about. When it comes to NonStop and the NonStop community, it is of more importance than many of us care to admit, but the wrong phrase at the wrong time can set an IT organization down a path we may not have anticipated. If we are looking to expand the market presence of NonStop then we should always consider carefully what we tell our managers and what explanations we provide when it comes to exactly what resources are needed to ensure NonStop systems continue to support mission critical applications.
There have been many examples through the years where we have experienced a divide even as we share a common language. Take for instance the early discussions between data center operators and those responsible for telecommunications. Whereas the request to “scratch a data set” may mean the operator needs to delete a file, to those working with phones, it may mean defacing a telephone. What brought this to a head this week was a conversation with a member of the NonStop vendor community who told me of how CIOs he talked to couldn’t find college graduates who knew how to program NonStop! Ouch – even as I cringed at what was said I did understand the sentiment, but really?
By comparison, these CIOs knew of many talented college graduates who knew how to program Linux and Windows and I have to admit, my countenance fell as an overwhelming sense of sorrow quickly set in. When it comes to today’s NonStop systems who on earth programs NonStop! And the very same can be said about who on earth programs Linux? Surely, even the most talented and experience CIO should realize we don’t program NonStop or Linux, but rather, we program in C / C++, Java, Python, JavaScript and so on. Some vendors may be using low-level languages to better interface with the Operating System but that is the role of vendors and that is one of the main reasons we buy their middleware and solutions – so we are not exposed to programming at this level.
When was the last time we heard a CIO ask for someone to program the equivalent of Pathway? Or, EXPNET? Clearly, we write programs to run under the monitoring oversight of Pathway, EXPNET, and so forth. Furthermore, with most NonStop users buying solutions from prominent vendors these days, the extent of “programming NonStop” is either via script modifications / extensions to what the vendor provides, changing some table entries, or should programming be involved, utilization of one of the programming languages already referenced. The HPE NonStop team has covered a lot of ground over the past few years to ensure even the least experienced college graduate can bring with them their skills in one or more of C / C++, Java, Python, JavaScript, etc. and be productive on NonStop almost immediately.
Maintaining this “handle with care” or “needs special attention” attitude when it comes to NonStop isn’t doing any of us any good. Before anyone throws water all over my arguments, I am not saying that within the NonStop vendor community there remains a need for architects knowledgeable in all things NonStop who steer development projects down the right path – they will always be valued and their value is commensurate with the experience they have accumulated over time. However, with this said, it doesn’t rule out just how straight-forward it is to have Java or JavaScript code redeployed on NonStop with the rest of IT unaware of the port.
When it comes to mission critical applications, there remains the need to deploy them on platforms that provide the very best uptime possible and this remains the almost exclusive domain of NonStop. After decades of effort, no other vendor can provide the level of uptime – and yes, with it, the ability to scale out, ad nauseam. This is what we need to be telling CIOs today – forget about programming NonStop and instead, tell them how NonStop supporting a new application will ensure its operation 24 x 7 and hence, be better suited to running those mission critical applications without outages or loss of data, and yes, can be written / maintained in exactly the same programming languages / frameworks as are supported on other platforms, including Linux and Windows. And this message is going to become even easier to convey with so much being discussed about transformation to hybrid IT!
It’s becoming a lot easier because of more work being done by the NonStop development team as they add more and more features to NonStop SQL/MX (NS SQL). Among the most obvious inclusion that will help sway conversations in NonStop’s favor is the Oracle compatibility NS SQL is gaining. Just as you don’t program NonStop, Linux or Windows, when you dive into the languages popular with college graduates you will find considerable dependence upon SQL support and for many developers, this simply translates to Oracle. Now, no worries; you will be able to leverage these skills while writing programs for NonStop systems. And why NS SQL? Well, it’s that hybrid IT story again.
As the team at NonStop gets more exposure to this major initiative of HPE, they are seeing more interest in having NonStop a part of the hybrid and in particular, having NS SQL accessible from Linux and Windows on the basis of DBaaS! Many of the IT folks I have talked to weren’t expecting this development but if you track the presentations coming from HPE IT for more than a year now, you will see NS SQL occupying center stage when it comes to supporting mission critical data. Again, mission critical runs 24 x 7 so why would you continue to rely on any other SQL not designed to run, out of the box, 24 x 7 – something that NS SQL has being doing since it was first released back in the late 1980s.
In talking to the architects, project managers and builders working on our new home I need to be careful of what I say as every now and then, I only add to the confusion. Likewise, we do have to be careful about what we tell our CIOs. We don’t need NonStop people so much as we need C / C++, Java, Python, JavaScript, etc. programmers and should they have skills in SQL, all the better. Many years ago, I was first recruited to be an applications programmer and in time, I became a systems programmer with responsibility for communications and data base management systems and I view this as a natural progression. If you are seriously concerned about having architects on hand, why not give the programmers a start and let them develop additional skills over time. After all, almost every programmer working on NonStop today didn’t suddenly come into work as NonStop architects … but they did get a lot of encouragement along the way. So, once again, let’s all tell the same story and let it be the right story – you need programmers and that’s all you need!
Comments