{"id":107578,"date":"2023-02-15T12:00:00","date_gmt":"2023-02-15T12:00:00","guid":{"rendered":"https:\/\/industry-science.com\/?post_type=article&p=107578"},"modified":"2025-02-05T16:51:29","modified_gmt":"2025-02-05T15:51:29","slug":"application-system-architectures","status":"publish","type":"article","link":"https:\/\/industry-science.com\/en\/articles\/application-system-architectures\/","title":{"rendered":"Determining Sustainable Application System Architectures"},"content":{"rendered":"\n

Quick and efficient adaptation ensures a company’s success, especially in the event of sudden changes in the corporate world. Companies must thus strive to create a versatile enterprise architecture in which business processes, application system architecture and application landscape are closely linked to one another.<\/p>\n\n\n\n

In practice, it can be observed that older systems in particular usually have insufficient adaptability, i.e. changed business processes can only be mapped incompletely and not efficiently. Therefore, the question of the long-term adaptability of ERP systems, for example, is of central importance [1].<\/p>\n\n\n\n

From a systems theory perspective, adaptability represents the ability of a system to adapt itself efficiently and quickly to changing requirements and to develop patterns of action for this adaptation [2, 3]. <\/p>\n\n\n\n

Criteria of adaptability <\/h2>\n\n\n\n

The adaptability of application systems can be determined based on two dimensions [4], the first of which considers adaptability as a technical (system-based) characteristic that indicates the inherent potential of an application system to handle changing requirements. This is determined using criteria. <\/p>\n\n\n\n

This article takes the indicators of scalability, modularity, mobility and interoperability found in factory planning and reinterprets them in this context to describe the adaptability of application systems. For example, the mobility indicator is subdivided into inde\u00adpendence and availability. Consideration of auto\u00adpoietic systems contributes the additional indicators of self-organization and self-similarity. Knowledge of the system is also relevant, and is thus included in the criteria (see Fig. 1<\/strong>). <\/p>\n\n\n\n

Scalability <\/h2>\n\n\n\n

Scalability means insensitivity to quantitative fluctuations. This indicator requires efficient adjustment both upwards and downwards to account for changing amounts of information that need to be processed. This can be achieved through both software and hardware architecture. The automatic addition and removal of resources such as storage or computing power can be used to ensure smooth system operation [6]. <\/p>\n\n\n\n

Modularity <\/h2>\n\n\n\n

Modularity generally means structuring a system into small, semi-autonomous and clear subsystems. These subsystems represent the so-called modules. This means that individual modules can be removed with little effort, replaced by others or added to another system. Modularity therefore indicates an opportunity to efficiently combine, reuse and quickly change applications. <\/p>\n\n\n\n

\"Criteria
Figure 1: Criteria for the adaptability of ERP systems [5]<\/em>.<\/figcaption><\/figure>\n\n\n\n

Availability <\/h2>\n\n\n\n

The criterion of availability stands for unlimited access to an application independent of time and place. Ideally, the system can be accessed and used with any relevant medium, regardless of time or location.<\/p>\n\n\n\n

Independence <\/h2>\n\n\n\n

A system must be able to act independently of other systems. On the one hand, this means that there are no dependencies or restrictions on the operating system or hardware (platform independence), but on the other hand, it also means that a system failure must not impact the other systems. This requirement already implies the necessity of backup strategies and redundancies for important subsystems. <\/p>\n\n\n\n

Interoperability <\/h2>\n\n\n\n

Interoperability refers to the ability of applications to interact and work together with other systems and to perform operations or functions that span multiple systems. Regardless of the hardware, operating systems or network technology used, cooperation between these applications can take place. Interoperability allows easy access to different data and processing resources within a workflow and facilitates ease of connection between different application systems. <\/p>\n\n\n\n

Self-organization <\/h2>\n\n\n\n

Self-organization refers to the ability of a system to use self-controlling and regulating mechanisms to determine system structure and functionality based on its own performance processes, ensuring the long-term viability of the system [3]. Self-organization of ERP systems is achieved when they are able to fully or partially determine their own internal structure or architecture. An example is the Internet, whose structure is determined solely by the number of connected servers. Based on a scant few standards, almost all tasks on the Internet are carried out decentrally. <\/p>\n\n\n\n

Self-similarity <\/h2>\n\n\n\n

Self-similarity describes the ability of a system to merge and divide in order to continually repeat the same patterns in terms of structure or functionality on a different scale. Self-similar and self-organizing elements lead to autopoietic system behavior, which has a positive effect on the adaptability of ERP systems [6]. An advantage, for example, is that it is easier to learn how to operate application systems that rely on a recurring operating philosophy across different levels and platforms.<\/p>\n\n\n\n

Knowledge <\/h2>\n\n\n\n

Knowledge facilitates adaptability. Each element of the information system architecture can possess knowledge. The human elements of the system have process and specialist knowledge, while the technical components of the system can hold knowledge, e.g. in the form of self-description skills. If desired, an interface can provide information about the formats in which it expects data to be transferred.<\/p>\n\n\n\n

Determination of adaptability <\/h2>\n\n\n\n

During the operational lifespan of an ERP system (which encompasses ten or more years), the discrepancy between the organizationally necessary and actual representation of business processes in the system often increases. Only when the disadvantages of the lack of accurate mapping of business processes become particularly burdensome will the system in use be completely replaced. This decision generally entails high investments, a long implementation phase and high reorganization costs. <\/p>\n\n\n\n

The investigation of the adaptability of application systems is based on a special architectural model (see Fig. 2<\/strong>). This model defines the individual areas of consideration in the form of layers, whose technological implementation can be evaluated using the (technical) criteria presented in the previous section. <\/p>\n\n\n\n

\n
\n
\"Architecture
Figure 2: Architecture model for adaptable application systems [1].<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n\n
\n

The base layer is the data storage layer, in which databases and the associated database management system are combined. Building on this is the application layer, which contains the functions of the application. The interface to the user is called the presentation layer. The architectural model for versatile ERP systems expands the established 3-layer model with a control layer that represents the modeling of business processes. This modeling is linked to the elements of the other layers, such as data and functions.<\/p>\n<\/div>\n<\/div>\n\n\n\n

If changes are made to the modeling within the control layer, these are transferred to the other elements. Below the data layer is an infrastructure layer. An adaptation layer runs vertically through all other layers and contains the adaptable elements of each layer. The customizable settings present in typical corporate application systems are assigned to the adaptation layer. The interfaces between the individual layers, which may need to be examined separately, are designated by numbers 1-9.<\/p>\n\n\n\n

Based on the properties of adaptable application systems, adaptability of a system in question can be determined using a process model (see Fig. 3<\/strong>), with results in the form of a condensed key figure. <\/p>\n\n\n\n

\"Process
Figure 3: Process model for determining adaptability [7].<\/em><\/figcaption><\/figure>\n\n\n\n

To determine the technical adaptability, the actual application system, its architecture and functions are considered. Using a questionnaire, each layer found in the system is examined to see if it meets the criteria, and is allotted a point value based on this. The quality of the adaptation layer in each individual layer of the reference model is queried using this questionnaire. For example, scalability of the data layer is assessed, among other things, by the question \u201cCan the database size adjust automatically?\u201d<\/p>\n\n\n\n

When determining business-specific adaptability, we measure how the system implements changes in the business process or whether it is possible to change the configuration of the system while in operation. Business-specific adaptability is determined with the help of industry-specific use cases (see Fig. 4<\/strong>). So-called reorganization types are used. For each type of reorganization, there are questions that need to be answered on a multi-level scale. Every company-specific change can be assigned to one or more reorganization types, meaning that all changes can be mapped using four basic types [6]. <\/p>\n\n\n\n

The first reorganization approach covers restructuring approaches that require subsystem formation, i.e. the assignment or splitting of task processing into individual, autonomous subsystems. <\/p>\n\n\n\n

\"Scenarios
Figure 4: Scenarios for business-specific adaptability.<\/em><\/figcaption><\/figure>\n\n\n\n

The second reorganization approach restructures the processes themselves. The way business processes are handled is aligned or adapted to accompany the supply chain. Continuous reorganization is a third reorganization approach that looks at the company over time and includes both the formation of subsystems and the alignment of processes with the supply chain. <\/p>\n\n\n\n

The fourth approach involves the dissolution of system boundaries, in which the supply chain e.g. is expanded beyond the bounds of the company and thus requires collaboration with other systems [6]. <\/p>\n\n\n\n

Application at an automotive supplier <\/h2>\n\n\n\n

In order to assess the future viability of the application systems of an international automotive supplier, their technical and business-specific adaptability was evaluated (see Fig. 5<\/strong>). The supplier\u2019s ERP, MES, BI, HR, Office, QM, Quality Planning, EDI, email software and databases were all considered. The aim of this assessment was to check whether sustainable use of the systems is possible against the background of changing market requirements or whether individual systems need to be replaced.<\/p>\n\n\n\n

\n
\n
\"Integrated
Figure 5: Integrated future viability analysis of the application systems.<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n\n
\n

The result in Figure 5<\/strong> demonstrate that most of the application systems used were assessed as sufficiently technically and functionally advanced. Systems in the technically advanced area are technically very versatile, but this is offset by a low adaptability to changes in business processes. One reason for this may be a limited form of the control layer. Systems in the functionally advanced area are characterized not only by their technical versatility, but also by their ability to adapt in functionality. It can also be seen that some systems are in the average range. These should be viewed as sufficiently adaptable, both on technical and business-specific level, but nothing more. The area of future viability stands for a very high level of both dimensions and represents the ideal target area for companies whose processes are very dynamic. <\/p>\n<\/div>\n<\/div>\n\n\n\n

Systems are classified here that have a high degree of adaptability in both dimensions. In the present use case, the email system and corresponding database solution are at the lower end of acceptable in terms of business-specific versatility. Overall, it can be seen that all of the systems evaluated have some potential for expansion in terms of business-specific adaptability, but most of them are sufficiently technically advanced.<\/p>\n\n\n\n

This article was written as part of the Junior Research Group ProMUT \u201cSustainability Management 4.0 – Transformative Potential of Digitally Networked Manufacturing for People, Environment and Technology\u201d (Reference number 01UU1705B), which is funded by the German Federal Ministry of Education and Research as part of the \u201cSocial-Ecological Research\u201d funding initiative. <\/em><\/p>\n

Bibliography <\/h2>[1] Gronau, N.; L\u00e4mmer, A.; Andresen, K.: Entwicklung wandlungsf\u00e4higer Auftragsabwicklungssysteme. In: Gronau, N.; L\u00e4mmer, A.; Andresen, K. (ed): Wandlungsf\u00e4hige ERP-Systeme, 2nd Edition. Berlin 2007.\r
[2] Weber, E.: Erarbeitung einer Methodik der Wandlungsf\u00e4higkeit. Berlin 2015.\r
[3] Ullrich, A.: Eigenschaften wandlungsf\u00e4higer Systeme \u2013 Erarbeitung eines Indikatorsystems. Berlin 2018. Dissertation. DOI:10.30844\/ullrich-a_2018.\r
[4] Andresen, K.; Gronau, N.: An Approach to Increase Adaptability in ERP Systems. In (Mehdi KhosrowPour Hrsg.): Managing Modern Organizations with Information Technology: Proceedings of the 2005 Information Resources Management Association International Conference. San Diego, CA, USA (May 15, 2005). Idea Group Publishing 2005, p. 883.\r
[5] Gronau, N.: Enterprise Resource Planning. Architektur, Funktionen und Management von ERP-Systemen. 3rd Edition. M\u00fcnchen 2014\r
[6] Gronau, N.: Wandlungsf\u00e4hige Informationssystemarchitekturen \u2013 Nachhaltigkeit bei organisatorischem Wandel. 2nd Edition. Berlin 2006.\r
[7] Andresen, K.; L\u00e4mmer, A.; Gronau, N.: Vorgehensmodell zur Ermittlung der Wandlungsf\u00e4higkeit von ERP-Systemen. In: F. Lehner, H. N\u00f6sekabel, P. Kleinschmidt (ed): Multikonferenz Wirtschaftsinformatik. Berlin 2006<\/div>

Your downloads<\/h2>