Results tagged “ibm” from ITJOBLOG

Is the mainframe dead?

July 23, 2010 7:31 AM
Is the mainframe dead? No, but it's changing shape. IBM's latest launch is a good example of how traditional mainframe culture is disappearing -- and how the landscape for mainframe skills is changing, too.

IBM's new machine, called the zEnterprise 196, is an update of its System z mainframe. The company, which is calling the unit a "hybrid computer", has married traditional mainframe components along with Power 7 blades, and x86 blades, too. The system, which is also being trumpeted as a "data centre in a box", is designed to support heterogeneous IT operations from a single platform.

Back in the day, a mainframe was a mainframe. Processors designed purely for the mainframe platform were combined with an operating system dedicated to that system. Developers wrote applications in mainframe-centric languages such as COBOL, and the concept of merging different operating systems and hardware platforms into the mainframe was rare, if heard of at all.

For some years now, IBM has been changing that. It has given its mainframe users the chance to run virtualised instances of Linux on its mainframe boxes, opening up the opportunity for many instances of open source applications to run alongside each other. And the zOS operating system supports many modern computing frameworks, such as Java. But IBM still relied heavily on its own processors as the hardware platform for the mainframe and operating system. Conversely, its competition -- who collectively make up a small percentage of the market that IBM dominates -- have mostly switched to commodity Intel CPUs to lower development costs for the hardware.

IBM's decision to mix its traditional home-grown processors along with commodity chips in its new mainframe offering indicates a significant change of direction. The company appears to be acknowledging that the mainframe is increasingly becoming a 'build-out' platform, rather than a traditional 'big iron'-only resource. The introduction of distributed technologies into the mainframe platform shows just how far it has penetrated this traditionally monolithic world. 

IBM has explained that this system is essentially a heterogeneous datacentre in a single hardware platform, with all the associated benefits, such as a smaller physical footprint, a unified management hub, and an integrated set of components.

What will this do to traditional mainframe skills? It simply acknowledges their passing. Mainframe administrators as we used to know them are retiring and their skills are disappearing. The new, modern breed of administrator is increasingly required to cope with a variety of heterogeneous technologies in addition to traditional mainframe system management. The mainframe as we knew it may not yet be dead, but it is certainly being displaced by a newer, more flexible approach to big iron

I attended a round table to discuss the use of open source software in government, with Red Hat, Ingres, Alfresco, and on the government side representatives from the Office of National Statistics and Islington Council.

It is a fascinating topic on several levels - and not just for government. The two big questions: first, what is the rationale for prefering open source; and second, if you are convinced of its desirability how on earth do you get a huge, diversified entity like the UK government to increase its adoption?

There is clearly some kind of disconnect. The government already has a policy which stops short of mandating open source, but does say:

Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.

In other words, given two otherwise equal proposals, open source is favoured - yet in practice we were told that 95% of software in use in the UK government remains proprietary.

So why is that? There are dozens of reasons. It's the available skills, with armies of experts in Microsoft, Oracle, IBM, and so on, compared with only a few willing to specify open source technologies. It's the culture, with countless existing supplier relationships and a well-trodden procurement path with the usual suspects. It's the existing envirnonment: if you start from a point where the servers are Windows, say, and the desktops all have Microsoft Office, it feels more comfortable to continue down that path. It's the lock-in, especially when it comes to things like proprietay SQL extensions and stored procedure languages, that simply do not port easily to new database managers. And it's canny vendors, who go for site licences with the widest possible scope, so that if a small group decides to break the mould and use something different, it looks more like a cost than a saving - because they are already licenced for the proprietary stuff.

These are tough obstacles to overcome. Put another way, the rationale for adoption has to be exceptionally strong to overcome the inertia; and it was here that I found the round table unconvincing. The open source companies gave diverse reasons for the benefits. Lower cost was mentioned frequently. By contrast, John Powell, President and CEO of Alfresco, talked intensely about how the UK was somehow handing over its soul to silicon valley, by not building up local skills in open source software. Someone else said how nice it was that open source software was free so that everyone in an organization could use it; another gently observed that since most open source companies make their money from support agreements that are per user, this is often not the case.

The most persuasive rationale is that open source software tends to support open standards and therefore avoids lock-in. This lowers long-term costs, by ensuring that the customer always has freedom to switch.

