The four definitions of client/server database project management that will be examined in this presentation will be the following:

A "True" Client Server Database Application

This definition is the classic definition of a client/server database where the data and an intelligent manager application for it reside on a "server" computer. "Client" applications on remote computers make specific demands for data as they require it usually using a Structured Query Language (SQL). Rather than sending the entire data file to the application to be dealt with, the server software sends only the data required by the application request. TimeControl 3 is a true client/server database application. It can store its data directly into Oracle, SQL Server, Interbase and Sybase formats using the Borland Database Engine (BDE) and SQL Links.

Client/Server means using a Client/Server database as a data repository

This definition occurs when users seek to ensure that the storage data of TimeControl will conform with the format of data of other applications already in place. This capability of storing data directly in the client/server database is distinct from a capability of importing or exporting to that format. TimeControl can store its data directly into a client/server database in Oracle, Microsoft SQL Server, Interbase and Sybase formats.

Client/Server means multi-user access

For some users, the term client/server means having the project data on a file server and having simultaneous, record-locking access to the file. This is a typical local area network environment. The largest advantage of this setup is the ability to manipulate many files at once. For a multi-project environment, this setup is critical. Also distinctive to this category is the ability to record-lock the project file to allow multiple users to access the file simultaneously. TimeControl uses 'optimistic concurrency', the latest in shared file technology and is a multi-user application.

Client/Server application architecture

Client/Server application as an architecture is a different category. When we think of an application like this, we think of satellite terminal stations feeding data to a central, more advanced repository. To qualify for this, an application must have multiple levels of interface or product, delivering a different, more useable version to the satellite users and a more complex, robust version at the central level. TimeControl allows limitless levels of functionality right down to the field level. This makes TimeControl very deployable as a Client/Server application architecture.

The desire for a client/server implementation of TimeControl often starts with the executive level of an organization. The interest in having an integrated project control environment where timekeeping data from the lowest level of the organization rolled up to the highest is popular with executives who are accountable for project satus but unable to determine their status in a timely manner.

Other initiators of a demand for client/server project management sometimes starts with the I/S department where an already existing client/server architecture is often in place.

Definition 1 - A "True" Client/Server Database Application

This is probably the most classic use of the term Client/Server and usually originates with someone in the I/S department who actually knows what it means. The most common request of such an environment is to create a globally integrated data model for the organization's project data. The notion is that the management can establish the status of all projects on a moment-by-moment basis. In fact, the desirability of such an environment diminishes when the requirement for data integrity insist on a validation of data and an accountability or "sign-off" of data as it moves from level to level within the organization.

A client/server data environment occurs as follows: A "client" application is started on a remote workstation. It opens a connection as required across a network to be able to access information. The user makes a request of the application to perform some function and then the application considers that request and determines what demands it must make of the data that resides on a "server" computer. The client application then formulates that demand and sends the request to the server computer. The server computer receives the demand, determines which data, if any, meets it and then sends that data back through the network to the client station.

This environment is best suited for a transactional system. For example, a contact manager. The client terminal could be used to enter a new contact entry. Then only that record is sent through the network to the server. Similarly, if you wanted a report on a particular contact, sending a data request in such a client/server environment would result in the server sending back only that particular contact record. A non-client/server environment would require sending the entire file across the network so that the "client" workstation could evaluate each record until it found a match. The advantage then of such an environment is that traffic across the network "wire" is reduced significantly.

A Timekeeping system such as TimeControl is ideally suited to a client/server environment. Paritularly in larger organizations, the amount of total data stored by the system may well be enourmous. Yet the data required for a particular function or transaction is likely to be only a small portion of the total data set. This is the perfect scenario for a client/server situation.

TimeControl as a Client/Server Database Application

TimeControl is a true client/server application. It uses the Borland Database Engine (BDE) and SQL Links to connect to reach the appropriate client/server database. TimeControl includes several scripts to be used on the database server to create a the database and tables for use by TimControl. The server database can be on any hardware platform for which it is supported. So long as the BDE is properly installed, the database, having TimeControl work as a client/server application is assured.

To install TimeControl into a Client/Server environment requires the cooperation of the Local Area Network Administrator and the Database Administrator (DBA). Included with every copy of TimeControl are SQL scripts specific to the databases TimeControl supports. SQL is an acronym for Structured Query Language, the fundamental building blocks of communicating with all modern Client/Server databases. The Database Administrator takes the scripts appropriate to the particular database which has been chosen for implementation and using it, creates either the database and tables which will be used by TimeControl. The Database Administrator and Server Adminstrator must ensure that all users who will be using TimeControl with this database are granted the appropriate rights to access it. If it has not already been done, each client (user) workstation must also have the client software which is part of the client/server database chosen. Since TimeControl will access the native drivers for the database, it is essential that these drivers be made available to each client station.

