Normalized Systems theory provides an important practical way of developing evolvable information systems, even huge application systems for organizations. The purpose of the paper is to present an analysis of the analysis patterns of the well-known Microsoft Dynamics CRM 2016 adhering to the design patterns of Normalized Systems theory.
At present, one of the most challenging aspects of designing enterprise information systems is evolvability. ERP systems are costly and time-consuming to developed. Moreover, ERP systems have extremely complicated structures, and therefore, they are not easy to implement. Due to both the complexity of ERP Systems and organizations' requirement for customized solutions to serve their business objectives, ERP systems should be evolvable. Here, evolvability means software should be easy to change over time [1, 2].
To ensure the evolvability of information systems that adhere to Normalized Systems theory, it has been argued that that information systems should be developed without combinatorial effects. Combinatorial effects occur when the impact of a change depends on the size of the information systems. To increase the evolvability of information systems, these combinatorial effects should be minimized. To date, a number of studies have already been done on Normalized Systems theory and implemented in several software projects [2-4]. Nevertheless, the analysis pattern of ERP packages applying Normalized Systems theory has a number of limitations.
Normalized Systems theory provides a practical way of developing evolvable information systems through the so-called pattern expansion of software elements [3]. Copyright © by the paper’s authors. Copying permitted for private and academic purposes. In: Aveiro et al. (Eds.): Proceedings of the EEWC Forum 2017, Antwerp, Belgium, 09-May-2017 to 11-May-2017, published at http://ceur-ws.org 2.1
To guarantee high evolvability of information systems, Normalized Systems theory proposes four theorems such as Separation of Concerns, Data Version Transparency, Action Version Transparency, and Separation of States [2]. Furthermore, how the four Normalized Systems theorems are manifested in a practical way is shown in Table 1.
Five expandable elements were proposed to ensure the evolvability of Normalized Systems applications. The internal structure of these five elements is described by Normalized Systems design patterns such as data elements, action elements, workflow elements. connector elements, trigger elements [2-4]. 3
In this section, we examined the
Here, our aim is to examine conformance between the model of Microsoft Dynamics CRM and Normalized Systems principles.
Based on the NS theorems, most of the model of Microsoft Dynamics CRM seem to be related to the NS principles. Firstly, the Microsoft Dynamics CRM architecture is the Multi-tier architectures. Moreover, the Microsoft Dynamics CRM implements cross-cutting concerns, for example, Reporting (Dashboards, Charts, Excel and SRS), Security model that focuses on access rights to the entities in the system [6-8]. For first and second points straightforwardly follow from the Separation of Concerns theorem.
According to the Data version transparency theorem, focusing on the interaction between data and action entities. Data Version Transparency implies that data entities can be modified (insert, delete, update) without affecting the calling actions [9]. In Microsoft Dynamics CRM, the information hiding has been applied to develop the software. Properties cannot be directly accessed, but can be read or written by using provided-method. Additionally, Microsoft Dynamics CRM has been implemented using XML-based technology that leads to conformance with the Data Version Transparency theorem.
Following the Action version transparency theorem, this theorem implies an action can be modified without affecting the calling actions. First, Microsoft Dynamics CRM is usually implemented through wrapper functions through the use of polymorphism in C#.NET or VB.NET. Second, the Microsoft Dynamics CRM implements cross-cutting concerns as explained above. Therefore, the developing of Microsoft Dynamics CRM relates the Action version transparency theorem.
The Microsoft Dynamics CRM relies on asynchronous service to improve overall system performance and scalability [10]. Combinatorial effects can be avoided through asynchronous processing. 3.2
When analysing the analysis patterns of Microsoft Dynamics CRM, some indications towards violation of the Normalized Systems principles might be noticed. Microsoft Dynamics CRM addresses challenge of customer management, therefore, this module was analysed in point of evolvability. We noticed that there is duplication of attributes about address details in many classes such as Account, Contact, Address, Lead, LeadAddress, Quote, Invoice, and Order. Attribute duplication seems contradictory to the Normalized Systems theorem, Separation of Concern. According to the assumption of unlimited systems evolution, software can be changed over time. Therefore, the eventual impact might become related to the overall system size and lead to a combinatorial effect. 4
In this paper, we analysed the analysis patterns of ERP package, Microsoft Dynamic CRM, to explore conformance with Normalized Systems theory and violations against it. While the interpretation of the analysis patterns of ERP package shows some conformance towards Normalized Systems theory, also some analysis patterns towards violations of Normalized Systems. The finding was found the developing well-known commercial ERP system seems to relate Normalized Systems theory both four theorems and five elements [5, 9]. On the other hand, a few points seem to contradict Normalized Systems principles. Similarly, the finding of Mendling et al [11], there are some error probabilities in enterprise models.
The limitations of our study need to be acknowledged. We only analysed partial analysis patterns of one ERP package. As part of future research, we will redesign and rebuild the existing data model of existing ERP software packages based on Normalized Systems theory. In practice, we will rebuild existing ERP packages using the Normalized Systems expander to obtain high evolvability. 5 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.