Steve Flanders (@smflanders) and I had a late-night Twitter conversation over the complexities inherent in cloud-native applications. My take was that we need to broaden our view and see the entire picture before we can delve into the weeds. Steve’s was that we need DevOps. I countered by saying we need better communication. In essence, we may have been saying the same thing, but we were on different planets, which led to a useful analogy. During the race to the moon, who were the systems engineers, the ones who saw the big picture of a program with well over 15 million moving parts, not to say people, involved?

Cloud-native applications can add complexity into the mix, whether it be about people, process, or developed code. To do this well, we do not need DevOps, but we do need communication. We also need a driver: someone or some group that can drive us to our end goal regardless of the hurdles we need to pass. For the Apollo program lunar missions, the ultimate driver was the President of the United States, and eventually his successor, as they were paying the bills; however, the real responsibility was put on the shoulders of NASA, and NASA placed the burden of systems engineering on the shoulders of its chosen astronauts.
One may argue that astronauts are operational folks, but in reality, the Apollo astronauts were not just the end users sitting on top of a roman candle of a complex system of machinery and people. They were also within the control room, and talking with the engineering teams working on each component. The astronauts were the systems engineers. They had to step back and see the big picture of how to get a human to the moon and back.
The operational folks were those in the control room in Houston and Cape Canaveral. They were not astronauts per se, but what the astronauts had to say to them had oomph behind it. The engineers were also involved with creating the systems the operational folks were going to use, the manuals placed within the craft, and the architecture and sometimes building of each component. Take the flight suit, designed by an engineer but built by people with nimble fingers with the ability to sew using different materials.
In addition, when it came time for Apollo 13 to come home, who was the one who came up with the proper boot sequence to save power? Yes, you got it: the systems engineer, with the help of quite a few people. No one is an island: they work as a team.
Now let us compare this to current deployment practices within many organizations, with a few questions:

  1. Is there a systems engineer who can see the big picture?
  2. Is there communication between the systems engineer and all the other players?
  3. Are there enough architects and designers?
  4. Is there communication between architects, designers, and systems engineers?
  5. Do the people who are doing the work know what they are doing and actually why they are doing it? (Consider the people sewing together space suits: they knew who they were for and why.)
  6. Is the environment so segmented that engineers, systems engineers, and operational folks cannot work together to solve a problem? (Consider how they got the capsule to boot after power-off.)

Today we call communication “DevOps.” I am not sure why we invented a new word to help us to communicate. Perhaps because the word “team” is overused? Today, I really call this “teamwork.” We need to have teamwork (note there is no “I” in “teamwork”) in order to succeed. In order to have a team, you have to have communication, give and take, an exchange of ideas. But most importantly, you need to have a goal in mind. That team cannot work toward an open-ended goal, but must have a goal in mind. That goal cannot be fluid, either, but must be pretty static. Yes, we know goals change—that today the world is seemingly fluid.
However, that is a role of system engineers as well: to take those seemingly fluid goals and make them something we can address and work toward. By knowing the system, they can subdivide tasks in such a way that if the system changes, work will not be lost. It really is tough to develop anything for a changing world, but if you take small enough steps, you get there. This is the reason for continuous integration and deployment. Small steps allow us to make small changes, which we do often enough to reach the end goal. Yet, we have simple goals that are attainable on that path. We break down the complexity to something understandable.
Where are you on the path? Do you have something so complex that it is hard to wrap your mind around it? Are you standing far enough back to see the big picture? Is it something you can divide up and conquer in pieces? Do you have help, communication, the give and take of ideas? If the goal is cloud-native applications, understand where you are and start moving in that direction, but make smaller changes—perhaps to code, perhaps to IT, perhaps to hardware.
These are requirements for the modern team, and modern teams should be breaking down the silos. Perhaps we can call that DevOps, but I still call it teamwork and the need for good communication. There are many stops along the way that can be taken as you work toward your ultimate goal. Those little stops remove the complexity from cloud-native applications.