Software engineers tend to document their systems’ architectures sporadically and superficially. Additionally, engineers frequently neglect to carefully consider the architectural impact of their changes to a system’s implementation. As a result, an existing system’s architecture will over time deviate from the engineers’ intent, and it will decay through unplanned introduction of new and/or invalidation of existing design decisions. Technical debt accumulates through architectural decay, increasing the cost of making modifications to a system and decreasing the system’s dependability. In this talk, I will introduce ARCADE, an integrated collection of tools for isolating three types of architectural information from the details readily available about a system’s implementation: architectural design decisions, change, and decay. I will show how ARCADE uses this information to identify the locations in a software system’s implementation that reflect the architectural decay, the points in a system’s lifetime when that decay tends to occur, and the reasons why it occurs. I will show how architectural decay tends to correlate with the occurrence of commonly reported implementation-level issues, and how it can be predicted. Finally, I will identify steps that engineers can take to manage the accumulated technical debt by stemming the decay. Data obtained by analyzing dozens of versions of several well-known systems - Android, Hadoop, Cassandra, Struts, etc. - will be used to illustrate the discussion throughout.