On May 22, 1990, Microsoft released Windows 3.0 and I purchased a copy as soon as it was available and installed it on my 386/20 PC. I was amazed. It could do everything that my SUN Sparc Station could do and it could do it faster, easier and in color. I started to really wonder about the wisdom of our choice at Ford Aerospace. Up until that time, Microsoft Windows had been little better than a proof of concept for a Graphical User Interface (GUI).Windows 2.0 was based on the Intel 80286 chip that had a limited address space and no virtual memory. As a result, Windows 2.0 was a bloated pig and could only support programs of limited size. The Intel 80386 chip was a game changer. It could support large programs and large spreadsheets and it had virtual memory so it could provide much better support for running multiple programs at the same time. Microsoft had been working closely with IBM to migrate towards OS/2 as their desktop and server operating system, but when Microsoft figured out how to make Windows use virtual memory, Windows became much more viable and Microsoft decided to push ahead with version 3.0. This caused a major riff between Microsoft and IBM and eventually resulted in a divorce. Windows 3.0 was a major hit and corporations started migrating towards it in large numbers.
This was not lost on David Vaskevitch, a brilliant thinker at Microsoft who had been a VSI customer of mine when he worked at 3Com. David had convinced Bill Gates that Microsoft needed to have its own consulting team to support corporate adoption of Microsoft technology and he had positioned himself as a director of this group. He recruited Bob McDowell from Ernst and Young in San Francisco as the VP of Microsoft Consulting Services and he wanted me as director of a core team of consultants. And he made me an offer I couldn’t refuse. On August 1, 1990, I put my house in San Jose on the market and uprooted my family to move from the sunshine of Silicon Valley to the rain and clouds of Redmond. We purchased a large house on Education Hill, close to the schools for each of our children and I settled into a new career as a Microsoft Consultant.
While I was still living in San Jose, David asked me to fly to Redmond for an important meeting with some senior executives from Anderson Consulting. They were trying to decide what operating system to standardize on for their server platforms and wanted to determine whether OS/2 would meet their needs. This represented a large sale, so Bill Gates joined the meeting. I sat next to him for lunch and listened closely as he walked a very fine line between OS/2 and the not yet released Windows NT. As I remember it, he never made a clear recommendation but certainly got them interested in NT which, unfortunately, was not released until 1993.
Another presentation during that meeting was made by Nevit Basker who demonstrated “Thunder,” the code name for the soon-to-be-released Visual Basic. Her presentation was quite relevant because until then, all Windows applications had to be built using C or C++ and programmers with these skills were not in great supply. In addition, it took considerable time and work to build a C++ application. Visual Basic was Microsoft’s answer to this problem. It allowed programmers with more limited skill sets to create useful Windows applications.
When I arrived for work at Microsoft, one of my first assignments was to learn Visual Basic. I dove right in and learned quickly that it had no capability for getting data from a database. Fortunately the folks on the SQL Server team had noticed this hole as well and plugged it quickly with an easy-to-use DLL. I soon had VB programs pulling and pushing data to and from a SQL database.
Life was good, but not for long. Microsoft at the time had about 4,000 employees and I had lots to learn. David and I would take long walks on the Microsoft campus while he reassured me that I would have plenty of time to learn the ropes. Then we would return to our offices where my instructions were that I was only to communicate with him using email. I could look up from my desk and see him right across the hall, but I could not talk with him without an appointment. He hired me as a director but would not provide me with such basic information as my budget. Working for David became very frustrating and my frustration was shared by his other direct reports. David picked up on this and arranged for us to have a training session with an expert team builder. He engaged Thommy Barton to take us through his Accountable Communications Training class. This was a five day class but because we were Microsoft, Thommy was required to deliver it over a single weekend.
Off we went to a hotel in Seattle to learn about team dynamics and the importance of structuring teams with high inclusion, low control and high openness. Unfortunately our team was structured just the wrong way. None of us felt included, David was very controlling and openness (which required trust) was a pipe dream at best. In the middle of this training, a light bulb clicked in my head and I realized that I had been seeing human relationship dynamics in various shades of grey all my life and Thommy was teaching me to start seeing in color. But then the weekend ended and the colors started to fade and I got pissed. I wanted more color.
Thommy helped me understand co-dependence and pointed me towards some additional work I could do, but it wasn’t enough to fix our team dynamics. Within a few months I got caught in a tug-of-war between David and Ken Tito, the director of the West Coast consulting group. Ken couldn’t stand Vaskevitch and wanted his consulting team to report directly to him. I got caught in the middle of this battle and did not have the skills to negotiate it successfully, so David used me as a sacrificial pawn. He pushed me out of the organization but gave me six months severance. Initially I was terrified and very depressed. I had uprooted my family and thrown their lives into turmoil. I had gone from a secure job with people I liked, trusted and respected and now I was on my own and our future was as cloudy as the winter sky above Redmond.
I looked closely at the common element in all of the failures of my life and realized they all had a common element: ME. I realized that I had been way over my head at Microsoft at least in part because I did not have the self-confidence to say “No” when it was needed. I was a pleaser. I wanted people to like me and I was terrified of conflict. I needed some serious work on myself. And I needed to find work. Fortunately, the Universe took care of me again and work fell right into my lap.
Microsoft realized that they needed to educate their market on this new technology. Terms like “Client/Server” and “Distributed Computing” needed clear explanations and these explanations could not come from a Microsoft employee without sounding like evangelizing. They had developed a course called “New Architectures for Enterprise Computing” (NAFEC) and they needed people outside Microsoft to teach it. The course covered Client/Server models, Local Area Networks and distributed databases. I could handle the Client/Server and the database material with only a small amount of brush up, but the networking material was way beyond my comfort zone (remember subnet masks?). I wanted badly to teach this course, so I dove into networking and studied it night and day. I even put a couple books under my pillow! The Microsoft manager in charge of the class gave me a piece of advice. “Never admit that you don’t know the answer.” That was the single worst piece of advice anybody had ever given me and fortunately I was wise enough to smile, nod my head and ignore his advice. He and I did my first trial run in front of an audience of about 100 people in Washington, D.C. and then he flew back to Redmond while I went on to teach the class at AT&T in Piscataway, NJ. I made it through day one just fine, but as soon as I got into the lower levels of the OSI networking model I realized that the folks in the room were the inventors of this layer. I stopped the class and copped to my embarrassment at this point, but they were just fine with it. Yes, they knew about the physical and data link layers of the OSI model, but the rest of my material was all new to them. We spent the next hour with my asking them questions! I learned that it is possible to place an instrument at a bend in an optical cable and catch bits that don’t make the turn and lots of other cool stuff. But most of all, I learned that being honest and vulnerable can reap huge rewards.
The Socrates Group
Donna and I started a company called “The Socrates Group.” We chose the name because we both admired Socrates’ teaching style. I set an intention that I would be the only person to deliver the NAFEC course material. I would deliver every class Microsoft could sell and I would make sure I got excellent reviews. I did both, and I still have a pile of student reviews. The only bad one I ever got complained that I had failed to present the materials in terms of Jesus’ teachings and that I didn’t open and close the class with a prayer. I didn’t take that one in.
I taught NAFEC all over North America from Seattle to St. John’s, Newfoundland to Miami to Los Angeles and many points in between. I even taught twice in Caracas, Venezuela where I just missed a revolution. One of my students took me for a drive after class and showed me the bullet holes in the walls surrounding her house, just across the street from the Presidential Palace. Wonderful people, but scary city.
We taught our public classes in a hotel and our corporate classes on site at the customer’s office. I encountered frequent logistics problems with the hotels and became increasingly frustrated with the arrogance of the Microsoft managers of the class. One day when I was teaching at Intel in Santa Clara, CA, the customer manager of the class told me flat out that they wanted to deal directly with me and not with Microsoft. By this time, I had developed much of my own material including “The Services Model” and I decided to cut my ties with Microsoft. Intel became a great customer and I taught classes at many Intel sites. I also returned four more times to Saint John’s, picked up Fleet Bank, KPMG Peat Marwick, US Army, IBM, AT&T and lots of other clients.
During this time, Donna managed the home office and printed all the course materials. She was absolutely meticulous in doing this and never made the kind of mistakes that Microsoft did. When I taught at the U.S. Army base in Tobyhanna, PA I had two apprentice teachers with me. They unpacked the boxes with the manuals but couldn’t find all of them and asked me if Donna had messed up. My response was clear and simple. “Nope. She doesn’t make that kind of mistake. Check again.” They did and the manuals were all there. In the time we worked as a team, the only problems we ever encountered were along the boundary of our responsibilities. Sometimes we assumed that the other was handling the issue and it would drop into the cracks. Donna knew her job and I knew mine. It was fun.
On The Road
I taught and consulted throughout the ’90s. I was on the road an average of 2 1/2 weeks of every month, but we were making lots of money. I developed many variants on my material and was able to offer classes that could be delivered in 1/2 day or five days and pretty much everything in between. It would be rather difficult to summarize what I spent almost seven years teaching, but the core of it was distributed application architecture. Most of my students were coming from a mainframe background where the application architecture was quite simple: COBOL programs ran in the mainframe and took structured blocks of data from a terminal, made some database queries and updates and spit back a structured block of data for the terminal to display. But Client/Server was different.
The Services Model
The Gartner Group presented a visual model of Client/Server that became rather ubiquitous in spite of the considerable flaws in its early versions. The term “Client/Server” tended to imply a “Fat Client” which this diagram labels as “Distributed Management”, so Client/Server is really only a single model of distributed application architecture. I felt it necessary to come up with a more flexible model and came up with the “Services Model” which breaks the problem in seven layers. The user is placed on the top to acknowledge that the purpose of technology is to provide services to the end user. This contrasts directly with the popular diagrams of mainframe computing which placed the users on the bottom of the page and the computer on top as if it were some transcendent god in the sky. The six layers beneath the user each provide a distinct service. The bottom three layers provide the infrastructure upon which application services build.
The very bottom layer is the Enterprise Connectivity Services layer which provides connectivity services. Its purpose is to transmit messages between programs that can be very near or very far away. Most of the OSI Seven Layers reside within this layer of the Services Model.
The next layer up is the Operating Platform Services layer which is the home of operating systems and the hardware they run in. This layer provides two major services: device and program management. Device Management involves moving blocks of data two and from devices, while program management facilitates the loading and execution of programs.
The third layer from the bottom provides Data Management Services and is the home of database servers such as SQL Server or Oracle, email servers like Exchange, IIS and Apache and any other service that provide multiple users shared access to a class of resources.
All of the elements of the infrastructure are likely to be purchased from vendors that specialize in developing or manufacturing them. Examples include Cisco, Microsoft, HP, Dell… and the list goes on. Above the infrastructure sit the application layers.
Again, working from the bottom up, we have the Data Access Services layer which reads and writes data to and from files, databases, email servers, etc. This layer is solely responsible for passing data access requests from the layers above it to the the Data Management Services layer which may (or may not) reside in the same computer.
Above the Data Access Services layer lies the Business Process Services layer which contains all of the application logic of the program. This layer interacts with the layers above and beneath it to retrieve and update data as requested by the user.
Immediately beneath the user is the User Interface Services layer. This layer interacts directly with the mouse, keyboard and screen. In today’s technology, this layer resides mostly in the browser.
The Services Model proved to be exceptionally versatile and easy to understand. Application Architecture is an example of these course materials.
All totaled, I have well over 1,000 slides that we produced for our courses, and by “we” I must include Donna’s brother, David Perrell of Hearn/Perrell Art Associates.
Originally, David produced physical transparencies that I would carry around with me on my trips. When I needed a new or changed image, I would phone or email David and he would FedEx me the new slide. If we had more time, I would sketch out a slide as best I could and David would make it look right. And moving to PowerPoint meant that David could turn around changes in minutes. This was a wonderful collaboration that I miss deeply. The “SDLC” image below is a good example of David’s work.
- Software Development Life Cycles (like the one we were developing at Ford Aerospace) can be excessively complex and sometimes produce rather bloated results.
- Having a clear understanding of the requirements is essential.
- Producing software can also be very difficult and customers frequently fail to understand how complex it can be as shown in this Dilbert cartoon that half my class brought in on the day it was published saying, “That’s my manager!”
The Challenge of Writing Client Server Applications
Moving to a distributed computing application architecture required new tools such as Visual Basic, but there were consequences to shifting from a known and stable development environment like mainframe COBOL to new tools. I used a simple drawing to explore this. I called it…
Assume that the X axis expresses the complexity of the problem being solved and the Y axis measures the cost of the solution. This relationship is not linear. It is exponential. Simple applications like managing a contact list don’t cost much to solve, but more complex problems like air line passenger manifest management cost substantially more to implement. Where the curve meets the origin indicates the cost to simply get started with a particular tool set. How much training is required? What additional infrastructure is needed? One of the big selling points of Client/Server was that it should cost substantially less to implement new solutions. Visual Basic was supposed to be a good example of that. VB was supposed to be the purple curve on the bottom. Start cheap and grow forever. Well, remember Dilbert’s pointy haired manager? VB turned out to be closer to the orange curve. It was great for real simple problems, but it did not scale well. You could get started with VB but you would hit a wall pretty soon where the cost of adding a new feature to an existing solution exceeded the value of the result. Early implementations of VB were very limited in their scaleability. This curve was so simple and so elegant that I used it all the time to explain why a small change may not come at a small cost. In fact, one of the rules of thumb I have heard many times is that a 10% enhancement to an existing code will often cost more than a complete rewrite. I taught my classes for over seven years and had many wonderful experiences like waking up one morning in St John’s, Newfoundland and seeing a giant iceberg blocking the entire channel, or getting on a bus at Hong Kong’s old airport and offering my seat to a little old Chinese lady who sat down and then reached up and rubbed my belly. But I was getting very tired with the constant travel. By late 1998, it was time to move on to the next phase of my life.