Qualifications and Experience

Question:

Provide a brief overview of your firm's experience in providing information management, enterprise management, e-commerce, and customer management applications and/or related software integration services.

Response:

Managing the scientific enterprise is Science Tools' core business, and we've been doing it since our first production software release of The BigSur System® in 1997. Because it's our core business, we're focused on doing it well. Note that the original design goals of our BigSur System® were as the "EOS-DIS Alternative Architecture ", and therefore other alternatives to the EOS-DIS Core System should share common design goals but in fact they do not, apparently because they are unable to meet them.

Our tools are forged in the heart of information management and computing technology - our systems are Database-centric. Because our tools are built upon the foundation of the RDBMS (Relational Database Management System) technology, and because our product architecture is designed to embrace technologies developed elsewhere, our systems enjoy the widest possible compatibility and interoperability with other systems that are available today to ensure broadest choices for adding auxiliary capabilities. Therefore, our customers enjoy a broad selection of third-party, off-the-shelf tools for backup and recovery, fault tolerance, replication redundancy and other technologies which help guarantee 24X7 uptime and robust failure recovery.

Our established customers may have needs very similar to yours. -

The Langley Research Center (LaRC) DAAC, headed by Richard McGinnis. The contact data is as follows:

NOTE: This data is stale. Bruce Barkstrom has succeeded Richard McGinnis as Director of the LaRC DAAC.

Richard McGinnis
2 S. Wright Street/MS 157D
Bdlg 1268C/Room 1310
NASA Langley Research Center
Hampton, Virginia 23681
Telephone: (757) 864-6893
FAX: (757) 864-9882
e-mail: r.s.mcginnis@larc.nasa.gov

(Please contact us for current referral information.)

Potential clients have already, visited the Langley DAAC specifically to see our system in production and talk to our customers in person. We also attended a meeting in which Tom Reagan and his colleagues at LaRC described how they use our BigSur System® to process satellite data. We were pleased to hear Tom report that since the software was put into production three and a half years previous, they use the system to process over twenty thousand data products per month, fully exercising our software over a million times in all. Remarkably, in that entire time, Tom, after conferring with his colleagues, stated they have experienced not one moment of down-time attributable to Science Tools' software, and have found not one single bug. We encourage you to confirm this by contacting LaRC. (Don Rieger reiterated this statement in 2009, then 12 years after the software was first installed.)

Proposed Solution

Question:

Describe the software solution you would propose. Include lists and specifications of all software and any hardware within the following constraints:

• Automation of procedures and processes to include production planning, job scheduling, and order tracking;
• Interfaces and infrastructure to permit the rapid, inexpensive integration of commercial-off-the-shelf (COTS) and research processors;
• Software that is platform independent to the maximum extent possible;
• Proactive asset management and configuration control;
• Dynamic allocation of computing resources to meet rapidly changing demands;
• Incorporation of robust quality assurance and quality control mechanisms;
• Extensible software infrastructure to support increasing processing, archiving, and distribution requirements;
• "Intelligent" maintenance support; i.e., automatic retrieval of system, process, and device statuses, as well as reporting of performance degradation and/or anticipated failures;
• Minimization of effort associated with revalidation and revalidation of data products;
• Addition of capabilities related to e-commerce, marketing, and comprehensive customer support; e.g., billing, accounting, and customer management tools; and
• Ergonomically correct man-machine interfaces readily adaptable for changing functional and operational requirements.

Response:

It is our vision any system should bring with it an infrastructure which will be sustainable for many decades, adapting to new data-formats and new technologies as they evolve. It will provide robust capabilities enhancing scientific-defensibility, provide automation processing tools, and provide for flexible and robust distribution strategies to client-customers, many of which will involve long-term relationships. For it to do this, it must address data and meta-data management from End-to-End, from data ingest from instruments, through archival, processing, distribution and to analysis and end-user visualization.

Clearly, the scope of the End-to-End challenge in Earth Science requires a great many technologies to come together, each addressing a part of the need. It is our view that a system is required which can bring together individual technologies and integrate them into a cohesive whole, rather than attempting a single, monolithic solution as is seen with the original Hughes Aerospace EOS-DIS (presently known as ECS). This system must permit optional use of individual components, permitting them to be utilized without regard to other components in the system so that an evolution in capabilities is possible, and so that individual technologies can be substituted whenever new, better solutions for particular subsets of the challenge become available.

