^{Author: Dipl.-Math. Jens Borchers, April 2024}

Abstract

Software reengineering, a crucial process in the software development life cycle, involves the examination and alteration of a subject system to reconstitute it in a new form. The essence of reengineering is to improve the system's maintainability and adaptability to current and future requirements. This essay delves into the management aspects of software reengineering, both at the enterprise and project levels, underscoring the pivotal role that effective management plays in the success of these initiatives.

In the realm of enterprise and project management, software reengineering is not just a technical challenge but also a managerial endeavour. It requires meticulous planning, strategic decision-making, and adept handling of resources and personnel. By focusing on the management perspective, this essay aims to provide insights into how managers can navigate the complex landscape of software reengineering, balancing technical objectives with organizational goals and stakeholder expectations.

As already outlined in the essay “Overview on Software Reengineering”, all activities in the area of software reengineering and evolution must be managed on different levels as part of the overall software development strategy:

• Enterprise
• Project Level
• Line Organization Level

This essay describes the goals and processes for the three levels of management in more detail.

Note: As is now customary and permissible for such work, the "ChatGPT 4" tool was used to generate basic texts and structures for this paper.  

Introduction and Overview

The management of software reengineering activities within the scope of IT systems’ development and evolution in an enterprise needs different levels of attention and detail level. These are listed below.

Enterprise-Level Software Reengineering Management

• Strategic Importance: Emphasize on the strategic role of reengineering in enterprise management.
• Challenges and Solutions: Discuss common challenges like legacy systems integration and propose solutions.

Project-Level Software Reengineering Management

• Role in Project Management: Discuss the role of reengineering in the context of specific projects.
• Managing Teams and Resources: Focus on human resource management, budgeting, and time management in reengineering projects.

Line Organization Software Reengineering in Classical and Agile Environments

• Release-based Software Development within “classical” waterfall processes
• Agile and Reengineering: How agile methodologies influence software reengineering.

Enterprise Level Software Reengineering Management

At the enterprise level, software reengineering is a strategic endeavour that requires careful planning, alignment with business objectives, and a focus on long-term value creation. It involves not just technical changes but a holistic approach encompassing organizational culture, processes, and future readiness. This strategic perspective ensures that software reengineering can act as another catalyst for business transformation, driving efficiency, competitiveness, and adaptability in an ever-evolving digital landscape.

Strategic Management Role

In the context of software reengineering, the strategic role of management cannot be overstated. Managers are tasked with the responsibility of aligning the reengineering process with the broader objectives of the organization. This involves setting clear goals, defining the scope of the reengineering efforts, and ensuring that these initiatives contribute to the overall strategic direction of the company. The strategic management role also encompasses the assessment of the current software systems, identifying areas that necessitate reengineering, and determining the feasibility of such projects.

Decision-Making: The reengineering process is replete with decisions that can have far-reaching implications on the project outcome. Managers must make informed choices regarding the selection of reengineering tools and methodologies, allocation of resources, and the scheduling of project phases. These decisions are often complex, requiring a balance between technical requirements, budget constraints, and time limitations. Effective decision-making in software reengineering also involves anticipating potential challenges and proactively devising strategies to mitigate them.

Balancing Stakeholder Interests: Software reengineering projects typically involve a variety of stakeholders, including developers, clients, end-users, and upper management. Each group may have different expectations and requirements from the project. Managers play a crucial role in understanding these diverse needs and ensuring that the reengineering process addresses them appropriately. This involves regular communication with stakeholders, gathering feedback, and adjusting project plans to accommodate their inputs while keeping the project on track.

Major Processes of Enterprise Software Reengineering Management: Software reengineering requires some standard processes on enterprise level to keep the reengineering strategy and roadmap in sync with the overall IT and in particular the application strategy.

Understanding the Strategic Imperative:

