An Effortless Approach for Migrating from Legacy Software Systems to Web Services

One of the vital reasons for reverse engineering legacy software systems is to make it inter-operable. Moreover, technological advancements and changes in usability also motivate reverse engineering to exploit new features and incorporate them in legacy software systems. In this context, Web services are emerging and evolving as solutions for software systems for business applications in terms of facilitating interactions between business to business and business to customers. Web services are gaining significance due to inherent features like interoperability, simple implementation, and exploiting the boom in Internet infrastructure. Thus, this work proposes a framework based strategy using .net for effortless migration from legacy software systems to Web services. Further, this work also proposes that software metrics observed during the process of reverse engineering facilitate design of Web services from legacy systems.

Business Risk Analysis

Up until now, efficient and applicable project methodologies, process improvement methodologies, product improvement methodologies, and relevant software engineering best practices have been developed and successfully implemented in many software projects in a variety of industries. However, projects still fail. Most of the project failure factors are diagnosed; however, some may fall through holes or gaps and get overlooked due to unknown reasons. The basis of this research study is a comprehensive questionnaire with relevant and probing questions that have collected data on obsolescence of requirements. Through analysis of the gathered data and information, this study aimed to present these risk factors, their impact, and a possible way to measure them. The critical factors identified and the result of this research project can be a trigger to conduct further in-depth analysis of project risks based on categories of projects (maintenance & support projects, development projects, data conversion projects, etc.), or rather, analysis of projects based on the business area/function. This research study is another attempt to assist in turning IT project failures into project successes.

Critical Issues to Consider when Evaluating Inter-Organizational Process Integration Configurations

Networks of companies can use a range of configurations to create inter-organizational processes. Problems become apparent when partnering companies decide to set them up. Those problems take a different form in centralized and decentralized inter-organizational process-integration scenarios. This chapter identifies eight process issues to be taken into account when evaluating inter-organizational integration configurations: difficulties to identify when a task should be executed, understanding what a task does exactly, agreeing how to trigger tasks, distributing investments among parties, delivering appropriate service levels, preserving value of the inter-organizational process, process ownership clarity, and managing in the frame of changing relationships. Examples are given of how problems arise in a completely centralized and in a completely decentralized inter-organizational process integration scenarios.

Component-Based Modeling for Information Systems Reengineering

An Information System can be envisioned as a set of interdependent components that provide the intended services. The component based modeling serves as a tool for collecting requirements of an Information System in user perspective and business perspective at various stages of software development. The chapter presents a methodology for component based modeling and development of an Information System, starting from the requirements definition phase, arriving at candidate components and creation of final components and their interfaces. The methodology aims at clarifying the intricate details and usage of an Information System via business type models and use-case models. The chapter presents the interaction diagrams in order to describe interactions among objects in systems perspective, and context diagrams for reflecting upon the business domain. Finally, the chapter proposes component replacement as a methodology for system reengineering, and model-view-control framework for component refinement and evolution in order to achieve a reengineered information system that reflects upon current requirements in business domain. The reengineering techniques proposed in this chapter can be applied to legacy systems to turn them into a component-oriented reengineered system.

Traditional Data Oriented versus Process Oriented Reengineering of Legacy Systems

The chapter presents data oriented and process oriented models of legacy systems. It discusses the details of systems development and evolution models mainly aiming at an ongoing reengineering of legacy systems. It proposes few strategies for reengineering of both data oriented model and process oriented models. The legacy systems often miss automatic interfaces to external systems, so the chapter presents a strategy focusing on automatic update of data of the system. Likewise, the chapter also presents a strategy for process reengineering in order to integrate external systems. Finally, a legacy system is envisioned as a comprehensive mix of both data and process oriented, while proposing a gradual ongoing reengineering of both data structures and process methods.

From an Ad-Hoc to a Proactive Software Release Plan and Deployment

Managing software and its various components such as maintenance, upgrades, and patches, has become a requirement to secure one’s place in a competitive market. The rapid change in engineering software, especially for the Aerospace industry, highlights the importance of software management. Negligence of any maintenance component can put the organization into risk. Therefore, standardizing processes are necessary to avoid not only these risks, but also minimize costs and ensure employee productivity. Currently, an Aerospace company upgrades most of their engineering software on an ad-hoc basis. This means that an upgrade is only done when an end-user requests it. The study will therefore examine the current operations and offer a strategic reengineered process. The objective of such changes is to ultimately streamline the distribution of engineering software upgrades proactively throughout the organization.

