CA Community






This Blog

July 2010 - Posts

Disasters, they DO happen…

Published: July 29 2010, 09:09 AM | no comments
by Marcel den Hartog

The world watched the BP oil accident in the past weeks. We all have our opinions about it and, like most others; I tried to look at it from a professional point of view.

Risk management is something we have to deal with. Either direct or indirect. And most of us are aware of the importance of IT to the companies we work for. But how thought through is our risk management really? Do we plan for the unthinkable? Or do we just plan for the things we know DO happen from time to time. To use the example of BP, if they had really thought of the unthinkable, they would have drilled a second pipe in every well deeper than "n" feet/km. Would BP's management have accepted the extra costs, would the shareholders have been happy with the lower dividend that would be caused by this? Did anybody even ever think about that?

Let me use another example: about 5 years ago I presented for a 100+ audience of Oracle DBA's. All Unix & Windows people. And I asked a simple question: "How many of you have ever deleted a production database by accident?" More than 80% raised their hands (but only after I admitted that it happened to me as well ....).
And when I asked if they had changed the security settings on the production systems so they would be prevented from doing it again, only 2 left their hands up. Think about the effect and the costs of a deleted Production Database. Think about the low cost of setting the right access levels and taking away the "God mode" Super user access from people who should not even be on production systems.... Has this changed in the past years? I don't think so. As a matter of fact, I know it has not. And this is a risk we can all think of from the top of our minds.....

There is an important lesson for all of us in the oil spill example. Not just about thinking about the unthinkable, but also in the way the disaster was handled. We all have experienced a disaster in our careers. And most of us have been lucky enough to see more than one. We have probably implemented all kinds of stuff to prevent THAT particular disaster to happen again, but what have we implemented to treat new disasters more efficiently and streamlined? We are all technical people and we tend to focus on technical things that solve technical problems. We often forget that a lot (if not most) of the time spent on solving a disaster is not spend on technical issues, but on the panic that occurs immediately after the discovery and the unclear responsibilities  of everybody involved.

Here are some hints and tips from the field:

1. Analyze past disasters, and see how you can create a playbook that deals with the human part of disasters. Who makes the decision to roll-back the production database back with 24hrs if that is necessary? Both on the production-, the middle management- and executive management level. Who informs who, and who approves what.

2. Think of the unthinkable by networking. Both Internal and External!! These days, we spend less and less time going to conferences, listening to webcasts and talking to peers. And I have seen brilliant presentations with lots of "aha" moments when peers or other specialists described a disaster they were confronted with and how they solved it. Implementing the lessons learned by others is cheap and often closer to reality than what you can come up with.

3. Work with the financial people to figure out the cost of a disaster. 1 hour, 2 hours, 1 day of down-time? How much money, customers, good-will does the company loose in case of a major hick-up? I am sure if someone in BP would have told an executive that by drilling a second pipe as a precaution, it could save the company 6 Billion $ in case a disaster stroke, at least a few people would have given it some serious thinking.....

4. Test. TEST!!! With budgets being constrained almost everywhere, testing is amongst the first things we drop. Takes too much time, is too expensive. Once you know the COST of downtime, it becomes easier to defend the things you need to do to prevent them. I still remember a new CEO discussing a DR testing plan with a Mainframer:

a. CEO;"Has it ever happened?" (answer: "No")

b. CEO;"How much will it cost us if it DOES happen?" (answer: "I don't know")

c. CEO;"How much does it cost to prevent it from happening?" (very detailed answer...)

d. CEO;"Forget it, too expensive!" Literally a 5 second conversation on a topic that could bring the company to bankruptcy in less than a day.

Let me leave you with a positive thought. IBM's new zEnterprise Mainframe is designed to " expand the mainframe's role in coordinating management of other, distributed systems that have surrounded it in the modern datacenter"". Good news for Mainframers because our DR procedures are unsurpassed, and good news for the "other" systems because they can now benefit from the more integrated and powerful Mainframe management capabilities.

 

Share this post:  

 

By: Marcel den Hartog
Marcel den Hartog is Principal Product Marketing EMEA for CA Technologies Mainframe solutions. In this role, he is a frequent speaker on both internal (customer) and external events where he talks about CA Technologies mainframe strategy, vision and market trends. Marcel joined CA Technologies in...
Read More..

Migrate From Mainframe? To What?

Published: July 29 2010, 08:46 AM | no comments
by Marcel den Hartog