• Alignment with Business Goals: The primary strategic aspect of software reengineering at the enterprise level is its alignment with the overarching business goals. Reengineering efforts should support and enhance the organization's mission, whether it's to increase market share, improve customer satisfaction, or innovate product offerings.
• Competitive Advantage: In a rapidly evolving business landscape, maintaining a competitive edge often requires leveraging the latest technological advancements. Strategic software reengineering can enable enterprises to integrate new technologies, streamline processes, and offer innovative services or products, thereby gaining a competitive advantage.
• Long-term Vision and Scalability: Enterprises must consider their long-term vision and scalability when undertaking software reengineering. The reengineered systems should not only meet current needs but also be scalable and adaptable to future business scenarios and technological advancements. Strategic Planning and Execution
• Comprehensive Assessment: Before embarking on reengineering, a thorough assessment of existing systems and processes is crucial. This includes evaluating the software's current performance, identifying pain points, and understanding how they align with business processes and objectives.
• Resource Allocation: Strategic resource allocation is essential in software reengineering. This involves not just financial resources but also human resources and time. Prioritizing projects that offer the highest value and align closely with strategic objectives is key.
• Risk Management: Software reengineering comes with its set of risks, including potential disruptions to business operations, unexpected costs, and resistance to change. A strategic approach involves identifying these risks early and developing mitigation strategies.
• Stakeholder Engagement: Engaging stakeholders at all levels - from executive leadership to end-users - is a strategic necessity. Their input can provide valuable insights into the business needs and help in aligning the reengineering project with these requirements. Innovation and Adaptability
• Embracing Emerging Technologies: Enterprises need to strategically consider the incorporation of emerging technologies like AI, cloud computing, or blockchain in their reengineering efforts. This not only improves current functionalities but also prepares the business for future technological shifts.
• Agility and Responsiveness: The reengineered systems should enhance the organization's agility and responsiveness to market changes. This requires a strategic approach to software architecture, ensuring systems are modular, adaptable, and can be quickly updated or modified. Measuring Success and Continuous Improvement
• KPIs and ROI: Defining clear Key Performance Indicators (KPIs) and measuring the Return on Investment (ROI) are crucial for evaluating the success of reengineering projects. These metrics should be aligned with the strategic goals of the enterprise.
• Feedback Loops and Continuous Improvement: Implementing feedback mechanisms to continually assess the performance of reengineered systems is vital. This allows for ongoing improvements and ensures that the systems remain aligned with business strategies.

Creating a Software Reengineering Roadmap at Enterprise Level: Based on the general IT development and software reengineering strategy, it is necessary to create a high to medium detail level road map for the next 3 to 5 years. This roadmap serves as a guide for the organization's journey through reengineering initiatives, ensuring alignment with business objectives and efficient resource utilization.

Following are the general steps how to accomplish this task (some of them have been already described above but are repeated here for clarity):

Initial Assessment and Analysis:

• Conduct a thorough analysis of existing software systems to understand their capabilities, limitations, and alignment with current business processes.
• Evaluate technical debt, maintenance costs, system performance, and user satisfaction.
• The relevant persons are application managers, enterprise and business architects and major business stakeholders.

Identifying Business Goals and Needs:

• Align with key stakeholders to understand the long-term business strategy and objectives.
• This can include a review of the business processes before assessing the current IT support for the current processes.
• Identify how current systems are hindering these goals and where reengineering can add value. Define Vision and Objectives
• Establish a clear vision for the reengineered systems, focusing on how they will support the business's future direction.
• This vision should encompass not just technological advancements but also improvements in processes, user experience, and business agility.
• Break down the vision into specific, measurable objectives.
• These objectives could range from increasing system efficiency, reducing operational and license costs, to improving customer experience or compliance with new regulations.

Prioritization and Sequencing

Identifying Key Areas:

• Based on the initial assessment, identify which systems or components are most critical and should be prioritized for reengineering.
• Consider factors like business impact, risk, cost, and dependencies, organisation aspects.

Creating a Sequence Plan:

• Develop a phased approach for reengineering activities.
• This should include a timeline with clear milestones, considering dependencies and potential disruptions to ongoing operations.

Resource Allocation and Budgeting

Resource Planning:

• Determine the resources required for each phase of the reengineering process, including personnel, technology, and training needs.
• Plan for both internal and external resources, such as hiring new talent or partnering with vendors.

Budgeting:

• Create a detailed budget that aligns with the reengineering phases.
• Include contingencies for unforeseen challenges or scope changes.

Risk Management and Mitigation

Risk Assessment:

• Identify potential risks associated with the reengineering process, such as technical challenges, cost overruns, or resistance to change.
• Assess the impact and likelihood of each risk.

Mitigation Strategies:

• Develop strategies to mitigate identified risks.
• This could include pilot testing, incremental implementation, stakeholder engagement plans, and regular reviews.

