TRIAD is a complete software management solution for distributed computer repair centers. It consists of a complex infrastructure aimed at providing interconnected services.
It’s the successor of LabManager, redesigned to be used by a large computer service chain.
The main goal is to handle all repair and triage jobs in a standardized workflow, which is connected to external systems that provide additional features and integrations.
The platform is designed to support a medium number of users, in the order of hundreds, scattered in a relatively large geographical area.
The FileMaker rapid application development (RAD) platform was a crucial asset for the production, and it was explicitly asked by the client.
Among the extensions
After studying thoroughly the business requirements and producing a 70-page Software Requirement Specification document, develompent started in early july 2017 with the aim to create a working prototype of the workflow and login subsystems. I proceeded to study a series of software patterns for the FileMaker platform in order to make it "less poor" from a serious development perspective.
As I foresaw in the requirements phase, performance has always been an issue, and advanced techniques were required in order to get a good compromise between usability and complexity. After nearly a week of intensive work dedicated to the topic, I finally found a way of dividing the code responsabilities in a reasonable way without impacting performance. Network latency is a critical requirement for an usable interface (the client interfaces with a proprietary protocol), and the Google Cloud Platform was chosen as one of the best services with this parameter in mind.
A formal and complex state machine was developed through the use of standard UML diagrams, and that included various parts of the workflow. The initial aim of covering every possible path of the support jobs seemed impossible initially, but in the end we figured out an excellent model that with minimal adjustments could handle every possible situation including shipments, queues, external laboratories, partners, estimates and tests. Also the inventory and part management model proved to be a difficult one to think, as it required to adapt to many different sources for the parts, each with different demands.
Also a very complex problem that seemed seemingly innocuous was the Google OAuth subsystem, which required the development of a web component, which would then become the base for the API that interfaces to the external portals.
In the end of August 2017, I presented my results to the stakeholders, and the response was very positive. They all shared ideas and concerns in a constructive way, the replacement of their old software with this solution was very welcome among the service managers. A custom-made contract with specific source code rights was created for the purpose of regulating the sale.
Until November 2017, the software went down an intensive development time, where every requirement was kept under control in a very large GANTT diagram I created for the purpose. Testing was performed initially in an isolated environment, then with a test group and finally with a small installation in the nearest location. Some difficulties were encountered during the first use, which gave the perfect vision for where to improve the foundations. Intensive development continued until January, when the software was put in production for two locations in total and the develompent of the additional web modules was started.
Between February and April 2018 four more applications were developed, the client portal, the partner portal, the dashboard and the statistics module. The first three are complete client-side Angular applications, interfaced through a custom-made API running on Node.JS that interfaces with FileMaker Server through HTTP calls, providing a strong abstraction over the poorly-designed API provided by the mentioned RAD platform.
Deployment took place between May and August 2018, it involved a huge effort from different parties, and fueled a continuous bug-fixing process aimed at making the whole thing very stable. An automatic bug reporting procedure was added, and it dramatically helped to spot internal inconsistencies and exceptions.
Additional requirements were added and developed in record time, while the platform became more and more complex yet still perfectly documented and manageable. As of November 2018 the system is installed in more than 14 locations with up to 50 active users, and it continues to grow and get better with new details and fixes every week. Thousands of new jobs are created every month.