Context: Google App Engine (GAE) is a cloud computing platform, which allows developers to develop and deploy web based applications on it. It is composed of hundreds of thousands of commodity servers, distributed globally. GAE scales computing resources automatically, and developers only pay for the amount of time their application uses GAE resources. It imposes some restrictions and limitations on the design and development of applications such as execution time limit, lack of global transactions, way of communication with other applications etc. Objectives: In this study, we evaluate Google App Engine from enterprise application development point of view. We analyzed the behavior and architecture of Google App Engine to evaluate its feasibility for enterprise application development and compared it with Amazon Elastic Compute 2 (Amazon cloud service). We also studied Google App Engine storage system, Bigtable, which is a distributed non-SQL based data store. Methods: In this research study, we performed a literature study of the related cloud computing technologies and then a prototype enterprise application was developed for experiment. Results: Our literature study showed that Google App Engine has some limitations and restrictions on the development tools and environment. It does not provide support for global transaction, lacks strict consistency mechanisms, and provides highly virtualized and abstract view of the platform to the developer. Despite these limitations, the literature study and our experiment showed that Google App Engine is suited for applications with high read, searching and large write-stream operations. Google App Engine showed consistent performance as compared to Amazon Elastic Compute 2 in our experiment. Conclusions: We conclude that Google App Engine is a scalable platform while maintaining consistent performance but has some limitations due to its architecture and restrictions imposed on the development tools and environment. These limitations make it non-feasible for some types of enterprise applications, such as applications with high and intensive data computation requirement. But in other cases, such as simple data management and non-transactional applications, Google App Engine is an attractive platform.

Approved for public release, distribution is unlimited / A thorough examination of the Secure Application Integration Methodology (SAIM) for applicability in the Department of the Navy (DON) would provide useful information about a beneficial methodology. SAIM is analyzed, by accessing its step by step directions, for suitability in the integration of the Enterprise Resource Planning (ERP) projects implemented by the SYSTEMS COMMANDS (SYSCOMS). The Navy Enterprise Convergence Team (NECT) that leads the ERP integration effort could benefit from a sound Enterprise Application Integration methodology. Results do not support SAIM as the sole guiding EAI methodology however it could have some value to the NECT. SAIM has three primary benefits which NECT could employ: 1) It provides a complete walkthrough of the EAI process, 2) It emphasizes the importance of an Enterprise Architecture, and 3) It provides useful management checklists along with other important considerations. SAIM also has some significant shortcomings: 1) It does not support all the DON Chief Information Officer requirements, 2) It does not provide Change Management Guidance, 3) It does not take into account the uniqueness of the Navy's environment, and finally 4) SAIM relies on an Enterprise Architecture as its foundation which the Navy does not currently have. / Lieutenant Commander, United States Navy

Univ., Diss.--Augsburg, 2003.

Electronic message transfer is the key element in enterprise application integration (EAI) and the privacy of data transferred must be protected by the systems involved in the message transfer from origin to the destination. The recent data privacy regulation such as GDPR (General Data Protection Regulation) has enforced the organizations to ensure the privacy of the personal data handled with obligations to provide visibility and control over to the data owner. Privacy concerns with relevant to sensitive data embedded and transferred through business-to-business (B2B) middleware platforms in enterprise architecture are mostly at risk with the legacy nature of the products and the complexity of system integrations. This poses a great threat and challenge to organizations processing sensitive data over the interconnected systems in complying with regulatory requirements.  This research proposes a solution design to address the data privacy issues related to personal data handled in an enterprise application integration framework. Where electronic messages used to transfer personally identifiable information (PII). The proposal consisting of a design called “Safety Locker” to issue unique tokens related to encrypted PII elements stored in a persistence data storage based on Apache Ignite. While adding REST API interfaces to access the application functionality such as tokenization, de-tokenization, token management and accessing audit logs. The safety locker can run as a standalone application allowing clients to access its functionality remotely utilizing hypertext transfer protocol (HTTP). The design allows the data controllers to ensure the privacy of PII by embedding tokens generated from the application within the electronic messages transferred through interconnected systems. The solution design is evaluated through a proof of concept implementation, which can be adapted, enhanced to apply in EAI implementations.

