You’re in charge of a major system overhaul. How can you ensure the implementation is successful?

To ensure our initiative's success, we must establish a structured approach, starting with clearly defining objectives and creating a comprehensive activity plan in a project charter. Engaging stakeholders from the outset is crucial, clarifying their roles and responsibilities and ensuring resource allocation. Additionally, integrating risk management, agile methodologies, change management, and communication strategies is essential. Proactively identifying and mitigating risks, managing change effectively, conducting security evaluations, and maintaining transparent communication channels will help us navigate challenges smoothly.

Major system overhaul of what, hardware, manufacturing, construction, biochemistry ......? Before sending these questions out, someone should think about the content.

Probably defining scope is one of the most important aspect of system architecture: 1. What problems are we solving? 2. What amount of future deviations we want to accommodate ( this is cost question) 3. What are the indented timelines ( parts/ technology/ target market can become obsolete pretty fast) 4. How does this system fit among larger product or system? 5. What are larger external (in and out of system) use case scenario’s? These questions should help find scope that’s well defined.

My approach would begin with establishing a solid plan and engaging stakeholders from the outset, ensuring our objectives are both clear and aligned with the project's overarching goals.This focus on continuous improvement is key. Early engagement with stakeholders is crucial to understanding their needs and securing their support. I would also segment the project into manageable stages, allowing for iterative feedback. The importance of system testing cannot be overstated, necessitating targeted test cases for at least the most critical components. Training might become necessary, especially if significant changes, such as backend service refactoring, are implemented. Lastly, I would prioritize open communication to ensure all are engaged.

Before defining ANY scope determine what Capabilities are needed from the "overhauled" system to accomplish a Mission or fulfill a Strategy resulting from or enabled by the new system. Then what are the Measures of Effectiveness and Measures of Performance of the resulting capabilities. With these in place, the project goals, objectives, and deliverables are a reason for being there. And from those all the technical and operational requirements have a reason for being there. Otherwise, any resulting deliverable is simply a solution looking for a problem to solve.

IMHO, the architecture plays a major role one the system overhauls. Defining the Reference Architecture, including all types of architecture (Systems, Application, Data, Cybersecurity, Governance, network, physical, etc.) are mandatory to quantify the scope of work and be prepared for the successful implementation.

Define the system architecture considering the critical events and self recovery procedures so that with minimum user intervention it can be brought up to operation. It is essential therefore apart from required functions and features, to add functions to act upon unintended critical events that affect the system operations

A must have is also metrics to measure how a specific design characteristic is improved via the architecture. Such as 'maintainability' for example that can be measured using static and dynamic analysis tools. Or 'performance' based on turn around times or latency.

Key underpinnings such as security, scalability goals, the nature of the platform (do APIs form part of the product) all drive the To-Be architecture. - 300,000 users may be the 3 years strategy, but year 1 goals may only have 20,000 users. You may be able to cut your cloth (and timelines) accordingly. - Don’t make expensive infrastructure decisions on what ‘might be’ - Like ‘we may be looking to tightly integrate systems in China and Europe later’. It’s a time and money pit with no guarantee to add value. - Data Security comes first, but don’t neglect business continuity and performance. - Design so that you can always demonstrate OKRs / KPIs set out as the project objectives are being hit through testing / tracking / data etc.

So the title of the question was major system overhaul. Again why? What was wrong in the first place? What does it need to do? I need more then just scope! I need requirements! Systems build 20 years ago are probably now either an app or a paid service on AWS.

It's also essential to have traceability right from product requirements, software requirements, design specification, risks, system/integration/unit test case. It must be documented and reviewed at each phase of project execution. This ensures major deviations are avoided and mitigate risks and also meet the timeline. When every single artefact developed and delivered is mapped to traceability, we can catch scope creeps early and create change requests thereby avoiding project overrun.

During implementation, good architecture governance helps measure deviations of the system from the patterns and rules that were designed. This helps calculate 'technical debt' as the implementation progresses so corrective actions can be accounted and planned for.

Mais do que implementar o código, deve-se garantir que o trecho ou processo migrado mantenha o mesmo comportamento, logo, n?o deve gerar uma regress?o. Fowler diz em seu livro Refatora??o, que à medida que aquele método é migrado deve-se realizar o teste e identificar se o comportamento é o mesmo. Portanto podemos concluir que a migra??o da codebase deve ser gradativa e altamente testável.

Develop the code following best practices, ensuring it is maintainable, well-documented, and tested. Utilize version control systems and adhere to coding standards throughout the development process.

