This week, I’m publishing a second blog entry from Marcel den Hartog, Principal Product Marketing for CA Technologies Mainframe Solutions. You can read more of his blogs here.
I know what you’re thinking: another Generation Z person wanting to ride the cloud hype and make sure we don’t forget about his favourite platform. But bear with me while I explain there is a lot of logic behind this...
I am old enough to remember the time when many of us in IT were surprised by the rise of the distributed environment. And, like many others, I did my fair share of work building applications on both mainframes and distributed servers. I was, however, lucky enough to work in an environment with little or no bias to any platform; our management simply asked us to pick the best platform for any given application.
Soon after building the first distributed applications, we found that we needed the data that resided on the mainframe. Not a big surprise, because most of the mission-critical data was stored on the mainframe AND we had a requirement that almost all the mission-critical data in the company had to be up-to-date, always!
This was not easy, especially in the early phases. We did not have ODBC, JDBC, MQSeries, Web services, or anything else that allowed us to send data back and forth from distributed applications to the mainframe. We had to rely on HLLAPI, a very low-level way of transmitting data by using the protocols that came with 3270 emulation boards like IRMA or Attachmate. And for the data that did not require continuous updates, we relied on extracts that were pumped up and down to a couple of distributed servers every night, where the data was then processed to make it usable for different applications.
The “fit-for-purpose” IT infrastructure we had back then was not ideal because it required a lot of work behind the scenes, mainly to make sure the data used by all these applications was up-to-date and “transformed” in the right way. But the technology became better and better, and with the move from text-based Clipper applications using HLLAPI to communicate with CICS transactions, we slowly moved to more modern, visually attractive programming languages that used more modern protocols like ODBC and JDBC. But since not all data on the mainframe or on distributed systems was capable of being accessed by these protocols (like VSAM files, IMS databases and others), for many applications we had to rely on data transport and transformation routines (and the servers to store and manage it) for many years. Even today, companies pump terabytes of data up and down their various platforms for many different purposes.
The next phase in IT was the switch from home-grown applications to buying applications like ERP, CRM, or other third-party (standardized) applications. And again, these applications not only required data from the mainframe and distributed applications, we also had to extract data FROM these applications to update the other applications our companies relied on. After all, every company runs with a mixture of applications on a mixture of platforms. And to complicate things even more, we do not buy all applications from the same vendors. So we have to exchange data between commercial applications as well. More complexity, more work, more money and more stuff to manage.
Welcome to the world of cloud. Where again, we will run (commercial) applications on a different platform and where we are (again) asked to make sure that our companies most valuable IT asset (our data) is up-to-date across all the different platforms: mainframe, cloud, and distributed. After all, we don’t want our customer data to be different across the different applications; the fact that we have to duplicate across all our different environments is already bad enough.
The efforts to create a pool of IT resources that enables us to create the “fit-for-purpose” IT infrastructure we are all aiming for has, until now, resulted in a very complex IT infrastructure that requires a lot of management. Here is where a latest IBM mainframe technology, comes in. The “pool of resources” can be found externally in the form of cloud services, as well as internally in blades that are configured to run virtualized systems on the mainframe. Adding the mainframe to this pool has big advantages. If you run Linux on the specialized engines (IFLs) on the mainframe, you need a lot less infrastructure to allow the Linux servers to communicate with each other and with your existing zOS applications. So there is no need for cabling and other network infrastructure. This not only greatly reduces the amount (and added complexity) of the hardware needed, it also means less power consumption and more flexibility. In the beginning of this article we agreed that many applications need access to mainframe data. By bringing the applications that need this data closer TO the mainframe, and by reducing the amount of infrastructure devices needed to connect it all, we make things simpler, faster, more manageable, and more reliable.
To make the mainframe part of an internal pool of IT resources that is flexible enough to accommodate the business needs of our management, there is one last step we must take; we need the right software to orchestrate, provision, and decommission servers on demand. There are already a number of vendors who offer software that helps you to provision both internal and external (cloud) resources in a matter of minutes. Simple drag-and-drop applications that provision servers and configure the network and connection settings make it possible to create complex environments in a matter of minutes. But none of them has supported the mainframe (yet). In the near future, however, the mainframe will also be supported, and this will open a new world of possibilities for everybody who already owns a mainframe. Soon, the mainframe will not just be used as part of an internal or hybrid cloud environment, it will act as one of the components you have in your pool of resources.
Yes, a stand-alone mainframe can offer many of the advantages that “cloud” offers: on-demand capacity, virtualization, flexibility and reliability. But not until you are able to use the mainframe as a component in a cloud infrastructure, so that you can bring the applications that need access to their data closer to the mainframe, will the two really be a perfect couple.
Showing posts with label Marcel den Hartog. Show all posts
Showing posts with label Marcel den Hartog. Show all posts
Sunday, 24 February 2013
Sunday, 27 January 2013
Guest blog - IT made simple? Automation lessons from the mainframe
This week, for a change, I’m publishing a blog entry from Marcel den Hartog, Principal Product Marketing for CA Technologies Mainframe Solutions.
Many moons ago, some smart people invented machines to do things (that were previously done manually) faster, better, and more consistently. Good examples are the car industry, the way we make (made) light bulbs, and how we produce clothes or other fabrics. Not much later, people invented machines to automate administrative tasks, so we could calculate faster and have better insights in our financials, with fewer people than ever before. Programmable typewriters are an early example, but the first simple computers did exactly that, add and subtract numbers faster and with fewer errors than an employee could (and ideally with no errors at all!).
The main reason for people inventing “machines” like this was to do things more efficiently, which in turn would make them more competitive. It was as simple as that. True, the equipment was a bit more complex, but the advantages far outweighed the problems of complexity.
This is where Information Technology was born. We soon needed people to drive these “machines”, maintain them, and program them to perform new tasks. And before we knew it, we had simplified a lot of manual tasks, invented some that we didn’t even know existed, and, probably even more important, we were seen as just another part of the business. A part that was able to help the company to run more efficiently and become more competitive.
Automation, in the most general sense, also helped our civilization to evolve faster and faster. Automating more meant we had more time to study, more time to invent even better technology that could automate even more...
However, somehow, at some point in the recent past, something went wrong. We kept implementing more technology that helped us to automate more bits and pieces, but we somehow forgot the next step of automation – automating our automation. Sounds weird? Well, look at how many manual interventions today’s IT systems need to keep them healthy. Ask your IT peers why it still takes 10 days to implement a new server (or 3 days if you do it on a virtualized server farm). Go and ask your Help Desk staff how much time it takes for a performance issue to bubble up, and get fixed again. Ask your operations staff how many of their events (across platforms) have automated actions attached to them that do stuff that could replace manual interventions...
Now, please don’t get me wrong, I know that there are many IT departments that have implemented automation in their IT environment. But in all fairness, it’s not really enough to cope with the complexity of today’s environments. There is another reason, however, for bringing this up now. In the past four years, many IT departments have implemented virtualization in some way. Some have been more successful than others, but there is one thing most people seem to agree on: the current mix of servers – Enterprise Servers like the IBM mainframe, standalone Unix, Linux, and Windows servers, and many virtualized systems running different kinds of OSs – is already hard to manage, and automation is already quite difficult. If the signs are right, we will add a lot of new stuff making it even harder to monitor, manage, and control everything we have.
With the addition of support for mobile devices, Cloud initiatives, and Big Data, we will be confronted with new and unpredictable behaviours arising from our systems. So if there were ever a time to give some extra attention to automate the things we already have, it’s now – at least then we will be more prepared for the unknowns that these new initiatives will bring us. I really think that this is also one of the ways to demonstrate to “the business” that IT really is ready to bring in the new IT services that the business requires. In the past, IT has often been accused of spending too much money to “keep the lights on”. Part of this, as we all know, is the fact that we still spend too much money and time on manual work (and interventions ) to keep these same lights on.
Now, please go back to my first paragraph and tell me if this sounds familiar. The business is now ready for new initiatives like Cloud, Big Data, and more and better support for mobile devices because it will help them to work in a more cost-effective way. IT is also ready for the next step, when we will be required to automate more of what is now running the business, to make sure that it runs as an efficient engine that needs a lot less attention, but also to free up the resources needed to run the new services that the business requires us to run...
I think we can all agree that what I just wrote makes sense. So why not go back to history once more for a final lesson?
Many Fortune 500 companies still run the majority of their mission-critical business services on a mainframe. And for good reason: it is a reliable environment, cost effective, and it is a platform that doesn’t confront managers with a lot of surprises. Some people might call this “boring”, others would say that it’s the way things are supposed to be run. Because of the nature of the mainframe (it was once the ONLY platform to run IT services on) automation has been perfected on this platform in the past decades. Some companies have tens of thousands of “rules” that kick in once unexpected things happen. Looking for proof? See how many people the average mainframe is managed with, compare that with the amount of mission-critical transactions running on that same mainframe, and everybody will agree that you need fewer people to manage a mainframe than you do to manage other environments. With mainframes, you really can have IT made simple.
People learn from the past. Experience is what has brought mankind to where it is today. But for some strange reason, we tend to think of history as something that goes 50+ years back. In IT, going back in history to learn something simply means going back 6-10 years. Talk to your mainframe peers, learn from their experience, and find how you can benefit from their automation expertise. It will not only make your current infrastructure run better, it will also help you to demonstrate to the business that you are ready for the next bulk of new and innovative IT projects – and you will save some money at the same time. And who doesn’t want to do that these days?
Many moons ago, some smart people invented machines to do things (that were previously done manually) faster, better, and more consistently. Good examples are the car industry, the way we make (made) light bulbs, and how we produce clothes or other fabrics. Not much later, people invented machines to automate administrative tasks, so we could calculate faster and have better insights in our financials, with fewer people than ever before. Programmable typewriters are an early example, but the first simple computers did exactly that, add and subtract numbers faster and with fewer errors than an employee could (and ideally with no errors at all!).
The main reason for people inventing “machines” like this was to do things more efficiently, which in turn would make them more competitive. It was as simple as that. True, the equipment was a bit more complex, but the advantages far outweighed the problems of complexity.
This is where Information Technology was born. We soon needed people to drive these “machines”, maintain them, and program them to perform new tasks. And before we knew it, we had simplified a lot of manual tasks, invented some that we didn’t even know existed, and, probably even more important, we were seen as just another part of the business. A part that was able to help the company to run more efficiently and become more competitive.
Automation, in the most general sense, also helped our civilization to evolve faster and faster. Automating more meant we had more time to study, more time to invent even better technology that could automate even more...
However, somehow, at some point in the recent past, something went wrong. We kept implementing more technology that helped us to automate more bits and pieces, but we somehow forgot the next step of automation – automating our automation. Sounds weird? Well, look at how many manual interventions today’s IT systems need to keep them healthy. Ask your IT peers why it still takes 10 days to implement a new server (or 3 days if you do it on a virtualized server farm). Go and ask your Help Desk staff how much time it takes for a performance issue to bubble up, and get fixed again. Ask your operations staff how many of their events (across platforms) have automated actions attached to them that do stuff that could replace manual interventions...
Now, please don’t get me wrong, I know that there are many IT departments that have implemented automation in their IT environment. But in all fairness, it’s not really enough to cope with the complexity of today’s environments. There is another reason, however, for bringing this up now. In the past four years, many IT departments have implemented virtualization in some way. Some have been more successful than others, but there is one thing most people seem to agree on: the current mix of servers – Enterprise Servers like the IBM mainframe, standalone Unix, Linux, and Windows servers, and many virtualized systems running different kinds of OSs – is already hard to manage, and automation is already quite difficult. If the signs are right, we will add a lot of new stuff making it even harder to monitor, manage, and control everything we have.
With the addition of support for mobile devices, Cloud initiatives, and Big Data, we will be confronted with new and unpredictable behaviours arising from our systems. So if there were ever a time to give some extra attention to automate the things we already have, it’s now – at least then we will be more prepared for the unknowns that these new initiatives will bring us. I really think that this is also one of the ways to demonstrate to “the business” that IT really is ready to bring in the new IT services that the business requires. In the past, IT has often been accused of spending too much money to “keep the lights on”. Part of this, as we all know, is the fact that we still spend too much money and time on manual work (and interventions ) to keep these same lights on.
Now, please go back to my first paragraph and tell me if this sounds familiar. The business is now ready for new initiatives like Cloud, Big Data, and more and better support for mobile devices because it will help them to work in a more cost-effective way. IT is also ready for the next step, when we will be required to automate more of what is now running the business, to make sure that it runs as an efficient engine that needs a lot less attention, but also to free up the resources needed to run the new services that the business requires us to run...
I think we can all agree that what I just wrote makes sense. So why not go back to history once more for a final lesson?
Many Fortune 500 companies still run the majority of their mission-critical business services on a mainframe. And for good reason: it is a reliable environment, cost effective, and it is a platform that doesn’t confront managers with a lot of surprises. Some people might call this “boring”, others would say that it’s the way things are supposed to be run. Because of the nature of the mainframe (it was once the ONLY platform to run IT services on) automation has been perfected on this platform in the past decades. Some companies have tens of thousands of “rules” that kick in once unexpected things happen. Looking for proof? See how many people the average mainframe is managed with, compare that with the amount of mission-critical transactions running on that same mainframe, and everybody will agree that you need fewer people to manage a mainframe than you do to manage other environments. With mainframes, you really can have IT made simple.
People learn from the past. Experience is what has brought mankind to where it is today. But for some strange reason, we tend to think of history as something that goes 50+ years back. In IT, going back in history to learn something simply means going back 6-10 years. Talk to your mainframe peers, learn from their experience, and find how you can benefit from their automation expertise. It will not only make your current infrastructure run better, it will also help you to demonstrate to the business that you are ready for the next bulk of new and innovative IT projects – and you will save some money at the same time. And who doesn’t want to do that these days?
Subscribe to:
Posts (Atom)