Compatibility with Legacy Processors

Question:

Is your system currently compatible with other legacy processors from JPL/Raytheon and Vexcel? Will clients be required to replace these processors with those from a single vendor in order to maintain compatibility with your proposed solution?

Response:

BigSur is absolutely compatible with "legacy" processors and will not require you to replace these processors. We feel as comfortable with this statement as we are with the statement that Earth orbits a star we call our Sun. There is simply no question about it.

Compatibility with new Processors

Question:

How will you achieve compatibility with other processors to be added or new missions? Will clients be required to purchase these processors from a single vendor in order to integrate well with your system?

Response:

BigSur will integrate the functionality of whatever processors you choose to add in the identical manner in which your existing processors will be integrated. From the BigSur System®'s perspective, these processors are just another scientific function to be automated (or accessed "manually") and managed. Unlike other systems which do have compatibility issues, BigSur avoids these issues by having abstracted out what it means to do scientific processing. We do not embed into the system elements that other systems typically do embed such as data-type formats. You won't find HDF-5 elements in our system, for example, though if you do have HDF-5 elements, these are simply declared types and any and all functions or tools that operate against the type are described to the system. In this way the whole question of compatibility with new or different processing capabilities becomes moot. Perhaps our answer to concern 1 above may shed some additional light on this topic.

Certainly, clients may purchase these processors from whomever it wishes.

Let us point out here that it is our ability to make concerns like this evaporate which give BigSur some of its greatest advantages over other approaches. Our system will never become technically stale, nor will it ever force purchase of computing technologies from any particular vendor. You can think of BigSur a bit like the Borg© from the Star Trek© series: BigSur assimilates new technologies by integrating them using existing features and resources. Rather than reinventing or rewriting, existing resources are simply integrated into the environment. They retain their original features and functionality, but having been put into the BigSur environment, they may be automated and accessed from places and in ways not previously possible.

Interfaces with Clients

Question:

Do you now or do you plan to provide interfaces to various other related agencies?

Response:

In the old paradigm, interfaces were published specifications of application level calls in which specialized software had to be written and specialists from each side of an interface had to work out together what information was required for requests and what information could or would be provided in return. While you can still do that kind of thing with BigSur, it's not as important as it once was, thanks to a combination of RDBMS technologies and a new paradigm for scientific partnering relationships.

If you want to think about interfaces differently, they represent who you are as a data-provider. They are what your customer sees. What if your customer could get a whole lot more from your "interface" - would they see it as more valuable? Would they be happy with delivery of scientific data products they have ordered from you directly into their own scientific processing systems? Would they be more comfortable if they were able to track the specific processing history and source data of their data products? What about re-ordering - the same product or a similar one? Given all of the new possibilities, after your customer has a taste of them, would your customers like any other interface if it gave them anything less?

Our system lets you "interface" with your customers and partners as has never before been possible. With BigSur, you can describe the kind of relationship you have with your partner organizations and set up rules for publishing results to them. Once established, you can provide them with robust services that were unthinkable in an earlier era. These publishing tasks can be performed when new data products are produced, on a scheduled basis, or upon demand. This publishing can be controlled at the process-level, the data-type level, or some sub-setting criteria. (The controls are stored in meta-data and are quite robust.) The publishing has the capability to insert meta-data directly into existing repositories your partners and customers already use for their business (such as another RDBMS database), and likewise, the data itself can be transported in the manner your customers choose or that you wish to permit - it can be a push instead of a pull, if you so desire.

A set of critical new capabilities are provided by virtue of meta-data management. By sharing just the right scientific meta-data, you make possible for your customers the prospect of them asking for the processing lineage of the specific data products you deliver to them. If they then retain this information, they could ask you for re-processing to confirm (or replace lost) results, comparison of processing histories of similar data products, or request otherwise identical data-products but with subtle differences in processing inputs. In this way, their science can be dramatically advanced. And, it can all be automated.

These capabilities are based upon our technologies of scientifically defensible meta-data management and our abstraction of the concept of publishing. Underlying technologies include traditional FTP mechanisms, but, more interestingly, also include the ability to transport directly into other RDBMSes. Importantly, our techniques include the option of secure, encrypted communications so that all parties may feel confident.

