How appropriate for the first post of the new year: the final value on the "Why" dimension is about new business value.
The fact is, if the mainframe really is the most leading-edge business computer out there, then it must be able to take on some seriously leading-edge new business computing.
This is important for many reasons, including that it's one of the best ways to optimize the value and culture you already have in your mainframe environment. As I identify more thoroughly in a white paper which has been sponsored by Terma Software Labs (click here to download a copy), one way to move your mainframe context forward is by empowering a new generation to become ambassadors between your mainframe culture and the other cultures affected by your mainframe. Another key way is through undertaking new technical initiatives such as installing new generation management and analytics software.
Add to this using the mainframe for brand new business activities, and you have the essence of this final "Why" value.
Now, speaking of new value, I'm also making the decision to remove the monetizing advertisements from this blog.
As the folks on one of my favourite TV shows point out, failure is always an option. In this case, not only have I not found that the ads generate any significant revenue, but more importantly I'm increasingly unhappy with the nature of the ads, and I don't feel they represent the quality that this blog and company are about. This blog is intended to bring value to people whom I respect, and I don't feel like I'm being very respectful by forcing you to see these ads. So, I'm calling the ads a failure and moving on without them.
Sunday, February 3, 2013
Saturday, December 22, 2012
Plumbing the Taxonomy: Why? Part E - Analysis and Planning
One of the things that really annoys me about modern business IT is that the decision makers and their closest advisers, including IT Architects, often have no clue about the role of the mainframe in their environments, even though they've bet their businesses on this most reliable of platforms decades ago, and would not survive without it.
As a result, you get some very odd and skewed perceptions and depictions. One of these is the IT Architecture diagram, a poster-sized picture of an organization's IT context that the Architect has spent a very long time fine-tuning to make it look just right. If you were to take into account all the time and effort that goes into one of these posters, they could easily be seen to have cost an organization over $100,000 to produce - which is nothing compared to their potential cost to the organization if done wrong.
Which they invariably are if the role of the mainframe is missing or understated - which it almost always is. Because the architect will spend months talking to all the people who have servers and routers, closets full of IT devices, and special projects, and create a politically-correct depiction of what they heard from all the people they talked to. And maybe they briefly talked to one or two mainframe-relevant people, and maybe they even stuck a picture of a little mainframe in the bottom right corner of the diagram just to keep from annoying those legacy dinosaurs. But the glorious new technology that is lighting the way and has all the political weight: that is far and away the bulk of the diagram.
Except that, if the IT Architect were to draw a picture that took into account the business value and essential role of each device, the mainframe would take up an unweildy majority of the poster, as it is the keeper of the corporate jewels - but that's "not fair" to all the other IT people affected.
And if the IT Architect were to draw a picture that shows the role of every machine in every application, the mainframe would show up as the foundational platform for just about every major application, with the other platforms providing barely more than cosmetic additions and user interfacing, but the essential data and processing held firmly on the mainframe.
The problem: politics and ignorance (and you thought IT would save us from the human condition). The other platforms take so many people to maintain them that they have far more political weight than the mainframe. And the mainframe works so invisibly well that everyone only notices the squeaky wheel and sizzle platforms that are barely more than nail polish on the underlying functionality provided by the mainframe.
But what has this rant to do with the "Analysis and Planning" value in the "why" dimension? This: not only does the mainframe offer so much value that any legitimate IT Architecture diagram would be mostly mainframe with tiny bits of the other platforms scattered like ornaments on a tree (like the seasonal reference?), but properly characterizing, understanding, and building on that value has the potential to bring more business value to the organization that is paying for IT like few other cost-effectiveness initiatives could.
And the software with this role gives the needed insights into resource configuration, usage, and future scenarios, therefore playing a role with significant business value, ensuring that the return on investment for the mainframe just keeps going up, regardless of what the IT Architects and other decision makers may decide to do with the minor platforms in the environment.
This is especially important combined with proactively responding to new initiatives - but that's the next (and last) value on this dimension, so I'll save that for the next blog post.
As a result, you get some very odd and skewed perceptions and depictions. One of these is the IT Architecture diagram, a poster-sized picture of an organization's IT context that the Architect has spent a very long time fine-tuning to make it look just right. If you were to take into account all the time and effort that goes into one of these posters, they could easily be seen to have cost an organization over $100,000 to produce - which is nothing compared to their potential cost to the organization if done wrong.
Which they invariably are if the role of the mainframe is missing or understated - which it almost always is. Because the architect will spend months talking to all the people who have servers and routers, closets full of IT devices, and special projects, and create a politically-correct depiction of what they heard from all the people they talked to. And maybe they briefly talked to one or two mainframe-relevant people, and maybe they even stuck a picture of a little mainframe in the bottom right corner of the diagram just to keep from annoying those legacy dinosaurs. But the glorious new technology that is lighting the way and has all the political weight: that is far and away the bulk of the diagram.
Except that, if the IT Architect were to draw a picture that took into account the business value and essential role of each device, the mainframe would take up an unweildy majority of the poster, as it is the keeper of the corporate jewels - but that's "not fair" to all the other IT people affected.
And if the IT Architect were to draw a picture that shows the role of every machine in every application, the mainframe would show up as the foundational platform for just about every major application, with the other platforms providing barely more than cosmetic additions and user interfacing, but the essential data and processing held firmly on the mainframe.
The problem: politics and ignorance (and you thought IT would save us from the human condition). The other platforms take so many people to maintain them that they have far more political weight than the mainframe. And the mainframe works so invisibly well that everyone only notices the squeaky wheel and sizzle platforms that are barely more than nail polish on the underlying functionality provided by the mainframe.
But what has this rant to do with the "Analysis and Planning" value in the "why" dimension? This: not only does the mainframe offer so much value that any legitimate IT Architecture diagram would be mostly mainframe with tiny bits of the other platforms scattered like ornaments on a tree (like the seasonal reference?), but properly characterizing, understanding, and building on that value has the potential to bring more business value to the organization that is paying for IT like few other cost-effectiveness initiatives could.
And the software with this role gives the needed insights into resource configuration, usage, and future scenarios, therefore playing a role with significant business value, ensuring that the return on investment for the mainframe just keeps going up, regardless of what the IT Architects and other decision makers may decide to do with the minor platforms in the environment.
This is especially important combined with proactively responding to new initiatives - but that's the next (and last) value on this dimension, so I'll save that for the next blog post.
Wednesday, December 5, 2012
Plumbing the Taxonomy: Why? Part D - Cost-Effective Operations
The "KISS" principle ("Keep It Simple, Stupid" or some gentler variation on that) has long been a key principle for effective living and business. It is closely related to keeping things affordable, as simplicity tends to be a good countermeasure against unnecessary expenditures.
In large-scale IT, keeping to these two principles is essential to maintaining the proper cost-benefits balance that keeps IT viable rather than it becoming an upward spiral of price and complexity.
So, this value of the "why" dimension is all about the business benefit of well-run IT. Over the years, many efforts have been made to document and codify how this is done - one of the more successful ones is ITIL - the Information Technology Infrastructure Library. Interestingly, this definitive set of guides that characterize a well-run environment is essentially the depiction of a functioning mainframe environment - in this case, the one at the British Government.
Where the software relevance comes in here is the selection of tools which create a layer of business-enabling simplicity, keeping IT easily manageable and consequently paying for itself. And that's an important business value!
In large-scale IT, keeping to these two principles is essential to maintaining the proper cost-benefits balance that keeps IT viable rather than it becoming an upward spiral of price and complexity.
So, this value of the "why" dimension is all about the business benefit of well-run IT. Over the years, many efforts have been made to document and codify how this is done - one of the more successful ones is ITIL - the Information Technology Infrastructure Library. Interestingly, this definitive set of guides that characterize a well-run environment is essentially the depiction of a functioning mainframe environment - in this case, the one at the British Government.
Where the software relevance comes in here is the selection of tools which create a layer of business-enabling simplicity, keeping IT easily manageable and consequently paying for itself. And that's an important business value!
Thursday, November 29, 2012
Plumbing the Taxonomy: Why? Part C - Security, Integrity and Compliance
During my years working as an employee of provincial and civic government, I discovered the importance of a special kind of incentive: removal and avoidance of pain.
We all know (I hope) that it's inappropriate to bribe government employees to get better or faster results from them - and that getting caught doing so could land everyone involved in jail.
What recent history has shown, however, is that there are many other types of business misbehavior that can land people - CEO's in particular - in jail, or at least get them and their organizations sued and/or sanctioned. And some of those types are also business MIS behavior.
So, if you want to incentivize a government employee - or anyone who works for a large, rule-bound organization (i.e. the kind that's prone to have a mainframe) - rather than giving them something, you want to take something away: negative experiences, consequences and potential for consequences, aka pain.
In the world of MIS (does anyone still use that abbreviation? it makes for some great puns), where some of an organization's most sensitive data and activities take place, having data or processing compromised can trigger significant pain, from regulatory audit findings and related sanctions to legal and criminal trouble for executives. Compromise can include exposure of confidential personal information of customers and citizens, leading to great expense to "make it right" as well.
All of which illustrates the value of ensuring your organization's most sensitive data, processing and business behaviors are provably compliant with relevant regulations, and sufficiently secure that only legitimately authorized parties have appropriate access to it.
Consequently, this is an essential value on the "why?" dimension of solutions used to manage large IT enterprise environments, particularly those that include mainframes.
We all know (I hope) that it's inappropriate to bribe government employees to get better or faster results from them - and that getting caught doing so could land everyone involved in jail.
What recent history has shown, however, is that there are many other types of business misbehavior that can land people - CEO's in particular - in jail, or at least get them and their organizations sued and/or sanctioned. And some of those types are also business MIS behavior.
So, if you want to incentivize a government employee - or anyone who works for a large, rule-bound organization (i.e. the kind that's prone to have a mainframe) - rather than giving them something, you want to take something away: negative experiences, consequences and potential for consequences, aka pain.
In the world of MIS (does anyone still use that abbreviation? it makes for some great puns), where some of an organization's most sensitive data and activities take place, having data or processing compromised can trigger significant pain, from regulatory audit findings and related sanctions to legal and criminal trouble for executives. Compromise can include exposure of confidential personal information of customers and citizens, leading to great expense to "make it right" as well.
All of which illustrates the value of ensuring your organization's most sensitive data, processing and business behaviors are provably compliant with relevant regulations, and sufficiently secure that only legitimately authorized parties have appropriate access to it.
Consequently, this is an essential value on the "why?" dimension of solutions used to manage large IT enterprise environments, particularly those that include mainframes.
Thursday, November 22, 2012
Plumbing the Taxonomy: Why? Part B - Continuity
How quickly can you reboot a bank if it crashes? And how do you access your accounts in the meantime?
What do you do if the air traffic controllers' computers suddenly become non-responsive - can you put the airplanes in a suspended state?
Why is it that we take for granted that the largest, most critical organizations on earth will keep functioning, 7x24, 365 days per year?
Because Continuity is a business mandate that is built into the computers that can be trusted to keep the world economy, and other critical areas, functioning.
And many of the software solutions that keep mainframes running so well have this reason for their existence: to keep the business running even if something bad happens to the mainframe. That can include backup and recovery, real-time fail-over to another mainframe (likely elsewhere in the world in case of natural disaster), and just the ability to see a problem coming and get everything in place to prevent or quickly deal with it.
This value of the "why" dimension is worth the entire existence of some organizations. If a bank suddenly stopped operating for hours, it would take a potentially lethal financial hit. If it stopped for days or weeks, it would likely go out of business. So its mainframe computers must have the necessary solutions for continuity to ensure that the bank doesn't crash. And yet, so few non-mainframe environments have ever done a successful recovery test of their entire production computing configuration - or even the most critical part - often, even in organizations where they have a mainframe that has done such disaster recovery testing and planning.
That's one of the reasons why the mainframe is such an important part of keeping the world economy running, and why Continuity is such an important value of the mainframe.
What do you do if the air traffic controllers' computers suddenly become non-responsive - can you put the airplanes in a suspended state?
Why is it that we take for granted that the largest, most critical organizations on earth will keep functioning, 7x24, 365 days per year?
Because Continuity is a business mandate that is built into the computers that can be trusted to keep the world economy, and other critical areas, functioning.
And many of the software solutions that keep mainframes running so well have this reason for their existence: to keep the business running even if something bad happens to the mainframe. That can include backup and recovery, real-time fail-over to another mainframe (likely elsewhere in the world in case of natural disaster), and just the ability to see a problem coming and get everything in place to prevent or quickly deal with it.
This value of the "why" dimension is worth the entire existence of some organizations. If a bank suddenly stopped operating for hours, it would take a potentially lethal financial hit. If it stopped for days or weeks, it would likely go out of business. So its mainframe computers must have the necessary solutions for continuity to ensure that the bank doesn't crash. And yet, so few non-mainframe environments have ever done a successful recovery test of their entire production computing configuration - or even the most critical part - often, even in organizations where they have a mainframe that has done such disaster recovery testing and planning.
That's one of the reasons why the mainframe is such an important part of keeping the world economy running, and why Continuity is such an important value of the mainframe.
Wednesday, November 7, 2012
Plumbing the Taxonomy: Why? Part A - Business Enablement
Welcome to the second dimension of the taxonomy! And this value is the most basic of reasons for running something on a computer, mainframe or not: to do the work of the business that's paying for it!
To be more specific, this is about the applications that provide specific business deliverables that drive revenue, handle accounting, manage products, and basically act as the core competence of the business that's paying for IT.
This is why computers were invented in the first place: to enable organizations to perform their core business activities in a faster, more reliable, automated manner.
Everything else in the taxonomy (with the possible exception of the last value in this dimension) serves the business indirectly, but this value is what it's all about. Therefore, anything that calls itself an "application" probably includes this value of this dimension.
But - and here's the interesting thing - this is only one of several values in this dimension, so there are other business reasons for computing than just performing core competence processing!
However, if you don't have this one, you definitely have a problem with your IT.
To be more specific, this is about the applications that provide specific business deliverables that drive revenue, handle accounting, manage products, and basically act as the core competence of the business that's paying for IT.
This is why computers were invented in the first place: to enable organizations to perform their core business activities in a faster, more reliable, automated manner.
Everything else in the taxonomy (with the possible exception of the last value in this dimension) serves the business indirectly, but this value is what it's all about. Therefore, anything that calls itself an "application" probably includes this value of this dimension.
But - and here's the interesting thing - this is only one of several values in this dimension, so there are other business reasons for computing than just performing core competence processing!
However, if you don't have this one, you definitely have a problem with your IT.
Tuesday, October 30, 2012
Plumbing the Taxonomy Part 7: Production
As we conclude the "what" dimension of the taxonomy, the topic of this post is about "Production" - the day-to-day running of scheduled, coordinated activities that keep the mainframe and related business running smoothly.
Many of the solutions that are responsible for this value also have an automation aspect - most notably, those which are considered Workload Automation. In those cases, this is the "workload" value as complementary to the "automation" value of such solutions.
The workload includes running all of the "batch" tasks that production applications require. Other words used for "batch" include "offline" and "background".
Your average user never knows or thinks about these things, because they don't talk to them. We're all used to dealing with banking machines, which are online or foreground. But there's a need for additional processing that doesn't require people to intervene - but does have to run regularly.
As an example, when you receive your utility bill in the mail, it was likely created and printed by programs running in batch mode, which pulled up the account information for you and every other customer, turned it into a bill, and sent it to the printer, all without human intervention.
And it is precisely the ability to schedule such things to run regularly without manual involvement that allows these bills to be created and sent out with such regular reliability.
However, it's not just a single step process. Often, there are "jobs" (i.e. a set of programs that are designated to run together in the same sequential order every time) that run first to perform one task - such as get all the billing information for today to be further processed - which are then followed by additional ones that only run if the first ones complete successfully (which they don't always do, for many different reasons).
So workload automation allows for the grouping, scheduling and coordination of many such jobs and applications in a regular, automated manner that only requires human intervention when there's a change or a problem that isn't readily solved by further automation.
Next time, we dig into the "why" dimension.
Subscribe to:
Posts (Atom)