Now at each client station, either the Remote Workstation Installation or Workstation Installation is run. Instructions for this are included with TimeControl's documentation. The Remote Workstation installation will install the BDE and all of TimeControl's client software onto the target machine. The Workstation installation is designed for users who are connected to a Local Area Network and wish to keep TimeControl's client software on the LAN. In this case, only the BDE will be installed and Icons will be created to call the software from the LAN. In either case the installation scripts will ask the user the location and type of the TimeControl database. Once this has been accomplished, TimeControl will begin to communicate with the central database without further intervention.

From this point forward, the power of the client/server database will ensure that only the data requested by the client terminal is sent down the wire to it. This allows large hardware implementations to support client imlementations of any size.

Costs and Benefits

When deciding to implement TimeControl as a true client/server database application, the various costs and benefits should be determined. The list below is not exhaustive but should serve to act as an initial framework for determining your own requirements.

Costs:

Learning Curve. If an organization does not already have a client/server database then the learning curve associated with installing and implementing one is significant. Aside from the complexities of any such database itself, establishing the practices and procedures to ensure that all data is being stored in an appropriate manner will require a full implementation plan in order to be a success.

Cost. The cost of purchasing and implementing a client/server database can be high and in many cases can be higher than the cost of purchasing TimeControl itself.

Complexity. Adding another layer of application and complexity simply more support and more details to manage. Unless there is a compelling reason with a clear benefit, then adding complexity is not effective.

Expertise. For all of the publicity that has surrounded Client/Server, there are remarkably few experts who have presided over a successful deployment of this architecture within a firm. Consequently, finding the database expertise may be costly or even impossible.

Benefits:

Geography. In a project environment which is widely distributed, setting TimeControl into a client/server database environment may make a significant difference to traffic over the network. This usually occurs only when multiple users must access the same data files from multiple locations simultaneously.

Multi-Platform. Setting up a TimeControl environment in a client/server database allows the user to take advantage of significantly advanced hardware to run the database server.

Data Integrity. Most client/server database environments are well suited to enhance your data integrity. First, having data on a stable hardware platform counts heavily. Backup routines for such data are generally well established and application users often need not concern themselves that the data has been appropriately cared for in case of hardware or power failure.

Security. The security included with many client/server databases far exceeds the capabilities of a PC database such as Microsoft's FoxPro. Database administrators can determine exactly who has what rights to the data and when it can be manipulated.

Compliancy. Having all data in a compliant database makes more data integration with other applications possible.

Definition 2 - Client/Server Means Using a C/S Database

Many large organizations have already implemented a client/server data environment and either have or are in the process of deploying various client/server applications. When considering new applications such as project management, it is often desirable to ensure that the new application supports the same database format as what has already been implemented. The transactional nature of a true client/server environment are secondary here to ensuring that data is stored in a compliant format. Distinct in this environment is an ability to use the client/server database directly as a repository.

TimeControl Using a Client/Server Database

TimeControl asks the installer to choose the database as part of the installation process. While it is possible to maintain several databases which are not of the same vendor, HMS recommends selecting a single flavor for data. To connect to this database, TimeControl takes advantage of Borland's Database

Engine (BDE) and SQL Links also from Borland. This combination allows a single TimeControl version to interact with one of several database types and alleviates the requirement for different versions for different databases. Because TimeControl supports several client/server databases including both Oracle and MS SQL Server (market leaders), the odds that TimeControl can support your own organization's database standard is very high. TimeControl also supports Interbase (by Borland) and Sybase's SQL Server. There are also drivers available for DB2 and Informix although these implementations have not been tested.

TimeControl internally supports MS FoxPro format for those organizations who do not wish to implement in a Client/Server environment. In this case, there is no additional database technology to deal with as the file format is completely supported internally and there is no Server-side component of the database.

Costs and Benefits

