Staff during the implementation phase

Question:

How will your staff interface with project management and engineering staff during the implementation phase? Will on-site support staff be required during implementation?

Response:

This will to some extent depend on the scope of our implementation responsibilities. In any case, we do not anticipate that onsite will be required but certainly it will be very helpful and the greater our responsibilities, the more important on-site work will be. We can do substantial work through the internet using secure, encrypted channels and our staff has great telephone skills.

Time line feasibility

Question:

The customer current time line calls for vendor selection in six to nine months, with implementation over the following 12 to 18 months. Is the schedule feasible? Explain.

Response:

The fact that the customer asks this question confirms that time is exceptionally short, yet we know it is possible. The wild-card, from our view, is your staff. One day at the end of April, 1997, when BigSur was just a University project and Science Tools wasn't even a dream, the phone rang. That call brought a visit to the Langley DAAC, which we soon learned was under-the-gun for developing a processing system for data from a satellite set to launch that fall, with a launch-delay deadline of September 1. The Republicans were trying to kill the Mission To Planet Earth and there was real concern any failure would mean the end of it. They had nothing. Their staff was filled with few stars. They wanted a commercial BigSur, on a different operating system, on a different database, written in a different language, running flaw-free for 30 days starting September 1. The project began in earnest on about June 1. We don't need to tell you, the project was successful, but only just, completed mere hours earlier. ...Yes, it's possible...

Customers will be using more features than LaRC is using, but largely they have more time and a larger staff. We are delighted to share our concerns but would prefer to do that in person.

Cost estimate

Question:

The customer requests, but does not require, respondents to provide a cost estimate for the system described in response to this white paper. This information may include specific prices or general cost estimates for any or all hardware and software components, support licenses, set-up and installation charges, on-going maintenance, training, etc. The information will be reviewed solely by the responsible procurement officer to determine an estimated cost range for this project. As an example, if the customer receives ten cost estimates, the range will be established by the lowest and highest values. Cost Estimate information shall remain confidential until such time as it is needed.

Response:

We are grateful that (this particular customer) does not require this estimate because it would require a quotation to be made and a quotation cannot be made given the information we have at this time.

Extensibility

Question:

Please describe how your system would achieve extension of functions?

Specific additional functionality might include:

a. Analytical tools used to filter and to display results from a catalog query.
b. Data mining mechanisms to construct and to execute complex catalog queries and to display the results in an easy-to-understand format.
c. Predictive maintenance indicators and troubleshooting assistance based on synthesis of system monitoring results.

Response:

There are quite a few ways in which the BigSur System® is extended to address the interests you express. The specific implementation of many of these techniques are proprietary. In each case enumerated above, more information would be very helpful in determining just how each of your suggestions of additional functionality should, technically, be implemented. We will therefore describe a number of approaches which among them may be used individually or in combination to achieve the desired results.

The most involved subject you mention is data-mining. This topic constitutes its own scientific discipline and while an in-depth discussion of data-mining is well beyond the scope of our response, we are pleased to report that since its inception, BigSur has been put to use in data-mining because it is an especially good tool to use to manage a data-mining environment.

