The development is based on appropriate standards.

The elegance of Epicycles is contained in its object model rather than the database. It is not only the advances in object oriented programming which led us to this design it is also the shortcomings of relational databases.

The search for an appropriate database was interesting. 

Firstly, having abandoned the distinction between materials and capacity (bills of materials and routings) it was necessary to find a database that would be efficient with not only recursive tree structures but also network structures. Not only are recursive tree structures only an extension of standard SQL we failed to find any mention of worthwhile support for network structures and the necessary traversal algorithms. 

Secondly, having drawn conclusions about rate based planning and time buckets, we perceived that some of the database functionality we required was in time series databases which are used for historical temporal data. This functionality typically occurs in two places. One is the plant historian database used to store historic analogue process data. Although functionally this may suit our requirements there is typically no facility to store data for future dates. The other is in data warehouses and analysis add-ins which unfortunately target predominantly financial data and miss some important functions. Regardless of whether the functionality is appropriate, where it is provided as an extension of SQL it is proprietary (non-standard).

The second class of database considered was the object database. However, it rapidly became clear that these had not yet reached a maturity which we required. Our logic would have to reside in our objects and the database would provide persistence.

Since we can't tackle all aspects of the technology at the same time as the non-trivial task of re-working MRP and re-working relational databases would have taken us well away from our primary focus, we have settled for using existing standard SQL based relational databases - Epicycles will work with any of them, your choice.

This simple use of the database and the advanced use of objects allows memory residence of critical data to provide high performance. The database is reliably updated after the server response has been given to the client.

There are a variety of data grid components available. Imagine it from the perspective of the user. The sophisticated user, faced with a large volume of data in a grid, typically wants to sort it, unsort it, filter it, show or hide some columns, move the columns around, insert, update and delete single or multiple rows, etc.

A simple case of a filtered set of data and an insert. The database only has one default for all conditions. If the inserted row doesn't have a value which appears through the filter the row will "disappear". With very simple scenarios we have moved past the generalised data grid / database combinations. While they can be extended we found that we eventually collided with seemingly trivial limitations to our human interface which we knew would disappoint us far into the future.

To cut the long story short we were unable to find a chart or Gantt chart which suited our purpose.

Our measure of success is that we are always accessible but our phones don't ring in the middle of the night.

In addition, both the server and the client have extensive error logging capability. Errors may be notified to a support organisation through e-mail. The inclusion of mobile phone SMS (Simple Message System) message and SNMP (Simple Network Management Protocol) is on the development agenda.

Thus, it may be that technical support services may become aware of problems within the system before the business users. Appropriate action can be taken.

There are basic diagnostics, particularly for client / server communications, available within the client. This includes a simple ping test through "server alive test", to round trip and messaging tests.

The logging system may be switched to more extensive logging to facilitate investigation of difficult support issues.

As development occurred it was also found that software components, such as charting, gantt chart, and even the ubiquitous grid, failed to satisfy the requirements of Epicycles for ease of use, speed, and functionality. Thus, most of the client human interface components have been developed specifically for Epicycles while matching the standards normally encountered within Microsoft Windows Forms applications.

The http (hypertext transfer protocol) used by the world wide web has developed so that the complex routing from client browser to server and back through proxy servers, firewalls, and network routers, is hidden from the general user. Unfortunately, a missing ingredients of the protocol is the ability for a server to raise an event with (send a message to) a particular browser when something changes. The normal, limited, approach is for the browser to periodically ask the server if anything has changed (client polling).

Epicycles has used Soap (Simple Object Access Protocol) to provide secure messaging. In addition, the Epicycles Router allows routing through multiple firewalls while also being capable of limiting communications by IP (Internet Protocol) address range, or domain,  if required. Although not yet demonstrated within Epicycles the addition of encryption is a standard part of Soap.

The Epicycles Router is always part of the client and server deployment but can also be deployed independently. Naturally, the Client, Server and Router can co-exist on the same machine if required. In addition the Router can initially be configured remotely (we say initially because if it is configured to limit access to particular IP addresses, for obvious security reasons, that also constrains the ability to configure).

The only limitation we are aware of is in our lack of support for bridged modems for some domestic applications. However, it should now be clear that our aim is to have no limits on topography.

The concept of Models within Epicycles which can be extended across multiple servers completes the design which allows unlimited network topologies to be provided by Epicycles. Hardware, software and network can be considered independently while contributing to the holistic application which is Epicycles.

The use of Soap allows wider communication and interfaces with other applications.

The concept of Seamless has been applied to the technical aspects of Epicycles in support of business objectives.