There are several advantages of such an environment. The most obvious is an economies of scale from having all expertise concentrating on one data environment. Another key advantage is compliancy. If all corporate data is already stored in a client/server database, then saving the project management information in this same format makes integration and exchange of data between applications simpler. Other benefits include security, backup facility and the other advantages that come with storing data directly onto a corporate client/server database. The costs of such an environment include complexity of another database layer, potential lack of database expertise, and the cost of supporting a client/server database. Organizations which have already established their use of a client/server database and want to ensure that new applications will support it are best suited to take advantage of any benefits of this environment.

Definition 3 - Client/Server Means Multi-User

For some users, the definition of client/server is simply the ability to store the project data centrally on a file server and then have multiple users accessing that data simultaneously. This definition requires a local area network with a file server. Project data saved on the file server and is then accessible to all users. Multi-user access is critical to this environment so that multiple users can access the file simultaneously.

How does it work?

Data is stored on a local area network's file server in a non "client/server" database. Once TimeControl's data has been installed on the server, users can access it directly. TimeControl uses an "optimistic concurrency" to manage multiple users accessing data simultaneously. This means that when editing data and the system goes to write data to the database, it first checks to make sure no one else has "gotten there first". It does this by checking the data that was originally read by the client station. If the data is the same as it was when you started editing, you're all set and the transaction is processed. Sometimes this means checking several tables but TimeControl manages this as part of a single transaction and "rolls-back" or undoes any transaction that can't be completed from beginning to end in order to assure referential integrity of the data. If a user can not complete their transaction because data has changed, they'll be notified that saving or "Applying" the data has been unsuccessful because someone else has changed the data in the meantime and the system will then refresh the data on the current screen with the updated data. The change, if still required, will have to be re-entered.

This may sound like a lot of work and it does involve some code working in the background but it's not as tough an issue as it might be for other kinds of applications. First of all timesheets are entered by individuals and no one is ever changing a single record simultaneously in a new timesheet. Also, the central tables of TimeControl, where you might reasonably expect to find more "collisions" of users trying to change data simultaneously are often each managed by a single individual in order to maintain order in the data. This lends itself to having very few data collisions in tables. The most likely place to have this occurance is in Debit/Credit or changing existing timesheets. While this is possible, it's hard to imagine more than a handful of people trying to edit the same record simultaneously.

TimeControl as a Multi-User System

Costs and Benefits

There are several benefits of a multi-user environment. Even if data is updated by only one person, the ability for many users to access that data for reporting or analysis purposes is very desirable. If a company is working in a multi-project environment, being able to get reports on all corporate projects simultaneously is essential. The benefits of multiple users having access to data simultaneously often outweighs the costs of implementing a local area network altogether. Also, most organizations have already installed a local area network and file server and this technology is often very stable in the organization. The costs of this environment are mostly administrative and procedural. Anytime data must be shared or stored in a common area, the procedures for who will update it, maintaining the appropriate security levels and rights for that data as well as managing the various files and historical data that tends to accumulate in common areas may entail additional effort.

Definition 4 - A Client/Server Application Architecture

If we take aside for a moment the classic definition of a client/server database, there are a number of applications which could be considered client/server architectures. In these systems, a centralized or "server" application accepts data from "satellite" or "client" applications. It then manipulates that data for analysis or reporting purposes and might even send some results back to the individual satellite applications thus "serving" them with results from the centralized database. Most accounting systems can be considered in this light. A centralized General Ledger forms the core definition of the system and then accepts data from subordinate systems or ledgers such as the Accounts Receivable, Accounts Payable and Payroll systems. These systems may themselves, be centralized systems and have subordinate systems with which they interact. For example, the Accounts Receivable system may have as a subsystem an invoicing module. In this fashion, such an accounting system would form a hierarchical structure and the centralized database in the General Ledger would be considered the "server" application. In some systems, the General Ledger also serves some subordinate systems with results such as the budget figures being returned to the Accounts Payable ledger so that individual managers know what amounts are left to be spent in each account.

One of the things that makes this type of integrated application work is the formalized process of data movement that is implemented during the implementation of the system. Accounts Receivable ledgers do not update the General Ledger on a minute-by-minute basis. In fact, the procedure of moving data from one level of the system to another is very well documented, happens on a rigidly controlled schedule and must contain validation procedures to ensure a very high degree of data integrity.

How does it work?

If we take this analogy to the timesheet system context, there are some immediate parallels. A timehseet enterer user should only see a tiny part of the functionality and data elements of the entire timekeeping system. Yet these users may be heavily in the majority. Remote "client" users are served by the central data repository and central system with pre-prepared data which makes it simple to complete a timesheet. The central group maintains valid Charge Code lists, Filters to ensure that only the Charge Codes which are appropriate to that Employee are viewed, Rates to manage costs in the background and Profiles to insulate the user from most of the complexities in the system.

