How can you proactively maintain and evolve your system?

Proactive system maintenance and evolution are vital for optimal performance. Key strategies include continuous monitoring, robust testing, iterative training, feedback integration, collaborative learning, research and development and ethical considerations. Monitoring system performance and user feedback helps identify issues. Rigorous testing identifies and fixes bugs. Iterative training improves language understanding. User feedback shapes development. Collaboration fosters learning. Staying updated with advancements enhances capabilities. Regular audits ensure ethical usage ! These proactive measures ensure cutting-edge solutions and exceed user expectations.

Practice future-ready systems engineering, an empirical architecture and design discipline that enables construction of systems that measurably implement (reactive) resilience and (proactive) opportunistic adaptation, across both the behavioral and structural aspects of a system (writ large).

Monitoring the systems themselves is one aspect. But even more important is to monitor the outcomes the system is designed to manage. This measures the effectiveness of the system itself. Such monitoring can deliver the opportunities for improvement of the system and the evolution of the system, since conditions can change over time which can result in the original system not being as effective as ot was intended. By monitoring the outcomes one is able to keep the primary objective and goals in focus and ensure they are being achieved and optimized.

Tracking all the issues (from the field or the development and production quality process), prioritizing the ones affecting reliability and customer satisfaction, exploring solutions addressing them, evaluating the cost of opportunities, assessing cost/benefit, deciding the path forward.

At the kickoff of any product objective or feature development, we should carefully assess the metric(s) we intend to move as well as any incidental consequences to existing services and adjacent metrics. Proactively tracking the influence of each new capability makes detecting breakdowns in performance or adoption much easier to ferret out before they snowball into a major customer support or adoption issue. This assumes you have a framework to capture and review both your application performance and adoption metrics. Choose these investments wisely and with an eye for consistent tooling that can be leverage across your product or platform (but start as a soon as possible).

This is another great principle. Let's take it a step further though: all of your code should be self documenting. No exceptions. Prioritize this concept and reap the benefits almost immediately. DON'T have AI document the codebase you already have. DO engage an AI entity to help your team execute on the priority of self-documenting software. The result will be software that is simple to use, understand, and modify. These will delight your two most important user groups: end-users and engineers.

Documenting your system is a fundamental practice in proactive maintenance and evolution. And it greatly facilitates communication with users and stakeholders, enhancing collaboration among developers and streamlining the planning and execution of updates and changes. Different processes and tools can be employed for documentation, such as architectural diagrams, code comments, version control systems, and collaborative documentation platforms, depending on the scale and complexity of the system.

One culture I have found helpful is DOCUMENTATION. Albeit this is a time-consuming process especially if you are startup/business trying to ship fast but Backend systems should be documented across these levels. 1. API Endpoints 2. Core feature process flow on the backend. 3. Backend components, DBs, Caches, external APIs, event-driven processes, and how they are all inter-connected. 2 & 3 can be achieved with short notes and also well detailed diagrams that can be done on Lucid.chart. If you have time or if your platform is one that offers developer tools, documentation is key. You can use ReadMe.io or Gitbook to ease the process. Using AI tools, you can also have AI look through your codebase and generate a skeletonized doc.

While this works for software, documentation may not get a team to success without the right KPP or metrics defined and the analysis follow-up by the engineering team to assess obsolete parts and trends in repair items. Understanding why a part keeps showing Cannot Duplicates (CND) is a big one that can cause a system to remain down and under pressures as parts are flown across the world for repairs all to learn the part is fine, in the mean time the bench stock is exhausted. So I would restate this as document, baseline, and analyze the data to discover spec non-compliances or inefficiencies that can drive better fleet availability or reliability rates.

At Scale, continental or global, it's much more important to set STANDARDS with complete documentation of exceptions in the network! Streamlined support starts with well known repeated systematic components. Can you imagine a doctor working on an alien 👽? Best effort results... The documentation starts at STANDARDS and continues through to evolutionary improvement.