Thesis (M.COM. (Business Management)) -- University of Limpopo, 2021 / Increasing consumer demand, customer expectations, and change in technology compel industrial corporations, governments and small medium enterprises (SMEs) to adopt Enterprise Application Architecture (EAA). EAA is a system where the applications and software are connected to each other in such a way that new components can easily be integrated with existing components. This study focused on how internal and external factors impact the adoption of EAA for Supply Chain Management (SCM) in SMEs, located in the Capricorn District Municipality. Data is analysed through a statistical package for the social sciences (SPSS version 25). A quantitative methodology with self-administered questionnaire was used to collect data from SMEs (SMEs owners and managers). In total, 480 questionnaires were distributed and 310 useable were returned. Cronbach’s Alpha was used to measure reliability. Data validity is obtained through the use of Kolmogorov-Sminorv-Test to ensuring that the questionnaire was based on assumptions from accepted theories as set out in the literature review. From the research findings, it was concluded that the adoption of EAA for SCM in SMEs depends on internal factors, external factors and perceived attitudes towards the adoption of EAA. The managerial implications of the study is based on actual results such as; (a) Internal factors on owners’ characteristics were described as assessment of interior dynamics affecting the enterprise, of which the management have a full control over them, such as employees, business culture, norms and ethics, processes and overall functional activities, (b) The Theory of Reasoned Action (TRA) revealed that behavioural measures on Enterprise Resources that depends on speculations about the intensions towards the adoption of EAA for SCM, (c) Compatibility in Diffusion Theory of Innovation ascertains that Technology Acceptance Models need to be linked with relevant Information System Components to have a functional EAA for SCM, (d) The Theory of Planned Behaviour (TPB) encourages apparent behaviour on control for supplementary forecaster on intentions of employees towards the adoption of EAA for SCM in SMEs, (e) The TPB encourages apparent behaviour on control for supplementary forecaster on intentions of employees towards the adoption of EAA for SCM in SMEs, (f) Consultations with government parastatals or legal representatives of the enterprise would save the SMEs against any unforeseen challenges such as product liabilities, legal costs on lawsuit, tax evasion or avoidance penalties so forth, (g) The Diffusion Theory of Innovation (DTI) proposes that the Perceived Attitudes towards the Adoption of EAA have is affected by behaviour challenges from employees’ personal conduct that affect SCM activities within the SMEs, and (h) The DTI on the intention towards the adoption of EAA for SCM provides the competence in limiting some negative thoughts about the integrative phases or steps limiting the adoption of EAA for SCM. Keywords: Enterprise Application Architecture; Supply Chain Management; Internal and External Factors Affecting Adoption; and Technology Acceptance Models

<p>U sklopu doktorske disertacije izvršeno je istraživanje vezano za<br />automatizaciju integracije poslovnih aplikacija. Prikazani pristup<br />kombinuje model strukture interfejsa aplikacija koje se integrišu sa<br />formalnim opisom njihove semantike, datim u vidu ontologije. Na<br />osnovu ovih izvora, obavlja se automatsko mapiranje među elementima<br />interfejsa koji se integrišu, kao i detekcija i razrešavanje<br />semantičkih konflikata. Razvijena je praktična implementacija<br />predloženog pristupa, koja je korišćena za verifikaciju teorijskih<br />razmatranja, a uključuje adaptivan radni okvir i jezik specifičan za<br />domen. Predloženi pristup je verifikovan na dva realna<br />integraciona scenarija i jednim eksperimentom.</p> / <p>This thesis presents a research in the field of automation of enterprise<br />application integration. The approach combines structural models of<br />interfaces of the applications being integrated with a formal specification of<br />their semantics, given in form of an ontology. Using information from these<br />sources, automated interface mapping is performed, along with detection and<br />resolution of semantic conflicts. A practical implementation of the presented<br />approach was developed and used to verify theoretical considerations. The<br />implementation includes an adaptive framework and a domain specific<br />language. The proposed approach has been verified on two real-world<br />integration scenarios and one experiment.</p>

Sensors in smart-item environments capture data about product conditions and usage to support business decisions as well as production automation processes. A challenging issue in this application area is the restricted quality of sensor SAP HANA is a pioneering, and one of the best performing, data platform designed from the grounds up to heavily exploit modern hardware capabilities, including SIMD, and large memory and CPU footprints. As a comprehensive data management solution, SAP HANA supports the complete data life cycle encompassing modeling, provisioning, and consumption. This extended abstract outlines the vision and planned next step of the SAP HANA evolution growing from a core data platform into an innovative enterprise application platform as the foundation for current as well as novel business applications in both on-premise and on-demand scenarios. We argue that only a holistic system design rigorously applying co-design at different levels may yield a highly optimized and sustainable platform for modern enterprise applications.