In return, the Client feeds actual timesheet data back to the central repository, aided by having been 'led down the garden path'.

This even more significant if the remote users are disconnected from the current database. Remote users who are never connected to the central data repository may still be considered part of a "client/server" environment. In this situation, a remote station might receive the key files it requires from the "server" or central repository of data via electronic mail or even diskette. The client station might return its data to the central repository via email or diskette.

TimeControl - As a Client/Server Application

TimeControl supports the concept of disconnected or "remote" users who are expected to never have a direct link to the central data repository. For these users, core files such as valid Charge Code lists, Rate descriptions and User lists (for release purposes) can be exported from the central repository and emailed or even mailed to remote users who can use TimeControl's Import Links functionality to bring them into their own copy of TimeControl. Once the remote user has completed their timesheet, they can "release" it via email directly from within TimeControl. The system packages up the essential information and ships it off to an administrative user who has access to the central repository where it becomes part of the corporate data without further intervention.

Costs and Benefits

For any organization who is already geographically separated, the costs are probably already obvious. For an organization considering implementing an enterprise-wide timekeeping system for the first time, there may be some costs or disadvantages which are not immediately apparent.

In implementing an enterprise-wide solution, one of the key elements is the acceptance of that solution by the very users who will have to use it. However, an irony of such implementations is that they are both chosen and provide the most benefit to a tiny minority of users. Management may have an absolute requirement for the data contained in the timesheets but the actual entry of that data may be done by 95% of users who have almost no interest and little investment in its contents.

In such an implementation, it is essential to get as much end-user "buy-in" or acceptance as possible. The client/server application concept can help to achieve this. Providing users with the minimal functionality required results in end-users not getting caught in a system which seems too complex for them to use to complete what should be a simple task. In addition, providing or "serving" them with pre-prepared timesheets or already prepared simple drop-down lists of valid charges and isolating the users from various data elements may make using the timesheet system palatable. Automated validation rules which instantly tell the user about potential errors in the timesheet according to the organization's business rules make the approval cycle that much shorter. The goal should be to make entering timesheets easier and faster than it had been with previous systems rather than to make end-users happy with the timesheet system. After all, it's unlikely that any end-user is going to be too excited about having to complete their timesheet at all.

If a system is not accepted by the end users, then it makes no difference how many great features it has. It will not succeed.

TimeControl's pre-prepared timesheet function, it's ability to remove functionality and features and data elements all the way to the field level, it's automated Validation Rules, it's easy to use timesheet interface all lend itself to an implementable client which can be served by the central users and central system.

When to Implement a Client/Server Database Environment

Established Environment:
If there is an established client/server database environment then many of the building blocks for implementing TimeControl as a client/server application are already in place. Also, having this application support an existing data structure instead of insisting on a new data structure and a new database provides economies of scale and the ability of other database application to integrate directly with TimeControl.

If there is not already a client/server database environment established in the organization, then the requirement for it for just the timekeeping application is immediately suspect. Clear benefits for the project management application alone will have to outweigh the not-insignificant costs.

Existing Expertise:
If there is an established client/server database environment in the organization, then it is likely that the expertise to make it work is in house as well. The availability of such personnel are essential to reaping any benefits available to a client/server project management implementation.

Trying to add the learning curve for the support of a client/server database at the same time as attempting to successfully deploy an enterprise-wide timkeeping environment will make the likelihood of a successful implementation of the project management system questionable.

Geography:
If the projected TimeControl users are widely distributed, the access to a common database through client server may pay back immense performance benefits. A requirement of multi-user simultaneous access to a common database from users in geographically separate locations provides the clearest requirement for client/server.

Security:
Many organizations have stringent security requirements for control of timekeeping data. Using a client/server database provides many functions in the security arena including security down to the field level in some client/server databases. A departmental data structure such as FoxPro provides virtually no database security. Anyone who is granted access to TimeControl files in FoxPro format has the ability to look at any other aspect of the database if they have a mind to. If security of the database is a key concern, implementing a high-end database may be worthwhile.

The Borland Database Engine (BDE)

Using the BDE allows a single version of TimeControl to simultaneously support Oracle, MS SQL Server, Sybase, Interbase, FoxPro and Paradox. Without this we would have to either rely on the ODBC (Open DataBase Connectivity) technology from Microsoft or create a separate version for each database we support.