Electric Guitars and Updating Vintage Development Environments
Wes Simonds 120000EFD6 email@example.com | | Tags:  x86 fender enterprise utilization gibson testing les software z low paul itergo capabilities ibm cost development system stratocaster modernization
0 Comments | 6,993 Visits
This week, I wanted to take a look at enterprise modernization capabilities and efforts in the context of software development. So, in the tradition of this blog, I'm going to begin by discussing a completely different area: electric guitars.
The electric guitar industry is one in which conservative design has almost completely trumped any attempt at modernization for the last half century. In 1954, there were two major companies that made electric guitars: Gibson, best known for the Les Paul model, and Fender, best known for the Stratocaster model.
Here we are in 2011, and none of that has changed. Why?
The basic problem is that guitarists are typically less interested in innovation and more interested in tradition -- they want a guitar with vintage feel and tone that, in a perfect world, also looks intensely vintage. They want it so much that today, there are aftermarket services available to ‘relic’ a guitar: make it look older and shabbier by attacking it with a razor blade, pouring acid on it, leaving it out in the sun for hours, etc.
I am not making this up.
You should also know that the priciest electric guitar you can buy today is a 1959 Les Paul Standard with a sunburst finish -- currently valued, even in this economy, somewhere north of a quarter million dollars.
So it's no coincidence that modern luthiers, well aware of that situation, have responded by creating new guitars that try to recreate, with many improvements, the famous 1959 Les Paul Standard mojo. Such guitars are a sort of synthesis of the best of the old and the best of the new -- and a clever way to get some sort of traction in a super-challenging market.
Balance innovation and convention and get higher business agility
This, of course, brings us to the point of this blog entry. Enterprise developers, particularly those working in mainframe environments, often face a similar conundrum as modern luthiers…and IBM is helping them solve it in a similarly clever way.
A recent announcement from IBM on the subject of business agility , for instance, included several elements pertinent to this theme of blending-old-and-new-to-achieve-a-better-outcome.
One that stood out to me was this: IBM Software is giving organizations a great new way to test new System z® mainframe applications, one that preserves and even extends the roots of the traditional mainframe value proposition.
This, as it turns out, is really important. Mainframe applications and the services they drive are right at the heart of many leading industries -- banking in particular comes to mind -- and are thus no place for compromise or risk. Furthermore, many organizations have made unusually deep investments in mainframe applications; this investment creates an unusually conservative outlook and a reluctance, even beyond the usual reluctance, to rip-and-replace with something new.
Even so, newness is, to at least some degree, what today's demanding market requires -- the innovation that distinguishes a company from its many competitors. It's also what business agility is all about. What is business agility, after all, but the ability to change, quickly and effectively, in parallel with new strategies or new challenges?
Test your System z applications on commodity x86 hardware
And that, in sum, is just what the new IBM Software offering -- IBM Rational® Developer for System z Unit Test -- can help bring to mainframe developers. Specifically, this technology (which is part of the IBM Rational Developer for System z family gives developers the power to develop for System z more quickly, more easily and at lower cost -- all of which contribute directly to higher agility.
When I talked to David Myers, Software Product Manager for Rational Enterprise Modernization and Compilers, his case for this new offering struck me as a strong one.
‘After decades of investment in green-screen mainframe development and tools, many organizations are looking for a new -- but not too new -- approach,’ he said. ’We're giving it to them by modernizing the tools and processes they need to become more productive and spur collaboration.’
The way IBM's solution works, in essence, is to create new test platforms not on the System z itself, but on everyday x86 boxes. These serve as isolated, controllable environments in which it's possible to change certain variables, for testing purposes, without the complexity or delay that would've been required to coordinate changes with multiple teams on a System z proper for a development prototype.
‘A lot of developers want to upgrade, for instance, at the middleware level to take advantage of new capabilities and simplify development,’ said Myers. ‘But typical organizations have long upgrade timelines – one customer upgrade cycle involves a 14-month process – which could drag the whole project off the rails or require developers to utilize older frameworks which take more coding time to meet deadlines. So, using our solution, they can create that middleware environment on a separate piece of the infrastructure that's off in a corner early in the cycle, as opposed to the centralized environment, to work on applications concurrently to when the official upgrade occurs. They can be prepared to take advantage of new functionality on day one.’
It's all good
The benefits of such an approach are clear; the drawbacks, invisible. Consider:
Faster build cycles. By increasing the number of test environments, developers can test software more quickly, release it more quickly into production and start receiving value from it more quickly.
Lower costs. By offloading certain testing functions to x86 hardware, IBM has essentially made it less expensive to develop for the mainframe -- getting more accomplished, yet without spending more money on any new hardware.
Higher System z business value. Because the System z proper allocates fewer resources to testing, it can dedicate more resources to higher-priority tasks -- like revenue-generating production services.
Smarter utilization of commodity platforms. The average hardware utilization of x86 boxes is not so great -- averaging well under 15 percent in most cases. Instead of wasting processing cycles and power on nothing useful a full 85 percent of the time, these boxes can help with something very useful indeed: testing new applications prior to roll out, to ensure they're as complete and bug-free as they can be.
It seems to me that these last two benefits define really neatly what IBM often has in mind when it talks about ‘smarter computing,’ too -- the idea that instead of buying more of something, you get a smarter use of what you already have.
Myers agrees, ‘Using x86 hardware when possible for testing basically creates more value at low to no cost. And limited availability on the System z can also be dealt with really effectively that way; if the z is constrained for resources at peak times, you can now move testing jobs to x86, instead of asking the testing team to take a whole day off because of the limitations of their test environment.’
Given these strengths, it seems like IBM clients who develop for the mainframe would be lining up to try the new approach -- and the ones that do would stand to rake in the benefits.
Such, in fact, is the case for ITERGO, a major insurance provider with offices in more than 30 countries. This organization was interested in developing System z applications in COBOL -- among the oldest of all programming languages -- yet doing so in a modern, GUI-based environment suited to the expectations of the new generation of developers.
Toward that end, ITERGO turned to Rational Developer for System z. And today more than 200 developers there use the IBM solution, leading to a substantial increase in developer productivity and more business value from System z-hosted services.
What's your strategy for enterprise modernization?
Look into IBM Software capabilities for Enterprise Modernization
Learn how multiplatform development enables improved business agility
Read the Invisible Thread blog about IBM Rational software
About the author
Guest blogger Wes Simonds worked in IT for seven years before becoming a technology writer on topics including virtualization, cloud computing and service management. He lives in sunny Austin, Texas and believes Mexican food should always be served with queso.