This is the fourth in a series of examples to illustrate the way that functionality that had been implemented on an older platform appears on a newer platform.
See this post for a general introduction with example and explanation of this peculiar pattern of software evolution. This earlier post contains an example in security services software, this earlier post describes an example in remote access software and this earlier post describes an example in market research.
Unlike the prior examples, this one is well known and I had no personal involvement.
Example: BEA systems
|
Old platform |
IBM mainframe MVS |
|
Old function |
Transaction application execution enhancement: CICS |
|
New platform |
UNIX |
|
New function |
Essentially the same, with special support for UNIX-oriented applications, databases and UI’s |
|
Outcome |
Slow growth at the beginning and some market education required, but became virtually a standard, with just a couple competitors. It was acquired by Oracle in 2008 when it had about $1.5 Billion in revenue. |
This is a classic example of the pattern of functionality emerging on a technology platform, and then emerging in pretty much the same way in the same order on other platforms.
IBM mainframes were originally used in a batch processing mode. They had operating systems that were really good at it. Groups of users increasingly wanted on-line access, and they wanted transaction processing control and security. The operating system didn’t provide it. So they built what the operating system thought of as an application, but which special applications that ran with it thought of as a specialized kind of operating system, a “transaction processing monitor.” Over time, the value of the main IBM TP monitor, CICS, became recognized, and it evolved to quasi-operating system status.
UNIX gets developed by a bunch of smart people at Bell Labs, and eventually becomes widely deployed on many kinds of computers. It was originally developed with interactive use in mind, and the early UNIX people would have been offended by the idea that it would need to be augmented by a primitive thing like a TP monitor. But that’s exactly what happened, and the UNIX-oriented TP monitors were built along very similar lines and for similar reasons as CICS!
The original authors of Unix ignored TP monitors when they built it in the 1970's, but AT&T had its own version of a TP monitor that ran on IBM mainframes to control its network. AT&T decided it would be cheaper to use their own computers instead of IBM mainframes to run its control software. Their computers had the Unix operating system, but transaction wouldn't work properly without a transaction monitor. So they set about building their own specifically to run on top of Unix, Tuxedo starting in 1983. It was successful and became widely used.
The founders of BEA were ex-Sun Microsystems employees who were amazingly prescient in seeing this need. But they didn't actually build anything! They started by buying Tuxedo, the Unix-centric TP monitor that had been owned by Novell since 1993. They played with other middleware companies but most importantly bought WebLogic, a TP monitor built specifically for Sun's Java language.
It was the availability of Unix-based TP monitors that helped enable the massive growth of the Unix platform during the internet explosion in the late '90's and early 2000's. I was active during this period, both with CICS applications and internet applications. The whole internet tech world, techies and investors, became convinced that certain things were required to build an application with that all-important characteristic, "scalability." It had to run on Sun computers, with the Sun version of Unix. It had to use the Oracle DBMS. And it had to be written in the Java language using the J2EE (usually spoken as jay-two-double-E) library, intended to ride on ... a TP monitor! Oracle ended up being the winner; it first acquired BEA in 2008 and shortly after acquired Sun.
The key, just as it was for CICS, was the integrity of transactions when many people are accessing a shared set of data. UNIX simply did not provide this capability, and just like on the mainframe, the capability was added on top of the operating system, with an application that the operating system thought of as a normal application, but which the applications that made use of it thought of as a specialized kind of operating system.
You might well think that this whole set of functionality is dead today. Who talks about TP monitors? Many companies showed that you don't need all the complexity and overhead of a TP monitor to build scalable applications.
In reality, it's a clear example of another strong, repeating pattern: bad ideas in software rarely die; they just fade for a bit and then re-emerge with a new name in slightly different form. Here's a good example of the morphing of data warehouse into Big Data.
I won't go into detail here, but while J2EE and classic Unix TP monitors are on life-support, the same idea of distributed applications for scalability lives on today in the form of microservices woven together with an enterprise message bus. Even though, just like 20 years ago, they're not needed for building scalable applications!
Comments