We developed several software and portal projects for a company, including a chemical testing system for checking and evaluating chemical substances. In addition, we created a filing component for online services and features for managing field service activities. We handled the entire software lifecycle, from requirements through to rollout, and continued to support the solutions in live operation.
Initial situation
The client was a company that needed several specialist software components within its digital environment. These included a system for checking and evaluating chemical substances, a filing component for online services, and features for managing field service activities.
The task was to implement these requirements as bespoke software and cover the entire path from requirements gathering to rollout. In addition, the applications were to be maintained and optimised in operation.
Solution
We implemented the requirements as bespoke web development based on .NET. The scope of the project included a testing and evaluation system for chemical substances, a filing component for online services, and features for managing field service activities.
Our work covered the complete software lifecycle, from requirements through to rollout. The implementation was based on .NET WebForms and SOAP interfaces. SOAP is a standardised protocol for structured data exchange between applications. We then also took on maintenance and optimisation in live operation.
The project ran from 2011-11 to 2013-07. The team size was 1.
Result
We delivered several completed software and portal components for different specialist tasks: a testing and evaluation system for chemical substances, a filing component for online services, and features for managing field service activities.
The project was completed and ran for 21 months. In addition to development through to rollout, the scope of services also included maintenance and optimisation in operation.
Technology
The following technologies were used:
- C# and Visual Basic to implement application logic
- .NET Framework as the technical foundation of the applications
- ASP.NET WebForms for the web applications and portal components
- JavaScript and jQuery for browser-based functions; jQuery is a library that simplifies typical processes in web interfaces
- SOAP for interfaces between systems
- MS SQL Server for data storage
Why bespoke software makes sense for a chemical testing system
A chemical testing system usually reflects specialist rules that are closely tied to internal processes, data sources and responsibilities. In projects like these, standard software is often only suitable to a limited extent, because testing workflows, evaluations and approvals are not organised in the same way everywhere. Bespoke software is the right choice when the system needs to adapt to the working process, rather than the other way round.
It is also typical for such a system not to work in isolation. It processes master data, takes in inputs from specialist departments, passes results on to other applications and must provide results in a traceable way. That is why the business logic should be clearly separated from the interface, data storage and interfaces. Business logic means the rules by which the system evaluates inputs and produces results. Clean separation makes changes easier when processes, data sources or reporting obligations change.
For decision-makers, it is important to classify the nature of such a project correctly at an early stage: it is not just about screens and database tables, but about a reliable working tool with traceable processes. In comparable projects, this usually includes a browser-based interface, structured data storage and database development, interfaces and data migration, so that information remains exchangeable between the systems involved.
Operation is just as important. Specialist applications with testing and evaluation functions are often used over a longer period and expanded step by step. That is why it pays to consider maintainability from the outset: clear responsibilities within the system, understandable data structures and an orderly process for adaptations. Maintainability means that changes can be made without triggering unnecessary side effects in other areas.
As soon as topics such as data protection, traceability, retention or access rights are involved, the specialist and organisational requirements should be reviewed separately. Whether requirements from contracts, internal policies or legal frameworks have to be met should be coordinated with the responsible specialist departments and, where needed, with legal advisers or data protection officers. This creates a system that is not only functionally suitable, but also planned on a sound organisational basis.
How similar projects are typically implemented
In comparable projects, the work begins with a proper clarification of the specialist objective. Decision-makers should define early on which substances, test characteristics, evaluations and roles the system is meant to cover. It is just as important to ask which existing applications need to be connected and which information is authoritative there. Authoritative means that one system is the decisive source for certain data.
This is usually followed by a concept for processes, the data model, interfaces and system interfaces. A data model describes which information is stored and how it is logically related. In a chemical testing system, this step is especially important because test objects, results, processing statuses and evaluations often build on one another. If this structure is defined too broadly too early, unnecessary detours arise later in reports, screens or integrations.
During implementation, the individual components are then developed step by step and aligned regularly from a specialist perspective. Especially with specialist systems, it makes sense not only to show views, but to review real processing workflows at an early stage: which inputs are required, when something is saved, how results are displayed and passed on to other systems. This brings misunderstandings to light earlier.
Typical work packages in projects like these are:
- Clarifying specialist workflows and roles
- Describing the data structure and interfaces
- Designing interfaces for capture, testing and evaluation
- Preparing integration, tests and rollout
- Planning operation, maintenance and later enhancements
After go-live, the project usually does not end from a specialist point of view. In practice, adjustments often follow because processes are refined, new data sources are connected or evaluations are expanded. That is why the project plan should already define how changes are commissioned, assessed and transferred into operation. If you would like to structure a similar project, you can use the Project Check to prepare a solid starting point from a description or a specification document.
What matters for interfaces, data and operation
Most of the risks in comparable specialist applications do not lie in individual screens, but in the transitions between data, rules and operation. A chemical testing system must process information consistently. Consistently means that the same data matches in content at all relevant points and does not become contradictory. That requires clear responsibilities, validation rules for inputs and unambiguous procedures for changes.
Interfaces are a particularly sensitive topic here. An interface is the defined connection through which applications exchange data. Even small ambiguities in fields, formats or processing statuses can lead to data being misinterpreted or transferred incompletely. That is why those responsible should clarify at an early stage which systems are involved, when data is transferred and how errors are identified and handled.
Operation should not be treated as an afterthought either. Specialist applications are used, maintained and expanded in day-to-day work. This requires a sound concept for monitoring, error handling, permissions and changes. Permissions define which people are allowed to see or edit which data. Especially in applications with testing and evaluation functions, it makes sense to plan access and responsibilities carefully.
In addition, typical cross-cutting topics should be considered from the outset:
- Data quality during capture, import and change
- Traceability of processing statuses and results
- Robustness in the event of interface errors and incomplete data
- Maintainability when adding specialist enhancements
- Operating model for hosting, updates and support
If an application is to be operated in the cloud or within an existing system landscape, technical and organisational decisions should be made early. These include responsibilities, approval processes and how disruptions are handled. If legal issues such as data protection, retention or accessibility are involved, these points should not be assumed on technical grounds, but reviewed with the relevant departments. For planning implementation and operation, it can also be useful to look at hosting and operation in the Microsoft Cloud (Azure) if you are looking for a suitable operating model.
Frequently asked questions
Which factors influence the cost of a project like this?
In projects like these, costs depend above all on the specialist complexity, the required interfaces, the data structure, the evaluations and the planned operating model. Added to this are requirements for roles, approvals, maintenance and future extensibility. The more clearly the requirements are described, the better the effort can be assessed. For an initial indication, the cost calculator is useful; if you already have more concrete documentation, the Project Check is the better option.
How long does it take to implement a chemical testing system?
The duration can only be derived from the specific requirements. In comparable projects, the key factors are above all the need for specialist coordination, the number and quality of existing interfaces, the state of the source data, and whether only a core system is to be built or portal functions and operation also need to be prepared. It is sensible to structure the project early into clear components and dependencies so that decisions can be made in good time and unnecessary detours avoided.
What is the best way to plan a specialist system like this?
A proven approach is to clarify the specialist process, data sources, roles and results first, and only then define interfaces and technical details. This makes it clear which information is actually needed and which rules the system has to support. This is followed by the concept, implementation, testing, rollout and operation. Regular specialist coordination is important. If you would like to discuss a similar project, a no-obligation initial consultation is a sensible starting point.
What risks typically arise in projects like these?
Common risks are unclear specialist terminology, contradictory data sources, underestimated interfaces and operational questions considered too late. Rules that are known only implicitly and not properly documented are just as problematic. This later leads to misunderstandings in development and acceptance. Countermeasures include precise requirements gathering, an early view of real workflows, clear responsibility for data, and proper planning of maintenance and changes.
What needs to be considered for the later operation of such a system?
For operation, responsibilities, permissions, error handling, change processes and the technical environment should be defined early. Monitoring, data backup and a clear approach to interface disruptions are just as important. If the system processes sensitive or regulated information, organisational requirements should be reviewed separately. ballmüller solutions supports projects like these from the concept stage through to further development; for an initial assessment, the Project Check can also be used.