The snag with all these arguments is that the proprietary companies can counter them easily. They will reel off all the open standards they support. They will draw graphs showing how much money you save by using their stuff. They will point out that those with skills in their technology can easily market them worldwide. The outcome is that nothing changes.

I don't doubt that leading vendors make excessive profits on software that should be commoditised and cheap, or that vendors follow strategies designed as much to keep us hooked on their stuff, as to advance technology for our benefit. It's a cycle that needs to change.

At the same time, the open source vendors have to recognize - and to be fair, I reckon they often do - that most of us will not switch for ideological reasons. We want to get our work done. The best open source projects, things like the Apache web server (if there is anything like it) succeed on sheer quality and reliability, not merely through being open source.

The tough question: does the open source ecosystem have sufficient resources to deliver that quality, against proprietary vendors with huge profits to pour into research and development? There are plenty of decent open source products; the number that are truly best of breed is more limited. Currently it is the big proprietary vendors that have the advantage.

I left the table with more questions than answers. Should governments introduce more draconian legislation, to counterbalance the industry bias towards the status quo? Will the move towards cloud computing break the pattern? Should legislation be focused on mandating standards support, or even that applications should be proven to work on two different platforms, rather than the matter of open versus closed source? If today's MySQL is tomorrow's Oracle, is there really any difference? Isn't there too much to worry about already, solving problems and delivering successful projects?

If pressed, I would always incline towards the best technical solution, rather than one which ticks boxes, even open source boxes. That said, we are all susceptible to being bamboozled, not even looking at open source alternatives if we already know a proprietary tool or component or platform that will do the job. Even for individual developers, it makes sense to choose the open source solution in cases where other things are equal; and to think twice before building vendor lock-in into the applications we create.

Eclipse Galileo is out now. It is remarkable: 33 projects and 24 million lines of code, according to the press release. Perhaps the two biggest features in this release are support for Mac Cocoa - in order words, proper Mac support - and PHP development tools. All open source, all free.

eclipse.png

Unsurprisingly, Eclipse appears to be the most popular Java development tool, and if you extend that to IDEs based on Eclipse, its dominance is overwhelming. Its obvious rival, Netbeans, has improved greatly in the last few years and may be better for some purposes; but it looks unlikely to catch Eclipse, and the impact of Oracle's impending acquisition of Sun is unknown.

Eclipse has also influenced other development tools, forcing vendors to offer more for free and to improve their extensibility. You can see this effect in Visual Studio, for example, with its Express editions and both technical and licensing enhancements to its extensibility in recent times. Microsoft may say that this would have happened anyway, but I am doubtful. Eclipse changed the game.

Still, there is something that I've always found intriguing about Eclipse, which may be a weakness in its business model (if a free platform can have such a thing). I put this to Executive Director Mike Milinkovich and he responded robustly, which I like because it usually means I've asked a good question.

Eclipse is a a tools platform, not an IDE, and member companies build their own products based on the shared platform. Examples are Adobe with Flex Builder, IBM with Rational Application Developer, Zend with Zend Studio, and Embarcadero with JBuilder. Each of these companies has a dilemma. The more they invest in the shared platform, the more they collectively benefit by getting features that they do not have to build on their own; but the better the shared platform gets, the more difficult it is to differentiate and sell their commercial products. I asked Milinkovich about this tension and he interrupted me:

That's not a tension, that's exactly the way Eclipse is designed to work. That is the Eclipse business model. Our licensing model and our business model are geared around the notion that we're building an open source platform which then people build products on top and differentiate in the marketplace based on what they do on the proprietary side.

Although Milinkovich says it is "not a tension", Embarcadero CEO Wayne Williams complained about this very thing, telling me that IBM is now pulling back from investment in Eclipse and reserving the best new features for its own products - which, whatever the truth of the matter, IBM has every right to do.

An additional factor is the difference between vendors like Google, which has an Eclipse plug-in for App Engine, but is only concerned to promote its platform; and those like Embarcadero whose business is selling tools. Vendors like Google can improve Eclipse without any threat to their business.

Eclipse is wildly popular, but came last in a recent Software Development Platform survey of developer satisfaction by Evans Data. To be fair, all the products won a reasonably good rating, so we should not infer that Eclipse is poor; it is not. I can understand, though, why some member companies may be happy to see Eclipse rated as good, but not too good, giving them space for their Eclipse-based products; and if this is the case, it may limit the extent to which Eclipse is likely to improve.

Current Vacancies from CWJobs

(* Required field)










Preferred format