Stakeholder Engagement and Communication: In order to keep motivation high for all those involved and those directly and indirectly affected, periodic reporting on the progress already made is essential.

Engaging Stakeholders:

• Involve stakeholders at all levels in the reengineering process.
• Gather their input and ensure their needs and concerns are addressed.

Effective Communication:

• Develop a communication plan that keeps stakeholders informed about progress, changes, and impacts.
• Regular updates and transparency are key to maintaining trust and buy-in. Implementation and Support Strategy

Big Bang vs. Phased Rollouts

Different strategies for the implementation and commissioning of customised components must be evaluated and ultimately decided upon. These alternatives cover the entire spectrum from "big bang" to package-orientated approaches to "creeping" takeovers.

Training and Support:

• Ensure that adequate training and support are provided to users.
• This eases the transition and encourages adoption of the new systems.

Monitoring and Continuous Improvement

Performance Monitoring:

• Establish KPIs and metrics to monitor the performance of reengineered systems against objectives.
• Use these KPI and metrics to evaluate success and identify areas for improvement.

Iterative Improvement:

• Adopt an iterative approach to continuously improve the systems.
• Encourage feedback from users and stakeholders to guide these improvements.

Conclusion

A well-structured software reengineering roadmap is crucial for guiding enterprises through complex reengineering initiatives. It provides a strategic framework that aligns with business goals, manages resources efficiently, and minimizes risks. By following these steps, enterprises can ensure that their reengineering efforts are focused, effective, and deliver tangible value to the business.

Software Reengineering: Project vs. Line Organisation

General Considerations: Deciding whether necessary software reengineering should be organized as a standalone project or integrated within the normal maintenance process involves evaluating several key factors related to the scope, impact, and objectives of the reengineering effort. A structured approach to making this decision should include these topics:

Assess the Scope and Complexity:

• Large-Scale vs. Incremental Changes: If the reengineering requires large-scale changes that impact multiple components or the entire system architecture, it might be more suitable as a project. Incremental improvements or small-scale refactoring can often be handled within normal maintenance activities.
• Technical Debt Assessment: Evaluate the amount and impact of technical debt. Extensive technical debt that significantly hinders new development or poses operational risks may necessitate a project approach to address it comprehensively. Consider the Business Impact and Objectives
• Strategic Importance: If the reengineering is critical for achieving strategic business objectives, such as entering new markets or launching new product lines, organizing it as a project with dedicated resources and timelines might be necessary.
• User Impact: Consider how the reengineering will affect end-users. Projects that involve substantial downtime or major changes in user interaction should be carefully planned as projects with clear communication and rollout plans. Evaluate Resource Availability
• Dedicated Resources: Large-scale reengineering efforts may require resources that are not available within the normal maintenance teams, including specialized skills or additional personnel. In such cases, organizing the effort as a project allows for dedicated resource allocation.
• Budget Considerations: Significant reengineering efforts may have budget implications that exceed normal maintenance budgets, necessitating project funding and approval processes.
• Team Setup: Separation of the reengineering team and the application development and maintenance team should be considered since both have different goals and time scopes. But the leads of these teams have to keep in close touch. The reengineering team should be held rather small in size but with good people who are willing to make it

Analyse Risk Management

Mainly larger reengineering projects are in general high-risk tasks. Especially when they are related to a running system and have to be integrated in stages, for each stage a fall back needs to be included in the plan.

• Risk Assessment: Projects with high risks due to complexity, integration challenges, or potential for significant disruption might be better managed as dedicated projects where risks can be more closely monitored and mitigated.
• Testing and Rollback Plans: Consider the need for extensive testing and potential rollback scenarios. Projects allow for more comprehensive testing phases and detailed contingency planning. Review Regulatory and Compliance Requirements
• Compliance Changes: Reengineering efforts driven by new regulatory or compliance requirements may be better structured as projects to ensure focused attention on meeting these requirements by specific deadlines. Determine the Timeline and Urgency
• Immediate vs. Long-Term Benefits: If the reengineering delivers immediate benefits or is urgently needed to address performance issues, integrating it into the normal maintenance cycle may provide quicker results. Long-term, strategic reengineering efforts might be more suited to a project structure with a defined timeline.

Decision Framework:

• Project Approach: Opt for a project approach when the reengineering is large-scale, strategically important, requires dedicated resources, has significant risk or compliance implications, or when it's necessary to meet specific business objectives within a defined timeline. Long term projects have the risk that business requirements change during the reengineering phase. This has to be considered in the decision process.
• Maintenance Process Integration: Choose to integrate reengineering within the normal maintenance process for incremental improvements, when resources are readily available within existing teams, and when the work can be completed without major disruption or risk.

Classical Software Reengineering Project Types

Software reengineering managed as standalone projects rather than as part of normal line maintenance is typically chosen for efforts that require substantial investment, are highly complex, have a broad impact, or need to be completed within a specific timeframe. Here are several examples where reengineering would likely be managed as projects:

Legacy System Modernization: A classic example is the complete overhaul of a legacy system that is critical to business operations but is running on outdated technology, making it difficult to maintain or integrate with modern systems. This might include migrating from a monolithic architecture to microservices, updating the database system, or moving from on-premise hosting to cloud services. Such projects require significant planning, testing, and execution that goes beyond routine maintenance.

Platform Migration: When a business decides to move its software from one platform to another, such as from Windows to Linux, or transitioning from a desktop application to a web-based application. This type of reengineering involves not just code conversion or rewriting, but also considering changes in user experience, security implications, and integration with other web-based services.

Adopting New Frameworks or Languages: Reengineering projects may involve updating the software to use modern programming languages or frameworks to improve performance, security, or developer productivity. For instance, moving a web application from PHP to a Node.js backend, or refactoring a software to use a new version of a framework like Angular or React, can significantly enhance the application but requires a project-level effort to manage the transition.

Performance Optimization for Scalability: Significant reengineering might be required when a software needs to be optimized for performance to handle increased load or to become more scalable. This could involve reengineering the database schema, introducing caching mechanisms, or optimizing critical code paths. Such optimizations often require in-depth analysis, testing, and phased rollouts.

Integrating Advanced Technologies: Integrating advanced technologies such as artificial intelligence, machine learning models, or blockchain into existing systems for enhanced capabilities or to offer new features. This type of reengineering might require specialized knowledge, significant changes to the application architecture, and extensive testing to ensure the new technology integrates well with existing systems.

Consolidating Multiple Systems: After mergers or acquisitions, a company may need to consolidate disparate systems into a unified platform. This reengineering project involves harmonizing data models, merging databases, and ensuring consistent user experiences across the combined systems, which goes beyond typical maintenance tasks.

Security Overhaul: In response to a security audit or after a significant breach, a comprehensive security overhaul might be necessary. This can include reengineering for secure coding practices, updating encryption methods, implementing advanced authentication mechanisms, and more. Such a project is critical to protect data integrity and user trust.

Regulatory Compliance Projects: Changes in regulations or compliance requirements (like GDPR, HIPAA, or CCPA) may necessitate significant modifications to ensure software systems comply with new legal standards. This could involve reengineering data handling processes, privacy features, or security measures.

Summary

Each of these examples represents a substantial effort that goes beyond the scope of routine maintenance, requiring dedicated teams, specialized skills, and project management methodologies to ensure successful completion. By treating these reengineering needs as projects, organizations can allocate the necessary resources, manage risks effectively, and achieve the desired outcomes within a controlled timeframe.

Project Level Software Reengineering Management

Overview: In the intricate landscape of software reengineering, project-level management stands as a critical determinant of success. This facet of management focuses on the nuances of executing reengineering projects, demanding a precise blend of technical acumen and managerial expertise. At this level, management responsibilities encompass methodologies adoption, team coordination, budget control, and stakeholder engagement. Each of these elements plays a pivotal role in steering reengineering projects towards their intended outcomes.

The handling of large software reengineering projects, in which in most cases several thousand software components of a system environment have to be processed can only be carried out efficiently within the framework of a project, which should have the goal of being able to be completed within a manageable period of time. The approach of "taking care" for such challenges in parallel to the day-to-day business in the line organisation will nearly always fail and leads to "never-ending stories".

Advantages in Software Reengineering Projects: The fact that software reengineering projects have a number of advantages over new development projects can be utilised:

