A Brief Introduction to the DSRP Approach From An Amateur

Systems thinking is a tool and a practice for better understanding and modeling the world around us. It is especially well suited to dealing with complex adaptive systems, which are systems with a lot of interconnected parts and that adapt or change in response to their environment or input. Ecosystems, organizations, and the human body are all complex adaptive systems. While there could certainly be poor system decompositions (based on a flawed understanding), there isn’t a canonically right one. A system that you can explain is a system that you are better prepared to modify and test, which is core to the work I’m doing on Scrimmage.

DSRP stands for Distinctions, Systems, Relationships, and Perspectives. According to the DSRP method, these are the four fundamental patterns that can be used to model anything in or about the world, at any scale. There are alternative perspectives, but this seems like a serviceable framework to start with.

Distinction (identity vs. other)
Name the system and its parts. This tells us what is within the system and, just as importantly, what might be outside the boundary of the system. Consider an org chart. A technology company may have an Engineering Department, a Marketing Department, and a Finance Department (among others). These departments are distinct parts of the company.

Relationships (action vs. reaction)
A system is defined by the relationships between its components. The engineering department works with marketing to define and products. The finance department sets departmental budgets.

Systems (whole vs. part)
Every part is a whole, and every whole is a part. That technology company is made up of the departments. Each department is made up of individuals, teams, and/or projects. There isn’t a single right way to decompose system into its parts. The right way is dependent on the what you are looking to learn from the model and the perspective you take.

Perspectives (point vs. view)
There is no universal perspective. Any perspective you take will bring its own implicit and explicit biases into the system. For the organization example, this is the perspective that someone in HR or operations may take. It is focused on reporting or management lines. The perspective of someone with a focus on product could slice it into cross-functional teams around the products they support.

What’s the point?
An organization chart is not a terribly complex model, but an company is a complex system. Building models like this allow us to interrogate and deepen our understanding of the underlying system, as well as prepare us to diagnose issues or suggest ways to modify the system to improve its operation.

Fighting for Perspectives in Software Development

For me, perspectives is the hardest part of the method to apply consistently. As a software engineer, I’m used to breaking apart systems and modeling the components and relationships. That is foundational to the object oriented programming model that was used for much of my career. I started my career at a large company doing small tasks. Those tasks were often accompanied by “DSR”-type requirements, like entity relationship diagrams and state diagrams. The only perspective I considered was my own, as a stand in for the ‘system’.

As I gained more responsibility, my view into the process grew. I started dealing with systems architecture, a larger, cross-functional team, and customers. The designers introduced me to user stories and personas, which provide perspectives of various customers. The systems architecture required me to consider other internal perspectives: the infrastructure team, the product manager, and the frontend vs. the backend team, etc.

It is very easy for me to fall back into those early methods and design systems that incompletely consider multiple perspectives, especially if I consider the system “just a piece of software”. That’s a silly and reductive statement that I should know better than to ever think. We don’t build software for the sake of building software. We build software to solve problems. We better consider the perspective of the problem holder.

The Lean Startup, Design Sprint, and Minimum Viable Product movements as ways to (re-)establish the importance of understanding perspective in software or product development. When done right, they force the developer to broaden beyond their own perspective. This is a fairly simplistic application of perspective, but it starts the conversation.

Ideally, we’d be considering more than the customers’ perspectives. What is the economic perspective? The socio-cultural perspective? The environmental perspective of the work we are doing?