Depending on your product, testing can be a no-brainer or not. There are different kinds of tests as you might already know: Unit, Integration, regression, end-2-end, performance, stress, security, quality assurance tests, etc. Whilst you might not be able to write tests for all your functions and processes, it is important to test for common exploits based on your product/project domain and also write unit tests for core business logic that can have direct impact on your company's finances. For old products that are live, alpha and beta testing is a way to go. If you are building for many users, load/stress test are also a todo. Security tests are also important, for FinTech applications race condition checks are important.

While Testing is key, one can’t always generate and simulate real world scenarios. Therefore ongoing monitoring as mentioned above is another way of actually resting the solutions deployed. This highlight vulnerabilities even before they cause an impact. Therefore periodic review of performance in different conditions can be viewed and real world testing to create improvements and also limit risks.

Engineers should write unit tests. I've seen a lot of teams make the mistake of delegating automated testing to QA or QE teams. This is a disaster waiting to happen. Unit tests not only prove the correctness of code, they also help defend against breaking changes due to refactoring or new feature development. Code should be unit-testable. No matter how much unit testing is enforced on a team, the unit tests won't be as effective if the code is not designed to be tested as small, isolatable units.

Use a cloud-based infrastructure. Cloud-based infrastructures can be more scalable and reliable than on-premises infrastructures. Cloud providers also offer a variety of services that can help you to manage and maintain your system more effectively. Invest in security. It is important to invest in security measures to protect your system from cyberattacks. These measures may include firewalls, intrusion detection systems, and data encryption. Create a disaster recovery plan. A disaster recovery plan will help you to recover your system in the event of a disaster, such as a power outage, fire, or flood.

At scale, testing and automatic recovery are very advanced implementations. The rewards are found in fewer dispatches. It can be extremely valuable. Systems with errors detected should be, at minimum, capable to reboot autonomously or remotely by a monitoring platform. 98% of problems are resolved by power cycle. Use that stat! It's $200 to remote a circuit. What does a dispatch cost?

Refactoring can definitely play an important role in reducing technical debt, but it also can serve the important purpose of identifying potential areas of vulnerability from a security perspective. Often, legacy systems have back-door vulnerabilities built-in by design. As these pieces of a system are forgotten due to changing team members and lost or nonexistent documentation, bad actors can exploit those as they become more and more stagnant. Understanding what technologies, libraries and tools exist in your system allows an organization to guard against security breaches, while ensuring the system is not only evolving but remains evolvable.

Saying that you are going to refactor an architecture is tricky as it quite often means very different things for different people. Myself belong to the ISO 42010 architecture definition. During my work career I have not experienced any architecture refactoring/change that isn't a revolution. When you do architecture changes I see that it is very hard if not impossible to perform architecture changes in the ordinary organization but you need to do it in a separate organization. If not in a separate organization it might take 10-15 years to make the change. When taking so long time it often has surpassed the topics it intended to address.

Use a DevOps approach to software development and deployment. DevOps is a set of practices that combines software development with IT operations. This approach can help you to deploy software more quickly and reliably, and it can also help you to identify and fix problems more quickly.

Continuous improvement is ITIL 101. You already know this... Your users are your guides. Focus on the UX! Simple is almost always better. Until it's not. That's an exception. Make as few exceptions as possible. For scale...

Tines have changed! Evaluate your costs and needs! Cloud and subscriptions can do it all better faster and cheaper 😉 and remove the burdens of support and maintenence.

Keep up with the latest trends and technologies. New technologies can help you to improve the performance, security, and scalability of your system. It is important to stay up-to-date on the latest trends and technologies so that you can evaluate and adopt new technologies that are beneficial to your system.

Get feedback from your users. Ask your users for feedback on your system and how it can be improved. This feedback can help you to identify areas where your system falls short and make changes to improve the user experience.

Keep the system as modular as possible. It helps us to make the six steps mentioned here quite easily. Smaller and loosely coupled modules make it easy to test, refactor, and release periodically and continuously.

The most valuable thing to add is a list of factors that add risk to the system. Don't accept the epithet that we are good engineers and do not have risk. All systems have risk. System complexity is one of many factors that add risk to a system. I can give you more factors.

I believe that the elusive answer is “grounded” (Not an audio pun… much) in the GIGO model. In my 30+ yr experience, if a Designer is empowered to invest appropriately in the Client/ Partner’s vision, post-deployment support is always mutually efficient for ALL stakeholders.