‘Openness’ is widely regarded as a positive attribute of a system. Indeed, systems that are regarded as not open, or ‘proprietary’, are compared unfavourably with those believed to be open. But what exactly do we mean when we describe a system as open? Establishing a reasonable definition is important as current debates on the subject often generate more heat than light.
An early view of an open system was one where the hardware was obtainable from more than one source. In particular, the availability of plug-compatible hardware suppliers such as Amdahl was regarded as making the IBM S360 and S370 systems open because they were alternative sources. Later definitions of open inclined much more towards software, in particular operating systems (primarily UNIX and Windows and, latterly, Linux).
Two factors require a different interpretation of open. First, application environments such as Java EE insulate the applications from the underlying platform of hardware and operating system. As a result, applications can be moved with relative ease between different platforms.
Secondly, systems increasingly have to co-operate with others in the same organisation and externally. Intersystem communication requires agreed standards and technologies which make no assumptions about the run-time environments of the various applications. They are regarded as black boxes. How they are implemented is not relevant; they just need to know how to talk to each other.
The result is a shift towards defining openness by the internal and external interfaces offered by a system, rather than the operating system or hardware platform on which it runs. Independent bodies such as The Open Group and the World Wide Web Consortium (W3C) take this approach.
Characterising openness by the internal and external interfaces supported means that there is not a simple open/not open distinction but rather a spectrum of openness. All systems are somewhere along the spectrum. Adding new interfaces makes systems more open. And the appearance of new interfaces in the industry reduces openness until the interfaces are implemented.
ClearPath systems are at the ‘open end’ of the spectrum for many reasons. Internally, they provide Implementations of industry-standard application environments, including Java, Java EE, and Open Group DTP. These environments are integrated with the native application servers COMS and TIP/HVTIP, and can access native databases and other data stores.
Externally, they support all the standard communications protocols and encryption algorithms. Distributed processing is a particularly strong feature. All the major middleware technologies are supported, enabling a wide range of collaboration options, including participation in distributed transactions across multiple platform types, and service-oriented architecture (SOA) implementations.
But openness is not the only desirable attribute of a system. ClearPath systems are typically used in mission-critical environments. Attributes such as reliability, efficiency, responsiveness to rapidly changing conditions and security are essential.
Security is particularly critical. If it is compromised, especially if valuable information is damaged or extracted from a database and used for fraudulent purposes, the results can be catastrophic. Information on system vulnerabilities in a NIST database shows that ClearPath systems have never allowed data to be compromised – the only system types with that record.
The major reason for the high levels of security and other mission-critical attributes is the integrated stack approach used for ClearPath systems. All the hardware and software is designed, implemented and tested together before release. Together with the open characteristics, it is a powerful combination.
I’ve covered this topic in much more detail in my white paper, ClearPath as an Open System.