I recently followed a discussion about this topic on : http://mervadrian.wordpress.com/2010/06/24/migrate-from-mainframe-to-what/ and could not help thinking back. Last year at a GSE conference in The Low Lands, I again met with a systems programmer who works for a bank. About 5-6 years ago, their management was convinced that migrating to a "more modern platform" would be a strategic move that would help them save a lot of money AND add a lot of business value. The systems programmer and I meet at every GSE meeting so year after year I was informed about the progress.

How did this project end? As you might guess, it was delivered too late, budgets were severely overspent, with an application that could not handle heavy loads and with a server farm and administrators that far outnumbered (both in numbers and in money) what they initially budgeted for. Not to mention the fact that the mainframe had to stay in business about 3 (THREE) years longer than expected. This is not the first time I have seen it and unfortunately, it will not be the last.

What went wrong here? Well, this is what likely happened:

First of all, the reason for the decision --- a "more modern platform". As far as I am concerned, the IBM Mainframe IS a modern platform, unless you do not really KNOW the platform. And as you can see in the blog, sometimes, the modern platform is so modern that adoption of it may not even take place on the scale it was expected/promised.

Second of all, cost. The project mentioned above will not have an ROI of less than 6 years. Too long for a project like this and caused by a few scary assumptions:

  • The costs that are in the Mainframe Cost Centre are really JUST mainframe costs (which is NEVER the case in my experience)
  • The cost for running the new environment is always initially too low. A complex Mainframe application turns into a very complex distributed application which is complex to manage. No matter what people promise you; managing 1 box is simpler than managing 30-40-50.....
  • The cost of re-developing a working Mainframe application is also ALWAYS much higher than expected. Years of knowledge will not transfer as easy as people think.

Thirdly, lack of deep knowledge of what the mainframe really does and why it is so reliable. People who now manage IT Departments of people who give you expensive advice have not grown up with the concept of a Mainframe. The projects they know (Windows, Linux, Web and Server Farms) on what they do not know (the Mainframe) and this simply cannot be done. It's like asking someone who has always built houses to build a complex manufacturing plant. Things are simply too different.... It often simply blows the minds of consultants once they find out what the 4-5 Mainframe Administrators really do. I have seen their faces when they did the calculations in their minds! They simply don't know, because they do not ask and also because it is not in some people's interest to tell them.

In our industry, we often find that we are still in our infancy. Decisions are often still based on emotions and we tend to "stick with our original decision" even though we find new facts while the project evolves. Only when we have facts, should we make decisions like migrating applications to "a more modern platform"... Real facts, not statements we THINK are facts. Do our current IT cost centers really properly reflect the IT costs or do we use "rule of thumb industry standards" that have not changed in the past five years? In other words, we should do our home work better, with less emotion. More modern does not automatically mean "better for the business" and ultimately, that's the only thing that counts.

 

Share this post:  

 

By: Marcel den Hartog
Marcel den Hartog is Principal Product Marketing EMEA for CA Technologies Mainframe solutions. In this role, he is a frequent speaker on both internal (customer) and external events where he talks about CA Technologies mainframe strategy, vision and market trends. Marcel joined CA Technologies in...
Read More..

zNext? zNow!

Published: July 25 2010, 06:44 PM | no comments
by Reg Harbeck

I'm trying to figure out how it is that zNextGen, which is a project in SHARE, and not an IBM initiative, has somehow gotten the reputation as the template for a bunch of IBM stuff.

Not that IBM has used it - they've been quite respectful of the SHARE ownership of this term.

But a few other folks seem to think that "zNextGen" and "zNext" belong to IBM.

Well, IBM just clarified once again that the next thing they're doing is not "zNext" - it's now, and it sure is one heckuva great idea.

It's zEnterprise, and it's a major step forward in enterprise computing. And working for one of the only companies that have solutions that manage IT enterprise-wide, including the mainframe, I think it's pretty cool.

Time for a little history here. Back in the late 1980's, CA Techologies (then known as Computer Associates) wrote something called Unicenter to offer mainframe qualities of management on UNIX.

Then, in the mid-1990's, CA introduced Unicenter TNG ("The Next Generation") to bring such management to Windows.