Due to the changing scope of data management from centrally stored data towards the management of distributed and heterogeneous systems, the integration takes place on different levels. The lack of standards for information integration as well as application integration resulted in a large number of different integration models and proprietary solutions. With the aim of a high degree of portability and the reduction of development efforts, the model-driven development—following the Model-Driven Architecture (MDA)—is advantageous in this context as well. Hence, in the GCIP project (Generation of Complex Integration Processes), we focus on the model-driven generation and optimization of integration tasks using a process-based approach. In this paper, we contribute detailed generation aspects and finally discuss open issues and further challenges.

The purpose of this project was to explore the use of Web services to solve enterprise computing problems. XML-based Web services allow complex information systems to be subdivided. In order to explore this architectural paradigm, two systems were built: an employee records sytem, and a vacation system.

Enterprise Resource Planning (ERP) systems are used to integrate all functions of an enterprise. They often evolve from a smaller monolithic object-oriented application, covering one functional area and organically grow over time in features and size until all functional areas are covered. Once they reach certain size, unrestricted dependencies among numerous classes increase complexity of the system and make it harder for development team to create new features and maintain code stability. This creates problems to further evolution of the ERP system and poses a risk to economic consequences for company developing it. ERP refactoring strategy, together with process of its creation, is presented in this thesis. It can be used with ERP systems, having architectural issues, with a purpose to improve quality of system’s architecture and thus prolong its lifecycle. The goal of modularizing monolithic system it pursued with intention to reduce complexity and make it easier to reason about the system. This architecture-level refactoring strategy is created for one specific medium-sized ERP system through iterative trial-and-error explorative approach. This thesis is carried out at the main development site for this ERP system by project team consisting of employees working on its development. The result shows the RefStratERP, an innovative refactoring strategy consisting of target architecture, refactoring process to reach it, refactoring principles and refactoring limitations. Contrary to initial expectation, arranging domain modules (modules containing business logic) in directed acyclic graph (DAG) is, in general, not feasible without sacrificing internal module cohesion of business logic. Accidental unidirectional dependency between two domain modules is at risk of becoming bidirectional under changing business requirements. On the other hand, non-domain modules (modules without business logic) could be completely separated from domain modules in a way that domain modules depend on non-domain modules. This comes from underlying nature of business domain and the fact that functional areas of an enterprise are interdependent. / Enterprise Resource Planning-system (ERP) används för att integrera alla funktioner inom ett företag. Oftast utvecklas dem från en mindre monolitisk objektorienterad applikation som täcker ett funktionellt område och växer organiskt över tiden i funktioner och storlek tills alla funktionella områden är täckta. När dem når en viss storlek ökar komplexiteten i systemet vilket gör det svårare fär utvecklingsteamet att skapa nya funktioner och hålla kodstabilitet. Detta skapar problem för fortsatt utveckling av ERP-systemet och utgör en risk för ekonomiska konsekvenser för utvecklingsföretaget. ERP refactoringstrategin, tillsammans med processen med att skapa den, presenteras i denna avhandling. Den kan användas med ERP-system, med arkitektoniska problem, med syfte att förbättra kvaliteten hos systemets arkitektur och därigenom förlänga dess livscykel. Målet att modularisera monolitiska system strävas efter i syfte att minska komplexiteten och göra det lättare att resonera kring systemet. En refaktorstrategi på arkitektnivå skapas för ett specifikt medelstort ERP-system genom en iterativ och försök-och-mistag-explorativ metod. Projektet genomfördes på ERPs huvudutvecklingsplats av ett projektteam bestående av anställda inom ERP utveckling. Resultatet visar RefStratERP, en innovativ refaktorstrategi som består av målarkitektur, refactoringprocess för att nå det, refactoringprinciper och refactoringbegränsningar. I motsats till inledande förväntningar är det i allmänhet inte möjligt att ordna domänmoduler (moduler som innehåller affärslogik) i en riktad acyklisk graf (DAG) utan att påverka interna modulsammanhang (cohesion) i affärslogiken. Oavsiktlig enriktad beroende mellan två domänmoduler riskerar att bli dubbelriktad under förändrade affärsbehov. Å andra sidan kan icke-domänmoduler (moduler utan affärslogik) helt separeras från domänmoduler så att domänmoduler beror på icke-domänmoduler. Detta kommer från underliggande egenskaper av affärsområden och det faktum att verksamhetsområden inom ett företag är beroende av varandra.