• The project goal can be clearly defined and is usually based on the technical specifications of the existing and intended implementation.
• A detailed work plan can be specified and secured, which can then be applied to many software components in the same way ("cookbook").
• For the people working on a technical changeover project, knowledge of the business background is practically not required.
• Proof of successful completion can be provided for each component (with great certainty) through regression testing (usually at a purely technical level without business specialist expertise).
• Many subtasks are candidates for extensive automation, which further increases the accuracy of the conversion tasks.
• A large proportion of the manual activities involved in the changeover project can be "outsourced" and can therefore be carried out cost-effectively today, especially when using "near/off-shore" resources.

Pitfalls in Software Reengineering Projects: On the other hand, there are of course also a number of pitfalls for software reengineering projects:

• No validation of results through comprehensive quality assurance, in particular no implementation of rigid regression tests.
• Underestimation of the complexity of the systems and the technical debt
• Too little automation, as manual work is - naturally - the most prone to errors.
• No rigid configuration management (in large projects, a total of several 10,000 individual components and well over 100,000 test sets have to be managed).
• Underestimating the resources required for computer performance and secondary storage, especially for test data and isolated test environments.
• And - last but not least - never violate “Rule 1”: To accept parallel requests like "When you are working on the components anyway, couldn’t you implement our business change request x in parallel?". Deviating from the basic rule of restoring the exact "1:1" business functionality is the greatest danger to the success of a software reengineering project!

General Project Management Aspects

Project Management Methodologies

The choice of project management methodologies significantly influences the trajectory of a reengineering initiative. Traditional methodologies like Waterfall offer a structured, linear approach, beneficial for projects with well-defined requirements and a clear scope. Agile on the other hand, with its iterative cycles and emphasis on adaptability, is particularly suited for reengineering projects where requirements evolve over time (but don’t forget “Rule 1”). Managers must evaluate the specific needs of the project to select a methodology that aligns with the project's goals, team dynamics, and stakeholder expectations.

Team Management and Communication

Effective team management is paramount also in reengineering projects. Managers must assemble teams with the right mix of skills and experience, considering the specific technical and operational challenges of the reengineering task. Once the team is in place, fostering a collaborative work environment becomes critical. This involves clear communication of project goals, individual roles, and expectations. Regular team meetings and open communication channels help in identifying issues early, allowing for timely interventions. Since not all obstacles can be anticipated in advance a „flight plan change“ model can be helpful. When planning a flight (in earlier days) one got the winds from the weather office and calculated the reaching time of milestones. When reaching a milestone, the head or tail wind could have been higher or lower thus one can recalculate how long the rest of the distance will take.

This cannot be fully applied fully to software reengineering projects since the distance (or effort) is not 100% accurately assessable. But it helps for better estimates.

Timeline and Budget Management

Managing timelines and budgets effectively is a challenging yet essential aspect of project-level reengineering management. Reengineering projects, particularly those involving legacy systems, can be prone to underestimation of time and resources required. Managers must exercise due diligence in project planning, incorporating buffer times for unforeseen complexities. Utilizing tools like Gantt charts or project management software can aid in tracking progress and identifying deviations from the plan early. Budget management in reengineering is equally critical. Managers must ensure that the project remains financially viable, balancing the costs of new implementations with the expected benefits. This involves not just tracking expenditures but also forecasting future costs and potential overruns. Effective budget management also requires regular communication with stakeholders, especially when adjustments are necessary.

Stakeholder Engagement and Feedback

Stakeholder engagement is a continuous process in project-level management. Managers must keep stakeholders informed about project progress, challenges, and changes. This transparency builds trust and facilitates smoother decision-making processes. Stakeholder feedback is invaluable, providing insights that can help refine project objectives and methodologies.

Involving stakeholders in regular reviews and milestone meetings ensures that their expectations are aligned with the project's trajectory. It also provides an opportunity for stakeholders to voice concerns and suggestions, which can be pivotal in navigating the project through complex reengineering phases. The stakeholders should also try to keep the pressure high that progress is happening otherwise especially reengineering projects tend to silting up or bobbing along. This consumes resources without significant progress.

Factory Style Processes in Software Reengineering Projects

The factory-style approach in software reengineering offers a systematic and organized method to handle the overall workload efficiently. While it brings advantages in terms of efficiency and quality, its successful implementation requires careful planning, management of complexities, and flexibility to adapt to evolving project needs. When applied thoughtfully, it can significantly streamline the reengineering process, leading to improved software systems.

Task Standardization: Tasks within the reengineering process are standardized to ensure consistency and efficiency. This involves defining clear procedures, guidelines, and best practices for each task.

