Research in code and architectural analysis has demonstrated that a clear understanding of structural dependencies among software elements helps developers comprehend the impact of change. Yet examples are abundant from industry of major issues due to missed dependencies associated with different views of the architecture. Key concerns include dependencies related to allocation of modules to implementation packages to improve safety-critical testing and allocation of implementation packages to hardware partitions to optimize performance. In this paper, we present an in-depth study of a safety-critical system that underwent major changes as a result of missed architectural dependencies. We describe the challenges that resulted in re-architecting the system, the techniques we used for intervention, our results, and the developers' perspective. While the engineering tools provided coverage of design concerns, they missed implications of end-to-end integration testing, latency, and cost of change. In our study, we observed that the tools led the engineers to focus on data and control flow and therefore to miss many data-entity relationships, resource behavior, and deployment-related dependencies. Research continues to focus on more tooling and automation to assist with dependency analysis rather than interim, easier-to-adopt solutions. Our findings demonstrate that providing developers with a lightweight, semantically well-defined description of dependencies enables them to reason about change impact and propagation implications that they might otherwise overlook.