Concept classix
The use of so-called "standard solutions" is beyond question for many corporate decision-makers. Behind this is the idea of "not wanting to reinvent the wheel again and again", but certainly also the experience that individual software development processes were and are not always completed on time or on budget.
Consequently, after more than 40 years of EDP use in the operational environment, a wide range of application solutions with extensive functionality is available.
Many of these application solutions each fulfil specific, clearly defined tasks. If your own requirements differ from these, you have the choice of orienting the processes in your company according to the software or you try to find a software on the market that is better suited to your own company.
If one finds the standard solution that fits one's own company perfectly, the introduction of this new software more or less establishes the image of one's own company that is valid at that time.
The not infrequent wish of users for an "egg-laying wool-milk sow" is precisely what the manufacturers of application solutions are using this term to deny. Nevertheless, they try to anticipate all possible ideas of the users by means of parameterisation.
The emergence of "object orientation" in the early 1990s was seen in the software industry as a paradigm shift in its own development processes. Especially in the field of business software, there was a conviction that a changed - i.e. object-oriented - view of the processes to be modelled, of the application solutions to be created, would provide a more modular, easier to configure and thus more suitable software for the requirements of the users.
A prominent example of this was the "San Francisco project" initiated by IBM. Within the framework of this project, "business objects" were developed that could be freely combined to create finished application solutions. After completion of over 7000 different classes with over 35,000 methods, the project was discontinued.
Our concept classix had and still has the same objective as the "San Francisco project", but both concepts differ in the rigidity of the abstraction of the business objects, which are identically named in both cases.
Every experienced programmer knows the déja vu experience of having developed everything at one time or another and yet having to start from scratch with every new project. Everything seems similar and yet it is difficult to work out the similarities.
Our concept classix was to find exactly these common features, the basic building blocks for business application solutions. Ultimately, this has resulted in a software architecture to
- rapid application development,
- flexible software adaptations
- and thus tailor-made application solutions
which can keep up with the dynamics of the constantly changing companies. classix Software GmbH from Hamburg, Germany was founded specifically for the purpose of offering a new, very flexible type of software solution on the market.
Our CyberEnterprise architecture focuses specifically on business applications. With a considerable investment volume, innovative concepts and the use of the latest software technology, we have worked over the last 20 years to achieve the desired efficiency and flexibility.
The traditional, widely accepted process of application development runs through all phases, from the definition of the requirement, through the design of the data model, to the finished application.
The approach of the CyberEnterprise architecture is based on the reuse of ready-made, object-oriented components, starting with a highly abstract enterprise data model (with business objects and the more complex business patterns based on them) up to functional, as well as UX application modules of various granularity that can be combined in any way.
Another aspect of the concept classix is a strict division of labour in the process of developing a business application solution. Developments that are not related to the application - which we call basic programming - should be created by pure computer scientists, specialised versions by business computer scientists - which we call application developers - and the user-related UX operating layer should be created by ergonomists specially trained for this purpose.
;){kind=link}