KISS, a potentially insulting command, carries risk. Why? First, because hearing “Keep It Simple Stupid” often makes us fixate on the word, “Stupid.” Second, because life's complexity is escalating. Third, because the costs of simplifying sometimes outweigh living with complexity. Technology provides a vivid example. Virtualization, for many, helps drive efficiencies in resource use. But it also yields complexity: added needs for management, security, and licensing. Not all bad, just not “simple.”
Data and application proliferation, global financial hardship, increased regulations, mounting piracy of physical and IT assets—in combination or even separately—point to added complexity, which can drive higher costs and a greater sense of frustration and vulnerability.
IT Simplification...a major quest and need. Make fewer things do more work at less cost. That's an appealing requirement or destination. But it is not one that is easily achievable. The goals of simplification are not always clear. Prioritizing simplification often proves challenging. How many times do we say, “I went for ‘simple’ and got very little in return?” For example, there are some who wonder if going from Command Line Interface (CLI) to Graphical User Interface (GUI) ultimately delivers the best payback. Or if reducing choices of UNIX® operating systems provides a superior user experience. Simplification can be a matter of perspective.
In the ideal World of IT, basic methods for the most cost-effective execution of workloads dominate design. Systems Administrators (SAs), their managers, the IT architects, and apps developers would speak the same language about needs, intersection, collaboration, and desired outcomes. They would also reduce the number of devices, the instructions governing their use, and the rules for device connectivity. The end result: well, some could say the mainframe is the paradigm for simplification. And, many others would shake their heads sideways. What’s the truth here? Is there an inherent contradiction to Simplification?
IBM's reputation for server excellence, from small capacity to immense, began with the System/360™ mainframe family. They were fed and cared for by a handful of highly focused people in white coats, exercising their skills in raised floor, glass-enclosed rooms with regulated climates. Hmmm...somehow that picture does not convey simplicity. In fact, mainframes were (essentially) the only architectures capable of handling large-scale, mission-critical tasks...but still required special language, skills, tools and rules. Simplicity was not the primary design center here: automating and performing large transactions and calculations were the super-ordinate goals; complexity was subservient to need.
It's now 2009. The server architectures have shrunk to a few, along with just a handful of mainstream operating systems: Linux®, UNIX, Microsoft® Windows® and mainframe. Does this equal simplification? If it does, is the IT user community better off than when UNIX had many personalities, OS/360 derivatives mutated, and there was no Linux as a potential unification point? Philosophical queries, pretty much, to this point.
So let's get down to the basics...
- What is your IT organizations first goal for simplification; what are the first measures of success?
- Who is the force behind simplification, and what does he/she expect to see by way of payback?
- What in your IT asset base is untouchable, because “simplifying it” might prove too disruptive?
- Where does your infrastructure today seem most complex and how did “it” get that way?
- How much could you save if you simplified, for example, just your servers (vs apps, networking, processes and storage)?
- Is simplification, like “continuous improvement,” a moving target?
- If you could shrink 3,300 distributed servers to 33 mainframes running Linux, would you consider simplification a “mission accomplished?”
- When might acquiring a mainframe or committing more workloads to ones you have be an act of simplification?
- In IT, is anything really simple any more and how much complexity will you tolerate from a cost/value standpoint?
- When did you last consider data management, apps delivery and security preservation “simple?” Do you measure that consideration in days, months, or years?
No simple answers, we suspect. Except, and a big “except,” we are completing a multi-year $100,000,000 investment solely in mainframe simplification; everything from GUI, to I/O, to programming, to script customization, to automated business-goal-driven IT resource allocation. Simplification, to IBM System z® means a superior user experience from the standpoint of workload execution, business continuity, ownership costs, and skill development. We chose this path to make a clear statement: we will always make our mainframes simpler to understand, acquire, use and maintain, to satisfy sharper market requirements for “faster, better, cheaper.”
Mainframes are not for beginners. That could be viewed, arguably, as a self-condemning statement, especially when made by a System z marketer or salesperson. However, there’s a coaching from Business Development that applies to mainframe simplification assessment: “Go Slow to Go Fast.” Translated: once the mainframe routines are mastered and protocols for effective service delivery become habit, mainframes may be the simplest of all systems today.
Consider this: Bank of China Core Banking Benchmark revealed IBM System z9® mainframes, working together, generating 9,400 transactions per second, while servicing 380 million customer accounts and approximately 1.3 billion account records. Those results exceed by four times what HP claims in its Temenos Core Banking benchmark. And, System z9 mainframes doing that work required roughly ¼ of the energy to execute. What does “Simplification” have to do with these comparisons?
Simple! (Sorry.) What a benchmark like this shows is that once a mainframe is “mastered,” it can execute more work at lower transactional costs than alternatives. So it would seem simplification is both process and result. To a System z novice, operating “the machine” may seem daunting. To the more than 50,000 students at 450+ universities worldwide who have recently completed mainframe curricula, operating a mainframe just got simpler.
To the mainframe owner who just adds specialty engines to the inside of an existing footprint to gain capacity and avoid more sprawl, delivering business enablement just got simpler. To the CxO concerned about sprawl and energy/space conservation, buying a mainframe makes IT’s value-add simpler. To the Line of Business executive using customized scripts from IT to retain customers, mainframes just make life simpler. So, the next time someone tells you to KISS, ask what he/she means. If they seriously believe Simplification is “easy,” remind them that getting to “simple” challenges experts. It is the destination that counts.
Want more proof? Talk, now, with a System z specialist. Ask how the complexity and expense of “distributed sprawl” can be cost-effectively overcome. Let us demonstrate, with validated facts, how System z security simplifies the protection of assets, a corporate urgency. Press that IBM System z specialist and client rep on the automation (simplification) of routines that enable businesses to benefit from System z’s right-sizing of IT resources to business-critical workloads.
Reality: the staggering complexity of our planet in 2009 probably means “simplification” is both a goal and relative term. System z, while great, requires learning BEFORE its incredible simplification potential gets realized by the user community. But, as we said in the beginning of this edition: “Go slow to go fast.” Think 9,445 transactions per second without a miss. Pretty simple, when viewed that way.
For more information, visit the System z home page.