(Too) many functions
Platforms provide a lot of functions. These have been enhanced and complemented over the years. In demonstrations we continue to observe that it is precisely the many functions that users and executives are impressed with: “Oh, so you can display this on a map as easy as that?” Yes, you can! And a lot more is possible which has been important for projects and been incorporated into them over the past few years. But which functions are actually useful for which projects? Which masks and views help the user and which features confuse or distract him? Many functions create a lot of possibilities. However, when assessing a platform, executives often find it hard to be critical and focus on the really important ones.
The right Basis technology
The basis technology (Java, .net..) of our OPTANO platform was chosen carefully. Which components enable the fastest calculations? Which technology allows the most efficient extension of individual functions? How can a convenient and modern user interface be created? Which technology is future-proof? These are examples of the questions which are asked when making this decision. The basis for this can change over the course of time. New technologies are developed, old ones discarded. It’s hard work for platform providers to keep their platforms up to date. Before deciding on a platform solution, its timeliness has to be looked into.
In a lot of companies there are additional requirements regarding the technologies to be used and restrictions which need to be made in order to enhance IT security (e.g. blueprint regulations). These mean that only rich clients can access databases, only old or rare browsers can be put into use, etc. These restrictions are, under some circumstances, negotiable and need to be reviewed before deciding on a platform solution!
Platforms are “only” obtainable on a license. Just like many other software products, you have to acquire the right to use a copy. Any changes to the platform itself are generally not possible – as is the case with almost all software that is deployed. Optimization solutions, however, are used frequently in crucial business processes. Therefore, many customers deem it important to have a software system that can be adapted independently of the provider. This may lead to an individual development without a platform or it may require special licensing conditions.
Best Practice for an issue
It is ideal if the platform provider has already implemented projects on the issue in question because then the client doesn’t just get sophisticated technology but also the expertise on how best to implement it. Maybe there is even a reference implementation available that gives an insight into the options available.
Best practice for general use cases
Platforms offer several concepts for various requirements of user management which have proven themselves in many projects. These are available as references for new projects, for instance how to work with scenarios, the input and output of mass data, views for data and details as tables, graphs, diagrams or networks – but also concepts to validate input and connections, managing time-consuming calculations, etc. These can be very useful when creating a new application – and alongisde the technology they can make a crucial diffeence between platforms.
If conventional concepts for certain applications change, then some concepts then quickly become “own” concepts – the Software feels unfamiliar and can bother the user. The introduction of ribbon menus as a common practice had this effect on a lot of users, for example.
A new product on the basis of a platform which has not yet been deployed in a company has to be integrated into the existing IT system. It may be obvious to users that the software looks different. Perhaps the operating concepts deviate from one or other of the available applications. Perhaps the only difference is the view and the operating elements, but it could also be that the basic concepts deviate greatly from one another. Can the users learn these differences easily?
Similar aspects are also to be observed in data integration: Can the new application access existing data? Are transformations necessary or even manual processing steps? Can optimization results be transferred back again?
A lot of research and experimenting has been carried out on quality assurance in software development. Common practices are auditing and change tracking, automated tests, manual tests, code analyses, automated and manual break-ins etc. The branch has a lot of experience in this field. The advantage of platforms is that a large part of the application has already undergone quality assurance. However, you have to bear in mind that the individual solutions can also undergo these tests. If business processes which are relevant to a company are developed on a platform, these should also meet quality requirements and be testable. There is no reason why you shouldn’t always demand information from the provider of a platform about the quality assurance measures taken on his own Solutions
Many of the challenges mentioned can be solved during a project or carefully avoided beforehand. Technical framework requirements can also be an absolute criteria. Especially when the platform provider is not willing to adapt the Basis technology to the framework conditions or – because he has no access to the source code – is not in a position to do so.
Autor: Jens Peter Kempkes