Dear Bob ... I think your critique of the Gartner approach was spot-on. Your advice to not get distracted and do a good job in the here and now was of your usual insightful quality. Nonetheless, I believe that the dream of putting most of the IT staff out of work is going to come to pass in the working lifetimes of our younger coworkers. The automotive analogy is that ride-along mechanics got run over by engine Dear Bob …I think your critique of the Gartner approach was spot-on. Your advice to not get distracted and do a good job in the here and now was of your usual insightful quality. Nonetheless, I believe that the dream of putting most of the IT staff out of work is going to come to pass in the working lifetimes of our younger coworkers. The automotive analogy is that ride-along mechanics got run over by engineering and manufacturing progress some time ago. You can still hire a mechanic but the only businesses with mechanics on staff have fleets, or use the mechanics to provide a service. While reasons for the changes in IT have to do with systematizing quality practice in a different (softer but harder?) realm of manufacturing, the need, the means and the trends are all there. Come to think of it, software doesn’t wear out, at least in the same way that car parts do, so maybe the IT future is bleaker than I first thought. All the gals and guys in the tools game may not know how to get there, but they know where they’re going. It’s toward selling stuff to business people who want working applications without having to deal with a bunch of on-staff technocrats. Building those tools won’t be easy (although it may be fun), but the progress is observable and non-trivial. Someday the languages we know and love (or hate) will be historical artifacts. Process engineers (whether formally anointed as such or not) will be guided by wizard-like things into cajoling working applications out of software that builds software. Not only that, but those applications will deploy, and work out of the gate, better than the average thing that comes out of today’s projects. Changing the generated applications will take a fraction of the time it now takes to change existing software. Put another way, it’s probably impossible to produce a recipe for running a project of any size – people are too diverse and their behavior is too complex. However, I predict it’s possible to produce a recipe for one (or a small handful of people) to describe and generate quite complex software in times measured in hours or small numbers of days, thus taming the risk and the cost of large software projects for most businesses.Really smart people (like you and me) don’t have to worry, but there are going to be a whole lot fewer people in the game than there are now, and that includes in China, India and everyplace else. Maybe someday there’ll be the software equivalent of NASCAR, where people will program for the thrill of the crowd. – Punditing for funDear Punditing …Gee – now I’m depressed! I’ll say with certainty that I have no idea. The core question, I think, is whether enterprise applications will evolve to the point where they’re shrink-wrapped or nearly so. If they can, then the Gartnerized future will happen. If they can’t, then IT will continue to have a role to play for quite awhile.Or, it’s possible, I suppose, that your vision of the very smart application generator could happen at some point. I’m not sure how possible it will be to perfect information engineering to the point that the software can translate “requirements” into a fully normalized data design, coherent object model or what have you, at least in the foreseeable future, but it’s at least imaginable. If nothing else, I can imagine a bunch of open source object models centered around some typical business domains, such as “customer,” “distributors,” and so on. I don’t know how useful they’ll be – Home Depot’s definition of “customer” is very different from EDS’s definition of customer – but perhaps the list of alternatives is finite and short enough that something useful could come of it.Then there’s the user interface – a matter of aesthetics, not easily eplained to software. There are going to be responsibilities that shift to the business either way, and workflow automation design is likely to be one of them, just as a lot of report design shifted to business departments with the onset of report-writing, data mining, and business intelligence tools (and by the way – am I the only one who suspects there’s more name-changing than substantive differences among these three software categories?).I’m skeptical, though, that businesses are going to want to reconfigure their workflows with any frequency. After all, every time you do you’ll be retraining end-users so they know how it’s all supposed to work today.It’s that change control discipline all of us in IT know we need, even if we don’t like it. Nor is that all, because business process design is an engineering discipline. So whether it’s the next evolutionary step for IT business analysts or a new role in business departments, it’s more than just dragging and dropping lines and boxes in Visio.As for the NASCAR thing … anything is possible. There are, after all, those who consider chess to be a spectator sport.– Bob ——– Technology Industry