Is the systems/software development life cycle still fit to describe the way teams build their applications? According to DevOps for Dummies author Emily Freeman, it’s time for something more current, which is why she presently tours the tech conference circuit to introduce the industry to a new “Revolutionary Model”.
Freeman’s Revolutionary Software Development Model is meant as a conversation starter and a challenger for the sequential software development life cycle (SDLC), variations of which many software engineers will be familiar with. The reason is quite simple: SDLC not only has its origins in the manufacturing of material goods — where roles are clearly defined — but also has been with systems engineers for almost sixty years now. Given the changes in software development in recent years, a model fit to “better reflect the actual nature of our work” and “the complexity of modern cloud native software development” seems to be due.
Key to that is the incorporation of a way to represent multiple processes happening in parallel — a reality in most organisations — instead of “only capturing pivotal moments during software development”. Freeman’s Revolutionary Model is therefore composed of five concentric circles describing “critical roles” in software development, which are then intersected by six spokes to symbolise production considerations engineers should take into account.
The critical roles are organised from architecting in the outer circle through developing, automating, and deploying to operating in the inner circle and are meant to give an alternative to a persona-based system. “Few people fit cleanly and completely into persona-based buckets like developers and operations anymore” Freeman argues at one point during her presentations, following up with the observation that personas are also dependent on the way people see themselves — which doesn’t always match up.
“Your work isn’t confined to a single set of skills — it may have been a decade ago, but it is not today. In any given week or sprint, you may play the role of an architect, thinking about how to design a feature or service, a developer, building out code or fixing a bug, an automation engineer, looking at how to improve manual processes we often refer to as toil, a release engineer, deploying code to different environments or releasing it to customers, or an operations engineer, ensuring an application functions in consistent, expected ways.”
All things considered
No matter what role a person plays in the software development process at any given day, however, they all have to consider the spokes of the Revolutionary Model (named that way because it is meant to revolve but also because it is challenging a 60-year-old artefact): testability, securability, reliability, observability, flexibility, and scalability. Some form of testing for instance is present in all disciplines, be it to ensure designs and code are working, infrastructure is configured correctly, or that changes won’t just bring down a system.
Besides general security concerns on all levels, the securability spoke looks to cover everything related to compliance and governance — mainly because they all have a factor of risk management in common (and adding more elements to the model would make it harder to grasp). Reliability in the model is meant to take into account anything that has to do with availability, latency, throughput, fidelity, and durability, while observability speaks to the need to produce systems that provide engineers involved with insights into its inner workings. This has been especially challenging to realise with the wider spread of distributed architectures and the integration of cloud resources and services, which is why it deserves special attention.
The last two spokes — flexibility and scalability — will surely conjure up mental images of cloud architectures for many, but Freeman does her best to highlight that these concerns are not just about being able to adapt to demand. In development, flexibility stands for code bases that are designed for expandability, partitioned by concern, and able to absorb new code smoothly, while from a systems perspective it means change dependencies are reduced or eliminated, database schemas accommodate change well, and components communicate via a standardized and well-documented API.
Scalability on the other hand “implies growth” according to Freeman, who currently works as a Head of DevOps Product Marketing at AWS. “It requires each of us in our various roles to consider everyone around us. Our customers who use the system or rely on IT services, our colleagues, current and future with whom we collaborate, and even our future selves.”
Translating models into practices
Of course Freeman isn’t the first to call out shortcomings in the SDLC as anyone who ever dove into agile models and paradigms might be able to attest. In fact, extreme programming and the spiral model are named as some of the main inspirations behind the proposal at hand. However, it doesn’t seem to convey ideas about processes in quite the same way and leans more towards pointing out responsibilities instead. At first looks, the RM therefore feels somewhat closer related to DevOps principles, which Freeman feels are “an increasingly outmoded solution to a previous problem” given that the challenges developers face have grown more complex since their first introduction.
Engineers who are now interested in how the new model can be used in practice need to exercise some patience still, since Freeman is currently working on creating examples for just that. First feedback saw developers warming up to the notion of turning the model into a radar chart to analyse a project’s current state and prioritise next steps accordingly. Freeman however also encouraged others to weigh in to turn the model into a useful engineering tool. “I really want it to morph and evolve as more folks get eyes on it. This is just the start. It’s not my model, it’s our model.”