We have affiliation with various other scientists, including leading researchers in data-mining, notably among these is Professor Sarah Graves, University of Alabama, Huntsville. In discussions with Professor Graves, she indicated that potential clients have been in contact with her with an interest in gaining her assistance in data-mining, though, she said, that collaboration has not progressed beyond the initial stage. We have furthered that dialogue and have a technical approach for addressing clients data-mining needs. In short, we would use BigSur to automate and manage her ADaM system ( http://datamining.itsc.uah.edu/adam/index.html). We have secured Professor Graves' support for a collaborative effort to meet client's data-mining needs. We should also point out that Prof. Graves is in the process of commercializing her work, so her contribution to clients efforts can fall under the "COTS" category. (sgraves@itsc.uah.edu)

In using BigSur for data-mining, algorithms are developed - typically by our customers, or through use of a system like ADaM - which detect features of interest which are then typically tracked or stored as objects themselves, used subsequently in further analytical processing, or passed to special tools for visualization. BigSur is nice for this task because it provides the automation processing environment and provides the all-important tracking meta-data so that the lineage of each object in the system is known. With BigSur, data-mining becomes integral with normal scientific processing.

These functions are at the complete discretion of BigSur users. They may be as simple a "shell script", or as complicated as a 25 year old, badly written, no-one knows how it works Fortran program. Very often, software tools such as Matlab® or Mathematica® are used. These extensions perform processing steps which create new objects. As a separate but related issue, lots of visualization tools exist and are specialized for the data-types involved, and BigSur is sensitive to which tools to use for what type. For example, many tools handle plain-text - Microsoft Word®, some display html - Netscape®, and still others manipulate images - PhotoShop®. BigSur "knows" which tools work with any given object. "Extending functions" doesn't require extending BigSur itself, it only requires entering the necessary meta-data into BigSur. "Extending data-types" is similarly accomplished as functions typically relate to specific data-types, and so they are handled in like manner. We use these meta-data to find appropriate tools which perform visualization and display of data contained within BigSur. And, favorite visualization tools for specific data-types is managed on a per-user basis so that each individual can have their own default choice known when many choices exist.

While BigSur provides some built-in room for extension with each and every component in the environment, every once in a while it would be nice to extend the meta-data to make for easy browsing of specialized components. BigSur provides a very simple, very effective mechanism for extending the schema without disturbing any existing features whatsoever. We use this capability ourselves to permit us to enter differentiating markets - we presently have the GeoDB® and MedDb® extensions for the Geospatial and Medical markets, respectively.

We understand that the fundamentals of predictive maintenance of hardware resources are based upon three criteria: time, use cycles, and known failure indications. BigSur can provide important information to aid in predictive maintenance, such as numbers of cycles, and reporting of errors. Collection of these data for analysis can be aided in several ways. For example, when our software automates the creation of magnetic media copies for distribution, the number of cycles on specific hardware can be directly tracked. When a failure or less severe error occurs, client's staff is easily able to direct the error-handling code to automatically save the pertinent information. In the case of tape writing instruments, for example, it is probably most appropriate to create an entry to manage the meta-data about that instrument as an object within BigSur. Either our built-in extension space, or new meta-data space (as outlined above) may be used to retain instrument-specific data. Subsequent analysis can be automated as just another job within the system - queued to run on a regular basis, when some threshold is reached, or by some other criteria such as operator whim. The analysis, when complete, can use BigSur mechanisms to email support staff as appropriate, or, using dialer hardware we do not (yet?) supply, the system can page staff members.

Predictive maintenance of software assets is not as straight forward but is based upon the behaviors of resource utilization and the potential need for archival of older information to keep resources free for good performance. The highest order concerns have to do with architecture and the principals of design used in developing a piece of software or software system. From the beginnings of the BigSur System®, our philosophies have been based upon the following principals and perspectives:

• Design for performance at every juncture, and presume worst case conditions are normal. (Assume millions of database entries and thousands of concurrent users.)
• Ours is a meta-data based system and the data is what the data is. Keep the meta-data organized so that duplication is minimized and "expensive" features are kept clear from nexus points. In other words, put "large" attributes in their own spaces, and where costly searches are likely, ensure the smallest scope of other users or data are impacted.
• Disk space is cheap - all objects are inserted and never deleted. There should never be a need to archive data out of the environment. There should be very few times when data is updated and even fewer times when data is deleted.

As a practical matter, BigSur itself will be limited by the needs and concerns of the RDBMS that hosts it and the sufficiency of resources devoted to it, such as disk space, and CPU power. There will, generally, be no need to perform weekly, monthly or even yearly purges and only that maintenance recommended by your chosen database vendor will be required. There may at times be insufficient resources on one platform or host computer and it may therefore be desirable to move components to a second installation. This can be readily accomplished through traditional DBMS tools as provided by your DBMS vendor, or we can assist in such efforts. And, in those cases where such a move would "tear" the meta-data, our publishing software may provide an easy and direct means of populating a second installation and establishing proper meta-data links so that the meta-data remains complete and intact though the data resides on multiple installations - fully distributed meta-data is an integral feature of our system. There should be no further maintenance required for BigSur.

There is another issue related to the health and potential need for maintenance of a database, BigSur or otherwise: Referential integrity. Given that we do not know what applications will eventually be applied, and we do not know that said applications will be thoroughly written, there exists a risk that at times bad entries in the database may be made by an errant application program. Such occurrences are violations of referential integrity. Because this is a universal concern for all databases, most database systems today provide for the definition of rules, usually called "constraints," which are designed to prevent referential integrity violations. We have developed a number of referential integrity constraints for use with our database, should your RDBMS provide constraint-checking features.

And, there exist a great many tools, mostly provided by database vendors or their associated partners, which are designed to detect and potentially help repair, referential integrity violations. The best application development tools provide for the definition of rules - sometimes called "business rules", the logical equivalent of constraints - which are designed to ensure such violations never occur. (Use of our Java API will also help prevent such occurrences.) To help illustrate this issue, consider a person entered into to the system who works for Oak Ridge National Laboratory, but for whom there was never entered an affiliated organization. A query to discover if the person is with ORNL, for example, would fail to uncover the association. By teaching your applications these constraints, this maintenance concern can be reduced or eliminated altogether.

So, when it comes to predictive software maintenance of our system, this issue is primarily driven by your choice of database vendor.

Customized Data-Views

Question:

2. Please describe how your system would achieve customization of data views for particular users or applications; e.g., custom portals for product customer, business office staff, maintenance personnel, department managers, and customer support specialists.

Response:

Technically speaking, data views are a technology provided by RDBMSes (Relational Database Management Systems) and implement a database query or set of queries on an underlying data-store and present to the user the results in a form that appear as if it were the underlying data-store itself. These custom views of the data are indeed used to tailor perspectives into a database for particular users or applications. Such technologies are available within most all modern RDBMSes and do not represent a component of BigSur. Creating and using views of a BigSur database is as simple or as difficult as your choice of database vendor has made it, though typically, they are all pretty simple. Where things get more interesting is in a variant called stored-procedures. The implementation of these are unique to each vendor.

Beyond the question asked, we suspect that the following additional commentary may be helpful: We ourselves are using three techniques for accessing our own installations and creating our own applications: DBMS tools provided by our RDBMS vendor(s), applications we've written in Java using our STDB Java API toolkit, and using specialized database-savvy application and development analytical tools used to filter and to display results from catalog queries. Most times, the queries are so simple that no additional help is necessary and straight SQL queries produce exactly the desired result though we recognize the security aspect of this technique is not robust. On other occasions, a script-like tool is easiest and for that we use Java-based tools from the command line, for which we have developed a security technology for which we are seeking a patent. And at still other times formal applications are desired.

Java-based programs all operate in the same fundamental way, and can be deployed in three distinct ways: command-line interfaces, direct GUI (Graphical User Interface) applications, and web-based GUIs. The advantages of Java are ubiquity, ease of programming, and the helping-hand of our Java API. Note also that in the past we have written some applications in Tcl/TK and sometimes in Perl. These applications are fine, but we have abandoned these languages for current development in favor of Java primarily because of the ubiquity of Java.

For those times when we want a sophisticated formal application, like you, we don't want to have to spend a lot of time programming or maintaining our programs. Thankfully, there is no need for us to write our own sophisticated "code-less application development" tools as these tools now abound. Among these we have used Illustra's® Object Knowledge® which is simply fantastic, and when it became unavailable, we switched to Informix's® Visionary®, equally fantastic. In both of the above cases, applications of outstanding quality are created by placing windows-like elements on a canvas and then describing what data is presented where, or which actions occur when the user manipulates something. We have ourselves created world-class applications with these tools, but unfortunately, while Visionary® is available today, we do not have a license to present our applications outside of our own offices. IBM®, which just purchased Informix Software®, has promised to continue to offer Visionary®, but has removed Visionary® from their partner program. So, we have secured an arrangement with Scopeland® Software for their Scopeland 2000® application development and deployment tools and our license permits us to deploy our applications on the public web. We have the tools in-house and have begun development using them. While not as sophisticated as Visionary®, Scopeland 2000® is much less expensive, and is doing the job quite well. Scopeland 2000Ò is designed for use by people with no programming skills whatsoever. We began developing an application the moment the software was installed and development is indeed quite rapid. We anticipate a couple of weeks spent on the learning curve, followed by a couple of weeks spent per application - for one "programmer". We will deploy these applications on one of our internet accessible servers.

We have established ourselves as a partner of Scopeland Software and will be offering their products and services as an optional part of our proposal to you.

In addition to these vendors, we have become aware of no less than four other vendors who serve the codeless-application-development market. Some of them have capabilities well beyond Scopeland, while others supply much less, yet all of them are complementary to our offerings and all of them greatly simplify the creation and deployment of suitable applications via web-servers. As our dialogues with them and evaluation of their products are not as far along, we are hesitant to cite them by name. However, we would gladly do so, if asked.