The first is testability. All software systems require testing to assure architects that designs work. Developers the code works. Operators, the infrastructure is running as expected and engineers of all disciplines like code changes won't bring down the system.
Testing in its many forms is what enables systems to be durable and have longevity. It's that layer of reassurance that changes won't impact current functionality. Security is everyone's responsibility, but I would argue few understand how to design and execute secure systems. This is an area of growth for me. I struggle with it. Security is something that we know we should dedicate time to, but we don't often make time for. And let's be honest, it's complicated and hard, and even the language around security, and the jargon is different. It is absolutely critical that applications and services work as expected for the vast majority of the time. That said, availability is often used as a synonym for reliability, and it's not the case. It's a single aspect of the concept. If a system is available, the customer data is inaccurate or out of sync, the system is not reliable. Reliability may be that in result, but for me, resiliency is the journey. The action the developers and engineers can take to improve reliability.
Observability is the ability to have insight into an application or a system. It's that combination of telemetry and monitoring and alerting available to us as engineers. There's an aspect of observability that overlaps with reliability, which is why their neighbors. But the purpose of observability isn't just to maintain a reliable system.
The concept actually originates in linear dynamic systems and is defined as how well the internal states of a system can be understood based on the information about its external outputs. Flexible systems are capable of adapting to the ever-changing needs of the customer and the market segment. Flexible code bases absorb new code smoothly. They embody a clean separation of concerns, and they're partitioned into small components. Flexible systems are architected to enable the now as well as the next. In these systems, chain dependencies are reduced or eliminated. Database schemas accommodate change well and components communicate via an API.
In our work, I would argue the only thing constant is change. And in every role we play, creating a flexible solution that grows as the application grows is critical. Scalability. This refers to more than a system's ability to scale for additional load and implies growth, a system's ability to grow over time. Scalability in the Revolution model carries the continuous innovation of a team and the byproducts of the growth within that system.
It also is the consideration that carries the human aspect of our systems, and requires each of us in our various roles, to consider everyone around us. Our customers, of course, who use the system, our colleagues, current and future, even ourselves.
Comments are closed.