Journal TopShelf's Journal: How to bring mainframers into the 21st century? 8
I've recently been tasked with leading the integration effort for a large systems implementation here at work, and am facing a challenge more daunting than any mere technical obstacle; how does one best get hardcore old-school programmers to embrace a new way of integrating our applications?
We're replacing a large, homegrown COBOL application on a mainframe with a more modular, Java-based ERP on a midrange platform. The kicker is that we need to replace over 100 interface points between other internal systems and the legacy app, and the direction we're headed in is to leverage a GUI-based middleware product to accomplish that task, and take initial steps towards establishing a more loosely coupled, flexible systems architecture. I'm convinced this is technically feasible and will reap many benefits going forward (particularly as other major projects come along), but our developers have a hard time letting go of their point-to-point, custom programs with lots of embedded information directing processing for specific customers or situations.
This group is throwing every conceivable objection to the middleware approach, and most of them are failing to make much headway as we develop some pilot projects to build expertise, despite having had ample training and the services of a consultant to provide mentorship as they work their way up the learning curve.
The bottom line is that they are resisting this new method by any means available: submitting lots of trouble tickets for minor issues, not digging through the documentation and throwing up their hands in futility, etc. Has anybody else here in the
You are taking their livelyhood (Score:2)
1.) Learn the new tech and adapt (which they've already refused)
2.) Try to stop the new tech from taking over as hard as you can.
If you can get some courses in Java for these people... have them understand OOP and embrace it, then you are most of the way there. Of course, this means having them unlearn years upon years of COBOL development and thinking, an
BTDT (Score:2)
Might I suggest... (Score:2)
I wish I had some actual good advice, but unfortuantely I have a feeling that each and everyone of the lot believes that not only are they justified in their behavior, but that its their duty to stop you from finishing such a henious mistake. Its like dealign with a self-righteous teenager.
Re: (Score:2)
expanding on the first post (Score:1)
* Maybe they're worried the project is making things more complicated than it needs to be. Java projects can get awfully "enterprisey" [worsethanfailure.com].
* Maybe they're worried that the endeavor might fail, and be cancelled leaving them looking bad.
* Maybe they figure this is the beginning of the end for them. No one likes to be put out of a job, b
I don't have experience in this (Score:2)
I expect that what your staff don't see is how the whole change benefits them. Obviously, what they will gain from it is a whole new tool set. But they need to decide that for themselves - which is where you come in. You are the person who
Re: (Score:2)
End result, fewer programmers required. The question they need to ask themselves, is do they want to be part of that future, or no
Use Git, maybe? (Score:2)
A distributed commit system would deal with a lot of your problems, it seems to me; tickets for minor issues is so dehibilitating precisely because your commit system is monolithic. Also, git would surely encourage (read: force) a distributed computing model in peoples' heads.