What I’ve Learned About Systems Analysis

I am still trying to wrap my brain around complexity in systems. I’ve always considered complexity in terms of how many parts interact in a system. Since performing the systems analysis on the issue tracking system at work, I’m seeing that complexity is really more about relationships between things than it is about the number of things. Kind of like the old saying, “it isn’t so much the quantity (insert commodity that can be counted or measured here) as it is the quality…”

I’m reminded of a graybeard systems architect I was working with several years ago. I was in the process of diagramming a taxonomy of learning objects and he suggested I create an ERD. At the time I didn’t know what that was, so I turned to Google to get smart about ERDs. Ultimately I learned enough to develop a rudimentary Entity Relationship Diagram, and the process helped immensely as I conceived of a way to capture learning objects in a database.

So, I initially conceived of Task 1 as an analysis of the Gray Eagle UAV simulation training system. It didn’t take too long for me to recognize that the entire training system was a much more ambitious task than I had time or skill for. I spent a long time deciding what system to analyze and ultimately I determined to use the issue tracking system that is used as part of the software development process. It is a critical system, but it is limited in its complexity while also being fairly well documented, giving me a rich source of information upon which to base the initial system description. I think I learned that it is important to understand the scope and scale of a system before beginning to analyze it. Without that understanding, I think I would have been buried in detail. Thinking of systems as macro-, meso-, and micro-systems also helped me to identify various levels of systems that allowed for more efficient analysis.

I also discovered something interesting about systems and systems engineers in general. At my company, at least, many systems engineers are not familiar with actual systems analysis. I would say that generally, systems engineers are not skilled in analysis or even systems thinking as I understand it. There are systems architects in our organization, and I believe that they are much more familiar with the processes we’ve been discussing in class. One lead systems engineer I work with had never been an engineer at all. 15 years or so ago she was working as a quality analyst and was asked to support the systems engineer on a project. At the end of the project she continued to do the work and eventually became a systems engineer.

As a researcher I find that a systems approach helps me to think about complexity in a more practical way. I think that a better understanding of complexity, and how to recognize it, will be valuable as I begin to tease apart the research topics I’m interested in pursuing. I’m not sure how often I’ll diagram a system, but learning how to identify relationships between the entities has been very helpful and will certainly aid in my own research in the next two to three years.