Todd A. Martin, IT Specialist Consulting

If you always do what you've always done, you'll always get what you always got. Change provides the means to conquer competition.
Home     Employment History     Contact Us     Technical Stories     Sample Client Application     Todd's Biography     Useful Technology Sites      
Story No. 1     Story No. 2      
  Technical Story


No Mad Dinosaurs in this one......just Blue and Red.

 

        vs.    

 

 


 
While the Client/Server migration project was winding down for the project team at this same company in Canada (see Story No.1 ); the next steps included training and handing off the maintenance and support of the new technologies to Support staff. This included the completion of documentation and cross training 1st and 2nd tier support personnel.
 
With my instructor background I played a large part in handing off the new technologies to Support staff.
This was very rewarding since I was viewed as the subject matter expert (SME) for most facets of the newly implemented Client/Server/Middleware technologies. 
 
For the next endeavor, we began to plan and perform P.O.C. (Proof Of Concept) tasks on implementing Microsoft's System Management Server (SMS Version 1.1) and additional Microsoft WinTel (Microsoft Windows Intel) Servers for the migration of file, print. and application services away from the existing Novell Servers.
At this time, we were also upgrading the Corporate Desktop image and Operating System from Microsoft Windows 3.1 / DOS 6.22 to Microsoft Windows NT 4.0.
Discussions had been ongoing surrounding a migration to Microsoft NT 3.51  or NT 4.0 for some time; however, the company had just gone through a major "right sizing", early retirement, and/or "other forms of attrition" initiatives, and resources were now scarce.
 
The first task at hand quickly became whether to keep a Novell Netware client on the desktop image (which was also compatible with Microsoft Servers) or to change the network client to Microsoft's native client.
 
A new phrase was soon born "Red good, Blue bad".
 
What this meant was that the Novell shop personnel were hugely opposed to migrating from Novell to Microsoft. This is why the meetings to discuss keeping the Novell vs. Microsoft client were always long and heated.
 
With lab testing the teams soon discovered the real reason why the Novell Network Group wished to keep the Novell Netware client. It was not a compatibility matter nor an performance efficiency matter that was the real motivation for examining the two different clients. The real motivation for keeping the Novell Netware client was because they required it to run and manage the remaining Novell Netware environment.
 
A compromise was reached that allowed the Novell personnel to uninstall the Microsoft client from the desktop image and install the Novell Netware client. In other words they were granted local administrator rights on the desktop to do so.
 
Security became a real "issue".
Management was brought into the loop for sponsorship of the newly locked down environment. Where necessary Management approval was required for elevated rights on the workstation.
This Security requirement also meant that the "build" and deployment of new application and/or software for the desktop was to be single sourced through the Desktop Engineering Team and distributed with the new ESD (Electronic Software Ditribution) software; namely Systems Management Server (SMS).
 
During the project, the resource pool was ramped up with approximately 12 Contracted Packagers in a very tightly spaced Development Lab as well as many SME's (Subject Matter Experts) that reported to a single Project Manager.
 
Coordination was key and communication amongst all Team Members was imperative.
 
Working closely with the Application Developers was really interesting.
There were many Application Development Teams dedicated to each of their application streams.
Power Builder,  Visual Basic, and Oracle Forms code were abundant. The source needed to be modified and remodified (especially when server names were hard coded in their applications).
The various Teams were so entrenched with their own applications that the "non-standard" devleopment and compilation of the applications began to show up when we (the Desktop Engineering Team) brought them into the Test Lab to test their applications in the Client/Server/Middleware Desktop environment.
 
We soon began to purposely and simultaneously book these application teams in the Test Lab and sit them next to each other to establish a rapport. This quickly paid off with Team communication and more common and standard approaches to their applications. This greatly helped with the integration of these applications on a single desktop image. It also helped with the installation packaging of software and applications.
 
The desktop was the point where all technologies converged and had to co-exist.
 
 
. Still writing ......... 
 
 
 
 This page was last modified on Wednesday, December 10, 2008 12:46:26 PM