The Scope story: times are changing
Explore the origins of Scope. Our multi-part blog series reveals the development of the digital Standard for logistics. All chapters at glance:
- The Dawn of a New Era
- An Idea Takes Flight
- Times Are Changing
- Everything Stays Different
- Not Yet Perfect, But Promising
- One Step Forward, Two Steps Back
- And Yet It Moves
Times are changing
That’s always been the case. But from the mid-1990s onward, things suddenly began moving much faster – especially in the world of IT. Two major developments emerged during this period that would prove to be a serious challenge for ProCarS. And no, neither of these developments involved the Internet. In fact, the Internet, at that time, was more of an advantage for ProCarS, as it allowed clients to connect globally to central UNIX servers at a fraction of the cost. The aforementioned global client only needed five servers to connect all its users worldwide.
The truly disruptive developments for ProCarS, however, were of a different nature. First, Windows 95 introduced the concept of graphical user interfaces (GUIs) to the business world. It wasn’t particularly stable, but suddenly the world on the screen became much more colorful. Second, SQL databases began to gain traction. Neither of these concepts was present in ProCarS. ProCarS was built on a technology that didn’t understand SQL. While PL/B had quickly mastered the concepts of "Graphical User Interface" and "SQL Database", ProCarS simply needed to be adapted to these new concepts, and both issues would have been solved in one fell swoop.
But it didn’t happen that way. And there were several reasons for this.
By then, ProCarS consisted of thousands (yes, thousands) of different programs that called each other. However, ProCarS also had thousands of advantages. All the forms could be designed more or less freely, the order of fields was configurable, and there were thousands of small settings that allowed the system to be tailored. Plus, ProCarS was extremely fast and remarkably inexpensive. So what was standing in the way of adapting it to the new concepts?
The problem with switching to an SQL database could have been managed, albeit at a very high cost. But there was another issue: there wasn’t just one SQL database, and these databases weren’t really compatible with one another. That alone raised a number of questions: Which database should be chosen? Who would maintain this database at the client’s end? Would it even fit into their IT landscape? Another large client from that era exclusively used IBM, so they would have insisted on DB/2, but Oracle was far more popular – albeit much more expensive – and the Microsoft SQL Server wasn’t even remotely in the picture yet. The idea of having a collection of different databases didn’t excite anyone. It was a Babylonian array of names with no clear decision-making framework.
The far bigger issue, however, was the graphical user interface. Back then, programs were limited to a maximum of 16 kilobytes in size and could handle only 16 kilobytes of data. Over time, these limits had grown, but much of ProCarS still relied on this basic structure. This structure, however, was completely incompatible with the way graphical user interfaces work. In a typical GUI-based system, you usually have a single program, not hundreds or even thousands of programs calling each other. Since the input forms in ProCarS were deeply intertwined with the business logic, these would have had to be untangled just to implement a GUI. This meant that ProCarS would have to be completely rewritten. And for Christian Riege, who had interned at the company as a student and was now responsible for development, that simply wasn’t an option. Better to develop something entirely new, rather than overhaul ProCarS.
To be continued...