Reengineering for Enterprise Resource Planning (ERP) Systems Implementation

Reengineering is a concept that is applicable to all industries, particularly information and communication technology (ICT) projects regardless of organizational type, size, culture, or location. The enterprise resource planning (ERP) system frequently requires organizations to change their existing business processes to harmonize them its functional activities. 72% of the ERP implementation failures reported worldwide (Eric, 2010) because of the various critical success factors (CSFs). A Critical Success Factor (CSF) is defined as a factor needed to implement ERP system successfully. Assessing the importance of CSFs of Enterprise Resource Planning systems has always remained an important concern for academicians and researchers. This study explores and assesses the CSFs affecting the ERP implementation success. Long term Top management Support (LTS), Perceived ERP benefits (PEB), ERP in-house Training (EIT), Project Tracking (PTG), Visible Project Phases (VPP), Project Phase Update (PPU), Interdepartmental Cooperation (IDP), Strategic IT planning (STP), ERP vendor Support (EVS), and Data Analysis and Conversion (DAC) were found dominant critical factors for the success of the ERP implementation in the manufacturing sector. This study investigates how many CSFs are strongly correlated with each other for the success of ERP projects in the manufacturing sector. Furthermore, this study also tests empirically using the Statistical Package for Social Science Analysis of Moment on Structures (SPSS AMOS 18.0) to justify the level of CSFs among the local and joint-venture companies using a t-test analysis.

Risk Management and Business Processes Reengineering, Success Drivers for ERP Projects

By using a case study example and focusing on the implementation phase, this chapter presents and emphasises the validity of specific risk management model. Briefly, an overview of another two ERP projects risk management’s models will be provided; the first model deals with ERP as technology where risks are managed in accordance to Information Technology and Information System (IT & IS) projects governance. The second model considers the integrated and interdisciplinary nature of ERP systems and introduces the term “ERP Governance” as a model that demands balance between IT and business governance. The third model, while similar to the second, relies heavily on best-practises and assessment frameworks from the industry. Throughout this chapter, the author explores this model, its importance, and application in contexts similar in nature to those found in the hierarchically structured intergovernmental organizations. Finally, the author concludes that embedding risk management best practices into the organization culture and business processes can positively influence the success of ERP system implementation. In other words, earlier adoption of risk management best practices for ERP system implementation will help both business & projects to meet their intended objectives and thus positively influence the success of ERP projects by ensuring that prescribed goals are met.

Supply Chain Reengineering

This chapter describes a debacle that occurred when a large assembler of fast moving consumer electronics commissioned the set up of a new supply chain. Four key players undertaking five processes were involved. These companies planned to operate sell-buy relationships. Upon starting to ramp-up of the first product component sets, it became clear that companies did not trust their successors to pay for all goods delivered. Similarly, suppliers were not trusted to deliver perfect goods. Companies receiving component sets refused liability for damage or defects introduced by companies further up the supply chain. A remedial quick-fix using centralised inspection at the principal supplier soon was adopted to facilitate supply of complete sets of mechanical parts to the assembler. Significant similarities exist between the case study supply chain and the concepts used in business process reengineering. The chapter identifies stages undertaken to improve an inbound supply chain for complex plastic mouldings assemblies. The principal research methods used were participant-observer and action orientation. All company names have been disguised to comply with confidentiality agreements. The author was a Logistics Project Leader during the period of this research. He acted as an internal consultant for Alpha Co, with responsibilities for encouraging new product development teams to modify the products to take into consideration ‘design for logistics’ concepts.

Assessing Workflow Ability of ERP and WfM Systems for Implementing Business Processes

Automation of a business process can be obtained by using a workflow management system or ERP system embedding workflow functionalities. The wider diffusion of ERP systems tends to favor the latter solution. There are several practical limitations of most ERP systems when automating business processes. To date, there is a lack of empirical studies aiming at achieving an evidence of these limitations. This chapter reports a study assessing the “workflow ability” of ERP systems and comparing this with that of Workflow Management Systems. Then, an empirical study was conducted regarding two different case studies. The correctness and completeness of the process models implemented using ERP and WfM systems were evaluated and analyzed.