This past weekend I was in Boulder, and the weather in Colorado was getting warmer. Not by Southern California standards, of course, but I did pull the dust cover off the car and took it for a quick run across the front ranges, and the picture above is of me framed against the Colorado Rockies – with views of the front ranges as well as of the snow-capped great “continental” divide that rises behind them.
When I moved to Boulder, my initial preference was for a home high in the front ranges and looking down on the plains as they stretched to the horizon. But battling winter conditions and driving up treacherous back-roads quickly highlighted the value of living on the plains and looking up at the mountains instead. And truthfully, the views I now enjoy of the mountains are a lot better than anything I had before.
I came to the US in the late ‘80s, and joined Tandem Computers. It was 1988 and the company had just celebrated its Billion Dollar Year. The marquee tents had been taken away and the entertainment was long gone – but the talk of Jimmy’s big celebration bash punctuated every conversation. It was an innovative company to be working for, and the demand for computers that didn’t fail remained insatiable.
I was a program manager – one of only a handful at the time. The role of the program manager was still being defined, but essentially each program manager was responsible for a major project spread across multiple development organizations. To get these programs completed called for large doses of patience, as program managers tried their best to cajole development managers into releasing resources. At the time, program managers were given no authority. Having responsibility and accountability, but with no authority, made for “exciting times” as Jimmy often reminded us.
In the film “A Few Good Men” it was Jack Nicholson’s character who responded to the questioning by Tom Cruise’s character with “you can’t handle the truth!” And sometimes in IT, it’s difficult to handle “home truths.” Even for a company as innovative as Tandem Computers, code was developed, tested and released the way it has always been done – even changing program priorities didn’t seem to help.
And a “great divide” appeared between the business and development, and the company’s executives became frustrated over slipping schedules. And no matter how many re-prioritizations of programs Tandem Computers executives performed, the divide could not be bridged. A good friend of mine Graeme Philipson, a founder of Strategic Publishing Group (Australia) that was later acquired by the Gartner Group, recently emailed me to say “I am convinced the ‘great divide’ will never be bridged. Its continued existence is one of the facts of life. Our job is to constantly confront it and minimize its adverse consequences.”
There was an exchange recently among participants in the NonStop Group on the Connect community web site, under the heading “Finance crisis as a chance!” where questions about coding and programming languages were raised. This thread started with asking whether the current financial crises would give many within IT a chance to “learn new things on your HP NonStop … and perhaps it is the best time to invest?” And as I re-read the thread I couldn’t help thinking about how much of our desire to “have another go at it” has it’s roots in better aligning what we do within IT with the goals of our business.
Do we keep training COBOL programmers to maintain the legacy COBOL applications we have? Do we hire more Java and C / C++ programmers and begin re-writing? Sam Ayres, the Chair of the Advocacy Steering Committee for the Connect user group, noted that “a complete system rewrite is typically out of the question in the present economic climate. ‘Embrace and extend’ or ‘encapsulate and rewrite’ might be better approaches; i.e. don't throw away that legacy code, instead integrate it and extend it with the newer technologies.”
Is writing more code however, part of the solution or simply further exacerbating the problem? If on the day we go live with any new application it becomes legacy, as one analysts suggested years ago, are we simply adding more fuel to the fire? After all, at the heart of any exchange over programming languages, and what should be done with the investments we have in our legacy applications, is our own belief that there are better ways to align business goals with our IT investments.
Can we ever achieve alignment between business and IT? Can we bridge the great divide, and can we develop the “agility” our business presumes we will attain once we are aligned. Specifically, does it make sense to even be considering adding more code into the mix, no matter what language we choose, if it only widens the great divide even further. Must our answers always include more code development?
One of the more innovative companies I have talked to recently has been the UK firm Erudine: http://www.erudine.com/ They have brought to market a “Behavior Engine” with the ability to duplicate business logic – not by cloning code, but by cloning the logic and (optionally) modifying it’s behavior. According to Erudine, the Behavior Engine “solves the issue of mental modeling by automating the capture and conflict resolution that would normally be done by humans. Effectively the system is being ‘taught’ the requirements in the same way a child learns.”
“It’s a change in process – teaching, not programming!” they suggest. One of the most-debated topics across the NonStop community is about new applications becoming available on NonStop. From the very simple demonstration I sat through – with a tool like the Erudine Behavior Engine, it may not be a problem. No coding, as we know it today, would be involved at all. At its simplest, the NonStop could be taught new applications.
According to Moore Ewing of HP NonStop, who has been looking at the product, “This starts as a modeling exercise where you start from an input (case data) then define a series of steps as nodes in a network by which you add information from other sources, do calculations, make decisions based on the data about what to do next until you have a result. This is business logic expert’s stuff not IT stuff. It is very close to specifying requirements.”
What is required to achieve the ability to “teach?” According to Erudine it’s “the ability to describe real world concepts; resolve conflicts (as in, ‘but earlier you said’); and rapid execution of (the) knowledge learned!” While I can only understand a little of what it can provide, what I found interesting was that the HP NonStop EMEA were talking with these folks, and had tested the behavior engine for use in bringing solutions to NonStop.
Erudine’s work with HP is an example of a regional cooperative effort being pursued by HP EMEA, and it may have a serious impact on the number of applications available on NonStop. It may even ease the burden of maintenance of existing applications. At the very least, it could improve the agility of IT in terms of being able to modify the behavior of an application that needs urgent change due to new government regulations or even basic M&A activities.
In the exchange among the NonStop Group on the Connect community web site, Sam Ayers was to add later “I don't believe those legacy applications are going away (but even if they do, we must reverse-engineer them, embrace and extend them, encapsulate and rewrite them!)” But perhaps, not so fast! Do we really have to continue thinking about this in programming terms
The truth may be that we need to move beyond our current thinking. Perhaps the great divide between IT and business will never be bridged as has been suggested, but then again, maybe it doesn’t have to be. Could we be missing the opportunity to simply step around it and walk in lock-step with our business leaders? Rather than playing catch up, or being better aligned, how about being synchronized with our business?
The end of programming is not likely to happen in the near term, but the truth is that we cannot continue writing code and expect our business not to lose opportunities. And again I will ask the question of the Erudine Behavior Engine: Game-changing? Innovative? Cool? While this product has developed a solid list of references it’s take-up among the NonStop community is yet to be tested but yes, after a few days looking into the product, it could become a very “cool” product.
Getting our computers to learn certainly appears to be a step in the right direction and definitely a step that could go a long way “minimizing (the great divides) adverse consequences.” After all, when it comes to us “learning new things on your HP NonStop” perhaps we should be letting HP NonStop learn some new things as well!