Our BigSur System® embodies just such a system. It is FGDC, SQL92, and ODBC/JDBC compliant. It has exceptionally few restrictions limiting which platforms it may run on. The system is designed to incorporate other technologies, existing or new, in providing a system for the entire enterprise. For example, new scientific processors are easily accommodated. The system utilizes any SQL92 compliant database engine as the primary data-store, requiring only the most basic database extensions to store files in and retrieve files from the database in order to achieve full functionality. The use of an RDBMS as the central repository carries with it opportunities for great flexibility. If a particular accounting software is preferred, for example, that software package can be integrated through the use of RDBMS "views", and optionally through a small set of API methods which ensure the components remain synchronized. Our BigSur System® includes optional components we recommend, including our Distributed Processing System (DPS), Archiving System, and Publishing System.

With our system, any computing equipment that can run Java can run our existing client software, and if a customer so chooses, we can port our work to other languages fairly easily. Our systems capabilities are greatly enhanced in networked environments, permitting a single repository to control and manage a great many machines, and permitting robust archiving and publishing. Publishing may include communicating results to clients and customers, and may also include access to alternative internal systems which might be used for limited scope work, live backups, testing or similar uses. By running DPS processes on networked machines, they may serve as clients to a central node that directs work being performed on such machines. Load-balancing can be accomplished by controlling the numbers of such servers started on given platforms and by directing their dequeueing strategy. And, this technology can be used to overcome security concerns of partner data-centers by permitting outbound-only links to be made to cooperating BigSur installations.

Note that our system does not couple itself to any other standards than are outlined herein in order to provide maximal platform independence. New and evolving technologies and standards, such as the HDF file format, are accommodated by updating the components which use them, none of which are a part of the BigSur System® itself.

Extensibility, Savings

Question:

Is the system you propose modular and extensible? Provide an example or an analysis of how cost savings have been or might be achieved through its use.

Response:

The system we propose - the BigSur System® - is as modular and extensible as one could ever hope to achieve in large part because these concepts were at the core of our original design criteria and were compelled by the realities of our team size and project scope. Our philosophy is to harness existing resources whenever and wherever possible and appropriate. It is inherently true that standards change with time and that new techniques are developed to address new challenges. Rather than try and write code to adapt BigSur itself to this changing landscape, BigSur learns about data-types, processing steps, and other tools that may exist and permits them to be harnessed easily and quickly to accommodate new technologies. Thus, the system avoids becoming technically stale.

Because our design is database centric, and because we only require that the database conform to the SQL92 standard, BigSur may be hosted on very nearly any system which exists today, leading to opportunities for savings and enhancements. This modularity and extensibility has the following scope:

1. Hardware
2. Operating Systems & Networks
3. Database Management System
4. "Applications" and Sub-systems

In each case, opportunities exist for savings because of the freedom to choose. When the balance of costs favors one choice over another, including licenses, training, staffing requirements, floor space or other infrastructure requirements, our system will not constrain that opportunity.

• Hardware: Our system doesn't mind what scale of hardware it runs on. LaRC, for example, runs our software on their Origin 2000 super-computers as well as older Sun SPARCstation's. In-house, we have run our software on the now horribly out of date Pentium Pro series CPU in a home-made PC running Linux and it runs quite well.
• Operating Systems & Networks: Operating System requirements may vary with specific intended uses, though such restrictions are based upon our customer needs and not upon the demands of our system. BigSur only requires a relational database management system (RDBMS) be available on a system in the environment. Beyond that, use of our Java Application Programming Interface (Java API) only requires that Java be available, making user interfaces and utilities easily extensible. If networking is required, BigSur makes use of existing network transport mechanisms, and, if TCP/IP is used, BigSur can manage the TCP/IP meta-data.
• Database Management System: Virtually all RDBMSes support the SQL92 standard - the most recent Standard Query Language (SQL) standard. Beyond this, DBMS vendors generally have extended their systems in similar, but incompatible ways. BigSur now includes new technology (patent application in progress) which permits SQL statements to be translated into the appropriate syntax for the DBMS which is being used at the time. In this way, our customers are freed to choose whichever DBMS best fits their needs and pocket book. Further, it permits the DBMS to be changed whenever a more appropriate choice becomes available. And, databases implemented in RDBMSes are very easily extended for enhancing user interface or utility functions.
• Applications and subsystems: Being database centric permits easy integration of a plethora of tools from the marketplace. Favorite software packages can be accommodated and integrated into the environment, be it for accounting or for science.