Remember infrastructure is a code. And more importantly code and configurations are increasingly automated. Now with gen ai tools like GitHub Copilot or AWS Cloud Whisperer code is no longer just generated by people. It will be more and more autogenerated from prompts. The challenge is that if you have many non standard systems and code bases you will end up be limited in terms of how much you can automate. Because if you have some custom applications you want to automate guess who will pay bill for training of AI models to learn your app. So it’s good idea rethink your architecture and code for future when AI not humans will be doing more heavy lifting.

CI/CD makes it so much easy to build and deploy your code and is very useful when you are incrementally deploying your changes to production at the end of each sprint, if that is at all possible in case of a system overhaul. If overhaul is an all or nothing deployment (i.e. you cannot deploy new system piece by piece to production but only as a whole at the end), you can still use CI/CD pipelines to deploy your code to Test.

System architect provides guidelines for how to integrate the new system. It usually means a lot of talking to people. CI/CD, monitoring and so on are the work of DevOps. Like in previous question with agile, it is definitely good for its purpose but not every system is for example a microservice that is rolled out continuously.

It is more complicated than integrating the component. The things we do well before the arrival of the components will influence the results of that integration. Poor configuration management will result in the design of parts that cannot be integrated, leading to rework. What interfaces matter? What are the specific attributes of those interfaces? Product development is a collection of systems (for example, config management and requirements management) that we must tweak to meet the needs of this particular project and product.

Carefully combine the new and existing system components. Focus on achieving seamless integration that minimizes downtime and preserves data integrity.

Do it every day, even if you're just starting out on the bare minimum. "If something is hard, do it often". I ran a year+ long data import project where we ran the ETL every single day, even if incomplete. The habit built the systems, measures, and health checks necessary that made finally going to production undramatic. I'd honestly start with that before spending too much time in 'design', 'architecture', and 'integration'. We're too good at imagining design & architecture 'needs' up front that we can paralyze ourselves.

Above all, observability and resilience, applied in layers starting with the minimum/just the necessary. The need for redundancy and eventuality with ETL execution can help us guarantee structures in Delta layers, bringing daily visibility, but also avoiding small files and exception of processing in-depth search. Observability guaranteeing health measures checks, and giving active notification to the system admin/SRE for any necessary actions.

Première étape: s'assurer que l'ancien système est correctement sauvegardé, et qu'on sera capable de le remettre en prod en urgence en cas de soucis. Tester le processus de migration à petite échelle, et choisir un panel de testeurs (du technique au fonctionnel) qui seront capable de valider la conservation des données

If the overhaul involves migrating data, ensure a well-planned and secure transfer process. Data integrity checks and a clear rollback plan are essential in case issues arise during the migration.

It's also good to benchmark with similar systems that are comparable and set the baseline KPIs inorder to plan acceptance and successful launch without hiccups in the last minute. Most important is agreeing on the KPIs with end customers so that the expectations are set right in first place and managed effectively.

After the implementation, conduct thorough testing and seek feedback to evaluate if the system meets the predefined objectives. Be prepared to make iterative improvements based on the feedback and testing results.

Assuming this is a software overhaul, its essential to have a contingency plan in place. This plan will outline potential risks and outline strategies to mitigate those risks. Having successfully completed software migrations throughout my career, I cant emphasize the importance of planning and risk assessment. Some examples of what is covered in a contingency plan are: * Data Backup and Recovery procedures * Phased deployment approaches * Response team readiness * Rollback or Roll-forward strategy * Deployment Plan Alternatives

Test early and often with the stakeholders to make sure the implementation is what is expected and can be changed, if necessary, based on feedback.

Test with end users …. Not with spec definers ….. the end users are the ultimate “acid test” to ensure your assumptions, and those of the stakeholders ….. were correct or not !

Approach you use for “Major system overhaul” depends a lot on the organization culture and technical skills of the teams. While there are best practices (some of which are shared above) there is no silver bullet. After creating overall blueprint, and High level plan, I prefer to go as much modular as we can. Follow LEAN principles, Do small PoCs, short Sprints, show results and the scale. Fail fast, Learn fast and Build fast. For example, CI/CD is great for faster Time to market, but what if teams are not yet ready for it. So you need to have team up skilling also part of your plan.

This article is structured on a somewhat "waterfallish" approach. I would like to highlight the importance of driving agile, iterative, value-focused deliveries, that from my experience provide more value sooner. Yes, define scope, but don't push to lock it down, instead align the stakeholders to an Agile approach in short cycles that will allow much faster learning. Yes, architect just enough to allow all the participants to have a north star and a good definition of frontiers, but don't write it on stone. Instead, adopt evolutionary architecture that will grow as you learn more. Yes, promote commitment and autonomy of teams. Glue it all together with automation to avoid bad investment of human time on non-creative activities.