Modularization: Breaking down the reengineering process into smaller, modular components allow for easier management and scalability. Each module represents a specific task or set of tasks that can be independently handled.

Specialization and Division of Labour: Different teams or individuals specialize in handling specific modules or tasks. This division of labour ensures that each component of the reengineering process is handled by experts, optimizing productivity and quality.

Workflow Automation: Utilizing automation tools and workflows streamlines repetitive tasks. Automation can range from code refactoring tools to automated testing and deployment pipelines, reducing manual effort and minimizing errors.

Continuous Improvement: The factory-style approach encourages a culture of continuous improvement. Regular assessment of processes and outcomes leads to refinements in procedures, tools, and methodologies for better efficiency and quality.

Advantages of Factory Style Processes in Software Reengineering:

• Efficiency: By breaking down tasks and standardizing processes, efficiency is increased as repetitive tasks can be handled more rapidly.
• Scalability: Modularization allows for easy scaling up or down of resources and efforts based on the project's needs.
• Quality Assurance: Standardized processes and specialized teams ensure higher quality outcomes due to focused expertise.
• Consistency: Standardization reduces variability in outcomes and ensures consistency in the reengineering process.

Challenges and Considerations:

• Complexity Management: Despite breaking down tasks, managing the interdependencies between modules and ensuring overall coherence can be challenging.
• Adaptability: Factory-style processes might struggle to adapt to unforeseen changes or unique situations, requiring flexibility in approach.
• Overhead: Setting up and maintaining a factory-style approach might require initial investment in tools, training, and infrastructure.
• Application in Different Scale Projects: In smaller projects, the factory-style approach might be managed more flexible, allowing for easier adoption due to the manageable scale. It helps in organizing and optimizing limited resources efficiently. In larger projects, while the factory-style approach is key to enhance efficiency, it requires a more elaborate setup due to the complexity of the systems involved. Coordinating specialized teams and managing interdependencies becomes crucial.  

Line Organisation Software Reengineering Management

Overview: Integrating software reengineering into the line maintenance process is a strategic approach that requires careful planning, coordination, and execution. By following these steps, organizations can ensure that their software systems are not just maintained with regard to functional business features but in parallel are continuously improved and adapted to meet evolving technological advancements and keep the “technical debt” under control.

The form of integration of software reengineering within the normal maintenance and evolution cycles of application systems depends on the basic methodology approach:

• Classic release management where the application system is maintained in defined cycles (e.g., three to four releases per year) and only emergency changes are applied between scheduled releases. In general, this incorporates a more “waterfall”-like process model. The reengineering requirements would be handled as technical “change requests” in parallel to business requests.
• Agile development based on respective methodologies like “Scrum” or “Kanban” where software reengineering requirements would be a part of the “backlog” (Scrum) or “board” (Kanban). E.g., in a Scrum based process reengineering requirements could be managed as “epics” or “user stories”.
• Also, hybrid process models can be used where the maintenance (including reengineering) tasks are managed in an agile manner but only defined “complete” releases are deployed to production.

General Processes for Integration of Reengineering in Line Organisation Maintenance: In order to achieve the integration of software reengineering within line organisation maintenance, the relevant general processes are described below. There is in principle no difference whether the maintenance process model is a “classic” or “agile” one.

The following sub-chapters contain a rough list of the main tasks that are necessary to integrate software reengineering with the general software maintenance process.

Implement a Continuous Comprehensive Assessment:

• Begin with a thorough analysis of the current software systems to identify components that are outdated, inefficient, or no longer meet the business requirements.
• Evaluate the software's architecture, codebase, dependencies, and performance metrics.
• The cumulation of all technical quality deficiencies in a software system is its current “technical debt” which should not grow over time. It will never be “zero” but a reduction (if technically and economically feasible) should at least be one of the maintenance goals.

Identify and Prioritise Reengineering Needs:

• Determine which parts of the system require reengineering. This could include parts that need optimization for performance, scalability, security improvements, or updates to meet new regulatory requirements.
• Include Reengineering in the overall Maintenance Plan
• Create a detailed plan that outlines the scope, objectives, and timeline for the reengineering process. The plan should align with the organization's strategic goals and consider the impact on ongoing operations.
• Prioritize reengineering efforts based on factors like business impact, technical risk, cost-benefit analysis, and regulatory compliance requirements.

