There are a couple of browser tabs I’ve had open for at least a week now and they’ve been making me think and I think they’re related but I still don’t have a synthesis. The first is Bill de hÓra’s Matchstick Men, which says a bunch of smart things about WS-* and REST, but that’s not what resonates, it’s this: Critically the upkeep and maintenance of legacy systems has come to dominate business software spending. Most large enterprise IT divisions now have the equivalent of a pensions fund crisis, except that all the money is being spent on old systems instead of old people. The second is Nicholas Carr’s Citi whacks IT, from begins: In yet another sign of the vast amount of waste inherent in big-company IT operations....
Clearly these two pieces are related, and I may not have a synthesis but I do have take-aways. First, Citi’s scope to slash is limited if, as Bill suggests, most of their spending is based on “supported living” for legacy apps. Sure, they can stack apps on fewer boxes via virtualization, but it’s not the boxes that cost the big bucks, these days.
Second, Citi’s stated strategy of “standardizing how the company develops, deploys and runs applications” seems to me like a recipe for stagnation and bureaucracy. Such a strategy would have led to fight-back in the Eighties against the PC and in the Nineties against the Web; any decent business strategy has to leave enough wiggle room for the discovery of its successor.
But the real take-away is this, and it’s something that worries me more and more. I’m convinced that, increasingly, the proportion of enterprise software development based on dynamic languages and AMP technologies and Rails and rapid-iteration continuous-beta “Web 2.0” thinking will increase for the foreseeable future. But that doesn’t mean that Java or .NET or even COBOL are going away, and the brutal truth is that we don’t really don’t have anything like industry consensus on the best practices for integrating Rails and PHP and Java EE and .NET/SQLServer and Cobol/IMS and Ada and all the other weird old shit that’s out there doing boring vital business functions.
Me, I think the best bet is something REST-flavored, but we’re kinda short of tooling and best practices and experience. I think this problem is urgent.
Contributions
Comment feed for ongoing:
From: Janne (Apr 22 2007, at 17:51)
But this really isn't a new problem, is it? There was exactly the same grumbles about most of the resources going to maintenance of older systems in the 1980's. I was working as a programmer for a large industrial corporation in the late 80's, before deciding that university might be a good idea, and at that point the place had a mix of late-model VAXen, PDP-11s and, still, a couple of IBM 360 running some legacy applications. I've since heard that the IBM's have been decommissioned, as have most (but not all) of the PDP's, but the VAX machines are still up and running.
If your and your compatriots' rosy ideas about online apps come to fruition, then no doubt will we have dire polemics about how so much of the IT spending is sucked up into the black hole of legacy offline PC applications.
[link]
From: Martin Probst (Apr 22 2007, at 23:57)
Also interesting is the question of maintenance over time for "dynamic languages". I don't quite know about Ruby, but in PHP, dynamic not only means it's interpreted, but also that the language specification (which doesn't exist as such) changes all the time in incompatible ways. I.e., to run a PHP 5.1.4 application on PHP 5.2 you will need to port and debug it, not only copy the files over. This is going to be one huge nightmare or all companies running PHP, sooner or later.
Python seems to be better in that regard, with the long maintenance of the branches.
[link]
From: Anton McConville (Apr 23 2007, at 06:15)
While REST services ( and in general programmatic access to shared data ) can help, I think a lot of it boils down to motivation to (re)use the interfaces - both in identifying opportunities for reuse, striving to build new effective services, and in believing it is the wisest thing to do. Learn to extend rather than re-write.
It seems really hard for us to not want to do our own thing - at least that's what I've seen in my career - not just in the company I work for but also in those we partner with. It results in rewrites of existing solutions. Some of it could be competitive, it might be argued - but I think in general the competitions should be higher up the stack.
Here's a simplistic example: I use Meebo, Netvibes and Extjs - they're all amazing and I don't think I can fault their effectiveness in development ( or their motivation, really :). One observation is that all three called on the talents of their world users to fuel their internationalization translations. Wouldn't it be cool if the translators of the world pooled resources to make Babelfish or similar sing like a lark, so we could all REST on that?
[link]
From: Patrick Mueller (Apr 23 2007, at 08:12)
Right on baby! REST (or other 'web service'-y) interfaces are one way to bridge the chasm. But that's really too heavy-weight for some of the interfacing you'd like to do. Recently blogged about the issues regarding programming language library interop here: http://tinyurl.com/2rzf2c . Time for us language geeks to start seriously looking at this.
[link]
From: John Cowan (Apr 23 2007, at 09:15)
"Why do programmers reinvent wheels? There are many reasons, reaching all the way from the narrowly technical to the psychology of programmers and the economics of the software production system. The damage from the endemic waste of programming time reaches all these levels as well."
That's the beginning of a good article by Eric Raymond (the "before" version) on the prevalence of non-reuse. It's at http://www.catb.org/~esr/writings/taoup/html/ch16s01.html .
[link]
From: a programmer (Apr 23 2007, at 13:12)
Citigroup's IT is known even within the banking industry as exceptionally bureaucratic and inefficient. It's state says more about the future of huge merged enterprises in information-heavy industries than about the future of IT.
[link]
From: Doug Kretzmann (Apr 23 2007, at 15:56)
Agree with Janne - this problem has been around since, well, roughly the first upgrade after business started using programmable computers..
I've been making a living since 1995 supporting (inter alia) a message broker that uses both an API and a RPC format to allow the old to talk to the new. There are Cobol applications out there with no source code, running businesses, that now have WS interfaces as well, via the broker. This of course is WS-* (death star) not REST, since enterprises like WS-*. What that means is a lot more enterprise applications that depend on WS-* web services, so the web service becomes the new legacy code.
The issue is not so much a lack of solutions, as an overabundance of them. DCOM, CORBA, message brokers, WS-*, any number of proprietary EAI solutions, EDI (now over the web instead of proprietary networks, but still a fine mess - pick your standard, UN or US), ebXML, and I could go on but I have a headache. Best practices forsooth.
As http://netzooid.com/blog/ observes,
"Whether you choose WS-* or a RESTful solution, you’re still going to have to worry about performance, scalability, reliability, transactions, etc."
and that WSDL is indeed a kind of 'killer app' for WS-*.
We'll go on as we always have, plugging patching and gluecoding it all together. I had high hopes for WS-* frankly, so it's depressing to see heading ever deeper into a morass of overspecified 'standards'.
[link]