Since then, CA has continued to expand and deepen enterprise-wide systems management, bringing the mainframe way to the rest of the IT world. And, of course, integrating across the enterprise, resulting in solutions like Cross-Enterprise Application Performance Management (see http://www.ca.com/us/analysts/reports/collateral.aspx?cid=223935, http://www.ca.com/us/demos/collateral.aspx?cid=218839 and http://www.ca.com/files/solutionbriefs/cross-enterprise-apm-solutionbrief_219696.pdf).

So, the idea of an enterprise in a box, isolated from sniffers and other weakest links, is not only business cool, it's totally manageable.

Of course, history has shown that introducing a new solution doesn't necessarily mean the end of established ones, so we can expect the rest of the enterprise to continue on, from PC's and other workstations, through various servers, to the mainframe and back.

Still I'm always happy to welcome new platforms into the scope of scrupulous computing that is so important to us mainframers. The mainframe ain't goin' away - but there's always room for more quality!

 

Share this post:  

 

By: Reg Harbeck
Reg Harbeck is CA's Product Management Director for Mainframe Strategy. In the more than two decades since he received his Bachelor's Degree in Computer Science he has worked with operating systems, networks, security and applications on mainframes, UNIX, Linux, Windows and other platforms. Reg...
Read More..

The Human Computer

Published: July 05 2010, 01:43 PM | no comments
by Reg Harbeck

Perhaps one of the clearest manifestations of our creative instinct is humanity's desire to create viable objects and systems that have an existence entirely distinct from their creators.

Whether you're talking tools, statues, buildings or businesses, we seem to like the idea that what we have produced has an existence so separate from us that it will continue on after we're gone.

Perhaps that's one reason why, when we produce such a spectacular invention as the computer, we tend to immediately think of it as somehow other, not just from ourselves, but from nature as well.

I think this is an interesting and practical way of approaching our inventions. Indeed, being able to "let go" has value from the perspective of our own viability beyond that of our inventions as well.

However, there's another side to this coin that we perhaps don't pay as much attention to: the objects and systems that we invent are, in their very essence, human.

Let's look at the computer as an example. The idea for a computational machine arose a long time before the first working prototype made its way into the world of business. In some ways, it could be seen as a logical next step from the industrial revolution: automate the physical work that people did, then begin to automate the clerical work as well.

And what clerical job description became the first one targeted for replacement by this innovation? Computer, of course.

Yes, as you probably already knew, "Computer" was actually a job title, and many hard-working people were employed doing continuous calculations before their role, and job title, was taken over by an electronic innovation.

It would be simplistically easy to assume that, once this first computing device got its foot in the door, its successors began to diverge into a completely separate existence that was all logic and not at all human, except maybe as a role model for Spock wanna-be's.

In fact, if we look at what business dollars were paying for, and businesses were demanding (often through user groups, including the first computer user group: SHARE), it always came back to their business requirements, which were shaped by the needs, wants, requirements and goals of... humans.

So, the computer (and particularly the business computer) was born and grew up in the context of business and humanity.

However, if there's one thing we can learn from history (other than the fact that we never seem to learn from history, of course), it's that plans too far in advance tend to not work out because the unforeseen and unforeseeable quickly occlude most of what we can project with our best predictive abilities. My favorite quotation about this comes from General Dwight D. Eisenhower, who famously said, "In preparing for battle, I have always found that plans are useless, but planning is indispensable."

So, while excellent ground work was laid for making business computing a viable, reliable reality, and while the announcement of the System/360 did indeed establish a foundation that continues to this day to support the most important business computing activities in the world, there were some things that couldn't have been easily foreseen back then, and many of them have to do with our humanity.

Which brings us to 2010. Computing (and networking) technology have grown and flourished, twisted and morphed in response to consumer and business demands and emergent and consequent technological breakthroughs, constantly re-adapting to humanity's requirements and interests. Yet one of our oldest and deepest requirements has always been for something stable, functional and trustworthy, and so we have continued to rely on the mainframe in the midst of all these other innovations.

And, as a result, while it continues to be ever-more reliable, the mainframe too has taken on the best of all these technical, human-centric adaptations, and is even taking on a new generation of humans to manage it.

Which brings me to my conclusion: with all of its history, mandates, innovation, quality, adaptations and optimizations, today's mainframe computer - particularly with key enablers for a new generation such as CA MSM and CA Mainframe Chorus - is one of the most human inventions yet.

Which is why I'd call it the Human Computer.

Share this post:  

 

By: Reg Harbeck
Reg Harbeck is CA's Product Management Director for Mainframe Strategy. In the more than two decades since he received his Bachelor's Degree in Computer Science he has worked with operating systems, networks, security and applications on mainframes, UNIX, Linux, Windows and other platforms. Reg...
Read More..

More Posts