Our approach is client-centric, problem-driven, tool-based and reflects our commitment to creating an infrastructure that provides seamless transport of information between any two points. Instead of enterprise-wide systems, we are addressing institutional data management needs with compositions based on web-based tools glued together with a scripting language. Our software development strategy is incremental and based on growing solutions starting with a simple instance, identifying the tools required to enable the processes associated with the instance, looking for common denominators among similar problems and moving on. In other words, we are identifying instances of problems from which we can generalize enterprise-like solutions, but from the bottom up instead of from the top down. The concept of generalization is critical, and provides a metric from which we can measure the utility of a solution. Problem solutions that do not readily generalize are lower priority than solutions with a large leveraging potential.
Our strategy starts with out colleagues with a problem to solve. As a minimum require our colleagues to provide a problem statement and the current process and/or workflow used to solve the problem. If there is no process or workflow (i.e. a problem without a solution or work around) then we work with our colleagues to outline the workflow of the solution. From the workflow we derive our software/web solution to the problem (and if we are lucky possibly simplify the solution process or workflow).
For implementation we rely on using industry standard data packaging, transport and tracking protocols in order to facilitate coupling (via an interface) of solutions. The overall paradigm is based on XML(data packages) + HTTP(data transport) + SOAP (activation of remote services). Our tools are designed to address seven critical areas:
Among our tools are ones designed to facilitate access to and transport from institutional databases, ones designed to capture data on a form, perhaps prepopulated with existing data from one or more enterprise resources: see the IT Lab toolbox . In addition - here is a useful suite of tools to build a web interface to a mySQL database: mySQL import and here is an extremely popular tool for building a browser-based interface to MySQL. So who crafts these tools? To deal with implementation, I started the IT Lab and populated it with 7 of the greatest and friendliest folks in the galaxy
We select a problem with an end user, and explore how to solve the problem with existing tools. If we find some tool is missing, we develop a new tool, that fits with extending the range of problems we can solve: thus the inductive component. Emphasis is placed on developing tools that address more than the immediate problem under investigation without destroying the one-function:one-tool concept. One goal is to rapidly prototype a script in order for the user to determine if the solution is pointed in the correct direction. In this manner, there is successive refinement of what the user perceived he/she needs while providing a foundation for tool use and developoment. Our goal is that when first meeting with a client, by the end of a session, we will have implemented a web-accessible prototype of a solution to their problem.
Our data-entry tools are based on PDF and HTML forms and unix-like filters for electronic signatures, credit card validation, merging data from a database with a PDF template, creating tab-delimited records from a submitted PDF form, placing and extracting data in an HTML and PDF form etc. We use MySQL as a backend database manager and a number of PHP3 scripts to interface the user with the database (PHPMySQLadmin etc) . We use JDBC as the primary database interface with some use of ODBC (when all else fails). We have recentlyfound a neat trick - to change the mime-type of a text file so that it can be automatically imported, for example, into an excel spread-sheet. This strategy for moving data is simple, powerful, and requires no special installations or maintenance. Another triumph for http protocols. We have build a portal (see worktable ) to explore distributed content management of out portal. We have also built a web-page registration system to facilitate central coordination of web-site integrity while promoting distributed web site management.
C. Frank Starmer