As your chosen vendor, we are delighted to implement whatever interface features you think are appropriate, in concert with considerations of the capabilities and desires of your customers and partners. We would be pleased to provide a web-based interface for your customers to discover what's possible and then choose to sign up for various technologies, and arrange for suitable payment of and approval for these services. We think that this will be a key differentiator for you as a vendor of scientific data products.

Longevity and Life Cycle

Question:

What is the evolutionary path for your proposed product(s) in 5 years? Five years plus? Will your proposed solution support a 10-year life cycle without its complete replacement or a large-scale overhaul of critical hardware and software components?

Response:

We believe system longevity and life cycle costs are another large differentiator between us and any competitor. We see our strategy as the correct one for science and believe that it will still be valid in fifty years time, and we invite you to close examination of the technology with us to demonstrate this to your satisfaction. While the strategy will surely be embellished, the system should never need replacement. It is reasonable to anticipate that upgrades we may provide in the future will be exclusively focused on the addition of new functionality.

BigSur first went online in the spring of 1995, and has commercially been in production use since September, 1997. The complete re-write that occurred earlier in 1997 was necessary to remove dependencies on particular vendors products which could risk the technologies life-cycle to that of the dependent vendor. We have eschewed embedding any technologies inside BigSur which can be provided externally. We have chosen to depend on very few underlying technologies so we can avoid the risk of software old-age and obsolescence. The technologies we have chosen to embrace should be very long lived, namely the SQL92 database query language standard and to some extent, the Java programming language, and the accompanying ODBC/JDBC database connectivity standard.

While favored programming languages and visualization tools have already come and gone in this time frame, never has the core technology come into question nor have to be replaced. We are therefore confident that our product will gain in additional features in the coming years, but the core will remain the same. And our decision to shift to Java was sound as it too appears solidly ensconced. We are quite confident that our system will not require complete replacement in ten years, and that any Java code written against it will also be viable for that length of time. Other application tools, however, may not share this long life cycle as has already been seen with Object Knowledge, for example.

We do envision that at some point it may be desirable to reload the database schema. When we introduced BigSur version 2.0, we changed our schema to simplify some of the naming to help users of the system. But the structure of the database itself did not change. Code which was written against the older schema did/does need to be updated, but because the underlying techniques, meanings, and strategy did not change, this is a largely superficial upgrade. This type of upgrade may be desired at some time in the future, but we think the odds are fairly low there will ever be any substantive change.

In the event that the operating system which hosts our software - or the hardware on which it lives - needs to be replaced, this should not impact the operation of our software so long as the new system supports an SQL92 compliant database and a network over which ODBC/JDBC database connections can be made. (We have installations running now on widely diverse operating systems, such as Windows NT, Linux, Sun Solaris, and others.) If the a change of database vendor occurs, there may be a few further considerations, such as evaluation of any applications which have been written to supplement the base system. If applications exist which are written in tools that depend upon features provided by the database vendor then clearly these applications may need to be re-written. We are, however, living in an era of polylingualism - we expect most sophisticated application development products are capable of "talking" to any and all commercially available databases with a similar SQL92 and ODBC/JDBC constraints, as we have ourselves.

Powderhorn Support

Question:

Does your storage management solution offer support for the current StorageTek Powderhorn tape silo?

Response:

We see absolutely no reason to think there will be any problem with BigSur utilizing the Storage Tek Powderhorn tape silo (though the Powderhorn itself may have some problems all its own). It is, after all, just a storage engine. BigSur has been using similar tape drive storage engines since its inception in 1995.

We would recommend, however, a re-evaluation of magnetic disks. You can get a terabyte of online RAID 5 storage with three year disk warranties for less than $25 000, and with prices falling all the time, disks are becoming a real alternative to tape. We are mindful that tapes, in addition to being slower to access than disks also require replacement at 5 year intervals or so. The quantity of storage required combined with the realities of physically managing these assets may require a never-ending refresh process due to nothing more than the practical limits of transfer time and drive availability, and nothing else. As disk prices fall and capacity continues to increase, a move now toward supporting all repositories on disks could dramatically increase data availability and lower costs as the transfer of data to disk ends your life-cycle costs spent on tapes.

We suggest that disk purchases now, on an as-needed basis, can begin this process, with the combined benefits of lower disk costs, and higher storage density over time allowing the gradual reduction in physical plant costs - electricity, air-conditioning, rack space - so that eventually all your assets will be available to generate revenue with a higher margin.