Opportunities for savings are created based upon differing choices of hardware platform, and operating system. If one database vendor provides their software at a reduced price, another savings opportunity is created. Not having to replace existing systems to introduce BigSur can result in tremendous savings, not only in software licenses, but in ancillary expenses such as training. And, avoiding having to replace the system as technology changes will result in substantial savings, extending the lifetime of the system - potentially indefinitely - and reducing life-cycle costs.

Examples of various customer needs

Question:

Provide examples of how your system has been used to meet the needs of customers, including integrating your software with their existing systems.

Response:

As we noted in response to Concern 1, the Langley DAAC provides an example of how our system provides an Earth Science System, adapted to the specifics of a particular DAAC. When LaRC approached us, they required that our system operate against an unfamiliar RDBMS, on a platform (hardware and operating system) with which we were unfamiliar, provide an API in a new language, and inter-operate with a resource scheduling system which they already owned and were familiar with. We integrated our whole system completely into their environment, including archiving, user interfaces and so on.

The transitions to these new environmental requirements was an opportunity for us as it gave us experience in porting our work between environments. From that experience, the success of which is noted above, our products were greatly strengthened and improved to be yet more flexible and adaptable. In particular, we moved BigSur from the Illustra RDBMS engine to the Informix RDBMS. This caused us to loose special features we had previously depended upon, so we re-wrote our code to eliminate these requirements and the result is that today we do not have any known database dependencies apart from those outlined above.

It should be pointed out that all database systems are not equally capable. We could have been contented with saying we have a version for each target DBMS, and resolve differences when they arise. However, this would limit interpretability within any given environment to a single database vendors RDBMS. We therefore chose to create new technology (patent application in progress) which permits BigSur clients to pass their database calls through a translator which re-writes SQL statements as appropriate for target database systems. This permits a single running instance of software to communicate directly with multiple database installations from different vendors without having to have different code sections to accomplish this feat - one code line is enough. Our translator is extensible, so that should new features become available within an RDBMS vendors offerings, or should new RDBMSes become available, the system can be easily updated to reflect these capabilities. Thus, our ability to support multiple database vendors far exceeds that of other software packages.

Similarly, we moved from DEC Alpha running OSF/1 to Origin 2000s running IRIX. This required some changes to the building tools. Subsequently, we have installed BigSur software and it has run virtually unchanged on both Sun Solaris and Windows NT. A brief test even ran successfully on Windows 98. Given the disparity between these systems, we believe we have truly portable software.

In addition, the BigSur API was originally written in TCL/TK. We rewrote it in Java.

Varied customers, varied requirements

Question:

The customer base is expected to include scientists, government agencies, as well as those with commercial interests. Requirements for cost recovery, fund exchange, and transaction taking vary accordingly. Has your company dealt with similar situations with other customers, and what solutions would you recommend?

Response:

Yes, we have been asked about this before. In response we have added support within our database schema to provide for accounts against which costs and credits may be accounted for. Our software is presently positioned to aid with the recording for accounting purposes of delivery of products to clients of all types, likely sufficient to describe all of the scenarios customers may envision. It would be a straightforward task to implement supporting applications, whether in concert with other accounting packages or "standalone", though our software does not presently provide any billing or other related functions. We anticipate that certain projects will need to utilize existing accounting systems and integrating such systems is an appropriate path, one which will yield near-term capabilities. Looking farther into the future, we anticipate replacing these older systems with ones more tailored to customers specific needs.

We should also point out our system has a lot of features to help with accommodating these requirements. The meta-data stored in our system can be very useful for determining what costs really are for specific data products, in terms of system utilization, processing times, storage costs, specific processing steps and many other attributes which may be involved in such calculations. Our system can be used to closely link clients to customers, creating new possibilities for intimate collaborations, or merely for ease of communicating technical requirements, product requests, completed data sets and related meta-data. To help foster this, we have several encrypted connection options available and our system is inherently transactional.