Manage Special Reengineering Tasks:

• Refactoring: Systematically improve the codebase for better readability, reduced complexity, and enhanced performance without changing external behaviour. This can be integrated into corrective maintenance tasks.
• Redesign: In cases where components are significantly outdated or inefficient, a complete redesign may be necessary. This involves rethinking the architecture or component design to improve performance, scalability, or to incorporate new technologies.
• Data Migration and Legacy System Integration: For systems that rely on legacy databases or applications, reengineering tasks may include data migration to more modern platforms or the creation of interfaces for legacy system integration. But note that this type of software reengineering in general needs a special project setup.
• Automated Testing: Develop and integrate automated testing procedures to ensure that reengineering efforts do not introduce new bugs or regressions. This complements corrective maintenance by improving software quality and reliability. Use regression testing approaches to ensure that reengineering activities did not affect your business functionality.

Form a Dedicated Reengineering Team:

• Establish a cross-functional team that includes members from the maintenance team, software engineers specializing in reengineering, QA testers, and stakeholders from the business side.
• This team will be responsible for executing the reengineering process while ensuring minimal disruption to ongoing maintenance activities.

Integrate Reengineering within Maintenance Cycles:

• Integrate reengineering activities into the regular maintenance schedule. This could mean setting aside specific periods during maintenance cycles for reengineering tasks to ensure they are treated with the same importance as regular maintenance.

Test and Validate Changes

Implement Rigorous Testing:

• Conduct comprehensive testing to ensure that the reengineered components integrate seamlessly with the existing system and that there are no negative impacts on system performance or functionality. Regression Testing
• Set up (automated) test processes which verify that pure software reengineering changes to application components have not impacted their functional behaviour. User Acceptance Testing (UAT)
• Involve end-users in the testing phase to validate the effectiveness of the reengineering efforts and ensure that the system meets business requirements.

Conclusion

Integrating software reengineering into the line software maintenance process is a strategic approach that requires careful planning, coordination, and execution. By following the processes and organizational approaches described in this chapter, organizations can ensure that their software systems are not just functionally maintained but continuously technically improved and adapted to meet evolving business needs and technological advancements. The author of this essay has coined the term “software evolution enabling” for this approach.

Literature

[1] Arnold, R.S.: Software Reengineering. IEEE Computer Society Press, Los Alamitos, 1993

[2] Baumöl, U., Borchers, J., Eicker, S., Hildebrand, K., Jung, R., Lehner, F.: Einordnung und Terminologie des Software Reengineering. In: Informatik Spektrum 19 (1996), S. 191-195

[3] Borchers, J.: Durchführung großer Reengineering-Projekte am Beispiel einer Datenbankumstellung. In: Scheibl, H.-J.(Hrsg.), Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen. 5. Kolloquium Technische Akademie Esslingen, September 1993, S. 643 - 646

[4] Borchers, J.: Erfolgsmechanismen großer Reengineering-Maßnahmen. In: Scheibl, H.-J.(Hrsg.), Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen. 6. Kolloquium Technische Akademie Esslingen, September 1995, S. 307 - 311

[5] Borchers, J.: Projekterfahrungen mit dem Einsatz einer Reengineering-Factory in einem großen Umstellungsprojekt. HMD Nr. 194, 1997, S. 19 - 29

[6] Borchers, J., Hildebrand, K.: Vorgehensmodell für das Software Reengineering. In: Vorgehensmodelle für die betriebliche Anwendungsentwicklung Teubner-Reihe, Wirtschaftsinformatik, 1998, S. 152 - 167

[7] Borchers, J., Steinbauer, D.: Teststrategie beim Redevelopment – Risikominimierung im SCHUFA-Projekt. HMD Praxis der Wirtschaftsinformatik, Nr. 257, Oktober 2007, S. 80 - 91

[8] Borchers, J.: Reengineering from a Practitioner's View - A Personal Lessons Learned Assessment. 15th European Conference on Software Maintenance and Reengineering, Oldenburg, March 2011

[9] Brodie, M., Stonebraker, M.: Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach. Morgan Kaufmann Publishers, San Francisco, CA, 1995

[10] Sneed, H., Verhoef, C.: Reengineering the Cooperation – A Manifesto for IT Evolution. In: John J. Marziniak, “Encyclopedia of Software Engineering”, New York NY: John Wiley & Sons, 2002