Holos is an influential OLAP (Online Analytical Processing) product of the 1990s. Developed by Holistic Systems in 1987, the product remained in use until around 2004.
The Holos product succeeded an older generation of mainframe products such as System-W. It was the first to use an industry standard SQL database (as opposed to a proprietary one), and also the first to use the new GUI PC for the user interface. In physically separating the number crunching from the user interface, the product’s model was immediately client/server, although that term didn’t come into use until some time later. In fact, the model was described as cooperative processing until the term client/server became ubiquitous. The client/server model used for Holos was initially for a very “light” client as it was not clear then (1986/7) that PCs were going to be so commonplace, and most were still running MS-DOS.
In fact, it was technically possible to run the system using “dumb” terminal with reduced functionality in early versions although, save for in Holistic’s test environment, this was rarely if ever done. In time, due to the increased popularly of PCs, their increased power, and the availability of a stable and more functional version of Microsoft Windows, additional functionality was added to the client end mostly in the form of development aids. In addition to data services, the Holos Server supplied business logic and calculation services. It also provided complementary services to the Holos Client which meant the internal processing associated with the report writer, worksheet, etc., was distributed between the two components.
The core of the Holos Server was a business intelligence (BI) virtual machine. The Holos Language (HL), used to drive server-side applications, was compiled into a soft instruction code and executed in this virtual machine (similar in concept to Java in more modern systems). The virtual machine was fully fault-tolerant, using structured exception handling internally, and provided a debugger interface. The debugger was virtual-machine-level until quite late on, after which it also supported source-level access.
OLAP data was handled as a core data type of HL, with specific syntax to accommodate multidimensional data concepts, and complete programmatic freedom to explore and use the data. This made it very different from the industry trend of query-based OLAP and SQL engines. On the upside, it allowed amazing flexibility in the applications to which it could be applied. On the downside, it mean that 3-tier configurations were never successfully implemented since the processing had to be close to the data itself. This hindered large-scale deployment to many clients, and the use of OLAP data from other vendors. In reality, its own data access times were probably some of the fastest around—at the individual cell level; they had to be in order to be practical. However, when fetching back bulk data from non-cooperating servers, or data from other vendors, the queries could not be optimised as a whole. Its own data access used a machine-wide shared memory cache.
The Holos Language was a very broad language in that it covered a wide range of statements and concepts, including the reporting system, business rules, OLAP data, SQL data (using the Embedded SQL syntax within the hosting HL), device properties, analysis, forecasting, and data mining. It even supported elements to enable self-documentation and self-verification. Placing all these areas on a common footing, and allowing them to co-operate by sharing data, events, etc., was key to the number of possibilities that resulted. For instance, the report writer supported data input as well as output, plus interactive graphics, and a comprehensive event mechanism to pass back information about the viewed data to event handlers. Also, reports and data were separate entities, thus allowing the same report to be applied to different data as long as it was described by similar meta-data. This meant that when terms like EIS and MIS were first coined, the industry norm was “slideshows”, i.e. pre-programmed transitions between views, whereas Holos provided data-driven drill-down, i.e. no pre-programmed views or links. The transitions could be made dependent upon the data values and trends, in conjunction with the available business logic.
Holos Server provided an array of different, but compatible, storage mechanisms for its multi-cube architecture: memory, disk, SQL. It was therefore the first product to provide “hybrid OLAP” (HOLAP). It provided a very versatile mechanism for joining cubes, irrespective of their storage technology, dimensionality, or meta-data, and this was eventually given a US patent (called COA—Compound OLAP Architecture U.S. Patent 6,289,352U.S. Patent 6,490,593). The COA mechanism allowed combinations of the following core transformations: the meta-data for a cube to be overridden (i.e. making a cube look different), allowing cubes to be joined side-by-side, in a ‘rack’ (i.e. increasing the dimensionality by one), supporting SQL-like operators to fold-up one-or-more dimensions on a cube, or ‘stack’ one ‘rack’ above another. The phrase ‘rack and stack’ was commonly used at the time. COA also accommodated other COA cubes seamlessly, and several customers used this to multiple depths.
As a practical example, the issue of multiple time dimensions was well-known in BI applications: do you design the data to show a year-on-year comparison (typically requiring separate year and month-per-year time dimensions), or to show continuous time (typically requiring a single time dimension with months spanning two or more years). The choice was usually based on whether you wanted to see a trend or year-on-year comparison. With COA, the data could be designed according to efficiency (locality, life-cycle, or maintenance) as the view required by any given application would be achieved using COA, which was only a meta-data construct and required no physical data change.
One novel aspect of this was a ‘stack’ feature that allowed read/write cubes to be stacked over read-only cubes. Read operations to the overall virtual cube then visited both ‘racks’ (top first, and then the bottom), whereas write operations only affected the top. The resulting valve-like mechanism found many applications in data sharing, what-if forecasting, and aggregation of slow SQL-based data. Since the overhead of the joining was small, it was not uncommon to have stacks 7 levels deep, and joining terabytes of real OLAP data. Around about V8.5, Holos Server implemented a hierarchical lock manager, allowing nesting of fine and coarse-grain OLAP locks, and full transaction control.
The business logic supported full cross-dimensional calculations, automatic ordering of rules using static data-flow analysis, and the identification and solution of simultaneous equations. The rules treated all dimensions in an orthogonal fashion. The aggregation process did not distinguish between simple summation or average calculations, and more complex non-commutative calculations. Both could be applied to any dimension member. The process allowed aggregation levels (i.e. those calculation levels starting with base data (level 0) and proceeding up to the overall grand total) to be individually pre-stored or left to be calculated on demand.
The Holos Client was both a design and delivery vehicle, and this made it quite large. Around about 2000, the Holos Language was made object-oriented (HL++) with a view to allowing the replacement of the Holos Client with a custom Java or VB product. However, the company were never sold on this, and so the project was abandoned.
One of the biggest failures was not to provide a thin-client interface to the Holos Server, and this must have contributed to the product’s demise. Although an HTML toolkit was sold, it was considered clumsy and restricted. By the time a real thin-client mechanism was developed, it was far too late and it never got to market.
Before its demise, the Holos Server product ran under Windows NT (Intel and Alpha), VMS (VAX and Alpha), plus about 10 flavours of UNIX, and accessed over half-a-dozen different SQL databases. It was also ported to several different locales, including Japanese.
Holistic Systems was purchased by the hardware company Seagate Technology in 1996. Along with other companies such as Crystal Services, it was used to create a new subsidiary company called Seagate Software. Only Holistic and Crystal remained, and Seagate Software was renamed to Crystal Decisions. Holistic and Crystal had very different sales models. The average sale for the Holos Product in the United States was in excess of $250,000 and was sold primarily to Fortune 500 companies by a direct sales force. The Crystal sales model was based upon a “shrink wrapped” product Crystal Reports sold primarily through resellers. As Crystal was acquired prior to Holistic the senior management in the sales and marketing arena were mostly drawn from that organisation. They felt that all the product range should be sold through third parties and over a period of time dismantled the direct sales force culmination in a significant drop in sales for the Holos Product. Subsequently, after some in-fighting and argument over product strategy, the main Holos development team finally started to leave around 2000, and Crystal Decisions was finally taken over by Business Objects in 2004. Following the takeover, support for Holos was outsourced to Raspberry Software, which was set up by former employees of Crystal Decisions.