Part I – Setting the Stage
By Chuck Ritley & Ken Ritley
Anyone working in IT has heard the terms offshoring and nearshoring. Two things about them usually come to mind. First, that they are supposedly about transferring jobs to low wage countries. And second, they were supposedly made possible by recent advances in technology, as Thomas Friedman describes in his book The World is Flat.
These statements are not entirely correct. In fact, IT offshoring began much earlier, even in the late 70’s and early 80’s, much before the Internet. And the motivation was less about saving money, but having access to top technical talent.
As an IT guy in the early 2000’s, Ken helped build large offshore and nearshore IT organizations in India and Eastern Europe. This is what we’ll call “second generation” IT offshoring – in which the work is made possible by the Internet and remote collaboration. But in the 1970’s Ken’s father Chuck was instrumental in setting up and directing some early “first generation” work – in which teams of foreign specialists were brought into the U.S.
What follows is a discussion between Ken and Chuck to tell the story of how first generation IT offshoring began, the strong impressions it left on the people involved with this work, and to highlight some differences and similarities between what happened then and what happened now.
KEN: I recall it’s all about mini-computers, which don’t exist anymore today. Can you paint the scene? What was the year, what was the industry like, and what were you and your company working on?
You have to understand the IT industry in the late 70’s and early 80’s. It was proprietary and minicomputer-based. Each company had its own processor design and, therefore, a unique OS and language. At the main-frame level, companies had their own mainframe programming staff who did custom programs. But the minis were meant for the small and medium-sized business. Since those companies could not afford a programming staff, or development time, the minicomputer manufacturers sold turnkey solutions.
The set-up involved a network of dealers, most of whom were specialty houses. For example, in a large market, there would be a number of dealers. One might specialize in finance, another in distribution, or wholesaling, or transportation, or retailing. Most would start with a standard accounting suite of software and then tailor it to the needs of a specific industry. For example, a trucking company would have different needs than a food wholesaler.
The main point is this: it was a turnkey solution for the end-user, both HW and SW.
Now, to make this happen, the computer manufacturer would provide the basic accounting package: sales, orders, accounts receivable and payable, purchasing, inventory, general ledger, shipping, etc. These are root functions that every company does – but a trucker does them differently than a clothing retailer. They were designed to be customized. Having customized one for a specific customer, the dealer now had some expertise and could sell the same customized version of the package to other prospects. The concept of having standard modules which could be tailored is probably the root of SAP and other systems like it.
KEN: That’s certainly much different than today. Today the hardware is standard, the software and programming languages are standard, and the main differentiator between companies is the domain or solution. Can you provide some details about your domain and solution?
The system of customizing basic accounting packages was used by most of the mini-makers. And all of them generally had the same set-up of specializing dealers. But that wasn’t enough.
There was a need for more complex software suites to handle much more than basic accounting, things that dealers with limited staff couldn’t handle. Manufacturers and distributors have complex operations and want to use computers for operations like scheduling work, planning lead times, and materials acquisition – far beyond the reach of normal accounting. So we began to specialize in full-function enterprise resource planning and manufacturing resource planning software. In other words, handling all of the functions a company would need to control every function. These were also meant to be customized easily at the dealer level, since individual needs vary. We also had a few others, but these were the most complex, and beyond the development scope of any of our dealers.
We designed it, trained the dealer, he sold it, and then tailored it to the customers needs. Now, here is where the problems lay: creating these complex software modules required not only excellence in coding, but expertise in the mechanics of a business. The solution was usually to have a business analyst working with the programmers to spell out the flow of work in terms that they could turn into code.