Why Build A Platform

Last updated on: 6/21/2012 11:50 AM 
Created on: 11/2/2016 2:22 PM 

The company for which I developed this application at first considered itself the developer of data security utilities. Old versions dating back to releases 3 and 4 had the look and feel of a utility application in which you would select files to either lock or unlock. The drawbacks surfaced when these utilities were being marketing to the commercial sector (the government sector had little doubts about purchasing utilities.)

Microsoft however did its job with the Windows Operating system. When Windows 95 was released users had an expectation of how applications on this platform worked. There were to be menus and they were to read (from left) File, Edit and View. These same menus were to end (at right) with Tools, Window and Help. Add in tool bars, context menus and a standard way of interacting with data was born.

Starting with version 5, and our client offerings following the release of 5, products were developed as applications instead of utilities. As standards for a public key infrastructure evolved, applications started to have duplicate code added. This code provided access to new standards for user authentication and validation checks. However, as these standards were implemented, not all the applications were rebuilt to incorporate these updates. Thus different applications that should have performed the same functions were not. As a final example, while the SecretAgent application contained the most robust PKI solution, SpyProof only had a small subset of those features. To add those features would have required a significant overhaul (a complete rewrite of the code) for the SpyProof product and the result would be two identical implementations in two different projects that would require maintenance.

To solve this problem the Security Console application was created. Version 6 of SecretAgent was implemented as an applet of Security Console. Much like a web app runs in a browser our security products became applets to run in this master application. Although this was technically Security Console version 1, it was called 6 and all software running in Security Console was given the version number of 6 because only a select number of people understood this was a paradigm shift and not an incremental release.

The Security Console application serves multiple purposes:

1. One common application that would contain the standards and improvements to the Infrastructure and Network communication. These features would be accessed via an API that applets can call. This moves all security features to the platform so application developers can focus specifically on the implementation of their application.
2. Security Console provides the User Interface and the look and feel. The Security Platform developers can verify that the UI components provided meet the requirements to be certified on the host platform. Combined with the Qt Framework for cross platform application development there can be one code base that runs on a variety of platforms.
3. The utilities that evolved into applications can now be built as applets using the provided interfaces. Improvements to the platform can be made readily available to all applets so all products can be made available with the same security features.

Building a platform, even one of this small scale compared to other platforms, requires much foresight and consideration for ease of expandability, ease of maintenance, and the ease in letting multiple programmers work on the code without interfering with each other. For an engineer, it is a fun challenge. With SC7, that challenge is intensified as the new requirements going forward will be placed in a framework level creating a client side workstation that runs apps and keeps itself configured according to specifications from our server products. Hence the paradigm shift from application to a platform based eco-system will become more evident and more practical to our ever evolving customer needs.